Leggi questa pagina per decidere su cosa costruire e da dove cominciare: il modello della chain in pochi paragrafi, i parametri della testnet attiva, come ottenere RAND di prova e una mappa del resto della documentazione.
Che cos’è Rand Protocol
Rand è una chain schermata post-quantistica. La sua moneta nativa è RAND, e RAND vive in un pool interamente schermato: on-chain non esistono account né saldi, solo commitment delle note e nullifier, e un trasferimento è una prova a conoscenza zero che quattro note sono diventate altre quattro note (note fittizie riempiono gli slot inutilizzati), senza rivelare quale asset si sia mosso. RAND e ogni token dello standard proprio della chain, RPL, condividono quell’unico pool. La stessa moneta paga i programmi confidenziali: programmi RISC-V che girano off-chain dentro una macchina virtuale a conoscenza zero e vengono regolati on-chain con una prova al posto dei loro input.
Ogni primitiva è scelta per resistere a un avversario quantistico:
| livello | cosa viene eseguito |
|---|---|
| Firme | Dilithium2 (basato su reticoli). I validatori firmano con esso blocchi e voti; con esso sono firmati anche il faucet, le azioni di staking e le registrazioni del bridge. Un wallet non firma mai una transazione: un bundle si autorizza con la propria prova. |
| Cifratura delle note | Incapsulamento di chiave ML-KEM-768 più ChaCha20-Poly1305. Ogni nota on-chain è accompagnata da una busta che solo il suo proprietario (e il suo mittente) può aprire. |
| Hashing | BLAKE3 con separazione di dominio per indirizzi, id di transazione, radice di stato e tutto il resto al di fuori del sistema di prova; Poseidon2 sul campo Goldilocks per note, nullifier, albero dei commitment e tutto ciò che sta dentro una prova. |
| Prove | Una STARK batch Plonky3 con FRI hiding (80 query, blowup 8, 20 bit di proof-of-work). Trasparente: nessun trusted setup, nessuna curva con pairing, e l’assunzione è una funzione hash resistente alle collisioni. |
| Calcolo confidenziale | La zkVM di Rand, una macchina RV32IM provata con quella STARK. Un programma è identificato da un digest in-circuit, e il verificatore non vede mai una sola parola di istruzione. |
| Consenso | HotStuff BFT concatenato: quorum pesati per stake superiori ai due terzi, leader a rotazione round-robin, una regola di commit a tre view consecutive. |
| Storage e rete | Un RocksDB per nodo con commit sincronizzati su disco (fsync) e un controllo di integrità all’avvio; libp2p (TCP, Noise, Yamux, gossipsub, Kademlia, mDNS sulle LAN). |
L’implementazione di riferimento è randprotocol/fullnode, in Rust: il binario rand-node è il nodo, il binario rand è il wallet, e i metodi JSON-RPC hanno il prefisso rand_. L’explorer è randscan.org.
La testnet: chain 20
La flotta pubblica esegue la chain 20, attiva dal 2026-10-01 06:17 UTC su fullnode v0.6.8. Le chain da 15 a 19 sono ritirate. Quattro chain sono state create in quattro giorni, ciascuna per una modifica che cambia ogni prova o il formato delle transazioni:
- La chain 16 (2026-09-28, fullnode v0.6.1) ha portato la zkVM al constraint set 7, che oscura ciò che una prova rivelava sui piccoli input privati, e ha attivato le regole
hardening_v6. - La chain 17 (2026-09-29, v0.6.3) ha separato l’autorizzazione di un trasferimento dalla sua prova: ogni bundle porta una seconda, piccola prova prodotta con la spend key, così che quella grande possa essere prodotta da una macchina che possiede solo una viewing key.
- La chain 18 (2026-09-29, v0.6.7) misura le chiamate confidenziali in gas (constraint set 8) e attiva il memo cifrato in ogni busta di nota.
- La chain 20 (2026-10-01, v0.6.8) lega ogni prova e ogni messaggio firmato all’hash di genesi, aggiunge lo stato dei programmi (RPL-2), applica una commissione sui mint e sui burn del bridge zUSD e attiva le regole audit-v6 elencate nella tabella qui sotto.
La chain 19 (2026-10-01 03:43 UTC, v0.6.7) è stata una nuova genesi della chain 18 sulla stessa build e non ha cambiato alcuna regola. La chain 18 è stata fermata all’altezza 143.776, e la chain 19 è stata creata da uno snapshot all’altezza 141.935. La sua genesi differiva da quella della chain 18 solo per l’id della chain, il timestamp, le note riportate e la sezione del bridge: nuovi emitter per gli endpoint Ethereum, Binance Smart Chain e Tron, con i contatori di sequenza riportati.
La chain 20 è un hard fork della chain 19: la sua genesi è stata creata da uno snapshot della chain 19 all’altezza 7.258, la chain 19 è stata fermata all’altezza 7.700, e tutti i 26 validatori sono stati riavviati insieme sulla chain 20, con le stesse chiavi, gli stessi peer id e gli stessi nodi di bootstrap. La chain 19 e la chain 18 sono ritirate. Un wallet richiede la v0.6.8 per inviare sulla chain 20: le prove e le firme di un wallet più vecchio non portano il legame con la genesi, e la chain le rifiuta.
Ciascuna è una chain nuova. I saldi RAND nei wallet dell’operatore e gli zUSD in circolazione sono stati riportati nella genesi successiva, e nient’altro: un programma distribuito su una chain non esiste sulla successiva. È software sperimentale: non è sottoposto ad audit, e RAND su di essa non ha alcun valore.
I programmi sulla chain 20 possono mantenere uno stato: le program cell di RPL-2, i program vault e l’azione Invoke sono attivi.
| chain id | 20 (rand_chainId) |
| genesis hash | 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 |
| file di genesis | deploy/genesis-chain20.json nel repository del fullnode |
| build | fullnode v0.6.8 (tag c9c9bd3c); un nodo riporta la propria build in rand_getVersion. Questa build rifiuta le chain da 14 a 17, e un wallet precedente alla v0.6.8 non può inviare sulla chain 20 |
| vincolo al genesis | binding_domain 1: il vincolo di prova di ogni bundle e ogni messaggio di azione firmato includono l’hash di genesis, quindi nulla di ciò che è stato provato o firmato per una chain risulta valido su un’altra |
| indicatore testnet | testnet true: il genesis si dichiara rete di test, ed è ciò che consente a un faucet di operare accanto al bridge |
| validatori | 26, ciascuno con uno stake di 1.000 RAND, il minimo di staking |
| quorum | 18 su 26: strettamente più di due terzi dello stake |
| intervallo tra i blocchi | il valore predefinito --block-interval-ms 1000; circa un blocco al secondo |
| tempo di blocco | un timestamp oltre 60 s dopo quello del blocco padre non è valido, e un validatore non vota un blocco più avanti di 15 s rispetto al proprio orologio, perciò i validatori eseguono NTP |
| finestra di prova | proof_window_blocks 1.024: l’ancora di un bundle deve essere una delle ultime 1.024 radici di fine blocco, e il suo time non deve essere più vecchio di così (256 blocchi sulle chain 18 e 19) |
| epoche | 1.000 blocchi; un nuovo bond attende due epoche in più prima di contare (bond_activation_epochs 2, con attivazione all’epoca e + 3), lo stake in svincolo viene rilasciato due epoche dopo |
| staking | le registrazioni sono v2 (rand-node register --v2), e una nuova chiave si registra solo dopo che i validatori che detengono più di due terzi del peso la approvano con il voto (admission_by_vote); il peso di un singolo validatore è limitato al 33,33 %; il nuovo stake che entra al confine di un’epoca è limitato al 25 % del peso attivo (max_stake_entry_bps_per_epoch 2.500); nessuno slashing |
| zkVM | insieme di vincoli 8, profilo FRI di produzione (80 query) |
| guest del bundle | hc_bundle 60af094acfe65d85fdb18fb3d06cf9085dcf28c96e59e87f1ee527226e6e3fce: il bundle di asset nascosti 4 in ingresso e 4 in uscita, versione 3, tier 14 |
| guest di autorizzazione | hc_auth 1e4e347f44cf86750b30a9a4bdf9ec9256efe353d4ff8017451eca7d195639c1: l’autorizzazione di spesa che ogni bundle porta con sé, tier 10 |
| gas | una chiamata dichiara un limite di gas che il circuito applica e paga gas_price per esso: 100 unità per gas e 800 unità per KiB al minimo, entrambi in movimento a ogni blocco verso un obiettivo di 262.144 gas e 10.485.760 byte, e mai oltre i massimi di 10.000 per gas e 80.000 per KiB. Solo i byte su cui si applica il prezzo per byte (la prova di una chiamata e la sua busta di input) contano nel carico di byte (byte_load: "paying"), perciò un blocco di trasferimenti non lo fa salire. Ogni bundle dichiara il limite fissato 20.479 e paga la quota fissa di 0,001 RAND |
| stato dei programmi | RPL-2 attivo: celle di programma, vault di programma e Invoke (Action 33); una cella creata costa 0,01 RAND (cell_fee 10.000.000 unità); un invoke legge al massimo 8 celle, ne scrive al massimo 8 ed effettua al massimo 4 pagamenti (rand_getLimits.program_state) |
| busta della nota | envelope_bytes 1860: la busta di ogni nota è di 1.860 byte e contiene un memo cifrato |
| limite dei programmi | max_program_words 65.535, ma con hardening_v6 un deploy che nessuna chiamata di tier 14 potrebbe contenere viene rifiutato (ProgramUncallable): 8.180 parole per un programma senza segmento pubblico |
| limite delle prove | max_proof_bytes 4.194.304 (4 MiB); era 8 MiB sulle chain da 13 a 16 |
| limite dei blocchi | max_block_bytes 20.971.520 (20 MiB) |
| limite della busta di chiamata | max_call_envelope_bytes 65.536 |
| input pubblico per programma | max_program_public_words 32.768, fissato al deploy |
| faucet | attivo, ma solo per i 16 wallet nella allowlist del genesis (staking.faucet_recipients), e solo dai 18 validatori che il genesis indica come minter (staking.faucet_minters): fino a 100 RAND per chiamata, 10.000 RAND per epoca in totale |
| calcolo riservato | attivo; la prova di una chiamata è limitata al tier 14. I programmi non si trasferiscono con un cambio di chain; i programmi di esempio indicano su quale chain è distribuito ciascuno |
| token | il registro RPL è attivo: tassa di registrazione 1 RAND, bruciato; al massimo 4.096 token; ogni valore di nota inferiore a 2⁶³. zUSD è elencato nel genesis all’indice 1 |
| bridge | attivo: insieme di guardiani 1 con otto guardiani, otto guardiani PQ Dilithium2, una chiave di pausa, emettitori per quattro chain di origine, un tetto giornaliero di mint di 100.000 zUSD per garanzia e un tetto globale di 4.000 zUSD su 24 ore mobili per tutte le garanzie. zUSD ha sette garanzie; la sua offerta è quanto risulta bloccato, letto in tempo reale da rand_getTokenSupply. Dalla chain 20 una commissione di 10 bps è applicata a ogni mint e a ogni burn, in zUSD, come nota a un indirizzo di tesoreria (bridge.fees): un deposito accredita l’importo lordo meno la commissione, e un burn rilascia amount − fee sulla chain di origine. Una rotazione dei guardiani PQ o della chiave di pausa porta la firma propria di ciascuna nuova chiave e ha effetto 86.400 s dopo essere stata accettata (bridge.rotation) |
| cronologia | 24 validatori conservano 24 ore di blocchi (--prune-history 24h) e rispondono -32010 oltre tale limite; due nodi archivio conservano ogni blocco, e l’RPC pubblico https://rpc.randprotocol.org inoltra a un archivio |
| aggregazione dei blocchi | disattivata (nessuna sezione aggregation nel genesis; la build si rifiuta di avviarsi con un genesis che ne contenga una) |
| valore del genesis | 26.000 RAND in staking nel registro dei validatori più sette note di deposito per un totale di 5.184,243719258 RAND, riportate dai wallet dell’operatore sulla chain 19: 31.184,243719258 RAND, prima dei mint del faucet (rand_getSupply riporta genesis_staked e genesis_deposited); più due note di genesis per un totale di 99 zUSD, corrispondenti ai 99 zUSD bloccati sulle rispettive garanzie |
I nodi di bootstrap (deploy/nodes.env):
/ip4/164.90.239.200/tcp/30303/p2p/12D3KooWEQEbUwZRgqhDPXhW7vNBmcRcnhUDGUADe81VFdv3ALYe
/ip4/165.245.173.74/tcp/30303/p2p/12D3KooWJyc5oDHggAr89e9QrRFBy9Tg8TxXh18yzrb1SM6KKLYw
/ip4/188.166.235.187/tcp/30303/p2p/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQLa chain 20 funziona con le chiavi dei validatori usate dalle chain da 14 a 19, perciò questi peer id non sono cambiati dalla rotazione delle chiavi della chain 14.
L’explorer su randscan.org indicizza la chain 20 ed espone un’API REST su https://randscan.org/api/v1 (API dell’explorer). Il JSON-RPC del full node è in ascolto su 127.0.0.1:8545 per impostazione predefinita; esegui un nodo (Eseguire un nodo), usane uno di cui ti fidi, oppure usa l’endpoint pubblico https://rpc.randprotocol.org (rand --rpc https://rpc.randprotocol.org …). L’endpoint pubblico serve tutto ciò di cui un wallet ha bisogno, compresa la prima sincronizzazione e l’invio di transazioni, con un limite di 1.200 letture e 6 invii al minuto per indirizzo. Non serve il faucet.
Ottenere RAND dal faucet
Il faucet è un tipo di transazione: un validatore conia una nota di importo pubblico verso un indirizzo schermato, e la nota può essere aperta solo dal titolare dell’indirizzo. Sulla chain 20 paga solo i 16 indirizzi nella allowlist del genesis: un mint verso qualsiasi altro indirizzo viene rifiutato con the faucet may not mint to this recipient (not in staking.faucet_recipients), perciò un wallet che non vi compare ottiene RAND di test ricevendone da qualcuno. Ciascuno dei tre percorsi seguenti chiede il mint a un nodo validatore; gli osservatori rispondono faucet mints are signed by validators; ask a validator node, e l’endpoint RPC pubblico non inoltra affatto rand_mint.
Con il wallet rand, puntato all’RPC di un validatore:
rand keygen # writes wallet.key.json; refuses to overwrite
rand address # the rand1… address on stdout (about 1,665 characters), its fingerprint on stderr
rand faucet # an allowlisted wallet: 100 RAND into a note only it can open
rand balance # scans the tree with this key; prints 100 RANDrand faucet [ADDRESS] --amount <RAND> conia verso un altro indirizzo o per un importo minore; 100 RAND è sia il valore predefinito sia il limite per chiamata. Via JSON-RPC la stessa richiesta è rand_mint:
curl -s http://127.0.0.1:8545 -H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"rand_mint","params":["rand1…", "100000000000"]}'Il risultato è l’hash della transazione di mint; interroga rand_getTransaction finché non restituisce un blocco. Gli importi sono stringhe di unità, e 1 RAND corrisponde a 10⁹ unità. Le app wallet offrono lo stesso faucet con un solo tocco; invia da esse con Rand Wallet v0.6.8 o successivo, la prima versione per la chain 20. La pagina del faucet di questo sito accetta richieste in lista d’attesa per le assegnazioni su devnet.
L’importo di un mint è pubblico sulla chain: la visibilità a un solo passaggio propria di ogni deposito da trasparente a schermato. Quanto vale la nota, e per chi, da quel momento in poi resta nascosto come per ogni altra nota.
Dove andare dopo
- Account e indirizzi: i due tipi di chiavi, che cos’è un indirizzo
rand1…e perché l’indirizzo di 54 caratteri della chain 11 è stato ripristinato. - Note e albero degli impegni, Transazioni e azioni, Commissioni, Consenso e finalità, Offerta: il modello.
- Crittografia e Prove: le primitive, i parametri STARK, come un bundle viene dimostrato e verificato.
- Token e Distribuire un token RPL: lo standard RPL, un token come voce di registro con un id
rpl1…e la sua creazione dal wallet. - Programmi: distribuire e chiamare un programma confidenziale, e che cosa non è ancora possibile.
- Bridge, Mint e burn, Staking, Eseguire un nodo.
- Scrivere un programma in Rust o C: la guida completa, dalla progettazione di input e output di un programma a un’asta a offerta sigillata scritta in entrambi i linguaggi, il budget di dimostrazione, la distribuzione e la verifica di una chiamata.
- Quattro programmi di esempio: applicazioni complete, ciascuna eseguita sulla testnet: un voto anonimo su una allowlist Keccak, una prova di passività su un albero delle somme SHA-256, un ledger off-chain il cui stato viene trasportato tra una chiamata e l’altra, e una decisione di credito privata basata su un modello pubblicato.
- L’ISA RISC-V, Distribuire un programma Rust, Distribuire un programma RISC-V: costruire e distribuire i propri programmi con la toolchain
rand-guest. - Il transpiler Solana e Il transpiler Ethereum: SPL Token e un ERC-20, tradotti in RISC-V e confrontati parola per parola con gli interpreti.
- Eseguire un validator e un aggregator: RAM, CPU e disco per ciascun ruolo, e i limiti di memoria di dimostrazione misurati.
- Sviluppatori: i repository, lo stack, le tappe della zkVM, ciò che è specificato ma non rilasciato, e come compilare, testare e contribuire.
- JSON-RPC, Riga di comando, API dell’explorer: i riferimenti.
La directory docs/ del repository fullnode è la fonte con cui queste pagine vengono verificate, e i paper forniscono il background crittografico.