Rand è open source. Il full node, l’explorer, il bridge, la ricerca sulle prove e i client wallet vivono ciascuno nel proprio repository su GitHub. Leggi il codice, esegui i test, invia patch. Questa pagina è la mappa: dove si trova ogni componente, con che cosa è costruito, fin dove è arrivato il sistema di prove e dove si ferma oggi.
Repository
| repository | che cosa contiene | linguaggio |
|---|---|---|
randprotocol/fullnode | Full node e wallet di riferimento: HotStuff BFT concatenato, rete libp2p, il pool schermato di note RAND, il verifier di prove zkVM, JSON-RPC, la CLI wallet rand e il prover delegato rand-prover. | Rust |
randprotocol/randscan.org | Block explorer alla base di randscan.org: un indexer axum con API REST e WebSocket su PostgreSQL, e un frontend Next.js. | Rust · TypeScript |
randprotocol/bridge | Bridge a guardiani per USDT e USDC da Ethereum, Binance Smart Chain, Tron e Solana: i contratti di custodia, il formato di attestazione condiviso e i relativi vettori di test. | Solidity · Rust |
randprotocol/zkp-circuits | Guide ai sistemi di prova (Groth16 contro STARK, pool schermato, firme ad anello, mixer), research/, la zkVM di riferimento di Rand, recursion/, la VM di ricorsione, la toolchain per i guest e i due traduttori, e i kernel CUDA. La build del fullnode richiede questo repository clonato accanto, come circuits/. | Rust |
randprotocol/clients | I client wallet: desktop, web, iOS e Android. | Rust · Swift · Java · JavaScript |
Lo stack
Rust da un capo all’altro. Rand è una chain a sé: un nodo HotStuff BFT con un livello di gossip libp2p, un pool di note interamente schermato come ledger, firme e cifratura delle note post-quantistiche, e la zkVM di Rand per il calcolo confidenziale, il tutto nel repository fullnode. Il sistema di prove vero e proprio è la parte in piena ricerca, qui sotto.
| livello | che cosa gira |
|---|---|
| Consenso | HotStuff BFT concatenato, quorum pesati per stake, commit a tre catene |
| Rete | libp2p: TCP, Noise, Yamux, gossipsub, Kademlia, mDNS sulle LAN |
| Ledger | Pool schermato di note: albero Poseidon2 di profondità 32, insieme dei nullifier, un bundle di asset nascosti 4-in-4-out per transazione (2-in-2-out fino alla chain 13); dalla chain 17 una seconda prova di autorizzazione di tier 10 accanto alla prova del bundle (autorizzazione divisa); dalla chain 18, buste di nota da 1.860 byte con un memo cifrato |
| Token | RPL: un token è una voce del registro del ledger con un id rpl1…, non un contratto; si muove come note nello stesso pool |
| Staking | Registro pubblico dei validatori: bond da un bundle, unbonding di due epoche, epoche di 1.000 blocchi; dalla chain 20 un nuovo validatore viene ammesso con un voto dell’insieme |
| Calcolo confidenziale | zkVM di Rand: RV32IM sotto uno STARK batch Plonky3, FRI con ZK-hiding, insieme di vincoli 8; dalla chain 18 una chiamata dichiara un limite di gas che il circuito impone e paga per gas e per KiB; dalla chain 20 un programma conserva lo stato in celle e detiene valore in un vault (RPL-2) |
| Crittografia | Dilithium2 · ML-KEM-768 · Poseidon2 · BLAKE3 · ChaCha20-Poly1305 |
| Storage | Un RocksDB per nodo, commit con fsync, controllo di integrità all’avvio; potatura opzionale della cronologia (--prune-history 24h), con i nodi archivio che conservano tutto |
| Bridge | Lock attestati dai guardiani su quattro chain, con un quorum di co-firme Dilithium2 su ogni mint; un asset bridged è una nota nello stesso pool |
| Linguaggio | Rust ovunque; Solidity per il bridge, TypeScript per l’explorer |
Una sola relazione per ogni programma
La relazione di esecuzione universale R_exec del whitepaper esiste come codice: rand_zkvm, una macchina RV32IM provata con un unico STARK batch su Plonky3 sul campo Goldilocks. Dimostra che una certa traccia ha eseguito il programma hc fino a questi output pubblici su input vincolati da un H_IN salato, e nulla del programma è mai un parametro del verifier. Pubblicare un programma confidenziale significa registrare un hash, mai generare un circuito su misura.
Il sistema di prove è trasparente, senza trusted setup e senza curve con pairing, e la sua assunzione è una funzione hash resistente alle collisioni. Ci si aspetta che ogni altro componente che tocca le prove converga su questo crate invece di svilupparne uno proprio. Il crate si trova in zkp-circuits/research ed è incluso nel fullnode (vendored) all’insieme di vincoli 8 (circuits aeacf31, fullnode v0.6.7 e v0.6.8). Le tabelle e le misurazioni qui sotto descrivono l’insieme di vincoli 5 (milestone M4.2), salvo che una riga ne nomini uno successivo; sono tratte da docs/zkvm.md, docs/zkvm-milestones.md e docs/confidential.md del fullnode al 2026-09-13, e le misurazioni sono riportate come misurate su un laptop Apple Silicon, non come obiettivi.
Otto tabelle su bus nominati, una nona su richiesta
Un solo commitment, una sola apertura FRI. Le tabelle non si chiamano mai a vicenda; si scambiano fatti su bus LogUp nominati (PROGRAM, PROGRAM_WORD, MEMORY, ALU, POSEIDON2, INPUT_DIGEST, INPUT_READ, KECCAK e le lookup di range e nibble) e il verifier controlla che ogni bus sia bilanciato globalmente. Il grado massimo dei vincoli di ogni tabella è fissato da un test al di sotto del limite di 8 che il blowup FRI consente.
| tabella | tipo | ruolo |
|---|---|---|
program | witness | Parole di istruzione grezze decodificate nel circuito dal M3.4, digerite dalla cpu in hc |
cpu | witness | Una riga per ciclo, più righe di digest che assorbono il programma in hc e gli input salati in H_IN |
memory | witness | Registri e RAM in un’unica tabella, ordinati per (space, addr, ts); accesso sub-word dal M2.5 |
alu | witness | Aritmetica a limb di byte, shift, confronti; moltiplicazione e divisione RV32M dal M2.6 |
range | preprocessed · 256 righe | Controlli di range e lookup delle potenze di due |
nibble | preprocessed · 256 righe | AND, OR, XOR a 4 bit; un riscontro è esso stesso un controllo di range su entrambi gli operandi |
poseidon2 | witness | Una riga per round di permutazione in blocchi da 32 righe; serve il bus POSEIDON2 e both i digest |
input | witness · dal M4.1 | Una riga per parola di input privato; serve INPUT_DIGEST e INPUT_READ, così una lettura non può sfuggire al commitment |
keccak | witness · opzionale | Keccak-f[1600] in blocchi da 32 righe, presente solo in una prova il cui guest ha chiamato KECCAK (M4.2) |
Da allora sono arrivati tre insiemi di vincoli. L’insieme 6 ha aggiunto una tabella public obbligatoria per l’input pubblico di un programma al momento del deploy, vincolata al digest non salato H_PUB, e una tabella sha256 opzionale accanto a keccak. L’insieme 7 (chain 16) acceca ogni terminale LogUp su un nuovo bus BLIND e fissa a 2⁷ righe il minimo di ogni tabella dichiarata, e aggiunge la syscall POSEIDON2_LEN vincolata alla lunghezza. L’insieme 8 (chain 18) aggiunge una colonna GAS alla tabella cpu e un valore pubblico, il GAS_LIMIT dichiarato.
Che cosa rivela una prova
Pubblico: il code hash hc (otto parole di digest nel circuito), il commitment di input salato H_IN (otto parole), il tier di gas e otto parole di output. Dall’insieme di vincoli 6 anche H_PUB, il digest dell’input pubblico, e dall’insieme di vincoli 8 il limite di gas dichiarato. L’intestazione della prova dichiara le altezze delle tabelle Keccak e SHA-256, quindi mostra se una chiamata ha eseguito hashing e, sopra il minimo di 2⁷, approssimativamente quanto.
Nascosto: gli input privati (H_IN è salato, quindi è hiding oltre che binding); ogni parola di istruzione, perché il verifier controlla hc e mai il programma; ogni valore di registro e di memoria; ogni salto eseguito; il numero esatto di cicli e il gas esatto usato; e quali syscall sono state eseguite, a parte ciò che mostrano le altezze delle due tabelle di hash.
Il tier è pubblico per ogni prova perché la dimensione di uno STARK rivela già l’altezza della sua traccia; nascondere l’indice non porterebbe nulla. hc è binding, non hiding: vedi dove si ferma oggi.
Misurato, all’insieme di vincoli 5
| FRI | 80 query · 20 bit di PoW · blowup 8 · arity 8 · ZK attivo; 260 bit congetturati, circa 86 dimostrati. Il retune a 27 query del M2 è stato annullato dall’audit del 2026-09-12 |
| Chiamata | private_payment al tier 10: circa 7 s per provare, circa 1,2 MB di prova a 80 query (435 KB a 27), in calo rispetto a 21,6 s e 892 KB del M1 |
| Trasferimento | Il guest del bundle 2-in-2-out delle chain fino alla 13: 3.811 parole, circa 9.160 cicli, tier 14; circa 100 s per provare, circa 1,3 MB di prova. Il guest ad asset nascosti 4-in-4-out della chain 14 è fissato allo stesso tier: circa 100 s, circa 1,42 MB |
| Verifica | Circa 16 ms con una chiave calda; la prima verifica a una nuova chiave (tier, altezze) richiede circa 230 ms |
| Blocco | Budget di 4 MiB e tetto di 2 MiB per le prove: circa tre trasferimenti schermati per blocco a 80 query |
Laptop Apple Silicon, build release. La divisione delle tabelle di byte nel M2.3 è ciò che ha ridotto il tempo di prova; il profilo a 80 query è ciò che ha riportato in alto la dimensione della prova. La chiave del verifier è indipendente dal contenuto del programma, identificata dal tier e dalle altezze di programma, input e keccak dichiarate dalla prova, così un nodo scalda una sola chiave e la riutilizza.
Gli insiemi successivi hanno modificato le dimensioni. Con l’insieme di vincoli 7 una prova di tier 10 pesa 1.367.688 byte al profilo di produzione e una prova di tier 10 con Keccak ne pesa 3.283.898 (misurato il 2026-09-28). Dalla chain 17 un trasferimento porta due prove: la prova del bundle di tier 14, di circa 1,49 MB, e la prova di autorizzazione di tier 10, di circa 1,37 MB e circa 7 s di tempo di generazione. Il genesis della chain 20 fissa un blocco di 20 MiB e un limite di 4 MiB per la prova, e una chiamata non può superare il tier 14.
Tre obiettivi, un solo circuito
Solo RISC-V viene eseguito in modo nativo. I programmi Solidity e Solana vengono eseguiti da una guest interprete all’interno della stessa relazione, con il loro bytecode come input, oppure vengono tradotti off chain in programmi RISC-V le cui uscite coincidono parola per parola con quelle dell’interprete. Gli opcode costosi richiedono tabelle di coprocessore dedicate anziché una simulazione bit per bit.
| obiettivo | percorso | coprocessori |
|---|---|---|
| RISC-V | Nativo. RV32IM, assemblato a mano con asm.rs oppure compilato come Rust no_std per riscv32im-unknown-none-elf, caricato come binario piatto dalla M4.1, oppure costruito da Rust o C da rand-guest nel contenitore dell’immagine (Distribuire un programma Rust) | Poseidon2 (e POSEIDON2_LEN dall’insieme 7); Keccak-f[1600] dalla M4.2; SHA-256 dall’insieme 6 |
| Solidity | solc --bin-runtime verso il bytecode EVM, poi la guest interprete evm.bin (bytecode come input) oppure evm2rv, che traduce il bytecode in C che rand-guest compila in un’immagine RV32IM con le stesse uscite (Il transpiler Ethereum) | Keccak-256 (tabella inclusa), aritmetica modulare a 256 bit, ECRECOVER, syscall di testimoni Merkle per lo storage |
| Solana / SVM | un ELF sBPF, eseguito dalla guest interprete sbpf.bin oppure tradotto da sbpf2rv in un’immagine RV32IM con le stesse uscite (Il transpiler Solana) | SHA-256, verifica Ed25519, moltiplicazione a 64 bit |
Tappe
La tappa 1 ha dimostrato la macchina generica. La tappa 3 l’ha trasformata in un pool shielded: un trasferimento con appartenenza nel circuito viene dimostrato sotto R_exec, e il verifier controlla hc senza mai vedere una parola del programma. La tappa 4 riguarda la compatibilità: il suo loader, l’impegno sull’input e la tabella Keccak sono stati rilasciati come insiemi di vincoli 4 e 5, e la tabella SHA-256 con l’insieme 6. Le guest interpreti EVM e sBPF, la toolchain rand-guest e i due traduttori sono costruiti. Il trasferimento ERC-20 è stato dimostrato, su una macchina da 128 GB; la prova dello SPL Token, al tier 20, non è ancora stata fatta. La tappa 5 è la VM di ricorsione dietro l’aggregazione dei blocchi, che è costruita e disattivata su ogni chain. Gli insiemi di vincoli 7 e 8 sono seguiti alle revisioni di settembre e al modello del gas.
| id | ambito | criterio di uscita | stato |
|---|---|---|---|
| M1 | Cinque tabelle, ISA di base RV32I, HALT/WRITE_OUTPUT/READ_INPUT, ZK attivo, padding per tier, assembler, emulatore | fib, memcpy, bubble_sort, alu_mix e balance_check vengono dimostrati e verificati; ogni test di frode viene respinto | completata. 44 test; una revisione successiva ha chiuso cinque lacune di soundness in un’unica ondata |
| M1.5 | Viewing key: una guest di trasferimento shielded da uno a uno, envelope delle note con ML-KEM-768 e ChaCha20-Poly1305, divulgazione limitata alla parte e alla transazione, un ledger simulato | Un trasferimento viene dimostrato al tier 12 e il ledger lo accetta; ogni ambito di divulgazione apre esattamente le proprie righe; una viewing key non può spendere | completata. Non incorporata nel nodo |
| M2 | Cache della verifier key, FRI riportato a un obiettivo congetturale di 100 bit, tabella dei byte divisa in range e nibble, load e store sub-word, estensione RV32M | Consegnata in forma più ridotta di quanto previsto: il loader del binario piatto e un vincolo più saldo su READ_INPUT sono stati rinviati alla M4.1 | completata. fib al tier 10: prova da 892 KB a 268 KB, generazione da 21,6 s a 3,1 s, prima verifica da 2,17 s a 16 ms. Insieme di vincoli 3, un hard fork |
| M3 | Chip Poseidon2 e syscall; NOTE_COMMIT, NULLIFY e MERKLE_VERIFY come routine della guest su di esso; l’impegno speso tolto dall’uscita pubblica; la tabella del programma come testimone con hc calcolato nel circuito | La relazione di trasferimento viene dimostrata sotto R_exec con appartenenza nel circuito, e verify(hc, proof) non vede mai una parola del programma | completata. Guest di trasferimento: 4.554 istruzioni, 4.903 cicli, tier 14. La visita Merkle è ora un ciclo contato, quindi la dimensione del programma non cresce più con la profondità dell’albero |
| CUDA | Backend prover su GPU: NTT e impegni Merkle Poseidon2 come kernel CUDA dietro i trait Dft e Mmcs di Plonky3; rand send, call e deploy accettano --cuda | Ogni guest viene dimostrata e verificata tramite il gemello di riferimento in puro Rust e il driver mock; il verifier su CPU non distingue i backend | completata; prima esecuzione su hardware il 2026-09-28. Su una NVIDIA H100 i kernel vengono compilati in PTX per sm_80 e sm_90 e coincidono con il riferimento CPU e Plonky3. La nuova misurazione di produzione su un nodo GPU della flotta resta da fare. Una chiamata CUDA non può sigillare un envelope di input, perché il sale non lascia mai il prover |
| M4.1 | Il loader del binario piatto e le prime guest Rust no_std compilate per riscv32im-unknown-none-elf; l’impegno salato sull’input H_IN con una propria tabella di input, così che READ_INPUT sia una lookup su un vettore impegnato | Una guest costruita con la toolchain standard viene caricata, dimostrata e verificata; due letture dello stesso indice di input concordano e gli input sono vincolati a H_IN | completata. Rilasciata il 2026-09-11 come insieme di vincoli 4: 26 valori pubblici, otto tabelle, un hard fork |
| M4.2 | Una tabella di coprocessore Keccak-f[1600] scritta a mano e la syscall KECCAK, presente in una prova solo se la guest l’ha usata; altezza della memoria dichiarata dalla prova; una verifier key indicizzata su quattro componenti; FRI riportato a 80 query dopo l’audit del 2026-09-12 | keccak256 viene dimostrato come guest compilata, e una prova senza la tabella ha una forma identica byte per byte a una della M4.1 | completata. Rilasciata il 2026-09-12 come insieme di vincoli 5, un hard fork. Una prova con Keccak è più grande di circa 1,9 MB, oltre il limite predefinito di 2 MiB. Una chain il cui genesis alza il limite ne ammette una: la chain 13 (8 MiB) ha accettato il 2026-09-19 una chiamata con Keccak da 3,41 MB, e il limite della chain 20 è di 4 MiB |
| M4.3 · M4.4 | Guest interpreti EVM e sBPF compilate in RV32IM, con il bytecode esterno come input; una tabella di coprocessore SHA-256 accanto a Keccak; poi la toolchain rand-guest e i traduttori evm2rv e sbpf2rv (2026-09-18) | Un trasferimento ERC-20 e un Transfer SPL vengono dimostrati ciascuno sotto R_exec | costruita; una prova di uscita effettuata. evm.bin (18.009 parole) e sbpf.bin (8.317) eseguono i vettori ERC-20 e SPL Token, e le immagini tradotte coincidono con essi parola per parola. Il transfer ERC-20 è stato dimostrato al tier 18 su un droplet da 128 GB il 2026-09-19 (85,0 GB di picco, 53,8 min); la prova dello SPL Token, al tier 20, è stimata per estrapolazione in circa 330 GB e non è stata fatta (memoria di proving). Nessuna delle due è richiamabile on chain: una chiamata è limitata al tier 14 |
| M5 | La VM di ricorsione (rVM): una macchina nativa Goldilocks a 24 istruzioni i cui programmi verificano le prove della zkVM di Rand, un programma di aggregazione generico in N per ogni forma di prova interna, una separazione dei backend CPU e CUDA, e un auto-verifier (da M5.1 a M5.4, dal 2026-09-13 al 2026-09-16) | 50 vere prove di bundle di produzione accettate e 50 manomesse rifiutate al passo indicato; una prova rVM del programma verifier su una vera prova di bundle viene verificata in modo nativo (profilo di test) | costruita; le prove di produzione richiedono una macchina grande. Incorporata come crates/randprotocol-rvm. L’aggregazione lato chain è integrata e disattivata su ogni chain (sotto) |
| set 7 | Ogni terminale LogUp oscurato; ogni tabella dichiarata portata ad almeno 2⁷ righe; controlli di range a 32 bit su parole di input, pubbliche e di sale; la syscall POSEIDON2_LEN; una correzione di JALR; verifier key salate da key_derivation_v2 | Le correzioni delle revisioni zkVM del 27 e 28 settembre 2026 che spostano una verifier key, raccolte in un unico taglio | completata. Fullnode v0.6.1, chain 16 (2026-09-28), un hard fork |
| set 8 | Il contatore del gas: una colonna GAS nella tabella cpu e un GAS_LIMIT pubblico, con GAS ≤ GAS_LIMIT dimostrato nel circuito; il gas esatto dell’esecuzione resta privato | Una chiamata paga il limite che dichiara, e ogni prova di bundle dichiara lo stesso limite fissato | completata. Fullnode v0.6.7-rc1, chain 18 (2026-09-29), un hard fork. bundle_gas_limit è 20.479 |
Fasi del pool shielded
Il ledger del fullnode è arrivato in tre fasi, ciascuna un hard fork (docs/shielded.md §7). S1 ha sostituito il ledger a conti con un pool di note; S3 ha riportato il bridge sotto forma di note ed è stata rilasciata per prima; S2 ha messo sopra lo staking. Tutte e tre sono su main e sulla chain attuale.
Le righe sotto S2 sono il lavoro della v0.5. Ogni riga è un hard fork; sono state prese insieme come un’unica chain nuova, la chain 14, creata il 2026-09-20 dalla build b3c594c e marcata v0.5 lo stesso giorno, dopo un round trip zUSD dal vivo attraverso gli endpoint sorgente distribuiti. La chain 15, attiva dal 2026-09-26 con la v0.5.8 e successive, ha portato tutto con sé, con attivate le correzioni degli audit v4 e v5 vincolate al genesis: un faucet con allowlist e budget per epoca, attivazione ritardata dei bond, un tetto al peso dello stake, registrazioni vincolate al genesis, consensus_domain 1, le regole del bridge v2 e il limite del registro dei token, la commissione di registrazione bruciata e il limite di 2⁶³ sulle note. La chain 20, attiva dal 2026-10-01 06:17 UTC con la v0.6.8 (c9c9bd3c), hard fork della chain 19, mantiene tutto e aggiunge il lavoro delle release v0.6, elencate di seguito.
| id | ambito | criterio di uscita | stato |
|---|---|---|---|
| S1 | Il pool in sé: note, bundle dimostrati 2-in-2-out, un albero di commitment Poseidon2 di profondità 32 e l’insieme dei nullifier, il wallet rand con un prover locale, l’RPC redatto | Un trasferimento schermato tra wallet, una corsa di double-spend tra due validatori e un deploy-and-call pagato con bundle superano tutti la suite del cluster | completato. Attivo sulla flotta pubblica dalla chain 6 (2026-09-12) |
| S3 | Il bridge come note: una posizione bridged porta l’indice dell’asset del registro, un’attestazione deposita una nota che la chain calcola da sé, BridgeBurn è l’unica transazione a due bundle; buste sigillate per gli input delle chiamate, apribili dal chiamante, da una chiave per chiamata o da un auditor designato | Un asset bridged viene coniato, speso e bruciato come nota; un chiamante può divulgare su cosa ha girato un programma senza pubblicarlo, e rand open-call verifica l’apertura rispetto a H_IN | completato. Arrivato per primo. Le chain da 9 a 13 hanno lasciato la sezione bridge fuori dal genesis; ogni chain dalla 14 in poi la include. Dalla chain 14 un burn è un solo bundle, non due |
| S2 | Staking sulla chain schermata: un registro pubblico dei validatori, Bond a partire dal burn di un bundle, Unbond in due epoche, Withdraw in una nota a un indirizzo di pagamento, epoche di 1.000 blocchi che ricalcolano l’insieme, e un audit della supply su registro e pool | Un quinto validatore si registra, effettua il bond e propone dall’epoca successiva; uno esce dall’insieme con l’unbond e preleva in una nota che il suo wallet di pagamento spende; entrambi superano la suite del cluster | completato. L’albero di commitment locale del wallet è seguito il 2026-09-21: un wallet calcola da sé i propri witness e non dice più al proprio nodo quale foglia sta spendendo |
| RPL | Lo standard dei token (docs/tokens.md): un token è una voce di registro nel ledger con un id bech32m rpl1… di 62 caratteri; la creazione è senza permessi, a fronte di una commissione di registrazione in RAND; l’autorità di mint è fissata alla registrazione come nessuna, una chiave o il bridge; i simboli non sono unici; rand token create, mint, set-authority, burn, info, list, e rand_getTokens, rand_getToken, rand_getTokenSupply | Un token viene registrato, coniato, inviato con rand send --asset e bruciato come nota nello stesso pool | in esecuzione dalla chain 14 (v0.5). Sulla chain 20 la commissione di registrazione è 1 RAND, bruciata, il registro contiene al massimo 4.096 token e il genesis elenca zUSD all’indice 1 |
| RPL-2 | Stato del programma (docs/program-state.md): celle per programma (una chiave di 8 parole verso un valore di 8 parole, nella radice di stato), un vault pubblico per asset, un token coniato solo dal suo programma, e l’azione Invoke (Action 33), una chiamata che dichiara le celle che legge e scrive e le note che paga; rand program invoke, state, vault, e rand_getProgramCell, rand_getProgramCells, rand_getProgramVault | Il ledger applica una transizione solo se ogni lettura dichiarata è ancora valida e il vault copre ogni pagamento; una lettura obsoleta viene rifiutata e dimostrata di nuovo | in esecuzione dalla chain 20 (v0.6.8). cell_fee 0,01 RAND per cella creata; al massimo 8 letture, 8 scritture e 4 pagamenti per invoke. Vedi Programmi |
| bundle con asset nascosto | Ogni transazione porta esattamente un bundle 4-in-4-out al posto di quello 2-in-2-out: gli slot 0–1 contengono l’asset privato (dummy in un trasferimento di soli RAND), gli slot 2–3 sono sempre RAND e pagano la commissione. Il trasferimento di token a due bundle e il bridge burn a due bundle non esistono più | Un trasferimento di RAND e un trasferimento di qualsiasi token RPL pubblicano la forma identica, così l’asset che si è mosso resta nascosto | in esecuzione dalla chain 14 (v0.5). Tier 14, circa 100 s per la dimostrazione, circa 1,42 MB di proof sulle chain 14 e 15; hc_bundle 83d3a370… lì. Le chain da 18 a 20 fissano la guest del bundle v3, hc_bundle 60af094a…, circa 1,49 MB |
| binding della transazione | Ogni proof di bundle è prodotta su, e verificata rispetto a, H("rand-tx-bind-1", chain_id ‖ tx with proofs blanked), trasportato nel segmento degli input pubblici | Una proof copiata e non modificata, ripresentata con una destinazione, un validatore o un memo cambiati, viene rifiutata | in esecuzione dalla chain 14 (v0.5). Dalla chain 20 (binding_domain 1) la preimmagine è H("rand-tx-bind-2", genesis hash ‖ chain_id ‖ …), e ogni messaggio di azione firmato porta anch’esso l’hash del genesis, così nulla di dimostrato o firmato per una chain si verifica su un’altra |
| B1–B4 | Rafforzamento del bridge (docs/bridge.md §§14–20). B1: un tetto giornaliero di mint per backing, e una chiave di pausa che può solo mettere in pausa (per riattivare serve il quorum PQ). B2: un timestamp di blocco oltre 60 s dopo quello del padre non è valido, e un validatore non vota un blocco più di 15 s in anticipo rispetto al proprio orologio, quindi i validatori hanno bisogno di NTP. B3: un quorum di co-firme Dilithium2 su ogni mint. B4: elencare un token bridged o un backing dopo il genesis sotto il quorum dei guardiani PQ, senza un taglio della chain | zUSD, un token con sette backing (USDT e USDC su Ethereum, Binance Smart Chain, Tron e Solana), è registrato tramite transazione, e total_supply == Σ backings.locked vale per costruzione. Il gate locale in nove fasi (zusd_e2e.rs: quattro validatori, proof reali, faucet, registrazione, deposito, trasferimento, burn, audit) ha superato 9 su 9 | in esecuzione dalla chain 14 (v0.5). Sulla chain 20: tetto di mint di 100.000 zUSD al giorno per backing più un globale di 4.000 zUSD per 24 ore mobili (regole del bridge v2), insieme di guardiani 1 con otto guardiani PQ, una commissione di 10 bps in zUSD su ogni mint e ogni burn (bridge.fees), e rotazioni dei guardiani che richiedono il possesso e attendono 86.400 s (bridge.rotation). zUSD è elencato nel genesis della chain 20 con i suoi sette backing e i 99 zUSD bloccati al momento del taglio |
| audit v3 | Le correzioni del terzo ciclo di audit interno, guidato da un co-fondatore (2026-09-19; non è stato eseguito alcun audit indipendente). POOL-1: un Mint del faucet porta l’apertura della propria nota (pk, time, r), l’ammissione ricalcola il commitment e il minter firma rand-mint-2; anche le note di alloc del genesis portano un’apertura. RPC-1: rand_getWitness(es) esegue al massimo due ricostruzioni dell’albero alla volta e risponde -32000 busy dopo 10 s. OPS-1: tutte le diciotto chiavi dei validatori ruotate, generate fuori dal repository, e nessuna chiave tracciata nel repository | Un mint il cui commitment si apre su più del suo importo viene rifiutato; nessuna chiave della chain 14 è mai stata nel repository | in esecuzione dalla chain 14 (v0.5). PRIV-1, la richiesta di witness che nomina la foglia, è stata chiusa il 2026-09-21 dall’albero del wallet stesso |
Release successive alla v0.5
Ogni release è un tag git con una voce nel CHANGELOG.md del fullnode. Una release che cambia il consenso, il formato di rete o una verifier key viene distribuita con una nuova chain; le altre vengono applicate alla chain attiva un nodo alla volta.
| release | cosa ha introdotto | catena |
|---|---|---|
| v0.5 a v0.5.8 | Token RPL, zUSD e il bridge rafforzato (sopra); le correzioni dell’audit; il pruning della cronologia; il rafforzamento di consenso e sincronizzazione | 14, 15 |
| v0.5.9 | Correzioni del rescan: il faucet conia solo dai validator del genesis, back-off della sincronizzazione, controlli preliminari del gossip | 15 |
| v0.5.10 | Condivisione degli indirizzi: impronte digitali, link randpay: e codici QR; il memo cifrato, attivato per la prima volta dalla catena 18 | 15 |
| v0.5.11 | Vesting del genesis con timelock per le allocazioni di team, investitori e partner. Subordinato al genesis e attivo su nessuna catena | nessuna |
| v0.6 | Le correzioni di zkVM, rVM e aggregazione dalle revisioni di settembre | 15 |
| v0.6.1 | Insieme di vincoli 7: blinding LogUp, una soglia minima di tabella di 2⁷, range check a 32 bit, POSEIDON2_LEN, la correzione di JALR. La catena 16 è stata creata con hardening_v6 e il guest del bundle v2 | 16 |
| v0.6.2 | Proving delegato, fase 1: il binario rand-prover e il --prover del wallet. Un prover di fase 1 riceve la chiave di spesa | 16 |
| v0.6.3, v0.6.4 | Proving delegato, fase 2: autorizzazione divisa. La prova del bundle non richiede più la chiave di spesa, la richiede una prova di autorizzazione di tier 10, e il dominio dell’id di transazione diventa rand-txid-3 | 17 |
| v0.6.6, v0.6.7-rc1 | Gas: insieme di vincoli 8, un limite di gas dichiarato per ogni prova, prezzi dinamici di gas e byte; il memo attivato. v0.6.6 non è mai stata rilasciata con un tag | 18 |
| v0.6.7 | Correzioni sulla catena 18 che non modificano alcuna regola di consenso: pruning delle prove sigillate (inattivo), blocco del formato dell’envelope, igiene della viewing key, l’allocatore della rVM, aliasing dei kernel GPU, copertura dei test della ALU. Taggata prima che la sua suite completa del workspace terminasse | 18, 19 |
| v0.6.8 | RPL-2: celle di programma, vault di programma e l’azione Invoke. Commissioni di bridge per zUSD, in entrambe le direzioni. Le ultime correzioni dell’audit-v6: nessun rilascio automatico dei lock (CON-4) e un pacemaker con certificato di timeout (CH-1); un listener --public-rpc, limiti di lettura, peer validator riservati, budget di sincronizzazione e gossip, il tetto di byte del pool, un limite al grado dichiarato nell’intestazione di una prova (ZKV-4); e le regole subordinate al genesis che la catena 20 attiva: il vincolo all’hash del genesis, testnet, una finestra di prova di 1.024 blocchi, tetti al prezzo del gas e il carico di byte pagante, l’ammissione per voto, il tetto di ingresso dello stake come frazione, possesso e un ritardo per le rotazioni del bridge. I wallet richiedono questa build per inviare sulla catena 20 | 20 |
Dove si ferma oggi
Scostamenti dal whitepaper, dichiarati e non edulcorati. Ciascuno è tracciato nella documentazione del relativo crate, insieme alla milestone che lo chiude.
hcè vincolante ma non nascondente: non contiene alcun salt, quindi un programma ipotizzato può essere confermato e due deployment dello stesso programma sono collegabili. Ciò che M3.4 ha eliminato è il verifier che tiene l’intero programma in chiaro.- Un wallet compilato prima del 2026-09-21 chiede i witness al proprio nodo, e una richiesta di witness indica la foglia che sta per essere spesa. Un
randattuale conserva una propria copia dell’albero e non chiede mai; il nodo serve ancorarand_getWitnessper i wallet più vecchi. - I depositi sono pubblici al confine: un mint del faucet, una nota del genesis e un deposito dal bridge riportano tutti il proprio importo in chiaro (dalla catena 14 un mint e una nota del genesis riportano anche la propria apertura, quindi anche la chiave del proprietario è pubblica), la stessa visibilità a un solo salto di qualsiasi deposito da trasparente a schermato.
- La conoscenza zero è statistica, non perfetta. È la proprietà che la FRI nascondente di Plonky3 0.7 fornisce effettivamente, e il crate lo dichiara.
- L’hash del transcript è Poseidon2 con costanti di round di sviluppo, non SHA3-384 / BLAKE3-384 dei paper. Un cambio di configurazione, non una riscrittura.
- Con 80 query FRI una prova di bundle pesava circa 1,42 MB sulle catene 14 e 15 (circa 1,3 MB fino alla catena 13). Dalla catena 17 un trasferimento porta circa 2,85 MB di prova: la prova del bundle, circa 1,49 MB, e la prova di autorizzazione, circa 1,37 MB. Su una catena predefinita, con blocchi da 4 MiB e un tetto di 2 MiB per le prove, una prova che contiene Keccak supera senz’altro il tetto; il genesis della catena 20 imposta blocchi da 20 MiB e un tetto di 4 MiB per le prove (le catene da 13 a 16 impostano 8 MiB).
- L’intestazione della prova di una chiamata non è nascosta. Dichiara il tier e le altezze delle tabelle Keccak e SHA-256, quindi mostra se la chiamata ha eseguito un hash. Le chiamate registrate sulla catena 15 prima della soglia minima del prover v0.6 esponevano di più: una tabella privata sotto le 2⁷ righe poteva essere letta dalla prova. La soglia minima del prover v0.6 ha chiuso il problema per le nuove chiamate, e l’insieme di vincoli 7 con
hardening_v6ne ha fatto una regola della catena dalla catena 16 in poi. - Una chiamata è limitata al tier 14, con al più 2¹² righe Keccak (128 permutazioni) e 2¹³ righe SHA-256 (128 compressioni), e con
hardening_v6un programma di più di 8.180 parole non può essere distribuito. I guest interpreti EVM e sBPF e le immagini tradotte di ERC-20 e SPL Token superano tutti questa soglia. - Chi detiene il witness vede tutto. La ZK protegge la vista del verifier, non quella del prover. Dalla catena 17 un wallet può consegnare la prova del bundle a un
rand-proverassociato senza consegnare la chiave di spesa, ma quel prover detiene comunque la viewing key e vede le note. Il backend CUDA è stato eseguito su hardware per la prima volta il 2026-09-28 e non ha ancora misurazioni in produzione.
Struttura del repository
Il workspace Cargo del fullnode, come descritto nel suo README e nella sua directory crates/.
| percorso | cosa contiene |
|---|---|
crates/randprotocol-core/ | Logica pura, senza I/O: crittografia, note e albero degli impegni, regole del ledger, gas, genesis, la macchina a stati HotStuff |
crates/randprotocol-zkvm/ | La zkVM di Rand, importata da zkp-circuits/research all’insieme di vincoli 8 (circuiti aeacf31; risincronizzata con deploy/sync-zkvm.sh), più il verifier di prove lato catena e la sua cache delle chiavi del verifier |
crates/randprotocol-rvm/ | La VM di ricorsione, importata da zkp-circuits/recursion: una macchina nativa sul campo i cui programmi verificano le prove della zkVM di Rand |
crates/bridge-codec/ | Il formato di trasmissione del bridge dei guardiani e la sua regola di quorum, condivisi byte per byte con i contratti Solidity e il programma Solana |
crates/randprotocol-node/ | Storage RocksDB, rete libp2p, mempool, sincronizzazione dei blocchi, il server JSON-RPC e il binario rand-node |
crates/randprotocol-client/ | Il binario del wallet rand e la libreria RpcClient, senza dipendenze da RocksDB o libp2p |
crates/randprotocol-prover/ | Il binario rand-prover: un prover delegato che genera le prove dei bundle per i wallet associati |
deploy/ | File genesis della testnet, nodes.env, script di avvio, provisioning cloud, script di cut-over e di ricostruzione. Nessuna chiave è tracciata qui dalla preparazione della catena 14 |
docs/ | Documentazione di riferimento e specifica di progetto |
scripts/ | Testnet locale con due validator |
Specificato, non ancora rilasciato
Questi componenti sono descritti nei paper o nella documentazione del fullnode ma non sono in esecuzione: o assenti dai repository, o realizzati e attivati su nessuna catena. Sono elencati perché il divario tra specifica e codice sia leggibile e non debba essere dedotto.
| componente | stato |
|---|---|
| bridge · guardiano | I daemon guardiano e relayer che eseguono il formato di attestazione da un capo all’altro; i contratti, il codec e la metà ricevente del fullnode sono rilasciati, i daemon no |
| fullnode · aggregazione | Aggregazione dei blocchi con la VM di ricorsione: sigillatura, pruning e sincronizzazione in forma sigillata. Realizzata e disattivata su ogni catena; rand-node rifiuta un genesis con una sezione aggregation. Manca ancora l’esercizio end-to-end con un aggregato falsificato, e rimuove solo la prova del bundle, non la prova di autorizzazione. Le prove rVM di produzione richiedono una macchina grande: con l’insieme di vincoli 7 un aggregato di due ha richiesto 133 GB, di tre 221 GB, e la prova di uscita più di 256 GB (misurato il 2026-09-28 e 29; non rimisurato con l’insieme di vincoli 8) |
| fullnode · vesting | Allocazioni del genesis con timelock per team, investitori e partner (v0.5.11, docs/vesting.md). Subordinato al genesis: senza una sezione vesting le quattro azioni di vesting sono rifiutate, e nessuna catena ne ha una. L’audit della supply della catena 20 riporta ogni contatore di vesting a zero. Dalla v0.6.8 una voce revocabile è revocata da una soglia dei suoi revocatori, e solo verso la tesoreria indicata dalla sua voce del genesis |
| fullnode · slashing | Lo slashing e il jailing per l’equivocazione del leader sono realizzati nella v0.6.8 dietro staking.slashing e disattivati sulla catena 20 (il suo genesis non ne ha, mentre tutte le 26 chiavi dei validator appartengono a un solo operatore). Le ricompense di blocco, il beacon del leader a sortition basata su hash, un accumulatore di nullifier e le chiamate tra programmi non sono realizzati. Lo stato persistente per programma è stato rilasciato come RPL-2 (sopra) |
prover/ | Daemon di proving su GPU: preleva i batch dalla coda, compete sull’invio. I kernel CUDA risiedono in zkp-circuits e sono stati eseguiti per la prima volta su una NVIDIA H100 il 2026-09-28; il daemon di mercato non esiste. rand-prover, che è rilasciato, genera prove per i wallet associati ed è non un mercato |
| zkp-circuits · M4.4 prova di uscita | Una prova di un trasferimento SPL Token (tier 20), estrapolata a circa 330 GB. Il trasferimento ERC-20 (tier 18) è stato provato su un droplet da 128 GB il 2026-09-19. Nessuno dei due può essere chiamato sulla catena 20, che limita una chiamata al tier 14 |
Compilazione e test
Workflow Rust standard in ogni repository. Il fullnode è un unico workspace Cargo con una toolchain fissata e una suite di test di cluster che avvia nodi reali su TCP. La sua build richiede che il repository dei circuiti sia sottoposto a checkout accanto ad esso, in una directory chiamata circuits, al commit da cui sono stati sincronizzati i crate vendorizzati (aeacf31 per v0.6.7 e v0.6.8). La zkVM è un crate autonomo in zkp-circuits, con una propria toolchain fissata e una demo che racconta che cosa rivela una chiamata riservata e che cosa non rivela.
Il fullnode:
git clone https://github.com/randprotocol/fullnode.git
git clone https://github.com/randprotocol/zkp-circuits.git circuits # the sibling directory must be named circuits
git -C circuits checkout "$(sed -n 's/^circuits: //p' fullnode/crates/randprotocol-zkvm/guests-compiled/PROVENANCE.md)"
cd fullnode
# Rust 1.98.1 is pinned by rust-toolchain.toml; first build pulls RocksDB and Plonky3, 10 to 20 minutes
cargo build --release # target/release/rand-node, target/release/rand, target/release/rand-prover
# All crates; release because STARK proving is slow in debug. One to two hours, mostly proving
cargo test --release
# One machine, two validators
scripts/local-testnet.sh
target/release/rand --rpc http://127.0.0.1:8545 statusLa zkVM di ricerca, in zkp-circuits/research:
# Toolchain is pinned by rust-toolchain.toml; the first build pulls Plonky3
cargo build --release
# Narrated demo: thirteen proofs, one at production FRI parameters (~6-7 min)
cargo run --release
# Emulator, per-table constraints, cheating provers, ZK, end-to-end, viewing keys, compiled guests (395 tests, ~17 min)
cargo testLa suite del fullnode misurata alla v0.6.1 su una macchina con 16 vCPU: core 521 test, node 373, client 117, la suite del prover disonesto 116, i cheat dei bundle nascosti 21 (75 min), il flusso del wallet 6 (53 min), il cluster 26 (44 min) e il gate end-to-end di zUSD 2 (51 min). Le prove di produzione della VM di ricorsione ne sono escluse e richiedono la memoria indicata sopra.
Running a node spiega come unirsi alla testnet pubblica con la build; il genesis della testnet, i peer di bootstrap e gli script di esecuzione sono inclusi nella directory deploy/ del fullnode, e la pagina di download ne offre la versione breve.
Contribute
Il fullnode è distribuito con licenza GNU General Public License v3.0 (GPL-3.0-only); prima era Apache-2.0. Aprite issue per bug e proposte di progettazione nel repository che la modifica riguarda. Le pull request sono benvenute: eseguite cargo fmt && cargo clippy prima dell’invio e mantenete le modifiche circoscritte. Le issue del fullnode sono il punto da cui iniziare.
L’architettura, il circuito di privacy, la prova del fee token e il compromesso post-quantistico sono tutti documentati nel whitepaper nella pagina dei paper. La directory docs/ del repository del fullnode è la fonte rispetto a cui è verificata ogni pagina di questa documentazione.