Token RPL

Questa pagina serve a capire che cosa sia un token su questa chain prima di crearne, elencarne o indicizzarne uno. RPL è lo standard di token di Rand, nuovo con la chain 14. Un token è un asset nativo schermato: una voce in un registro del ledger, con i saldi detenuti come note ordinarie nello stesso albero degli impegni che usa RAND. Non è un contratto. Per crearne uno passo dopo passo, vedi Deploy an RPL token.

Il motivo è strutturale. Una Call scrive soltanto una ricevuta, quindi un contratto in stile ERC-20 non aveva dove conservare un saldo, e una tabella pubblica dei saldi renderebbe i token l’unico asset trasparente di una chain schermata. RPL fa invece di un token un oggetto di prima classe del ledger. La chain 20 aggiunge RPL-2 (v0.6.8): un programma può mantenere celle di stato pubbliche e un vault pubblico, e può essere l’autorità di mint di un token proprio (sotto); i saldi detenuti dalle persone restano note.

Un token è una voce di registro

TokenRegistry (crates/randprotocol-core/src/ledger/tokens.rs) è una tabella unica condivisa da ogni token, nativo o con bridge. È lo stesso registro attraverso cui il bridge risolve l’indice di un asset. Ogni voce:

I decimali si fermano a 9 perché gli importi sono u64: con 18 decimali un u64 contiene solo 18,4 token interi, e 9 è la precisione propria di RAND. Un token con bridge si registra sempre con 8 decimali, qualunque sia la precisione delle monete di origine.

Il registro si attiva con una sezione tokens nel file di genesis, come bridge e aggregation con le loro. Senza di essa ogni azione sui token viene rifiutata prima di qualsiasi altro controllo (TokenError::Disabled). Il genesis della chain 20 ha la sezione ed elenca un token, zUSD, con i suoi sette backing, riportato dalla chain 14 attraverso ogni cut successivo; ogni altro token sulla chain arriva tramite transazione. (Il genesis della chain 14 non ne elencava alcuno.) Con il gate attivo, un tokens_root (la radice merkle delle foglie blake3("rand-token-leaf-1", bincode(TokenInfo)) in ordine di indice) confluisce nella state root. Il dominio della radice è rand-state-4 su una chain senza nulla di successivo attivato; la radice della chain 20 include anche lo stato del faucet e della bond-queue, i prezzi del gas in vigore e la radice dello stato dei programmi, con hash sotto rand-state-8, ed è avvolta ancora una volta dall’insieme dei validator ammessi (Consensus).

Una chain con una sezione tokens richiede inoltre che ogni nota alloc del genesis porti la propria apertura (pk, time, r); il nodo ricalcola l’impegno e rifiuta un file che non corrisponde. L’impegno è all’asset 0, a meno che l’apertura non nomini l’indice di un token elencato dallo stesso genesis — la chain 20 ha due note di questo tipo, 10 e 89 zUSD all’indice 1 — e, per ogni token elencato, le note del genesis devono sommare a quanto i suoi backing hanno all’avvio come locked. Una volta che una nota ha una parola asset in grado di nominare un token, un impegno di genesis non aperto sarebbe l’unico modo per immettere nel pool, senza controllo, una nota priva di copertura di qualsiasi asset.

Id dell’asset, indice e rpl1…

Un token ha due nomi, e l’RPC fornisce entrambi.

• L’id dell’asset è di 32 byte, indirizzato per contenuto come l’id di un programma. L’id di un token nativo è blake3("rand-rpl-asset", bincode(name, symbol, decimals, authority, initial, salt)), dove salt è un valore di 32 byte scelto dal creatore e initial è l’intero mint iniziale, se presente. L’id di un token con bridge è blake3("rand-rpl-asset", bincode(name, symbol, 8, salt)). Registrare un id già esistente viene rifiutato (TokenError::AlreadyRegistered).
• L’indice è ciò che una nota porta effettivamente, perché un id di 32 byte non entra in una sola parola. È una scorciatoia che ha significato soltanto su questa chain.
• La forma testuale rpl1… è bech32m (BIP-350) con parte leggibile rpl sui 32 byte dell’id: 52 caratteri di dati e un checksum di 6 caratteri, 62 caratteri in tutto. Viene mostrata accanto all’id di 64 caratteri esadecimali ovunque un token sia nominato ed è accettata ovunque se ne faccia la ricerca; l’esadecimale resta accettato. L’analisi è rigorosa: un checksum errato, un prefisso sbagliato, un payload che non sia esattamente di 32 byte o maiuscole e minuscole miste vengono rifiutati, così un errore di battitura non può risolversi in un token diverso.

I simboli non sono univoci. Come con ERC-20 e SPL, l’identità di un token è il suo id dell’asset, mai il nome o il ticker.

Il vecchio valore per (chain, token) che rand_bridgeAssetId calcola e che rand_getAssets stampa per ogni riga di backing è un identificatore più ristretto, per il formato di trasmissione del bridge, non l’id proprio del token.

Autorità di mint

Una RegisterToken che nomina Bridge viene rifiutata (TokenError::AuthorityNotAllowed), così come una che nomina Program con un mint iniziale o su una chain senza program_state. Un’autorità Key è esattamente una chiave pubblica Dilithium2: una chiave di qualsiasi altra lunghezza in byte viene rifiutata (TokenError::BadAuthorityKey), e la chiave ML-KEM del destinatario in un mint è vincolata alla propria lunghezza allo stesso modo. Entrambe sono stato di consenso o spazio di blocco acquistato a una tariffa fissa, quindi nessuna delle due può essere arbitrariamente grande.

Creare un token

La creazione è senza permessi. Action::RegisterToken { name, symbol, decimals, authority, initial, salt, index } viaggia su un ordinario fee bundle in RAND e paga BUNDLE_BASE più la registration_fee del registro. La commissione di registrazione è un parametro di genesis compreso tra 1 RAND e 10.000 RAND, così un token di spam ha sempre un costo. Sulla chain 20 è 1 RAND, quindi una registrazione costa 1,001 RAND, e la chain 20 la brucia, come ogni chain dalla 15 in poi: il proposer trattiene solo la base del bundle (sotto).

index nomina l’indice di registro per il quale il creatore ha sigillato la nota iniziale. Se un’altra registrazione ha preso prima quell’indice, la transazione viene rifiutata (TokenError::IndexMismatch) invece di lasciare la nota bloccata; il creatore genera di nuovo la prova per l’indice successivo.

La nota coniata è calcolata dalla chain, non scelta da chi invia: note_commitment(recipient.pk, MINT_FROM, amount, index, time, r). L’importo e la pk del destinatario sono pubblici nel formato di trasmissione, quindi il destinatario può ricostruire la nota dai campi della transazione stessa anche se la busta sigillata è spazzatura. Un deposito via bridge ha la stessa difesa.

Perché l’id vincola l’intero mint iniziale

Una RegisterToken non è firmata. Il binding della transazione impedisce che una copia con prova venga alterata, ma non dice nulla su ciò che una copia nuova può nominare. Se l’id coprisse solo l’importo iniziale, chi osserva una registrazione in sospeso potrebbe inviarne una copia con un destinatario diverso, registrarla con lo stesso id e prendersi l’intera offerta di un token a offerta fissa facendo il commit per primo. Poiché l’id copre l’intero mint iniziale (importo, destinatario, r, time e busta), una copia reindirizzata produce un hash con un id dell’asset diverso: un token diverso con lo stesso simbolo, cosa che un simbolo non univoco già consente. L’originale approda comunque all’indice successivo al costo di una nuova prova.

I trasferimenti sono lo stesso bundle di RAND

Dalla chain 14 ogni transazione che sposta valore porta esattamente un bundle, la forma fissa a 4 ingressi e 4 uscite con asset nascosto (Transactions and actions). Gli slot 0–1 portano un asset privato, RAND o un qualsiasi token RPL, e il circuito non viene mai a sapere quale. Gli slot 2–3 portano sempre RAND. Un trasferimento di qualsiasi asset è Action::None, l’azione che usa un semplice pagamento in RAND. Non esiste un’azione di trasferimento di token né un campo pubblico che nomini il token.

Ciò che un osservatore vede in un trasferimento di token è esattamente ciò che pubblica un pagamento in RAND: un anchor, quattro nullifier, quattro commitment, la fee in RAND, burn_a = burn_r = burn_asset = 0, un time, quattro cifrati di envelope e la prova del bundle. Dalla chain 17 (autorizzazione separata) ogni bundle porta anche un auth_commit e una seconda prova di autorizzazione, più piccola, identica per ogni asset. Sulla chain 20 ogni envelope è lungo esattamente 1.860 byte e ha spazio per un memo cifrato (rand send --memo), che ne venga inviato uno o no. Non vede il mittente, il destinatario, l’importo, quale asset si è mosso, quali slot erano dummy né il resto.

Il wallet spende fino a due note del token negli slot 0–1 e fino a due note RAND negli slot 2–3 per la commissione. La commissione è sempre in RAND, perciò chi detiene un token senza RAND viene rifiutato prima della prova. Il costo è lo stesso di un pagamento in RAND (Commissioni). Sulla chain 20 sono due prove STARK generate sulla macchina del mittente: l’autorizzazione della spesa (tier 10, circa 7 s, circa 1,37 MB) e il bundle (tier 14, circa 100 s, circa 1,5 MB), circa 2,85 MB in totale sulla rete. Ciascuna è sotto il limite di 4 MiB per prova fissato dalla chain. Prima della chain 17 un trasferimento portava la sola prova del bundle, circa 1,42 MB come misurato allora.

Conio e autorità

TokenMint { asset, amount, recipient, r, time, envelope, nonce, signature } conia altro token autorizzato da una Key. SetAuthority { asset, new, nonce, signature } cede l’autorità a un’altra chiave, oppure vi rinuncia quando new è assente; dopo una rinuncia nessuna chiave potrà più coniare il token. Entrambe le azioni su un token la cui autorità non sia Key vengono rifiutate (TokenError::NotKeyAuthority).

L’autorità firma blake3("rand-rpl-mint-1" | "rand-rpl-authority-1", chain_id ‖ asset_id ‖ nonce ‖ body). Il nonce deve essere uguale al mint_nonce del token, che poi viene incrementato, così un conio firmato non può essere riproposto su questa chain né trasferito a un’altra. Il body di un conio include il digest dell’envelope: il solo commitment non lo copre, e senza il digest un terzo potrebbe reincapsulare un conio diffuso via gossip con un envelope spazzatura e consumare il nonce.

Entrambe le azioni viaggiano su un bundle di commissione in RAND che paga BUNDLE_BASE. Il wallet che paga la commissione e la chiave che autorizza il conio sono distinti e possono appartenere a persone diverse.

Bruciatura

Action::TokenBurn { asset, amount } viaggia nello stesso bundle unico: il burn_asset del bundle deve essere uguale ad asset, burn_a deve essere uguale ad amount e burn_r è 0. Il token esce dal pool attraverso gli slot dell’asset e la commissione in RAND attraverso gli slot 2–3 della stessa prova. total_supply diminuisce esattamente di amount. Un token con autorità Bridge qui viene rifiutato (TokenError::BridgedToken); esce tramite una bruciatura del bridge.

Commissioni

Ogni azione RPL paga in RAND.

Il genesis della chain 20 ha una sezione gas, che prezza soltanto le chiamate e le invocazioni di programmi. Queste soglie sono fisse: nessuna azione RPL paga a gas o a byte.

Che cosa è pubblico e che cosa è nascosto

total_supply è dunque sempre verificabile: è ciò che la registrazione e ogni conio hanno aggiunto, meno ogni bruciatura. Un trasferimento tra detentori non rivela nulla, nemmeno che a passare di mano sia stato un token anziché RAND.

La divulgazione funziona come per RAND. Il testo in chiaro della nota contiene l’asset, perciò una chiave per transazione (rand tx-key <hash>) o una viewing key apre una nota di token esattamente come ne apre una in RAND, e rand_checkTransaction e rand_getViewingNotes restituiscono asset nella nota che divulgano. Data una tale chiave, randscan risolve l’indice rispetto al registro e mostra il trasferimento come il token indicato per nome; la pagina pubblica della stessa transazione non ne mostra nulla.

Token con bridge

Un token con autorità Bridge è comunque un token RPL: la stessa voce di registro, lo stesso trasferimento nascosto, la stessa meccanica di bruciatura. La sua offerta si muove solo attraverso un blocco su una chain di origine (BridgeAttest) o un rilascio (BridgeBurn). Un token con bridge può avere molti backing, ciascuno una coppia (chain, token) con i propri decimali di origine, importo bloccato e tetto di conio, e total_supply è sempre uguale alla somma di ciò che i suoi backing hanno bloccato. Un token con bridge viene registrato, e un backing aggiunto, solo con il quorum dei guardiani post-quantistici del bridge.

Sulla chain 20 il primo token del registro è zUSD («Shielded USD»), indice 1, 8 decimali, elencato nel file di genesis con sette backing (USDT e USDC su Ethereum, Binance Smart Chain e Solana, e USDT su Tron). Mantiene l’id d’asset che aveva sulla chain 14, dove fu registrato con una transazione all’altezza 256: le chain dalla 15 alla 20 lo elencano ciascuna nel genesis con lo stesso nome, simbolo e salt. Ha iniziato la chain 20 con 99 zUSD in due note di genesis (10 e 89), garantiti da 22 USDT bloccati su Ethereum, 22 su Binance Smart Chain, 30 su Tron e 25 su Solana, riportati dallo stato del bridge della chain 19. La chain 19 era partita con 10 zUSD, garantiti da 10 USDT su Solana; la chain 18 con 9 USDT bloccati su Tron e 1 su Solana. La sua offerta totale è uguale a ciò che i suoi backing hanno bloccato e si muove a ogni deposito e riscatto. Il suo id è rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx. Bridge tratta backing, unità di rilascio, tetti di conio, la pausa e la cofirma.

zUSD è un paniere, non sette crediti separati. I suoi backing sono messi in comune al valore nominale, quindi un detentore sopporta il rischio di ogni backing elencato, non solo della moneta che ha depositato: un backing che ha perso l’ancoraggio può essere depositato alla pari e gli zUSD bruciati verso un backing solido, finché quelli solidi non sono esauriti. A limitare la perdita sono la finestra di conio mobile (sulla chain 20, 4.000 zUSD su tutti i backing per 24 ore, oltre a 100.000 per backing) e la custodia effettivamente bloccata. La finestra limita il ritmo e dà il tempo di mettere in pausa i conii. Non pone un tetto al totale. Un backing viene elencato solo con il quorum dei guardiani post-quantistici, e non mentre i conii sono in pausa.

Le commissioni del bridge, in zUSD (chain 20). Il genesis della chain 20 imposta bridge.fees: 10 bps su un deposito e 10 bps su una bruciatura, ciascuna arrotondata per difetto a un’intera unità di rilascio del backing (100 unità di base per un USDT a 6 decimali), pagate come nota zUSD a un indirizzo di tesoreria indicato dal genesis (v0.6.8, fullnode docs/bridge.md §25). Un deposito di g aggiunge due note: quella del depositante, g − fee, e quella della tesoreria, fee; 1 USDT in ingresso sono 0,999 zUSD al depositante. Una bruciatura di amount trattiene fee come nota della tesoreria e rilascia amount − fee sulla chain di origine; i guardiani firmano quell’importo di rilascio, e rand_getBridgeBurn restituisce amount, release_amount e fee. Una nota di commissione è emessa e garantita, quindi total_supply resta uguale alla somma dei locked dei backing: un deposito sposta entrambi di g, una bruciatura abbassa entrambi di amount − fee. Una nota di commissione non ha envelope. Ogni suo elemento è pubblico (l’importo dalla transazione e dall’aliquota del genesis, l’asset e il time, un blinding derivato dal digest dell’attestazione o dall’id della transazione della bruciatura, il proprietario dal genesis), perciò il wallet della tesoreria la ricostruisce dai campi pubblici (Note). BRIDGE_BURN_FEE, i 0.01 RAND che una bruciatura paga al proposer, resta invariata. Le chain dalla 14 alla 19 non avevano commissioni di bridge su Rand.

Il registro dalla chain 15

Dalla chain 15 il genesis attiva tre regole del registro che la chain 14 non aveva, e il genesis della chain 20 imposta gli stessi tre valori. Ciascuna è vincolata all’hash del genesis e alla radice dei token.

Il limite sul valore delle note esiste perché il circuito del bundle verifica con un range check che ogni importo stia entro 63 bit: una nota di valore pari o superiore a 2^63 potrebbe essere vincolata da un impegno ma mai spesa, pur continuando a contare nella supply del token. Ogni nodo rifiuta inoltre un simile importo all’ammissione su qualsiasi chain, qualunque cosa dica il suo genesis.

RPC e CLI

Ogni importo in questi risultati (total_supply, registration_fee, il locked di un backing, mint_cap_per_day e minted_today) è una stringa decimale, perché un numero JSON non è esatto oltre 2⁵³. index, next_index, mint_day e max_tokens sono interi semplici (max_tokens è null su una chain senza limite); burn_registration_fee e bound_note_value sono booleani. Il campo authority di una riga è {"kind":"none"}, {"kind":"key","key","address"}, {"kind":"bridge","backings":[…]} oppure {"kind":"program","program"}. Il dettaglio completo è in JSON-RPC.

Privacy. rand_getTokens costa lo stesso quale che sia il token a cui pensa chi chiama. rand_getToken e rand_getTokenSupply indicano al nodo a quale token è interessato chi chiama: va bene per un explorer, è sbagliato per un wallet che sta per inviare. Il wallet risolve quindi ogni --asset a partire dall’elenco completo, e un indice numerico non raggiunge mai il nodo.

Dalla v0.5.10 gli importi di rand send --asset, rand token mint e rand token burn sono espressi nelle unità di visualizzazione del token, lette secondo i decimals della riga di registro del token stesso: 1.5 di un token a 6 decimali equivale a 1.500.000 della sua unità minima, e un numero di cifre frazionarie superiore a quello del token viene rifiutato. La conferma di send stampa entrambi (1.500000 USDX (1500000 units)). Le opzioni --fixed-supply e --initial di rand token create accettano ancora unità minime intere, così come rand bridge-burn, e rand asset-balance stampa in unità minime. On chain l’importo è sempre l’intero espresso nell’unità minima. Opzioni e valori predefiniti sono in Command line.

Differenze rispetto a ERC-20 e SPL

Limiti noti

• Nessuna allowance. approve e transferFrom sono previsti nella specifica RPL come account di allowance vincolati e non sono stati realizzati.
• Le disponibilità di un programma sono pubbliche. Su chain 20 un programma può detenere token nel proprio vault ed emettere un token proprio (RPL-2), ma il saldo di un vault è pubblico, come la supply di un token; solo le note sono private. Le chain precedenti alla 20 non avevano alcuno stato di programma.
• Le commissioni sono solo in RAND. Un token non può pagare la propria commissione; un wallet che possiede solo token non può muoversi.
• Importi u64 e al massimo 9 decimali. Una coin di origine a 18 decimali è rappresentata con precisione inferiore; il bridge risolve la questione con 8 decimali e un’unità di rilascio per backing.
• Ogni trasferimento è dimostrato. Circa 100 s e diversi GB di memoria sulla macchina del mittente; per un token non esiste un percorso più economico che per RAND.
• Nessun freeze, blacklist o pausa su un token nativo, per decisione. La pausa di mint del bridge si applica solo ai mint bridged.
• Le ricerche per singolo token rivelano interesse. rand_getToken, rand_getTokenSupply e /tokens/:id dell’explorer indicano al server su quale token è stata fatta la richiesta.