Mint e burn

Usa questa pagina per eseguire un faucet su una test chain, per capire che cos’è una transazione Mint sul wire e per vedere esattamente come un bond o un burn di bridge porta il valore fuori dal pool. Ogni ingresso e ogni uscita è pubblico; tutto ciò che sta in mezzo è una nota.

Il mint del faucet

Un Mint è l’unico modo in cui RAND viene creato dopo il genesis sulla chain 20, ed esiste solo sulle chain il cui genesis riporta "faucet": true. È una transazione firmata da un validatore e priva di bundle:

Action::Mint { cm: Word8, pk: Word8, time: u32, r: Word8, envelope: Envelope, amount: u64,
               minter: PublicKey, signature: Signature }

rand_mint(address[, amount]) su un nodo validatore costruisce una nota di amount verso l’indirizzo rand1… indicato, sigilla il suo envelope con una chiave mittente usa e getta, firma il mint con la chiave Dilithium2 del nodo stesso e lo invia attraverso la normale mempool: così il mint passa per il consenso e ogni nodo lo applica. Il limite è 100000000000 unità, cioè 100 RAND, per chiamata, e il valore predefinito è il limite. Dalla chain 14 il mint porta con sé l’apertura della nota (pk, time e r) e la firma la copre: l’ammissione ricalcola l’impegno di (pk, no sender, amount, asset 0, time, r) e rifiuta un cm che non corrisponde con the mint's commitment does not open to its published note and amount, e vincola time alla finestra del bundle. I parametri di rand_mint sono invariati. Il messaggio firmato è blake3("rand-mint-2" ‖ bincode(chain_id, cm, pk, time, r, envelope, amount)) sulle chain da 14 a 19; sulla chain 20, il cui genesis imposta binding_domain: 1, è rand-mint-3 calcolato sull’hash del genesis seguito dagli stessi campi, per cui un mint firmato per una chain viene rifiutato su qualsiasi altra, anche una che condivida l’id della chain e le chiavi dei validatori. Un osservatore non ha una chiave di validatore e risponde faucet mints are signed by validators; ask a validator node; una chain senza il flag risponde faucet is disabled on this chain.

Il faucet della chain 20 è attivo ma limitato dalla sezione staking del suo genesis, con gli stessi valori della chain 19:

Quindi rand faucet sulla chain 20 funziona solo per un wallet presente nella lista, richiesto a un nodo validatore la cui chiave sia un minter elencato; qualsiasi altro indirizzo deve essere pagato da chi detiene RAND.

rand faucet                          # 100 RAND to this wallet's address, waits for the commit
rand faucet rand1… --amount 25       # to another address, less than the cap

→ {"method":"rand_mint","params":["rand1…", "100000000000"]}
← "9ab1c0…4f"

Ciò che è pubblico: l’impegno della nuova nota, il suo envelope, l’importo in chiaro, e la chiave pubblica del validatore che ha emesso il mint (mostrata come indirizzo) con la sua firma. L’apertura pubblica anche la chiave proprietaria della nota pk, quindi il proprietario di una nota del faucet è pubblico, come lo è il pagamento di un withdraw; ciò che resta nascosto è quando e dove quella nota viene spesa in seguito. Il collegamento a un solo passo tra «sono stati emessi 100 RAND» e «esiste una nota da 100 RAND» è la stessa visibilità che ha ovunque un deposito da trasparente a schermato. L’ammissione verifica che il faucet sia abilitato, che l’importo sia sotto il limite, che il budget dell’epoca abbia margine, che il destinatario sia nella allowlist dove il genesis ne prevede una, che l’impegno si apra sulla nota pubblicata, che il minter sia un validatore (e compaia nella lista dei minter dove il genesis ne prevede una) e che la firma sia valida; un mint non paga alcuna commissione.

rand_getTransaction ne restituisce una come { "kind": "mint", "cm": "…", "amount": "100000000000", "minter": "<validator base58>" } con "bundle": null: l’importo è una stringa decimale, come ogni importo u64 che l’RPC serve dalla chain 14; l’explorer li elenca sotto kind=mint, uno dei pochi tipi con un amount pubblico.

Depositi del genesis

L’altro modo in cui entra valore è il file di genesis: ogni --alloc rand1<address>=<RAND> passato a rand-node genesis diventa una nota di deposito { cm, envelope, amount, opening } con casualità dell’impegno nuova, le prime foglie dell’albero. La chain 20 ha nove note di genesis: sette note RAND, 5,184.243719258 RAND in tutto (genesis_deposited), i saldi degli operatori riportati da uno snapshot della chain 19, e due note zUSD da 10 e 89 zUSD, i 99 zUSD di custodia del bridge riportati dalla chain 19 (Bridge), che non sono RAND e non rientrano in genesis_deposited. I RAND detenuti sulla chain 19 da wallet che l’operatore non controlla, circa 520 RAND, e le commissioni dei validatori non ritirate non sono stati riportati. Storico: la chain 19 ne aveva otto, sette note RAND per 5,294.644359629 RAND e una da 10 zUSD; la chain 18 aveva sei note RAND, cinque da 1,000 RAND e una da 300 RAND; le chain 14 e 15 ne avevano cinque da 1,000 RAND. L’importo è pubblico in modo che tutti possano sommare l’offerta iniziale, e dalla chain 14 la nota porta anche la sua apertura, quindi il proprietario di una nota di genesis è pubblico per progetto. Ricreare le stesse allocazioni produce note diverse e un hash di genesis diverso, di proposito.

Burn

Ogni transazione porta un bundle di asset nascosti a quattro slot, e questo ha due parole di burn: burn_r è RAND che lascia il pool verso un luogo pubblico, e burn_a è un importo del token indicato da burn_asset. La guest del bundle bilancia entrambi i gruppi in una sola prova, e l’ammissione richiede che tutti e tre siano zero tranne in queste azioni:

(Anche il bundle di un register_aggregator brucia il suo bond di genesis tramite burn_r; l’aggregazione è disattivata sulla chain 20.)

I burn non sono commissioni. Il burn di un bond è RAND che passa dal pool al register ed è contato nel burned dell’audit dell’offerta (e ricompare in register_total). Un burn di bridge è un solo bundle dalla chain 14 (prima erano due): gli slot 0–1 bruciano l’asset bridged e gli slot 2–3 pagano la commissione, così tocca l’offerta di RAND solo attraverso quella commissione, BRIDGE_BURN_FEE, 0.01 RAND. Deve indicare una moneta che sostenga l’asset, rilasciare un numero intero di unità di quella moneta ed entrare in ciò che quel sostegno ha bloccato (Bridge). Sulla chain 20 il suo bridge.fees di genesis preleva inoltre 10 bps su ogni mint e burn bridged in zUSD: un deposito accredita il lordo meno la commissione e un burn rilascia amount − fee, ogni commissione essendo una nota zUSD schermata alla tesoreria. La nota di commissione resta emessa e garantita, quindi total_supply == Σ locked di zUSD continua a valere; non è un movimento di RAND e non entra nell’audit dell’offerta di RAND. Un TokenBurn paga la base del bundle di 0.001 RAND; un token bridged vi viene rifiutato ed esce tramite bridge-burn.

Una commissione è anch’essa un burn sulla chain 20, come su ogni chain dalla 15: il suo genesis imposta tokens.burn_registration_fee, così la registration_fee di 1 RAND di un RegisterToken o RegisterBridgedToken viene distrutta invece di essere pagata al proposer, che trattiene solo la base del bundle. È contata in burned e, separatamente, in registration_fees_burned (RPL tokens).

rand bond <validator> 1000 [--registration <hex>]     # burns 1000 RAND out of this wallet's notes
rand bridge-burn <ASSET> <AMOUNT> <TO_CHAIN> <TOKEN> <TO>   # burns AMOUNT of a bridged asset, released as TOKEN on TO_CHAIN
rand token burn <ASSET> <AMOUNT>                      # destroys AMOUNT of an RPL token this wallet holds

Le commissioni sono l’altra uscita

La fee di ogni bundle lascia il pool verso i rewards del proposer del blocco, un campo pubblico del register, e rientra nel pool solo quando il validatore la ritira come nota (Staking). Un Withdraw paga la base di 0.001 RAND, prelevata dall’importo ritirato, al proposer del blocco che lo applica; quella base non lascia mai il register, quindi non è un attraversamento.

Come si muove l’offerta

in:   genesis_deposited, faucet_minted, withdraw_deposited, program_rand_out
out:  fees_paid, burned
pool_value     = in − out
total_supply   = pool_value + Σ register (stake + pending + rewards) + program_rand_held
               ==  genesis_deposited + genesis_staked + faucet_minted − slashed − registration_fees_burned

program_rand_held e program_rand_out sono nuovi sulla chain 20 (RPL-2): il RAND che un Invoke brucia in un vault di programma tramite burn_r è contato in burned sul lato del pool e detenuto nel vault, e ciò che un vault paga come note rientra nel pool. rand_getSupply serve entrambi, insieme a invariant_holds.

Solo un mint del faucet aumenta ciò che la catena ha emesso, e sulla chain 20 solo una commissione di registrazione bruciata lo riduce: slashed conterebbe un bond di aggregator sottoposto a slashing o, in base a una sezione genesis staking.slashing, uno stake di validator sottoposto a slashing, e la chain 20 non ha né l’uno né l’altro (l’aggregazione è disattivata e slashing è null). Un bond, una commissione, un prelievo e un deposito in un vault spostano valore tra il pool, il registro e i vault, e non creano nulla. Supply riporta i contatori e un esempio svolto. Il sussidio di aggregazione dei blocchi — nuovi RAND per ogni blocco sigillato secondo un programma di dimezzamento, pagati a un aggregator come note di deposito — sarebbe la prima emissione programmata, e non è attivo sulla chain 20.