Questa pagina documenta la motivazione di ciascuna decisione di progetto rilevante in Rand: la proprietà che un componente deve garantire, l’ipotesi sotto la quale la garantisce e il costo accettato in cambio. È stata compilata il 29 settembre 2026 a partire da questo sito, dal riepilogo del whitepaper e dal full node di riferimento (github.com/randprotocol/fullnode: il suo README, docs/ e docs/superpowers/specs/). Ogni risposta cita il documento in cui la motivazione è enunciata; i percorsi si riferiscono al repository fullnode, salvo quelli che iniziano con randprotocol.org.
Stato. Rand funziona su una testnet gestita dal team fondatore e il protocollo non è stato sottoposto ad audit indipendente. Diverse decisioni qui sotto sono implementate per fasi nel corso dei chain cut. Tutte le cifre sono misurazioni del nodo in esecuzione al momento della compilazione; è prevedibile che cambino e vanno rimisurate prima di essere citate.
Primitive crittografiche
1. Perché ML-KEM-768 (Kyber) per la cifratura delle note?
Il testo in chiaro di una nota è cifrato per il suo destinatario in una busta che resta sul registro pubblico a tempo indefinito. La sua riservatezza è dunque una proprietà irrevocabile (domanda 8): un avversario che ottenga in un qualsiasi momento successivo un computer quantistico crittograficamente rilevante potrebbe decifrare ogni busta storica sigillata con un KEM su curva ellittica, poiché l’algoritmo di Shor risolve il logaritmo discreto in tempo polinomiale. ML-KEM è standardizzato in NIST FIPS 203 e la sua sicurezza si riduce a Module-LWE, per il quale non si conosce alcun algoritmo quantistico efficiente. Il set di parametri 768 (categoria 3 del NIST) è stato scelto come compromesso tra margine di sicurezza e la chiave di incapsulamento da 1.184 byte che ogni indirizzo deve contenere. La busta è ML-KEM-768 combinato con ChaCha20-Poly1305: 1.348 byte, oppure 1.860 byte con il campo memo fisso.
Fonte: randprotocol.org (sezione post-quantistica); README di fullnode; docs/shielded.md §2
2. Perché impegni Poseidon2 anziché Pedersen?
Gli impegni di Pedersen sono perfettamente nascondenti ma solo computazionalmente vincolanti, e il loro vincolo si riduce all’ipotesi del logaritmo discreto, che un avversario quantistico infrange; un avversario in grado di calcolare logaritmi discreti può aprire un impegno su un valore diverso. Poiché un impegno pubblicato oggi deve restare solido e nascondente per tutta la vita del registro, lo schema deve poggiare su ipotesi ritenute valide anche contro avversari quantistici, il che in pratica significa una funzione hash. Poseidon2 è una funzione hash orientata all’aritmetizzazione, definita sul campo Goldilocks, per cui valutarla all’interno della STARK costa pochi vincoli. La stessa funzione hash istanzia l’impegno della nota, l’albero di Merkle di profondità 32 e il nullifier.
Fonte: randprotocol.org (sezione post-quantistica); docs/shielded.md §1–2
3. Perché due funzioni hash — BLAKE3 e Poseidon2?
Le due funzioni sono ottimizzate per modelli di costo diversi. Poseidon2 è usata ovunque un hash debba essere valutato all’interno di una prova — note, albero degli impegni, nullifier e tabelle interne della zkVM — perché il suo costo si misura in vincoli. BLAKE3 è usata ovunque non sia coinvolta alcuna prova e prevalga il throughput nativo: hash dei blocchi, radice di stato sull’albero, sull’insieme dei nullifier, sul registro dei validatori e sulla tabella dei programmi, e indirizzi dei validatori (il digest BLAKE3 della chiave pubblica). Poseidon2 è relativamente lenta su una CPU; BLAKE3 è relativamente costosa da aritmetizzare. Ciascuna è usata solo dove si applica il suo modello di costo.
Fonte: README di fullnode (riga firme / hash); docs/architecture.md
4. Perché Dilithium2 (ML-DSA) per le firme dei validatori?
Le firme di consenso garantiscono una proprietà rinnovabile (domanda 8): una successiva violazione dello schema consente di falsificare messaggi futuri ma non invalida retroattivamente i blocchi già finalizzati, per cui lo schema potrebbe in linea di principio essere sostituito prima che esista un avversario quantistico. Uno schema reticolare è stato comunque adottato fin dal genesis, in modo che i voti di consenso, le co-firme dei guardiani del bridge e il registro dei validatori condividano un unico tipo di chiave post-quantistica. Il nodo implementa il set di parametri Dilithium2 del round 3 (il crate crystals-dilithium), che differisce dal definitivo FIPS 204 ML-DSA-44; le chiavi pubbliche sono di 1.312 byte e le firme di 2.420 byte.
Fonte: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §2; randprotocol.org
5. Perché una STARK trasparente (FRI su Goldilocks) anziché una SNARK?
La scelta discende da tre requisiti. Primo, nessun trusted setup: la solidità poggia solo sulla resistenza alle collisioni di una funzione hash, non su una stringa di riferimento strutturata né su una curva compatibile con i pairing. Secondo, solidità plausibilmente post-quantistica: l’argomento non fa alcuna ipotesi sul logaritmo discreto né sui pairing. Terzo, compatibilità con lo schema di impegno basato su hash della domanda 2. Il costo è la dimensione della prova: la prova di un bundle è di circa 1,3 MB, da 300 a 600 volte la dimensione di una transazione schermata di Zcash o Monero. Questo costo è stato accettato ed è affrontato separatamente dall’aggregazione a livello di blocco (domande 31 e 34).
Fonte: randprotocol.org; docs/block-space.md §1; docs/zkvm.md
6. Perché il profilo FRI da 80 query anziché da 27?
Il profilo di produzione (80 query, fattore di blowup 8, 20 bit di grinding di proof-of-work) offre circa 86 bit di solidità dimostrabile, contro circa 42 bit del profilo da 27 query, a 2,75 volte la dimensione della prova. Il tempo di verifica resta pressoché invariato: da 809 ms a 838 ms a freddo, e circa 16 ms a caldo. Si è data priorità alla solidità dimostrabile rispetto alla dimensione della prova, e il costo in dimensione è stato trasferito al progetto di spazio di blocco e aggregazione.
Fonte: docs/block-space.md §1, §3
7. Perché l’affermazione post-quantistica è formulata per primitiva anziché come ‘128 bit a livello di protocollo’?
Le prime bozze affermavano una sicurezza post-quantistica di 128 bit per il protocollo nel suo complesso. Tale affermazione è incompatibile con il limite di Brassard–Høyer–Tapp, secondo il quale un avversario quantistico trova collisioni in un hash a 256 bit in circa 2^85 query, perciò è stata ritirata anziché qualificata. Il paper enuncia ora la sicurezza per primitiva e per ruolo — un hash di trascrizione a 384 bit, hash a 256 bit usati solo dove serve la resistenza alla preimmagine, Dilithium2, ML-KEM-768 e FRI su un campo di estensione — sotto le ipotesi Module-LWE e Module-SIS, con le funzioni hash modellate come oracoli casuali quantistici. L’hash di trascrizione del nodo è attualmente Poseidon2; la documentazione elenca questo punto come lacuna di configurazione aperta.
Fonte: randprotocol.org (sezione post-quantistica)
8. Che cos’è la classificazione ‘irrevocabile vs rinnovabile’ e perché guida le scelte?
Una proprietà di sicurezza è irrevocabile se un avversario che acquisisce una nuova capacità in un qualsiasi momento futuro può violarla retroattivamente per dati già pubblicati; la riservatezza delle note e la proprietà nascondente degli impegni sono di questo tipo, quindi devono essere resistenti ai computer quantistici al momento della pubblicazione. Una proprietà è rinnovabile se viene ristabilita a ogni uso, così che uno schema possa essere sostituito prima che la minaccia si concretizzi; le firme e la solidità delle prove sono di questo tipo. Ogni scelta di primitiva in questa sezione discende dalla classificazione della proprietà che essa protegge.
Fonte: randprotocol.org (sezione post-quantistica)
Il pool schermato
9. Perché un modello a note/UTXO, senza account né saldi?
Un registro basato su account pubblica i saldi per costruzione; nasconderli richiede di cifrare lo stato e di dimostrare enunciati sui testi cifrati, il che è sostanzialmente più costoso. Un pool di note memorizza solo impegni e nullifier, nessuno dei quali rivela un proprietario o un importo, perciò lo stato pubblico non contiene alcuna informazione sui saldi. L’unica eccezione è il registro dei validatori, i cui pesi di stake devono essere pubblici affinché le repliche concordino sulla composizione del quorum (domanda 29).
Fonte: docs/shielded.md §1–2; docs/staking.md §1
10. Perché l’indirizzo è di ~1,6 KB?
Un indirizzo schermato è composto dal campo proprietario pk di 32 byte e dalla chiave di incapsulamento ML-KEM-768 di 1.184 byte di cui il mittente ha bisogno per sigillare la busta; codificato in base58, ammonta a circa 1.667 caratteri. La lunghezza è una conseguenza diretta del KEM post-quantistico. Un progetto approvato (indirizzi schermati brevi, 2026-09-17) sostituisce l’indirizzo con un identificatore del destinatario di circa 256 bit che si risolve in un record aggiornabile, firmato con la chiave di spesa e servito dall’explorer, così che la chiave di incapsulamento venga recuperata anziché trascritta.
Fonte: docs/shielded.md §1; docs/superpowers/specs/2026-09-17-short-shielded-address.md
11. Perché ogni chiave è derivata da un’unica chiave di spesa a 256 bit?
Tutto il resto del materiale crittografico è una funzione deterministica di un unico segreto sk: la chiave di visualizzazione nk = H(NK, sk), il campo proprietario pk = H(PK, nk), il nullifier H(NF, nk, cm), la chiave di visualizzazione in uscita e la chiave di decapsulamento ML-KEM, ciascuna con il proprio separatore di dominio. Il file delle chiavi memorizza quindi solo sk, un backup è un unico valore e una nuova scansione dell’albero dalla foglia 0 recupera ogni nota. Poiché non esiste una seconda copia da cui recuperare, il wallet rifiuta di sovrascrivere un file di chiavi esistente.
Fonte: docs/shielded.md §1
12. Perché una forma di bundle fissa 4-in-4-out?
Una forma fissa rende ogni bundle della stessa dimensione e struttura, indipendentemente da ciò che sposta. Ogni bundle pubblica esattamente quattro nullifier e quattro impegni; gli slot inutilizzati sono note fittizie di valore zero, e l’output di resto è pubblicato anche quando il suo valore è zero, poiché l’assenza di un output di resto distinguerebbe la transazione. La specifica originale era 2-in-2-out, sul modello di Sapling. È stata ampliata a 4-in-4-out con il bundle ad asset nascosto, così che gli slot 0–1 trasportino un asset privato e gli slot 2–3 trasportino RAND per la commissione; quattro slot anziché tre consentono a un trasferimento di token di finanziare la propria commissione con fino a due note RAND.
Fonte: docs/shielded.md §2; docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §3
13. Perché una sola prova sposta qualsiasi asset (RAND, zUSD, token RPL)?
Prima della chain 14, un trasferimento di token comprendeva due bundle, uno per la commissione in RAND e uno per l’asset, il che richiedeva due prove e rivelava a qualsiasi osservatore quale token fosse stato spostato. Il guest con asset nascosto riceve l’identificatore dell’asset come input privato, per cui un trasferimento di zUSD è indistinguibile da un pagamento in RAND. Il guest rientra nel tier 14 (circa 100 s e 5,7 GB di memoria) solo perché legge i propri input in un ciclo e integra il controllo di appartenenza a Merkle; un’implementazione completamente srotolata richiede il tier 16 (circa 400 s e 21 GB), che supera la memoria di una macchina da 16 GB.
Source: docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3
14. Perché la commissione è pubblica e viene pagata al proposer?
Una commissione pubblica è coerente con il registro pubblico dello stake e rende l’ammissione poco costosa: un nodo può verificare la soglia minima della commissione prima di eseguire qualsiasi verifica. La prova del bundle impone l’equazione di bilancio Σ inputs = Σ outputs + fee + burn, per cui la commissione viene pagata con note nascoste senza rivelare quali note. Il costo accettato è che l’importo della commissione possa rivelare la classe della transazione (trasferimento o chiamata di programma).
Source: docs/superpowers/specs/2026-09-11-shielded-pool-design.md (rulings table); docs/fees.md §1
15. Perché i depositi (mint, bridge attest) hanno un importo pubblico?
Il valore che entra nel pool deve essere contabilizzato pubblicamente, e l’attestazione del bridge è la prova pubblica che sulla chain di origine è avvenuto un blocco corrispondente. La visibilità che ne deriva è limitata alla fase di ingresso, analoga a una transazione da trasparente a schermato (t-to-z) in Zcash; le spese successive della nota depositata sono nascoste.
Source: docs/superpowers/specs/2026-09-11-shielded-pool-design.md; docs/shielded.md (what is public table)
16. Perché il memo è un campo fisso di 512 byte?
Un campo a lunghezza fissa garantisce che il ledger non riveli se un memo sia presente né quanto sia lungo: su una chain con memo abilitato ogni envelope che crea una nota, inclusi dummy e resto, è esattamente di 1.860 byte. Il memo è trasportato solo all’interno dell’envelope cifrato, mai nella nota, nell’impegno (commitment) o nella prova, ed è leggibile esattamente dalle parti che possono già decifrare la nota. Un memo malformato viene decodificato come memo vuoto, in modo da non poter rendere irrecuperabile la nota stessa.
Source: docs/shielded.md §2; docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md
17. Perché la generazione della prova è locale, e come fa il prover delegato a non comprometterlo?
La prova stessa è l’autorizzazione di spesa: un bundle non contiene alcuna firma né alcun campo mittente, per cui la chiave di spesa non ha mai bisogno di lasciare il wallet. La prova del bundle di tier 14 richiede circa 5,7 GB di memoria, più di quanto telefoni e browser possano offrire, da cui il prover delegato. L’autorizzazione suddivisa (bundle guest v3, parametro di genesi hc_auth) separa i due ruoli: il prover riceve solo la chiave di visualizzazione nk e produce la prova del bundle, mentre il wallet produce una piccola prova di autorizzazione di tier 10 usando sk. Un prover può quindi costruire una prova del bundle ma non può autorizzare una spesa (domanda 36).
Source: docs/prover.md §1; docs/shielded.md (split authorisation); docs/superpowers/specs/2026-09-28-delegated-proving-design.md
18. Perché una finestra di ancoraggio di 256 blocchi?
Una prova viene costruita rispetto a una particolare radice dell’albero degli impegni (il suo anchor), e la costruzione di una prova di bundle di tier 14 richiede circa 100 s. Il ledger deve quindi accettare anchor che al momento dell’invio risalgono a diversi minuti prima. La finestra era di 64 blocchi nella specifica originale ed è stata ampliata a 256 blocchi al ridursi dell’intervallo tra i blocchi, mantenendo la sua durata in tempo reale superiore al tempo di generazione della prova.
Source: docs/superpowers/specs/2026-09-11-shielded-pool-design.md; docs/shielded.md
La zkVM e il calcolo riservato
19. Perché RV32I come ISA del guest (e non RV64)?
Una parola a 32 bit si scompone in esattamente quattro limb da un byte, e il primo di Goldilocks p = 2^64 − 2^32 + 1 è abbastanza grande da garantire che il prodotto di due valori a 32 bit non vada mai in overflow nel campo. RV64 raddoppierebbe il numero di colonne di limb nelle tabelle ALU e memoria. RISC-V è inoltre un target già supportato dai compilatori più diffusi, per cui i programmi guest sono normali binari compilati e non programmi scritti in un linguaggio progettato ad hoc.
Source: docs/zkvm.md §2; research/docs/01-isa.md (‘Why RV32, not RV64’)
20. Perché Goldilocks e non un campo a 256 bit?
Goldilocks è un primo a 64 bit la cui aritmetica si traduce in modo efficiente nelle istruzioni native a 64 bit della CPU e il cui gruppo moltiplicativo possiede un ampio sottogruppo di ordine potenza di due, come richiede FRI. Insieme alle parole a 32 bit, mantiene strette tutte le righe della traccia, il che rende fattibile su un laptop la generazione di prove con profilo di produzione. La sicurezza (soundness) persa lavorando su un campo piccolo viene recuperata estraendo le sfide di FRI da un campo di estensione.
Source: docs/zkvm.md §2; randprotocol.org (performance section)
21. Perché i gas tier invece della misurazione del gas per singolo opcode?
Il gas per opcode esiste in Ethereum perché ogni nodo riesegue ogni transazione e la lunghezza dell’esecuzione non è limitata in anticipo. In Rand nessun nodo esegue un programma: il mittente lo esegue una sola volta, off chain, e i nodi verificano un singolo STARK il cui costo di verifica dipende solo dal tier, non dal calcolo eseguito. La terminazione è imposta dal tier, poiché un’esecuzione che non si arresta entro 2^t cicli non ammette alcuna prova al tier t. Il prezzo è una soglia minima fissa più una stima del gas limitata dall’header, e la capacità del blocco è un budget di byte. Il gas compare solo all’interno dei guest interpreti EVM e sBPF, come stato privato, dove serve a riprodurre la semantica della chain di origine.
Source: docs/fees.md §3–4; docs/superpowers/specs/2026-09-28-gas-model-design.md
22. Perché la traccia è suddivisa in nove tabelle collegate da bus LogUp?
Una singola tabella monolitica riempirebbe ogni riga fino alla larghezza dell’operazione più ampia. Separare la traccia in nove tabelle — CPU, memoria, ALU, range, nibble, Poseidon2, programma, input e pubblica — ciascuna riempita solo fino alla propria altezza, mantiene contenuta la traccia complessiva. Gli argomenti LogUp stabiliscono le relazioni tra multinsiemi fra le tabelle. Le tabelle Keccak e SHA-256 sono opzionali e vengono incluse solo quando il guest invoca la corrispondente chiamata di sistema.
Source: docs/zkvm.md §5
23. Perché una chiamata di programma pubblica solo otto parole di output?
Una chiamata di programma è la prova che un codice pubblico è stato eseguito correttamente su input privati; il ledger registra soltanto la ricevuta. Otto parole a 32 bit bastano a vincolare un risultato, un impegno o una decisione, e una dimensione di output fissa garantisce che la forma della ricevuta non riveli nulla sul programma. Al momento gli output sono solo dati: un programma non può trasferire valore da sé.
Source: randprotocol.org/usecases (platform note); docs/confidential.md
24. Perché esiste una call-input envelope?
Un chiamante che conserva gli input privati può dimostrare in seguito su quali dati sia stata calcolata una chiamata. La call-input envelope rende questa possibilità duratura archiviando gli input, cifrati, insieme alla chiamata, dove un revisore designato può decifrarli con una chiave. Ciò estende la divulgazione selettiva — riservata al mercato, aperta a un regolatore designato — dai pagamenti all’esecuzione dei programmi.
Source: docs/confidential.md (‘Call input envelopes’)
25. Perché una modifica dell’insieme di vincoli è un hard fork?
Ogni nodo riverifica ogni prova durante la sincronizzazione, e una prova è valida solo rispetto all’insieme di vincoli (AIR) con cui è stata prodotta. Una modifica dell’AIR cambia quindi l’insieme delle chain valide, e viene introdotta con un taglio di genesi anziché essere adottata nodo per nodo.
Source: docs/architecture.md (‘Why a constraint-set change is a hard fork’)
26. Perché il riferimento è l’emulatore e non l’AIR?
L’emulatore è la specifica leggibile della macchina e l’AIR è una codifica di tale specifica come vincoli polinomiali. Dove i due divergono, l’errore è per definizione dell’AIR. Ciò colloca la definizione normativa nell’artefatto che per le persone è più pratico da verificare.
Source: docs/zkvm.md §5
Consenso e nodo
27. Perché HotStuff BFT concatenato?
Chained HotStuff offre finalità deterministica: con quorum ponderati per stake superiori a due terzi, un blocco è definitivo quando sopra di esso sono stati formati tre quorum certificate consecutivi, e un blocco definitivo non viene mai riorganizzato. L’intervallo tra i blocchi misurato è di 1,2 s e il tempo alla finalità di circa 3,6 s. Gli utenti istituzionali a cui il sistema è destinato richiedono una finalità di regolamento su cui poter registrare le scritture, cosa che una chain con finalità probabilistica non offre.
Source: fullnode README; randprotocol.org (performance section); docs/architecture.md §6
28. Perché la verifica delle prove è fuori dal ciclo di consenso?
Un nodo verifica ogni STARK quando ammette la transazione (circa 32 ms a caldo), prima di inoltrarla, per cui la verifica non si trova mai sul percorso critico della proposta di blocco. L’intervallo tra i blocchi è quindi determinato dalla latenza del consenso e non dalla dimensione della prova. I controlli sono ordinati per costo, con lo STARK verificato per ultimo, in modo che una transazione malformata venga respinta prima del passaggio più oneroso.
Source: randprotocol.org; docs/architecture.md (‘How it works’)
29. Perché il registro dei validator è pubblico quando tutto il resto è schermato?
Tutte le repliche devono concordare su quali validator possano proporre e su quali voti costituiscano un quorum, il che richiede che i pesi dello stake siano pubblici. Il registro contiene quindi gli importi dello stake in chiaro. Il legame con la proprietà resta nascosto: un bond è finanziato da una nota schermata e un prelievo viene versato su una nota, e nessuna delle due operazioni rivela di chi sia la nota.
Source: docs/staking.md §2
30. Perché un nodo in sincronizzazione riesegue ogni blocco invece di fidarsi dei certificati?
Un nodo che si unisce in ritardo verifica ogni quorum certificate, riverifica ogni proof di bundle e di chiamata e confronta le ricevute risultanti prima di accettare la catena. Poiché la validità è stabilita dalle prove e non dalle sole firme, questa procedura non è esposta agli attacchi a lungo raggio che colpiscono le catene protette soltanto da firme. La rimozione delle prove dalla cronologia è stata scartata perché eliminerebbe questa garanzia.
Fonte: docs/architecture.md; docs/aggregation.md (introduzione)
31. Perché mantenere il limite di blocco a 4 MiB quando una prova supera 1 MB?
Con un limite fisso, la dimensione del blocco non può crescere; quando la domanda supera la capacità, a essere limitato è invece il throughput (a tre trasferimenti schermati per blocco con il profilo a 80 query). Un limite di throughput è stato ritenuto una modalità di guasto più sicura rispetto a una crescita illimitata dei blocchi. Il rimedio scelto è l’aggregazione a livello di blocco, con una prova ricorsiva per blocco, anziché l’innalzamento del limite o la riduzione del livello di soundness.
Fonte: docs/block-space.md §1, §6
32. Perché la testnet riduce la cronologia a un giorno?
Un quorum certificate con 18 firme Dilithium2 occupa circa 44 KB e viene memorizzato due volte per blocco. Con blocchi per lo più vuoti ogni 1,4 s, questo corrispondeva a circa 6,6 GB per nodo al giorno; i dischi dei nodi si sono riempiti e la catena ha perso il quorum all’altezza 248.953. I full node della testnet conservano ora un giorno di cronologia, un singolo nodo di archivio la conserva per intero e i nodi della mainnet la conserveranno per intero. Lo stato del ledger — l’albero, l’insieme dei nullifier, il registro e i programmi — non viene mai eliminato.
Fonte: docs/superpowers/specs/2026-09-24-history-pruning-design.md
33. Perché libp2p?
Il nodo usa TCP con Noise e Yamux, gossipsub per transazioni e voti, Kademlia con un elenco di bootstrap per la scoperta dei peer, mDNS sulle reti locali e request-response per la sincronizzazione dei blocchi. Sono componenti standard e ampiamente diffusi, per cui il nodo eredita peer scoring, riconnessione e aggiornamenti del trasporto senza dover mantenere implementazioni proprie.
Fonte: README del fullnode (riga sul networking)
Mercato del proving e aggregazione
34. Perché l’aggregazione delle prove a livello di blocco?
Lo spazio di blocco cresce linearmente con il numero di bundle se ciascuno porta una propria prova di circa 1,3 MB. Un singolo STARK ricorsivo per blocco, che verifica tutte le N prove dei bundle, mantiene costante in N il costo on-chain della prova. I validatori verificano quindi una sola prova aggregata (circa 16 ms a caldo) su una CPU, così l’hardware commerciale può ancora validare, mentre gli aggregatori dotati di GPU competono in un mercato separato e senza permessi per la quota di commissioni destinata al proving e per un sussidio di blocco.
Fonte: docs/aggregation.md §1
35. Perché tre ruoli — validatore, aggregatore, prover delegato?
I tre ruoli hanno requisiti hardware diversi e sono pagati da parti diverse. Un validatore ordina e verifica le transazioni su una CPU ed è pagato con la quota di commissioni destinata alla verifica. Un aggregatore produce la prova ricorsiva del blocco su una GPU ed è pagato con la quota destinata al proving e con il sussidio. Un prover delegato produce la prova di un singolo bundle per un mittente il cui dispositivo non è in grado di farlo (un telefono o un browser) ed è pagato privatamente da quel mittente. La separazione dei ruoli mantiene economica la validazione e rende competitivo il proving.
Fonte: docs/prover.md §1
36. Perché un prover delegato non può rubare i fondi?
Con l’autorizzazione divisa, il prover riceve la viewing key nk ma non la spend key sk. La prova del bundle si impegna su c = H(AUTH, nk || salt), e la distinta prova di autorizzazione del wallet dimostra la conoscenza di sk per lo stesso c. Senza sk il prover può calcolare la prova del bundle ma non può produrre un’autorizzazione valida, e il wallet verifica la prova restituita prima di inviarla.
Fonte: docs/shielded.md (autorizzazione divisa); docs/prover.md §8
Il bridge e zUSD
37. Perché bloccare USDT/USDC sulle loro catene d’origine invece di emettere una nuova stablecoin?
L’emissione nativa su Rand renderebbe la capacità di riserva dipendente dalle decisioni di distribuzione degli emittenti, che sono al di fuori del controllo del progetto. Il blocco di USDT e USDC su Ethereum, BSC, Tron e Solana attinge le riserve dalle catene su cui questi asset già circolano e non introduce alcun nuovo emittente: ogni unità di zUSD è un credito su USDT o USDC detenuti in un contratto di custodia leggibile pubblicamente.
Fonte: randprotocol.org (sezione sulle riserve)
38. Perché un insieme di guardiani t-su-n, e perché dichiararlo apertamente?
L’attestazione è l’unica prova di cui Rand dispone che un blocco sia avvenuto su un’altra catena, e deve quindi essere firmata da un gruppo a soglia; un’attestazione valida richiede le firme di più di due terzi dei guardiani. L’assunzione di fiducia che ne deriva è dichiarata esplicitamente. La garanzia effettiva è la più debole tra la solvibilità delle riserve e l’integrità del bridge; una coalizione di t guardiani può autorizzare il minting senza un corrispondente blocco; e l’esposizione è limitata dalla custodia detenuta su ciascuna catena. Questa assunzione era in origine l’argomento contro la costruzione di un bridge. Non è ritirata, ma accettata in cambio di capacità di riserva.
Fonte: randprotocol.org (sezione sulle riserve, ‘Quanto costa’)
39. Perché una co-firma Dilithium2 accanto all’attestazione ECDSA?
Le catene di origine non offrono alcun verificatore di firme basate su reticoli, per cui i rilasci su quelle catene restano protetti dall’ECDSA classico, con un’esposizione limitata dalla custodia e dai massimali. Ogni messaggio che il ledger di Rand accetta dai guardiani — depositi e rotazioni dell’insieme dei guardiani — deve inoltre riportare un quorum di firme Dilithium2 degli stessi guardiani. Il percorso di mint è quindi post-quantistico anche se gli endpoint esterni non lo sono. Le co-firme sono trasmesse insieme all’attestazione e non richiedono alcuna modifica ai contratti già distribuiti.
Fonte: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1
40. Perché il blinding della nota di deposito è derivato anziché scelto?
In precedenza l’impegno della nota di deposito non era determinato finché un relayer non inviava l’attestazione, per cui due relayer potevano inviare la stessa attestazione con note diverse. Derivare il fattore di blinding r in modo deterministico dall’attestazione fissa l’impegno, così che gli invii concorrenti collidono su un unico impegno e il deposito non può essere coniato due volte.
Fonte: docs/bridge.md (F1, chain 14)
41. Perché USDT bloccati su Tron possono uscire come USDT su Ethereum?
zUSD è fungibile: ogni unità è un credito sulla riserva aggregata, non sulla catena attraverso cui è entrata. Disaccoppiare l’ingresso dall’uscita consente alla liquidità di spostarsi dove è richiesta, a condizione che la catena di destinazione detenga riserve sufficienti. Il paper sulla stablecoin dimostra che l’invariante S ≤ Σ_c R_c, ossia l’offerta totale limitata dalla somma delle riserve per catena, è preservato da ogni transizione di stato.
Fonte: randprotocol.org (sezione sulle riserve)
42. Perché lo schermo nasconde la distribuzione ma non la quantità?
L’offerta totale di zUSD è pubblica nel registro dei token e la riserva di ciascuna catena è un saldo pubblico, per cui la solvibilità può essere verificata da chiunque; ciò che è nascosto è la distribuzione delle quote detenute tra i proprietari. Vale una limitazione: i quattro saldi di riserva non possono essere osservati in modo atomico in un singolo istante, per cui per quelle catene il controllo rileva l’insolvenza a posteriori anziché prevenirla.
Fonte: randprotocol.org (sezione sulle riserve)
43. Perché un burn è l’unica transazione che nomina il proprio asset?
Un burn rilascia uno specifico asset su una specifica catena, per cui il contratto di custodia deve sapere di quale asset e di quale catena si tratti. Ogni altra transazione trasferisce un asset non identificato. Il burn porta anche la commissione del bridge, perché è l’unica transazione del bridge il cui mittente è il beneficiario.
Fonte: docs/architecture.md; docs/shielded.md §2
Conformità e divulgazione
44. Perché le viewing key anziché ‘privato per tutti’?
I regolatori non hanno accettato i sistemi di privacy in cui la divulgazione dipende dalla cooperazione della parte sotto indagine, come illustra il caso di Tornado Cash. Rand tratta quindi la divulgazione come un oggetto di protocollo. Il titolare, o un intermediario regolamentato, conserva una viewing key; un revisore può decifrare le transazioni indicate in una richiesta legittima; e l’obiettivo di progetto sono chiavi con ambito limitato che rivelano controparte e importo senza rivelare la strategia di trading. Per applicazioni come il payroll, questa verificabilità è un requisito e non una limitazione.
Fonte: randprotocol.org/usecases (sezione sulla regolamentazione; caso del payroll)
45. Perché la outgoing viewing key è distinta da quella in ingresso?
La separazione consente a un mittente di dimostrare quanto ha pagato senza ottenere accesso alla cronologia del destinatario, e viceversa. La outgoing viewing key ovk decifra le buste inviate dal wallet; la chiave di decapsulazione ML-KEM decifra le buste inviate a essa; e una chiave per singola transazione divulga esattamente un output a una terza parte.
Fonte: docs/shielded.md §1–2
Limitazioni note
46. Che cosa rivelano oggi le prove, e perché è documentato?
La revisione del 2026-09-27 ha rilevato che con il guest v1 (chain 14–15) ogni prova di bundle rivela quali slot di input contengono note reali e il peso di Hamming dell’indice di ciascuna foglia spesa. La causa è duplice: i totali LogUp per tabella sono pubblicati senza blinding, e il flusso di controllo del guest si ramifica a seconda che un input sia fittizio. Il rimedio è un guest senza ramificazioni (v2), da selezionare al prossimo genesis. Il risultato è pubblicato perché la rete è una testnet e la documentazione funge da registro di audit.
Fonte: docs/shielded.md (‘Cosa rivelano oggi le prove’)
47. Perché la crescita dello stato è sottovalutata nei prezzi?
Ethereum prezza le scritture nello storage perché lo stato memorizzato impone un costo permanente a ogni nodo. Rand attualmente prezza la crescita del commitment tree, del nullifier set e dello storage dei programmi soltanto attraverso la tariffa di deployment per parola e la tariffa fissa per bundle. Ciò è adeguato per una testnet, ma è registrato come questione di pricing aperta da risolvere prima di mainnet; la sua soluzione non richiede un metering per singolo opcode.
Fonte: docs/fees.md §3 (caveats)
48. Perché non è ancora stato completato alcun audit indipendente?
Il protocollo è in sviluppo attivo su una testnet gestita dal team, e prima che il design sia stabile sono previsti ulteriori insiemi di vincoli e chain cut. Il sito web lo dichiara in ogni pagina. I cicli di audit interno (v3–v5) sono pubblicati in docs/consensus.md e nelle specifiche di progetto, così che l’eventuale audit esterno disponga di una documentazione completa su cui lavorare.
Fonte: randprotocol.org (footer); docs/consensus.md