Usa questa pagina per capire chi fa cosa quando un trasferimento attraversa Rand. Dimostrare è costoso e verificare è economico, quindi il lavoro è diviso lungo questa linea. Il lato del mittente produce le prove. I validatori si limitano a controllarle, ordinarle e votare. Un aggregatore, una volta attivato, comprimerebbe molte prove in una sola. La figura segue un trasferimento dal wallet fino a un blocco finale; le sezioni successive trattano ciascun ruolo a turno.
Il percorso di un trasferimento
- Il wallet costruisce il trasferimento. Sceglie le note di input, recupera i relativi witness di Merkle, costruisce quattro output e sigilla ciascuno in una busta ML-KEM-768. Calcola poi il binding della transazione, un hash su tutto tranne le prove (Transactions).
- Il wallet dimostra da sé l’autorizzazione. È una prova di tier 10 sulla chiave di spesa e su un salt nuovo, questione di pochi secondi. È l’unica prova che tocca la chiave di spesa, e viene sempre prodotta sulla macchina del wallet stesso.
- La prova del bundle viene prodotta dove c’è memoria sufficiente. Questa prova di tier 14 dimostra la proprietà, l’appartenenza, i nullifier e il bilancio, e raggiunge un picco di circa 6 GB. L’app desktop e un telefono con circa 8 GB la producono da soli. Qualsiasi dispositivo più piccolo affida il compito a un prover con cui è associato: uno che gestisci tu, oppure il pool dei validatori su
prover.randprotocol.org. A entrambi vengono inviati la chiave di visualizzazione e il salt, mai la chiave di spesa (Proofs). - Un nodo RPC la controlla. Il nodo a cui il wallet invia la transazione ricalcola il digest del bundle, verifica entrambe le prove rispetto al binding, controlla la commissione e solo allora propaga la transazione ai propri peer (Proofs, Mempool).
- I validatori la ordinano e la finalizzano. Il leader della view prende le transazioni ancora valide, partendo da quelle con la miglior commissione per KiB, e propone un blocco. Ogni validatore riverifica ogni prova al suo interno e vota. Il blocco viene confermato quando tre quorum certificate si concatenano su di esso in view consecutive, il che richiede 18 dei 26 validatori della chain 20 online (Consensus).
- Il blocco è finale e chiunque può verificarlo. Una transazione è finale quando
rand_getTransactionrestituisce un blocco. Un nodo che si sincronizza più tardi riverifica ogni certificato e ogni prova, invece di fidarsi delle firme.
I ruoli
| ruolo | cosa fa | dimostra? | cosa vede | esegue |
|---|---|---|---|---|
| wallet | costruisce, autorizza e invia trasferimenti e chiamate; scansiona la chain con le proprie chiavi | sempre la prova di autorizzazione; la prova del bundle quando il dispositivo ha memoria sufficiente | tutto ciò che riguarda le proprie note | le app della pagina Clients, oppure rand; sulla chain 20, Rand Wallet o rand v0.6.8 o successivo |
| prover delegato | produce la prova del bundle per un wallet associato; ogni risposta viene controllata dal wallet prima che venga inviato qualsiasi cosa | solo prove del bundle | la chiave di visualizzazione del wallet associato: tutta la sua cronologia, passata e futura; non può spendere | rand-prover run, oppure rand-node run --prover |
| pool di prover dei validatori | un prover delegato gestito da quattro host, due validatori e due macchine che si limitano a dimostrare, dietro un solo nome e una sola chiave, per i wallet privi di un prover proprio; nessuna commissione | solo prove del bundle | lo stesso di qualsiasi prover delegato, per ogni wallet che vi si associa | prover.randprotocol.org, impronta RGTF-7HKJ-XZFV-GQ1J |
| nodo RPC (osservatore) | si sincronizza, riverifica ogni prova, serve JSON-RPC, propaga le transazioni verificate; non vota | no | solo campi pubblici: commitment, nullifier, buste sigillate, prove | rand-node run |
| validatore | tutto ciò che fa un osservatore, più la proposta di blocchi nelle proprie view e il voto in HotStuff | no | solo campi pubblici | rand-node run --validator |
| aggregatore | produce una prova ricorsiva su una finestra di prove di bundle finalizzate e la invia per un blocco di sigillatura | sì, le prove più grandi della rete | solo campi pubblici e prove | rand-node aggregate --watch, su una chain con una sezione aggregation |
Dimostrare e validare sono compiti distinti, e un validatore non ha bisogno di hardware da prover. Due dei quattro membri del pool sono validatori che eseguono anche un prover, come servizio; gli altri due sono macchine dedicate alla prova che non detengono alcuna chiave di validatore. Gestire il pool non fa parte della validazione. Le dimensioni per ciascun ruolo e la memoria di proving misurata per ogni tier si trovano in Validator and aggregator hardware.
Cosa può apprendere ciascun ruolo
La privacy di un trasferimento dipende da chi detiene quale chiave, non dalla fiducia nella rete:
- I validatori, i nodi RPC e l’explorer vedono ciò che vede ogni nodo: commitment, nullifier, buste sigillate, la commissione e le prove. Non l’importo, l’asset, il mittente né il destinatario.
- Un prover delegato, pool incluso, riceve la chiave di visualizzazione. Con essa può leggere l’intera cronologia del wallet associato. Non può mai spendere, perché la prova di autorizzazione sulla chiave di spesa viene prodotta sulla macchina del wallet. Associare il pool significa scegliere di mostrare quella cronologia ai suoi operatori. Se vuoi mantenerla privata, dimostra sul tuo dispositivo o gestisci un tuo prover.
- Un prover delegato non può ingannare il wallet. Il wallet legge il digest da ogni prova ricevuta, ne controlla la dimensione e la verifica in locale, così una prova errata non raggiunge mai un nodo.
Aggregazione: sviluppata, non attiva
Oggi ogni blocco contiene ogni prova grezza, circa 2,85 MB per un trasferimento, quindi un blocco da 20 MiB ne contiene circa sette. L’aggregazione dei blocchi è la risposta del fullnode. Un aggregatore prende le prove di bundle di una finestra di blocchi finalizzati (rand_getUnsealed), produce una prova ricorsiva che le verifica tutte e la invia. Il blocco che la include sigilla la finestra. I validatori verificano così un solo aggregato anziché N prove, e i nodi possono scartare le prove grezze coperte. Gli aggregatori sono vincolati da un bond e senza permessi, girano su macchine di classe GPU e ricevono la quota di proving dei bundle coperti più un sussidio di blocco in nuovi RAND.
È sviluppata e integrata, ma non è attiva. Richiede una sezione aggregation nel genesis, e la chain 20 non ne ha una, quindi rand_status riporta a zero tutti i contatori di aggregazione. Prima che possa essere attivata, la forma del suo bundle deve essere rimisurata con l’attuale insieme di vincoli, e va eseguito un test con aggregati contraffatti contro il verificatore della ricorsione. Su una chain con autorizzazione separata sigillerebbe inoltre solo le prove di bundle, non le prove di autorizzazione (Proofs).