Commissioni

Usa questa pagina per impostare la commissione di una transazione, per stimare quanto costa un deploy o una chiamata e per capire come viene pagato un validatore. Le commissioni sono soglie minime in RAND. Ogni azione tranne la chiamata ne paga una fissa. Su chain 20 una chiamata paga il limite di gas dichiarato dalla sua prova e i suoi byte, a prezzi che si muovono con il riempimento dei blocchi e si fermano a un tetto.

I minimi

Le commissioni sono espresse in unità di 10⁻⁹ RAND. Le costanti si trovano in randprotocol_core::gas:

La commissione è una parola pubblica del bundle ed è sempre in RAND. Il guest del bundle per asset nascosti la vincola alla relazione di bilancio del gruppo RAND in₂ + in₃ = out₂ + out₃ + fee + burn_r (slot 2–3), così viene pagata da note schermate senza rivelare quali; un token si muove attraverso gli slot 0–1 dello stesso bundle con una propria relazione, in₀ + in₁ = out₀ + out₁ + burn_a. Una sola prova sposta quindi un token e paga la sua commissione in RAND, e un wallet che detiene un token ma nessun RAND spendibile viene rifiutato prima della generazione della prova.

Il costo del bridge ricade sul burn perché è l’unica transazione del bridge il cui mittente detiene di sicuro RAND; un deposito paga solo la base, dato che il depositante non ha ancora RAND. La commissione di registrazione è un fatto del ledger e non parte di fee_floor, perciò viene verificata con le regole proprie dell’azione (RegistrationFeeTooLow), nello stesso modo in cui la parte di gas o di livello di una chiamata viene addebitata dopo che la sua prova è stata decodificata. Il minimo di una chiamata viene verificato due volte, perché ciò che dichiara è attendibile solo dopo che la sua prova è stata verificata. Su chain 20 la prima verifica, prima di ogni verifica crittografica, prezza i byte della chiamata e un limite dichiarato pari a 1 (anche un Invoke deve lì la sua commissione per le celle); la seconda prezza il limite che la prova verificata dichiara. Su una catena senza sezione gas le due sono BUNDLE_BASE + CALL_BASE e il minimo esatto per livello.

Chiedi al nodo invece di tirare a indovinare:

rand fee bundle          # 0.001 RAND
rand fee deploy 256      # 0.0266 RAND
rand fee call 14 --gas 20479 --bytes 1350000   # 0.0041 RAND at chain 20's starting prices

→ {"method":"rand_estimateFee","params":[{"kind":"call","tier":14,"gas":20479,"bytes":1350000}]}
← "4103100"

Quella risposta è 1,000,000 + 100 × 20,479 + 800 × 1,319 ai prezzi iniziali; il nodo applica i prezzi correnti della punta della catena nel momento in cui gli si chiede. Su chain 20 il campo gas della specifica della chiamata è obbligatorio via JSON-RPC (-32602 se manca). rand fee call <tier> senza --gas invia il tetto del livello e, senza --bytes, non prezza alcun byte. Un invoke viene prezzato allo stesso modo, con "kind":"invoke" e "created_cells": c che aggiunge c commissioni per le celle (24103100 per l’esempio qui sopra con due celle, richiesto a chain 20 il 2026-10-01). Su chain 15, che non aveva sezione gas, rand fee call 14 rispondeva 0,0022 RAND.

I valori predefiniti del wallet sono esattamente i minimi, salvo per una chiamata su chain 20, il cui valore predefinito aggiunge un margine (sotto); rand send --fee <RAND> e il flag --fee su bond, call, bridge-mint, bridge-burn (predefinito 0,01) e sui sottocomandi token li alzano. Tutto ciò che supera il minimo è una mancia.

Gas su chain 18

Chain 18, attiva dal 2026-09-29 al 2026-10-01, è stata la prima catena con misurazione del gas, e chain 19, il suo re-genesis sulla stessa build, portava la stessa sezione gas. Chain 20 (v0.6.8) mantiene ogni regola di questa sezione e aggiunge due tetti di prezzo e un carico di byte contato solo sui byte che pagano (sotto). Una catena senza sezione gas mantiene la tabella dei livelli della tabella qui sopra.

Cosa viene contato. Un gas è una riga della tabella cpu della zkVM, quindi un’istruzione ordinaria costa 1. Le syscall sono gli unici altri costi:

Il limite dichiarato. Una prova di chiamata porta un valore pubblico in più rispetto a prima, GAS_LIMIT, e il circuito (insieme di vincoli 8) dimostra che il gas della esecuzione è pari o inferiore ad esso. Il gas esatto resta privato. Un limite sopra il tetto dell’intestazione della prova stessa viene rifiutato prima che venga costruita qualsiasi chiave del verificatore:

gas_max = (2ᵗ − 1) + 2^(t−2) + 191 × (keccak rows / 32) + 63 × (sha256 rows / 64)

Sono 1.279 al livello 10, 5.119 al livello 12 e 20.479 al livello 14 per una chiamata che non usa nessuna delle due tabelle di hash.

Il minimo. Il ledger addebita il limite dichiarato e i byte, ai prezzi in vigore all’inizio del blocco:

fee ≥ BUNDLE_BASE + gas_price × gas_limit + byte_price × ⌈bytes / 1024⌉

bytes è la prova della chiamata più l’envelope di input. La tabella dei livelli e la sua franchigia non si applicano su una catena di questo tipo. Il pool richiede esattamente ciò che richiede un blocco e rifiuta una chiamata più economica come FeeTooLow.

I bundle e la prova di autorizzazione dichiarano limiti fissati. Ogni prova di bundle deve dichiarare esattamente il bundle_gas_limit del genesis, 20.479 (il tetto del livello 14), altrimenti la transazione viene rifiutata come BundleGasLimit. Chain 20, come ogni catena da 17 in poi, usa l’autorizzazione divisa, quindi ogni bundle porta una prova di autorizzazione di livello 10, che deve dichiarare 1.279 (AuthGasLimit). Nessuno dei due è un addebito: un trasferimento, un bond o un deploy paga ancora il suo minimo fisso dalla tabella qui sopra. Il wallet dichiara entrambi i valori da sé.

I prezzi si muovono. La sezione gas di chain 20 ha un controllore dynamic, quindi gas_price e byte_price sono stato del ledger, vincolati nella state root. Una volta per blocco, dopo le sue transazioni, ciascuno si muove in base a quanto il blocco era pieno rispetto a un obiettivo:

price' = min(max_price, max(min_price, price + ⌊price × adjust_bps × (used − target) / (10,000 × target)⌋))

used è limitato al doppio dell’obiettivo, quindi adjust_bps è il massimo spostamento che un blocco può produrre in entrambe le direzioni. max_price è il tetto del genesis; chain 18 e 19 non ne avevano. byte_price segue i byte paganti del blocco (sotto); gas_price segue la somma dei limiti dichiarati dalle sue chiamate e dai suoi invoke più 20.479 per ogni bundle.

Un blocco al di sotto dei propri target fa scendere i prezzi, quindi su una chain poco trafficata restano ai minimi. rand_getLimits restituisce i valori correnti di gas_price e byte_price in cima alla chain con gas_metering: "circuit", bundle_gas_limit, adjust_bps e, dalla v0.6.8, max_gas_price, max_byte_price e byte_load (null su una chain che non li prevede); rand_status riporta gli stessi due prezzi come gas_prices.

Massimi e carico di byte pagante

Entrambi sono campi del genesis in gas.dynamic, introdotti nella v0.6.8 (audit v6, POOL-2), e chain 20 è la prima chain a impostarli. Correggono un difetto delle chain 18 e 19. Lì byte_price si muoveva con la lunghezza codificata di ogni transazione, mentre a pagarlo è solo una chiamata. Sette trasferimenti (circa 2,85 MB ciascuno, commissione fissa) riempiono un blocco fino a circa 1,9 volte il target di byte e alzano il prezzo di circa l’11% a blocco, senza alcun massimo: circa 65 blocchi di questo tipo lo portano a 1.000 volte il valore iniziale, e una chiamata costa allora circa 1 RAND invece di circa 0,004.

• Massimi. max_gas_price e max_byte_price sono prezzi che il controllore non supera mai. Il passo è lo stesso e poi viene limitato (gas::next_price_capped), quindi un prezzo al proprio massimo vi resta per qualsiasi serie di blocchi pieni e scende al primo blocco sotto il target. Un genesis deve fissare ciascun massimo uguale o superiore al prezzo iniziale. Ai massimi di chain 20 la chiamata di tier 14 vista sopra, 20.479 gas e 1.319 KiB, ha un minimo di 0,3113 RAND, il più alto che il suo minimo possa raggiungere.
• Il carico di byte pagante. Con byte_load: "paying" i bytes_used del blocco contano solo i byte su cui si applica il prezzo per byte: la prova più l’envelope di input di ogni Call e Invoke (gas::call_bytes), nulla di un trasferimento, di un bond o di un burn. Un blocco di trasferimenti non muove alcun prezzo per byte. Ledger::block_usage calcola il valore sia per il proposer sia per la replica, così i due concordano.

Con il carico pagante un blocco pieno di trasferimenti non dà alcun segnale di prezzo a una chiamata, perciò un proposer onesto riserva anche spazio per le chiamate. Questa è una politica del nodo, non una regola di validità: finché una call o un invoke è nel pool e paga il proprio minimo corrente, le transazioni a commissione fissa occupano al massimo tre quarti dei byte del blocco nel primo passaggio, e ciò che le chiamate lasciano dell’ultimo quarto viene poi riempito con i trasferimenti trattenuti (Mempool).

Cosa paga il wallet per una chiamata

rand call esegue prima il programma nell’emulatore e stampa gas: <exact> (declaring <limit>, tier <t>). Per impostazione predefinita dichiara il gas esatto arrotondato per eccesso a un multiplo di 2^(tier − 2); --gas-limit N dichiara un valore esatto e --gas-limit max il massimo dell’header.

Due fattori rendono la commissione predefinita più alta del minimo:

• La prova è valutata al limite massimo. Dalla chain 16 (hardening_v6, chain 20 inclusa) la prova di una chiamata è legata alla propria transazione, quindi la commissione è fissata prima che la prova esista. Il wallet valuta il limite massimo di prova della chain, 4 MiB, al posto della dimensione reale della prova (wallet::hardened_call_quote_bytes). Questo può solo far pagare di più.
• Due passi di prezzo di margine. rand_getLimits restituisce i prezzi della testa confermata e una chiamata viene inclusa due o tre blocchi dopo, quindi l’impostazione predefinita moltiplica il minimo per (1 + adjust_bps / 10,000)², che su chain 20 è 1,125².

Misurate su chain 18 il 2026-09-30, quattro chiamate sono costate tra 0,0057 e 0,0075 RAND ciascuna con queste impostazioni predefinite (Example programs). --fee sostituisce il valore predefinito; il wallet rivaluta la prova reale prima dell’invio e rifiuta una commissione inferiore al proprio minimo.

Dove va la commissione

Tutta la commissione, minimo e mancia, viene accreditata ai rewards del proposer del blocco nel registro dei validator, l’unico punto di questa chain che memorizza un importo in chiaro, con un’eccezione. In un genesis con tokens.burn_registration_fee (chain 20, come ogni chain dalla 15), la registration_fee di una RegisterToken o di una RegisterBridgedToken viene bruciata e il proposer trattiene fee − registration_fee; rand_getSupply la conta in registration_fees_burned. Su chain 14, priva del flag, il proposer tratteneva l’intera commissione. Nient’altro viene bruciato e non c’è alcuna ripartizione. Un validator trasforma le ricompense accumulate in una nota con rand-node withdraw (Staking). La commissione di cella di un invoke fa parte della commissione del suo bundle e va al proposer insieme al resto. Su chain 20 non ci sono ricompense di blocco né inflazione: le commissioni sono l’intero reddito di un validator.

Una commissione su chain 20 non è in RAND e non va a nessun validator. Secondo bridge.fees del genesis (novità della v0.6.8) il bridge trattiene 10 bps di ogni deposito di zUSD e di ogni burn di zUSD, arrotondati per difetto a un’unità intera di rilascio del collaterale, come nota zUSD verso un indirizzo di tesoreria indicato dal genesis. Un deposito accredita al depositante l’importo lordo meno la commissione; un burn rilascia amount − fee sulla chain di origine. La nota della commissione resta emessa e garantita. Vedi Bridge e RPL tokens.

Il mempool ordina i candidati in base a quanto pagano sopra il proprio minimo per KiB, poi in base alla commissione (Mempool), quindi una commissione più alta conta solo in caso di congestione. Un trasferimento pesa circa 2,85 MB (misurato su chain 18): una prova del bundle da 1,49 MB e una prova di autorizzazione da 1,36 MB, quindi ne entrano circa sette nel blocco da 20 MiB di chain 20. L’osservazione del fullnode stesso era che un mercato delle commissioni sui byte, non sugli opcode, è ciò che il minimo dovrebbe diventare prima della mainnet. Il prezzo per byte di chain 20 è quel mercato per le chiamate, mosso solo dai byte per cui le chiamate pagano; il minimo di un trasferimento resta fisso.

Perché qui il gas è un prezzo, non un limite

Ethereum misura ogni opcode perché ogni nodo esegue ogni transazione e l’esecuzione è illimitata. Su Rand nessun nodo esegue nulla: il mittente esegue il programma una volta, off chain, e consegna alla chain una prova. Il lavoro di un nodo per transazione è una sequenza fissa — decodificare i campi pubblici, eseguire i controlli gratuiti, verificare una STARK — e questa verifica costa circa 16 ms con una chiave del verificatore già in cache, qualunque cosa abbia fatto il programma. Così i tre compiti del gas si separano:

• La terminazione è imposta dal tier: un’esecuzione che non termina entro 2ᵗ − 1 cicli non può essere provata affatto, e il prover assorbe il fallimento.
• La valutazione del lavoro è ciò che fa il minimo del gas, dalla chain 18. Il costo della rete per istruzione è prossimo a zero, ma il lavoro di prova del mittente è reale, e un minimo fisso valutava una chiamata da un milione di cicli come una da mille. Fino alla chain 18 il minimo era fisso per tier.
• Il dimensionamento dei blocchi è un budget di byte (MAX_BLOCK_BYTES = 4 MiB per impostazione predefinita, altrimenti il max_block_bytes del genesis) e un numero di transazioni (2.000).

Due avvertenze che il fullnode dichiara apertamente: i byte variano (una prova supera il megabyte, quindi lo spazio nei blocchi, non il calcolo, è la risorsa scarsa), e la crescita dello stato — l’albero, l’insieme dei nullifier, i byte dei programmi distribuiti — è valutata solo dalla commissione di deploy per parola e dalla base fissa, il che è adeguato per una testnet e merita una revisione quando la dimensione dello stato conterà.

Cosa paga invece il mittente: la prova

L’unico costo variabile è la produzione della prova STARK, e lo paga solo la macchina del mittente. In ordine di effetto:

1. Il tier t ∈ {10, 12, 14, 16, 18, 20} (una chiamata oltre il 14 è rifiutata sulla chain dalla v0.5.6; un bundle è fissato a 14 e, dalla chain 17, porta accanto una prova di autorizzazione di tier 10, circa 7 s in più): la tabella cpu viene riempita fino a 2ᵗ righe e ogni passo quadruplica all’incirca la traccia riempita. Misurato sul laptop di sviluppo: private_payment al tier 10 in circa 7 s; la guest del bundle con asset nascosto al tier 14 in circa 100 s, qualunque asset sposti.
2. I cicli eseguiti, perché decidono il tier: le istruzioni eseguite, non quelle scritte.
3. La dimensione del programma, in modo debole: una riga di digest ogni quattro parole all’inizio della traccia.
4. La dimensione dell’input privato, allo stesso modo.
5. Quali tabelle sono presenti: una tabella keccak o sha256 costa la quota delle proprie colonne solo se la guest l’ha usata.
6. Il profilo FRI: 80 query invece di 27 triplicano la dimensione della prova ma cambiano appena il tempo di prova.

La prova non dipende dagli importi, da quante note possiede il mittente né dalla dimensione della chain: l’appartenenza è provata rispetto a un albero a profondità fissa, quindi un trasferimento costa lo stesso al blocco dieci e al blocco dieci milioni.

Riferimento