Eseguire un validator e un aggregator

Usa questa pagina per dimensionare una macchina prima di avviarne una. Un validatore costa poco. Generare le prove no: la memoria di una prova cresce rapidamente con il suo livello (tier), ed è l’unico numero che decide se una macchina può svolgere il compito. Ogni cifra qui riportata è una misurazione dalla testnet o dai registri del fullnode. Le cifre non definitive sono contrassegnate.

Che cosa fa ciascun ruolo

Validatori e osservatori non generano mai prove. Un trasferimento schermato o una chiamata viene provato dal wallet che lo invia oppure, per la sola prova del pacchetto, da un prover a cui quel wallet è abbinato (Esecuzione di un nodo). Oggi i validatori della flotta non generano alcuna prova.

L’aggregazione dei blocchi è implementata ma non attiva. Richiede una sezione aggregation nel genesis. La catena 20 non ne ha: l’aggregazione è disattivata, come sulle catene da 9 a 19, e la build si rifiuta di avviarsi su un genesis che contiene la sezione.

Dimensionamento in sintesi

Oggi il prover è a thread singolo. Un droplet da 16 vCPU ha funzionato al 99% di un solo core. Più core non rendono più veloce una singola prova; è la RAM in più a decidere se si conclude.

Validatori e osservatori

Memoria e CPU

I diciotto validatori originali girano su droplet da 2 GB. Verificare una prova costa poco:

La memoria che serve a un validatore per verificare una prova di chiamata tier 18 o tier 20 è ora in parte misurata, su un laptop Apple Silicon da 48 GB, indipendentemente dal droplet DigitalOcean che ha prodotto ciascuna prova: verificare la prova transfer tier 18 ha richiesto 50,2 s con un picco di RSS di 3,66 GB (tradotto) oppure 49,6 s (interprete, RSS non registrato separatamente); verificare la prova approve tier 16 ha richiesto 12,2 s (RSS non registrato separatamente). Il tier 20 non è stato misurato: non esiste ancora alcuna prova tier 20 da verificare. Dalla v0.5.6 un validatore non costruisce mai una chiave così grande: l’intestazione di una prova di chiamata viene controllata prima che si costruisca qualsiasi verifier key, e una chiamata oltre il tier 14 (o con una tabella keccak oltre 2^12, o una tabella sha256 oltre 2^13) viene rifiutata, in fase di ammissione e come regola di validità del blocco. La peggiore intestazione di chiamata ammissibile misurata ha richiesto 4,7 s e 312 MB per la verifica.

Un droplet da 1 vCPU e 2 GB non può compilare i binari. Compila su una macchina più grande e copiali (vedi setup).

Disco

Sulla catena 20, come sulla 19, 24 dei 26 validatori eseguono --prune-history 24h e conservano circa un giorno di blocchi; il ledger stesso (note, nullifier, ancore, il registro) non viene mai potato. Gli archivi, obs1 e rand-archive-2 (entrambi anche validatori), girano senza il flag. Un nodo mainnet non lo passa mai. Il nodo rifiuta di avviarsi con meno di --min-free-disk-mb (1.024 MB per impostazione predefinita) liberi sul filesystem della propria directory dei dati, e rand_getHealth risponde disk_low sotto il quadruplo di tale valore; un roll che attende ok si ferma su un nodo che si sta riempiendo. Vedi Potatura della storia per ciò a cui un nodo potato risponde ancora.

Elimina la directory dati di una catena dismessa dopo un cut-over. Le directory dati sono identificate dall’hash del genesis (data-<name>-<hash8>: -6210cf07 per la catena 20, -a3defc93 per la catena 19; i sei host guardian usano /var/lib/randnode/data-20), quindi quelle vecchie restano finché non le rimuovi. Al cut-over della catena 20 un validatore regionale (syd1) è partito in disk_low con 3,9 GB liberi e ha bloccato l’avvio a 25 su 26, perché sulla macchina c’erano ancora le directory delle catene da 14 a 17; eliminarle ha liberato 22 GB. Tieni la directory della catena precedente per un giorno come target di rollback, poi rimuovila. A blocchi pieni ogni prova raw di bundle pesa circa 1,42 MB dalla catena 14 (circa 1,3 MB fino alla catena 13). Dalla catena 17 ogni bundle porta anche una prova di autorizzazione, quindi un trasferimento pesa circa 2,85 MB di prove: circa 1,49 MB per la prova del bundle e 1,36 MB per la prova di autorizzazione (profilo di produzione, misurato il 2026-09-29). L’aggregazione, una volta attiva, riduce la prova di un bundle sigillato a circa 3 KB, a meno che il nodo non giri con --keep-raw-proofs. Non riguarda la prova di autorizzazione, che resta a dimensione piena.

Rete

Apri la porta TCP 30303 in ingresso su un nodo pubblico. I nodi dietro NAT si collegano in uscita con --bootstrap. Con blocchi pieni da 4 MiB un collegamento tra validatori trasporta circa 2 MB/s.

Orologio

Un validatore ha bisogno di NTP. La catena 14 è la prima in cui l’ora di sistema fa parte del consenso (bridge hardening B2):

Un validatore con l’orologio in ritardo di 20 s smette di votare in silenzio: vede ogni blocco onesto come in anticipo rispetto al proprio orologio e trattiene il voto, senza che nulla dia errore. Sulla catena 20, diciotto validatori su ventisei devono votare per far committare qualsiasi cosa. Controlla ogni validatore e installa chrony dove l’orologio non è sincronizzato:

timedatectl                     # want "System clock synchronized: yes" and "NTP service: active"
chronyc tracking 2>/dev/null || timedatectl show-timesync --all 2>/dev/null
apt-get install -y chrony && systemctl enable --now chrony

Lo stesso limite di 15 s vale per un genesis. Imposta timestamp_ms vicino all’ora di lancio e mai oltre: un genesis più di 15 s nel futuro non committa alcun blocco 1 finché l’ora reale non lo raggiunge, e uno molto nel passato lascia il tempo dei blocchi indietro rispetto all’orologio, recuperando al massimo 60 s per blocco (docs/deploy.md). Un osservatore non vota, quindi la regola di voto non lo vincola.

Dimensioni DigitalOcean su cui gira la testnet

Questa tabella riguarda i diciotto validatori originali. Dal 2026-09-27 anche il validatore A gira su un droplet (sgp1), non su un laptop. Altri otto validatori sono stati vincolati con bond sulla catena 15 (2026-09-27): i due archivi, obs1 e rand-archive-2 (fra1), e i sei host guardian. Le dimensioni dei loro droplet non sono registrate qui, e neppure se mkc1 e mem1 siano stati ridimensionati. Tutti e 26 sono validatori genesis sulla catena 20, come sulla catena 19, con 1.000 RAND ciascuno, e al 2026-09-30 tutte e 26 le chiavi sono detenute da un unico operatore.

Memoria di proving

Il wallet produce la prova di ogni transazione che invia, quindi chi chiama un programma ha bisogno della memoria del tier di quel programma. Questi sono i limiti misurati. Le esecuzioni del tier 18 sono terminate, con prova generata e verificata su DigitalOcean; quelle del tier 20 no. Dalla v0.5.6 la catena rifiuta una prova di chiamata sopra il tier 14 (MAX_CALL_TIER), quindi le righe dei tier 16, 18 e 20 qui sotto sono misurazioni, non chiamate che la catena 20 ammette; ogni chiamata committata sulla catena 14 era di tier 10.

Le chiamate ERC-20 arrivano ai tier 16 e 18 e SPL Token al tier 20 (Ethereum, Solana). Nessuna prova ai tier 18 o 20 è stata prodotta su una macchina da 48 GB.

Aggregatori

Un aggregatore osserva la catena, prende le prove dei bundle di una finestra di blocchi finalizzati, produce una prova ricorsiva aggregata che li copre e la invia. Il blocco che la include è un blocco di sigillatura. L’aggregatore riceve la quota di proving dei bundle coperti più un sussidio di blocco in nuovi RAND, al suo indirizzo di pagamento registrato. L’aggregazione è senza permessi: può registrarsi qualsiasi operatore con un bond.

Esiste solo su una catena il cui genesis ha una sezione aggregation. La catena 20 non ce l’ha, e la sua build si rifiuta di avviarsi su un genesis che la contenga.

Hardware

Le cifre per N = 2 e N = 3 sono state misurate su un droplet DigitalOcean da 256 GB il 2026-09-28/29, con il constraint set 7, e la prova di uscita di produzione richiedeva più dei 256 GB di quella macchina. Nessuna è stata rimisurata con il constraint set 8, che le catene da 18 a 20 eseguono, quindi considera la riga N = 1 come un limite inferiore. Il backend CUDA è girato per la prima volta su hardware reale il 2026-09-28, su una NVIDIA H100: i suoi kernel vengono compilati in PTX per sm_80 e sm_90 e coincidono con il riferimento CPU. La misurazione di produzione su un nodo GPU della flotta resta da fare. Ogni nodo paga inoltre una costruzione delle chiavi all’avvio, una tantum, per il programma di aggregazione: da 13,0 a 13,4 s al profilo di test (2¹⁹), e da 30 a 70 s attesi in produzione (2²¹).

Comandi

# print a signed registration; the bond burns out of a wallet bundle as the register bundle's burn
rand-node aggregator register --key agg.key.json --bond <RAND> --payout rand1… --rpc http://127.0.0.1:8545

# the daemon: poll rand_getUnsealed, fetch the raw bundles, prove, seal the payment note, submit
rand-node aggregate --key agg.key.json --rpc http://127.0.0.1:8545 --watch

# leave, then withdraw the released bond into a note at the payout address
rand-node aggregator unbond --key agg.key.json --rpc http://127.0.0.1:8545
rand-node aggregator withdraw --key agg.key.json --rpc http://127.0.0.1:8545

rand status mostra una sezione aggregation su una chain di questo tipo: aggregator registrati, blocchi non sigillati e indice del programma di sussidio. rand_getUnsealed è la lista di lavoro.

Setup

Questi passaggi seguono gli script che usa la testnet (deploy/vps-setup.sh, deploy/update-droplet.sh). Producono un validator o un observer Linux.

1. Compilare su un build host

La compilazione richiede build-essential clang cmake pkg-config libssl-dev, Rust 1.98.1 (fissato da rust-toolchain.toml) e un checkout di circuits accanto al checkout del fullnode. La prima compilazione richiede da 10 a 20 minuti.

git clone https://github.com/randprotocol/fullnode
git clone https://github.com/randprotocol/zkp-circuits circuits
cd fullnode
git checkout v0.6.8                       # c9c9bd3c, the build chain 20 runs
git -C ../circuits checkout "$(sed -n 's/^circuits: //p' crates/randprotocol-zkvm/guests-compiled/PROVENANCE.md)"   # aeacf31 for v0.6.8
git show origin/main:deploy/genesis-chain20.json > deploy/genesis-chain20.json   # committed after the tag
cargo build --release -p randprotocol-node -p randprotocol-client
sha256sum target/release/rand-node         # compare on every node you copy it to

La chain 20 richiede v0.6.8 su ogni nodo prima di init. Il suo genesis contiene campi che nessuna build precedente legge (testnet, binding_domain, proof_window_blocks, program_state, i gruppi rotation e fees del bridge, i massimali di gas, l’ammissione allo staking tramite voto), e v0.6.8 include le modifiche di consenso CON-4 e CH-1 dell’audit v6. Le proof sono ancora prodotte con il constraint set 8, come sulle chain 18 e 19, con una proof di autorizzazione accanto a ogni proof di bundle (hc_auth). Una build v0.6.8 rifiuta il genesis delle chain da 14 a 17 con run e verify. Eseguite l’unica build che esegue la flotta. Il file di genesis si trova nel main del fullnode (commit 74cfaca0), non nel tag v0.6.8, da cui la terza riga git. Il checkout di circuits deve essere al commit da cui la release è stata vendorizzata, che la seconda riga git qui sopra legge dall’albero del fullnode. Aggiungete -p randprotocol-prover per compilare anche rand-prover.

2. Installare i binari sul nodo

scp target/release/rand-node target/release/rand deploy/genesis-chain20.json root@<node>:/root/
ssh root@<node> 'install -m 755 /root/rand-node /root/rand /usr/local/bin/'

3. Chiave, genesis, firewall

Sul nodo:

install -d -m 700 /root/keys
test -e /root/keys/node.key.json || rand-node keygen --out /root/keys/node.key.json   # prints the address; keep the seed secret
rand-node init --datadir /root/data-6210cf07 --genesis /root/genesis-chain20.json
timedatectl                                        # "System clock synchronized: yes" (see Clock)
ufw allow 22/tcp && ufw allow 30303/tcp && ufw enable

Generate la chiave sul nodo, come sopra, e tenetela fuori da qualsiasi checkout. Nessuna chiave è più tracciata nel repository del fullnode (audit v3, OPS-1). I file deploy/node-*.key.json committati per le chain da 8 a 13 sono seed pubblicati; le chiavi dei validator della chain 20 (le diciotto generate per la chain 14 e le otto vincolate sulla chain 15) sono state generate fuori dal repository, e la flotta conserva la chiave di ogni droplet in /root/keys/node-<name>.key.json, fuori dall’albero dei sorgenti. La posizione conta su un nodo predisposto dagli script della flotta: deploy/rebuild-vps.sh e deploy/push-to-vps.sh sincronizzano /root/fullnode con rsync e --delete, quindi una chiave tenuta dentro quell’albero viene cancellata dalla ricostruzione successiva e l’unit non riesce più a riavviarsi. Da v0.6.8 keygen rifiuta di sovrascrivere un file esistente (v0.6.7 lo sovrascriveva senza chiedere); il test -e rende la riga sicura da rieseguire in entrambi i casi. Fate un backup della chiave fuori dall’host prima di vincolarla.

init stampa l’hash del genesis. Deve risultare 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 (chain 20). Il file di genesis è genesis-chain20.json in deploy/ del repository del fullnode, su main. Date alla directory dei dati il nome dei primi otto caratteri dell’hash, come fa la flotta (data-<name>-6210cf07), così da non collidere mai con quella della chain 19 (-a3defc93) né con quella di una chain successiva. Il genesis imposta questi limiti. Il tetto delle proof era 8 MiB sulle chain da 13 a 16 ed è 4 MiB dalla chain 17, dove una transazione ha cominciato a portare fino a tre proof:

Il genesis della chain 20 contiene anche consensus_domain: 1, binding_domain: 1, testnet: true, una sezione staking con ammissione tramite voto, una sezione gas con massimali di prezzo, i gruppi rotation e fees del bridge, hardening_v6 e i due pin di guest hc_bundle e hc_auth; Running a node elenca ciò che impostano.

4. Un’unit systemd

Questa è l’unit che scrive deploy/vps-setup.sh, con i percorsi indicati sopra:

[Unit]
Description=RAND full node
After=network-online.target
[Service]
Environment=RUST_LOG=info,libp2p=warn,libp2p_mdns=off
ExecStart=/usr/local/bin/rand-node run --datadir /root/data-6210cf07 --key /root/keys/node.key.json --validator --listen /ip4/0.0.0.0/tcp/30303 --rpc 127.0.0.1:8545 --no-mdns --prune-history 24h --bootstrap <multiaddr> --bootstrap <multiaddr>
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target

Eliminate --validator per un observer. --prune-history 24h è ciò che eseguono i validator della testnet, tranne gli archivi; eliminatelo per un nodo che conserva la storia completa, e non passatelo mai su mainnet. I multiaddr di bootstrap per la chain 20 sono i nodi C (fra1), D (ric1) ed E (sgp1), invariati rispetto alla chain 19. La chain 20 gira sulle chiavi dei validator generate per la chain 14, e un’identità p2p deriva dalla chiave del validator, quindi questi peer id sono quelli usati dalla chain 14. Un nuovo nodo che si sincronizza dal genesis ha inoltre bisogno di un peer con storia completa, perciò aggiungete uno dei due archivi (obs1, poi rand-archive-2):

/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/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQ
/ip4/168.144.46.203/tcp/30303/p2p/12D3KooWS5usdMPvsbaWSaT2xtKndHvDYurwmueoNvaRRarb2wRf
/ip4/206.81.29.236/tcp/30303/p2p/12D3KooWPocyZGcNB9Vp68VSfgVvNXhSzBBoJa4h9R1yMkp71XHh

Tenete l’RPC su 127.0.0.1 a meno che un firewall non lo protegga. Un nodo che deve servire il pubblico apre accanto ad esso il listener pubblico di v0.6.8 (--public-rpc <ADDR>) e vi pone davanti un proxy, mai davanti a --rpc (JSON-RPC). Un’unit ereditata da v0.6.7 non deve passare --prover-accept-spend-key, che v0.6.8 rifiuta all’avvio.

systemctl daemon-reload && systemctl enable --now rand-node
journalctl -u rand-node -f
rand status                       # height climbing, peer_count rising

5. Entrare nel set dei validator

Una nuova chiave non fa parte del set di nessuna epoch. Sulla chain 20 deve prima essere votata: il suo genesis imposta staking.admission_by_vote, quindi i validator che detengono più di due terzi del peso di voto la firmano ciascuno con rand-node admit sign --candidate <key or registration> --key <validator key> --genesis-hash <chain 20's hash>, e uno di essi invia i voti con rand-node admit submit; rand_getAdmitted la elenca poi. Quindi vincolate ad essa almeno 1.000 RAND: stampate una registrazione con rand-node register --key /root/keys/node.key.json --payout rand1… --v2 (la chain 20 rifiuta una registrazione v1), poi eseguite il bond da un wallet con rand bond <address> 1000 --registration <hex>. Il bond attende la sua epoch di attivazione, al più presto tre confini di 1.000 blocchi dopo il suo commit, e al massimo 2.500 bps del peso attivo diventano nuovo peso per confine (la chain 19 lo limitava a un valore fisso di 10.000 RAND). Staking lo illustra passo per passo.

6. Aggiornamento

Questo vale per una build che esegue la stessa chain. Passare da una chain precedente alla chain 20 non è un aggiornamento: servono il nuovo binario, il nuovo genesis e una directory dei dati nuova, e la directory dei dati della vecchia chain può essere eliminata in seguito (deploy/retire-chain-dirs.sh; la flotta la conserva per un giorno in vista di un rollback). Per distribuire una nuova build senza un cambio di chain, compilate una volta, confrontate lo sha256 di rand-node e di rand, fermate il servizio, installate e riavviate, un nodo alla volta. Alcune release vengono distribuite con arresto totale e riavvio totale (la regola dei call-tier di v0.5.6, la modifica del wire Status di v0.5.7, la verifica delle proof più rigorosa di v0.6); le note di ogni release indicano quale. v0.6.7 è stata distribuita sulla chain 18 un nodo alla volta; v0.6.8 è arrivata con la chain 20, con arresto totale e riavvio totale, perché le sue modifiche di consenso CON-4 e CH-1 non devono mai essere distribuite nodo per nodo. Attendete che ogni nodo si riunisca prima del successivo, così il quorum non risulta mai carente di più di uno. deploy/update-droplet.sh <ip> [build-host] fa esattamente questo via SSH.

Le release fino a v0.6.8 sono state compilate a mano su un solo host e non sono firmate. La release v0.6.8 su GitHub contiene rand-node, rand, rand-prover e SHA256SUMS, compilati sul nodo E; quel checksum intercetta un download corrotto e non garantisce per il build host. v0.6.8 include un workflow di release che compila i binari dal tag, e deploy/update-droplet.sh rifiuta un’installazione senza un SHA256SUMS firmato, a meno che non sia impostato ALLOW_UNSIGNED=1. deploy/release-signers non elenca ancora alcuna chiave, quindi il percorso firmato non è mai stato usato.

Le chain 15, 16, 17 e 18 sono entrate in funzione nell’arco di 2,7 giorni (dal 2026-09-26 al 2026-09-29), ciascuna con un arresto totale della flotta. La chain 19 è seguita il 2026-10-01 alle 03:43 UTC, un re-genesis della chain 18 sulla stessa build, e la chain 20 lo stesso giorno alle 06:17 UTC, ricavata da uno snapshot della chain 19 all’hard fork v0.6.8; ogni nodo si è fermato all’altezza 7.700 della chain 19. Una politica scritta di cambio chain (2026-09-30) si applica dalla chain 20 in poi; il registro del cambio della chain 20 ha derogato alla ricostruzione da parte di un secondo operatore, perché un solo operatore detiene tutte le chiavi. Un cambio richiede un motivo che un aggiornamento progressivo non può soddisfare, un elenco pubblicato di ciò che porta e di ciò che elimina, una checklist di ricostruzione dei client completata in anticipo, un secondo operatore che ricostruisce il genesis fino allo stesso hash, un piano di rollback e un id di chain mai usato prima.