Executar um validator e um aggregator

Use esta página para dimensionar uma máquina antes de executar uma. Um validador é barato. Provar não é: a memória de uma prova cresce de forma acentuada com o seu tier, e é o único número que decide se uma máquina consegue fazer o trabalho. Todos os valores aqui são medições da testnet ou dos registros do fullnode. Os valores que ainda não são definitivos estão marcados.

O que cada função faz

Validadores e observadores nunca provam. Uma transferência shielded ou uma chamada é provada pela carteira que a envia ou, no caso da prova do bundle apenas, por um provador ao qual essa carteira está pareada (Running a node). Os validadores da frota não provam nada hoje.

A agregação de blocos está construída, mas não está ativa. Ela exige uma seção aggregation no genesis. A chain 20 não tem nenhuma: a agregação está desligada, como nas chains 9 a 19, e o build se recusa a iniciar com um genesis que contenha a seção.

Dimensionamento em resumo

O provador é single-threaded hoje. Um droplet de 16 vCPU rodou a 99% de um núcleo. Mais núcleos não tornam uma prova mais rápida; mais RAM decide se ela termina.

Validadores e observadores

Memória e CPU

Os dezoito validadores originais rodam em droplets de 2 GB. Verificar uma prova é barato:

A memória de que um validador precisa para verificar uma prova de chamada de tier 18 ou tier 20 está agora parcialmente medida, em um laptop Apple Silicon de 48 GB, independentemente do droplet da DigitalOcean que produziu cada prova: verificar a prova do transfer de tier 18 levou 50,2 s com pico de 3,66 GB de RSS (traduzido) ou 49,6 s (interpretador, RSS não registrado separadamente); verificar a prova do approve de tier 16 levou 12,2 s (RSS não registrado separadamente). O tier 20 não foi medido — ainda não existe prova de tier 20 para verificar. Desde a v0.5.6 um validador nunca constrói uma key desse tamanho: o cabeçalho da prova de uma chamada é verificado antes de qualquer verifier key ser construída, e uma chamada acima do tier 14 (ou com uma tabela keccak acima de 2^12, ou uma tabela sha256 acima de 2^13) é recusada, na admissão e como regra de validade de bloco. O pior cabeçalho de chamada admissível levou 4,7 s e 312 MB para verificar.

Um droplet de 1 vCPU e 2 GB não consegue compilar os binários. Compile em uma máquina maior e copie-os (veja configuração).

Disco

Na chain 20, como na chain 19, 24 dos 26 validadores rodam com --prune-history 24h e mantêm cerca de um dia de blocos; o próprio ledger (notes, nullifiers, anchors, o registro) nunca é podado. Os arquivos, obs1 e rand-archive-2 (ambos também validadores), rodam sem a flag. Um nó da mainnet nunca a utiliza. O nó se recusa a iniciar com menos de --min-free-disk-mb (1.024 MB por padrão) livres no sistema de arquivos do seu diretório de dados, e rand_getHealth responde disk_low abaixo de quatro vezes esse valor; um roll que espera por ok para em um nó que está enchendo. Veja History pruning para saber o que um nó podado ainda responde.

Apague o diretório de dados de uma chain desativada após uma transição. Os diretórios de dados são identificados pelo hash do genesis (data-<name>-<hash8>: -6210cf07 para a chain 20, -a3defc93 para a chain 19; os seis hosts guardiões usam /var/lib/randnode/data-20), portanto os antigos permanecem até que você os remova. Na transição para a chain 20, um validador regional (syd1) iniciou com disk_low, com 3,9 GB livres, e manteve a partida em 25 de 26, porque os diretórios das chains 14 a 17 ainda estavam nele; apagá-los liberou 22 GB. Mantenha o diretório da chain anterior por um dia como alvo de rollback e depois remova-o. Com blocos cheios, cada prova bruta de bundle tem cerca de 1,42 MB desde a chain 14 (cerca de 1,3 MB até a chain 13). Desde a chain 17, todo bundle também carrega uma prova de autorização, de modo que uma transferência tem cerca de 2,85 MB de provas: cerca de 1,49 MB da prova do bundle e 1,36 MB da prova de autorização (perfil de produção, medido em 2026-09-29). A agregação, quando ativa, reduz a prova de um bundle selado a cerca de 3 KB, a menos que o nó seja executado com --keep-raw-proofs. Ela não cobre a prova de autorização, que permanece com o tamanho integral.

Rede

Abra a porta TCP 30303 de entrada em um nó público. Nós atrás de NAT se conectam de saída com --bootstrap. Com blocos cheios de 4 MiB, o link de um validador transporta cerca de 2 MB/s.

Relógio

Um validador precisa de NTP. A chain 14 é a primeira chain em que o horário de relógio faz parte do consenso (endurecimento da ponte B2):

Um validador cujo relógio esteja 20 s atrasado deixa de votar silenciosamente: ele vê todo bloco honesto como adiantado em relação ao seu relógio e retém o voto, e nada falha. Na chain 20, dezoito dos vinte e seis precisam votar para que qualquer coisa seja confirmada. Verifique todos os validadores e instale o chrony onde o relógio não estiver sincronizado:

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

O mesmo limite de 15 s se aplica a um genesis. Defina timestamp_ms próximo ao horário de lançamento e nunca à frente dele: um genesis mais de 15 s no futuro não confirma o bloco 1 até que o horário real o alcance, e um genesis muito no passado deixa o horário do bloco atrás do relógio real, recuperando-se no máximo 60 s por bloco (docs/deploy.md). Um observador não vota, portanto a regra de voto não o limita.

Tamanhos do DigitalOcean em que a testnet é executada

Esta tabela cobre os dezoito validadores originais. Desde 2026-09-27, o validador A também é executado em um droplet (sgp1), não em um laptop. Mais oito validadores foram vinculados com bond na chain 15 (2026-09-27): os dois arquivos, obs1 e rand-archive-2 (fra1), e os seis hosts guardiões. Os tamanhos de seus droplets não estão registrados aqui, nem se mkc1 e mem1 foram redimensionados. Todos os 26 são validadores de genesis na chain 20, como na chain 19, com 1.000 RAND cada, e, em 2026-09-30, as 26 chaves estão em poder de um único operador.

Memória de prova

A carteira gera a prova de cada transação que envia, portanto quem chama um programa precisa da memória correspondente ao tier desse programa. Estes são os limites medidos. As execuções do tier 18 terminaram, geraram prova e foram verificadas no DigitalOcean; o tier 20 não. Desde a v0.5.6, a chain recusa uma prova de chamada acima do tier 14 (MAX_CALL_TIER); portanto, as linhas dos tiers 16, 18 e 20 abaixo são medições, não chamadas que a chain 20 admite; toda chamada confirmada na chain 14 era de tier 10.

As chamadas ERC-20 caem nos tiers 16 e 18, e o SPL Token no tier 20 (Ethereum, Solana). Nenhuma prova de tier 18 ou 20 foi gerada em uma máquina de 48 GB.

Agregadores

Um agregador observa a chain, reúne as provas de bundle de uma janela de blocos finalizados, gera uma prova agregada recursiva sobre elas e a submete. O bloco que a inclui é um bloco de selagem. O agregador recebe a parcela de prova dos bundles cobertos mais um subsídio de bloco em novos RAND, em seu endereço de pagamento registrado. A agregação é sem permissão: qualquer operador com um bond pode se registrar.

Ela só existe em uma chain cujo genesis tenha uma seção aggregation. A chain 20 não tem nenhuma, e sua compilação se recusa a iniciar com um genesis que tenha uma.

Hardware

Os valores de N = 2 e N = 3 foram medidos em um droplet DigitalOcean de 256 GB em 2026-09-28/29, sob o constraint set 7, e a prova de saída de produção precisou de mais do que os 256 GB dessa máquina. Nenhum foi medido novamente sob o constraint set 8, que as chains 18 a 20 executam; portanto, trate a linha de N = 1 como um limite inferior. O backend CUDA rodou pela primeira vez em hardware real em 2026-09-28, em uma NVIDIA H100: seus kernels são compilados para PTX em sm_80 e sm_90 e coincidem com a referência de CPU. A medição de produção em um nó de GPU da frota ainda está por fazer. Todo nó também paga uma construção de chave de inicialização única para o programa de agregação: 13,0 a 13,4 s no perfil de teste (2¹⁹) e, esperados, 30 a 70 s em produção (2²¹).

Comandos

# 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 uma seção aggregation em uma chain desse tipo: agregadores registrados, blocos não selados e o índice do cronograma de subsídio. rand_getUnsealed é a lista de trabalho.

Configuração

Estes passos seguem os scripts que a testnet usa (deploy/vps-setup.sh, deploy/update-droplet.sh). Eles produzem um validador ou um observador Linux.

1. Compilar em uma máquina de build

A compilação exige build-essential clang cmake pkg-config libssl-dev, Rust 1.98.1 (fixado por rust-toolchain.toml) e um checkout de circuits ao lado do checkout do fullnode. A primeira compilação leva de 10 a 20 minutos.

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

A chain 20 exige a v0.6.8 em todos os nós antes do init. Seu genesis traz campos que nenhuma compilação anterior lê (testnet, binding_domain, proof_window_blocks, program_state, os grupos rotation e fees da bridge, os tetos de gas, a admissão de staking por voto), e a v0.6.8 traz as mudanças de consenso CON-4 e CH-1 da auditoria v6. As provas continuam sendo feitas sob o conjunto de restrições 8, como nas chains 18 e 19, com uma prova de autorização ao lado de cada prova de bundle (hc_auth). Uma compilação v0.6.8 recusa o genesis das chains 14 a 17 em run e verify. Execute a mesma compilação que a frota executa. O arquivo de genesis está no main do fullnode (commit 74cfaca0), não na tag v0.6.8, daí a terceira linha git. O checkout de circuits deve estar no commit a partir do qual a release foi vendorizada, que a segunda linha git acima lê da árvore do fullnode. Acrescente -p randprotocol-prover para compilar também o rand-prover.

2. Instalar os binários no nó

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. Chave, genesis, firewall

No nó:

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

Gere a chave no nó, como acima, e mantenha-a fora de qualquer checkout. Nenhuma chave é mais versionada no repositório do fullnode (auditoria v3, OPS-1). Os arquivos deploy/node-*.key.json commitados para as chains 8 a 13 são seeds publicadas; as chaves de validador da chain 20 (as dezoito geradas para a chain 14 e as oito vinculadas na chain 15) foram geradas fora do repositório, e a frota guarda a chave de cada droplet em /root/keys/node-<name>.key.json, fora da árvore de código-fonte. O local importa em um nó provisionado pelos scripts da frota: deploy/rebuild-vps.sh e deploy/push-to-vps.sh sincronizam /root/fullnode com rsync usando --delete, de modo que uma chave mantida dentro dessa árvore é apagada pela próxima reconstrução e a unit então falha ao reiniciar. Desde a v0.6.8, keygen se recusa a sobrescrever um arquivo existente (a v0.6.7 o sobrescrevia sem perguntar); o test -e mantém a linha segura para reexecução em ambos os casos. Faça o backup da chave fora do host antes de vinculá-la.

init imprime o hash do genesis. Ele deve ser 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 (chain 20). O arquivo de genesis é genesis-chain20.json, em deploy/ no main do repositório do fullnode. Nomeie o diretório de dados com os oito primeiros caracteres do hash, como a frota faz (data-<name>-6210cf07), para que nunca colida com o da chain 19 (-a3defc93) nem com o de uma chain posterior. O genesis define estes limites. O limite de prova era de 8 MiB nas chains 13 a 16 e é de 4 MiB desde a chain 17, quando uma transação passou a carregar até três provas:

O genesis da chain 20 também traz consensus_domain: 1, binding_domain: 1, testnet: true, uma seção staking com admissão por voto, uma seção gas com tetos de preço, os grupos rotation e fees da bridge, hardening_v6 e os dois pins de guest hc_bundle e hc_auth; Executando um nó lista o que eles definem.

4. Uma unit do systemd

Esta é a unit que deploy/vps-setup.sh escreve, com os caminhos acima:

[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

Remova --validator para um observador. --prune-history 24h é o que os validadores da testnet executam, exceto os arquivos; remova-o para um nó que mantém o histórico completo, e nunca o passe na mainnet. Os multiaddrs de bootstrap da chain 20 são os nós C (fra1), D (ric1) e E (sgp1), inalterados desde a chain 19. A chain 20 roda com as chaves de validador geradas para a chain 14, e uma identidade p2p é derivada da chave do validador, de modo que estes peer ids são os que a chain 14 usava. Um novo nó que sincroniza desde o genesis também precisa de um peer com histórico completo; portanto, acrescente um dos dois arquivos (obs1, depois 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

Mantenha o RPC em 127.0.0.1, a menos que um firewall o proteja. Um nó que deva atender ao público abre ao lado dele o listener público da v0.6.8 (--public-rpc <ADDR>) e coloca um proxy na frente dele, nunca na frente de --rpc (JSON-RPC). Uma unit herdada da v0.6.7 não deve passar --prover-accept-spend-key, que a v0.6.8 recusa na inicialização.

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

5. Entrar no conjunto de validadores

Uma chave nova não pertence ao conjunto de nenhuma época. Na chain 20, ela precisa primeiro ser aprovada por voto: o genesis define staking.admission_by_vote, de modo que validadores que detêm mais de dois terços do peso de voto assinam, cada um, com rand-node admit sign --candidate <key or registration> --key <validator key> --genesis-hash <chain 20's hash>, e um deles envia os votos com rand-node admit submit; rand_getAdmitted então a lista. Depois, vincule ao menos 1.000 RAND a ela: imprima um registro com rand-node register --key /root/keys/node.key.json --payout rand1… --v2 (a chain 20 recusa um registro v1) e, então, faça o bond a partir de uma carteira com rand bond <address> 1000 --registration <hex>. O bond aguarda sua época de ativação, no mínimo três fronteiras de 1.000 blocos depois de sua confirmação, e no máximo 2.500 bps do peso ativo se tornam peso novo por fronteira (a chain 19 o limitava a 10.000 RAND fixos). Staking percorre o processo.

6. Atualização

Isto vale para uma compilação que roda a mesma chain. Passar de uma chain anterior para a chain 20 não é uma atualização: exige o novo binário, o novo genesis e um diretório de dados novo, e o diretório de dados da chain antiga pode ser apagado depois (deploy/retire-chain-dirs.sh; a frota o mantém por um dia para rollback). Para distribuir uma nova compilação sem um corte de chain, compile uma vez, compare o sha256 de rand-node e de rand, pare o serviço, instale e reinicie, um nó de cada vez. Algumas releases são distribuídas com parada total e início total (a regra de call-tier da v0.5.6, a mudança de wire de Status da v0.5.7, a verificação de provas mais estrita da v0.6); as notas de cada release dizem qual. A v0.6.7 foi distribuída na chain 18 um nó de cada vez; a v0.6.8 veio com a chain 20, com parada total e início total, porque suas mudanças de consenso CON-4 e CH-1 nunca devem ser distribuídas nó a nó. Espere cada nó voltar ao conjunto antes do próximo, para que o quórum nunca fique desfalcado em mais de um. deploy/update-droplet.sh <ip> [build-host] faz exatamente isso por SSH.

As releases até a v0.6.8 foram compiladas à mão em um único host e não são assinadas. A release v0.6.8 no GitHub traz rand-node, rand, rand-prover e SHA256SUMS, compilados no nó E; esse checksum detecta um download corrompido e não atesta a máquina de build. A v0.6.8 inclui um workflow de release que compila os binários a partir da tag, e deploy/update-droplet.sh recusa uma instalação sem um SHA256SUMS assinado, a menos que ALLOW_UNSIGNED=1 esteja definido. deploy/release-signers ainda não lista nenhuma chave, de modo que o caminho assinado não foi usado.

As chains 15, 16, 17 e 18 entraram no ar em 2,7 dias (de 2026-09-26 a 2026-09-29), cada uma com parada total da frota. A chain 19 veio em 2026-10-01 às 03:43 UTC, um re-genesis da chain 18 na mesma compilação, e a chain 20 no mesmo dia às 06:17 UTC, cortada de um snapshot da chain 19 no hard fork da v0.6.8; todos os nós pararam na altura 7.700 da chain 19. Uma política escrita de cortes (2026-09-30) vale a partir da chain 20; o registro de corte da chain 20 dispensou a reconstrução pelo segundo operador, porque um único operador detém todas as chaves. Um corte exige um motivo que uma atualização gradual não possa atender, uma lista publicada do que ele traz e do que descarta, uma lista de verificação de reconstrução dos clientes cumprida de antemão, um segundo operador que reconstrua o genesis até o mesmo hash, um plano de rollback e um id de chain nunca usado antes.