Ejecutar un validator y un aggregator

Use esta página para dimensionar una máquina antes de ejecutar una. Un validador es barato. Probar no lo es: la memoria de una prueba crece de forma abrupta con su nivel, y es la única cifra que decide si una máquina puede hacer el trabajo. Todas las cifras de aquí son mediciones de la testnet o de los registros del fullnode. Las cifras que no son definitivas están marcadas.

Qué hace cada rol

Los validadores y los observadores nunca prueban. Una transferencia blindada o una llamada la prueba la wallet que la envía o, solo para la prueba del bundle, un prover con el que esa wallet está emparejada (Running a node). Los validadores de la flota no prueban nada hoy.

La agregación de bloques está construida, pero no activa. Necesita una sección aggregation en el genesis. La chain 20 no la tiene: la agregación está desactivada, como en las chains 9 a 19, y la compilación se niega a arrancar con un genesis que incluya la sección.

Dimensionamiento de un vistazo

El prover es monohilo hoy. Un droplet de 16 vCPU funcionó al 99 % de un núcleo. Más núcleos no hacen más rápida una prueba; más RAM decide si termina.

Validadores y observadores

Memoria y CPU

Los dieciocho validadores originales funcionan en droplets de 2 GB. Verificar una prueba es barato:

La memoria que necesita un validador para verificar una prueba de llamada de nivel 18 o 20 está ahora medida en parte, en un portátil Apple Silicon de 48 GB, con independencia del droplet de DigitalOcean que produjo cada prueba: verificar la prueba de transfer de nivel 18 tardó 50,2 s con un RSS máximo de 3,66 GB (traducido) o 49,6 s (intérprete, RSS no registrado por separado); verificar la prueba de approve de nivel 16 tardó 12,2 s (RSS no registrado por separado). El nivel 20 no está medido: todavía no existe ninguna prueba de nivel 20 que verificar. Desde la v0.5.6 un validador nunca construye una clave tan grande: el encabezado de una prueba de llamada se comprueba antes de construir cualquier verifier key, y una llamada por encima del nivel 14 (o con una tabla keccak por encima de 2^12, o una tabla sha256 por encima de 2^13) se rechaza, en la admisión y como regla de validez de bloque. El peor encabezado de llamada admisible midió 4,7 s y 312 MB para verificarse.

Un droplet de 1 vCPU y 2 GB no puede compilar los binarios. Compile en una máquina más grande y copie los binarios (véase configuración).

Disco

En la chain 20, como en la chain 19, 24 de los 26 validadores ejecutan --prune-history 24h y conservan aproximadamente un día de bloques; el ledger en sí (notes, nullifiers, anchors, el registro) nunca se poda. Los archivos, obs1 y rand-archive-2 (ambos también validadores), funcionan sin la opción. Un nodo de mainnet nunca la usa. El nodo se niega a arrancar con menos de --min-free-disk-mb (1.024 MB por defecto) libres en el sistema de archivos de su directorio de datos, y rand_getHealth responde disk_low por debajo de cuatro veces esa cifra; un despliegue que espera a ok se detiene en un nodo que se está llenando. Véase History pruning para lo que un nodo podado sigue respondiendo.

Elimine el directorio de datos de una cadena retirada después de un cambio de cadena. Los directorios de datos se identifican por el hash del génesis (data-<name>-<hash8>: -6210cf07 para la cadena 20, -a3defc93 para la cadena 19; los seis hosts guardianes usan /var/lib/randnode/data-20), por lo que los antiguos permanecen hasta que se eliminan. En el cambio a la cadena 20, un validador regional (syd1) arrancó con disk_low y 3,9 GB libres, y mantuvo el arranque en 25 de 26, porque los directorios de las cadenas 14 a 17 seguían en él; borrarlos liberó 22 GB. Conserve el directorio de la cadena anterior durante un día como destino de reversión y luego elimínelo. Con bloques llenos, cada prueba de bundle sin procesar ocupa unos 1,42 MB desde la cadena 14 (unos 1,3 MB hasta la cadena 13). Desde la cadena 17, cada bundle lleva además una prueba de autorización, de modo que una transferencia ocupa unos 2,85 MB de pruebas: unos 1,49 MB de la prueba del bundle y 1,36 MB de la prueba de autorización (perfil de producción, medido el 2026-09-29). La agregación, una vez activa, reduce la prueba de un bundle sellado a unos 3 KB, salvo que el nodo se ejecute con --keep-raw-proofs. No abarca la prueba de autorización, que conserva su tamaño completo.

Red

Abra el puerto TCP 30303 de entrada en un nodo público. Los nodos detrás de NAT se conectan hacia fuera con --bootstrap. Con bloques completos de 4 MiB, un enlace de validador transporta unos 2 MB/s.

Reloj

Un validador necesita NTP. La cadena 14 es la primera en la que la hora de reloj es parte del consenso (endurecimiento del puente B2):

Un validador cuyo reloj atrasa 20 s deja de votar en silencio: ve cada bloque honesto como adelantado respecto de su reloj y retiene su voto, sin que nada falle. En la cadena 20, dieciocho de veintiséis deben votar para confirmar cualquier cosa. Compruebe cada validador e instale chrony donde el reloj no esté 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

El mismo límite de 15 s se aplica a un génesis. Fije timestamp_ms cerca de la hora de lanzamiento y nunca por delante de ella: un génesis más de 15 s en el futuro no confirma ningún bloque 1 hasta que la hora real lo alcance, y uno muy anterior deja la hora de bloque por detrás del reloj, que se pone al día a no más de 60 s por bloque (docs/deploy.md). Un observador no vota, así que la regla de voto no lo obliga.

Tamaños de DigitalOcean en los que se ejecuta la testnet

Esta tabla abarca los dieciocho validadores originales. Desde el 2026-09-27 el validador A también se ejecuta en un droplet (sgp1), no en un portátil. Se vincularon ocho validadores más en la cadena 15 (2026-09-27): los dos archivos, obs1 y rand-archive-2 (fra1), y los seis hosts guardianes. Aquí no se registran los tamaños de sus droplets, ni si mkc1 y mem1 fueron redimensionados. Los 26 son validadores de génesis en la cadena 20, como en la cadena 19, con 1,000 RAND cada uno, y a 2026-09-30 las 26 claves están en manos de un único operador.

Memoria de prueba

La wallet genera una prueba de cada transacción que envía, así que quien llama a un programa necesita la memoria correspondiente al tier de ese programa. Estos son los límites medidos. Las ejecuciones del tier 18 han terminado, se han probado y verificado en DigitalOcean; la del tier 20 no. Desde v0.5.6 la cadena rechaza una prueba de llamada por encima del tier 14 (MAX_CALL_TIER), así que las filas de los tiers 16, 18 y 20 de abajo son mediciones, no llamadas que la cadena 20 admita; toda llamada confirmada en la cadena 14 fue de tier 10.

Las llamadas ERC-20 caen en los tiers 16 y 18 y SPL Token en el tier 20 (Ethereum, Solana). No se ha generado ninguna prueba de tier 18 o 20 en una máquina de 48 GB.

Agregadores

Un agregador vigila la cadena, toma las pruebas de bundle de una ventana de bloques finalizados, genera una prueba agregada recursiva sobre ellas y la envía. El bloque que la incluye es un bloque de sellado. El agregador recibe la parte de prueba de los bundles cubiertos más un subsidio de bloque en RAND nuevos, en su dirección de pago registrada. La agregación no requiere permiso: cualquier operador con una fianza puede registrarse.

Solo existe en una cadena cuyo génesis tiene una sección aggregation. La cadena 20 no la tiene, y su compilación se niega a arrancar con un génesis que sí la tenga.

Hardware

Las cifras de N = 2 y N = 3 se midieron en un droplet de DigitalOcean de 256 GB el 2026-09-28/29, bajo el conjunto de restricciones 7, y la prueba de salida de producción necesitó más que los 256 GB de esa máquina. Ninguna se ha vuelto a medir bajo el conjunto de restricciones 8, que ejecutan las cadenas 18 a 20, así que trate la fila de N = 1 como un límite inferior. El backend CUDA se ejecutó por primera vez en hardware real el 2026-09-28, en una NVIDIA H100: sus kernels se compilan a PTX para sm_80 y sm_90 y coinciden con la referencia de CPU. La medición de producción en un nodo GPU de la flota sigue pendiente. Cada nodo paga además una construcción de claves única al arrancar para el programa de agregación: de 13.0 a 13.4 s en el perfil de prueba (2¹⁹), y se esperan de 30 a 70 s en producción (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 muestra una sección aggregation en una cadena de este tipo: agregadores registrados, bloques sin sellar y el índice del calendario de subsidios. rand_getUnsealed es la lista de trabajo.

Configuración

Estos pasos siguen los scripts que usa la testnet (deploy/vps-setup.sh, deploy/update-droplet.sh). Producen un validador u observador Linux.

1. Compilar en un host de compilación

La compilación necesita build-essential clang cmake pkg-config libssl-dev, Rust 1.98.1 (fijado por rust-toolchain.toml) y una copia de trabajo de circuits junto a la copia de trabajo de fullnode. La primera compilación tarda 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

La chain 20 necesita v0.6.8 en cada nodo antes de init. Su génesis incluye campos que ninguna compilación anterior lee (testnet, binding_domain, proof_window_blocks, program_state, los grupos rotation y fees del puente, los techos de gas, la admisión de staking por votación), y v0.6.8 incluye los cambios de consenso CON-4 y CH-1 de la auditoría v6. Las pruebas se siguen generando bajo el conjunto de restricciones 8, como en las chains 18 y 19, con una prueba de autorización junto a cada prueba de paquete (hc_auth). Una compilación v0.6.8 rechaza el génesis de las chains 14 a 17 en run y verify. Ejecute la única compilación que ejecuta la flota. El archivo de génesis está en la rama main de fullnode (commit 74cfaca0), no en la etiqueta v0.6.8; de ahí la tercera línea de git. La copia de trabajo de circuits debe estar en el commit a partir del cual se incorporó la versión, que la segunda línea de git anterior lee del árbol de fullnode. Añada -p randprotocol-prover para compilar también rand-prover.

2. Instalar los binarios en el 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. Clave, génesis, cortafuegos

En el 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

Genere la clave en el nodo, como se indica arriba, y manténgala fuera de cualquier copia de trabajo. Ya no se rastrea ninguna clave en el repositorio de fullnode (auditoría v3, OPS-1). Los archivos deploy/node-*.key.json confirmados para las chains 8 a 13 son semillas publicadas; las claves de validador de la chain 20 (las dieciocho generadas para la chain 14 y las ocho vinculadas en la chain 15) se generaron fuera del repositorio, y la flota guarda la clave de cada droplet en /root/keys/node-<name>.key.json, fuera del árbol de código fuente. La ubicación importa en un nodo aprovisionado con los scripts de la flota: deploy/rebuild-vps.sh y deploy/push-to-vps.sh sincronizan /root/fullnode con rsync y --delete, de modo que una clave guardada dentro de ese árbol se elimina en la siguiente recompilación y la unidad ya no logra reiniciarse. Desde v0.6.8, keygen se niega a sobrescribir un archivo existente (v0.6.7 lo sobrescribía sin preguntar); test -e mantiene la línea segura para volver a ejecutarla en ambos casos. Haga una copia de seguridad de la clave fuera del host antes de vincularla.

init imprime el hash del génesis. Debe ser 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 (chain 20). El archivo de génesis es genesis-chain20.json, en deploy/ del repositorio de fullnode, en main. Nombre el directorio de datos con los primeros ocho caracteres del hash, como hace la flota (data-<name>-6210cf07), para que nunca colisione con el de la chain 19 (-a3defc93) ni con el de una chain posterior. El génesis fija estos límites. El límite de prueba era de 8 MiB en las chains 13 a 16 y es de 4 MiB desde la chain 17, donde una transacción empezó a incluir hasta tres pruebas:

El génesis de la chain 20 incluye además consensus_domain: 1, binding_domain: 1, testnet: true, una sección staking con admisión por votación, una sección gas con techos de precio, los grupos rotation y fees del puente, hardening_v6 y los dos pines de guest hc_bundle y hc_auth; Running a node enumera lo que establecen.

4. Una unidad de systemd

Esta es la unidad que escribe deploy/vps-setup.sh, con las rutas anteriores:

[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

Omita --validator para un observador. --prune-history 24h es lo que ejecutan los validadores de la testnet, salvo los archivos; omítalo en un nodo que conserve el historial completo y no lo pase nunca en mainnet. Las multiaddrs de arranque de la chain 20 son los nodos C (fra1), D (ric1) y E (sgp1), sin cambios respecto de la chain 19. La chain 20 funciona con las claves de validador generadas para la chain 14, y la identidad p2p se deriva de la clave de validador, de modo que estos identificadores de par son los que usó la chain 14. Un nodo nuevo que se sincroniza desde el génesis necesita además un par con historial completo, así que añada uno de los dos archivos (obs1 y luego 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

Mantenga el RPC en 127.0.0.1 a menos que lo proteja un cortafuegos. Un nodo que deba servir al público abre junto a él el listener público de v0.6.8 (--public-rpc <ADDR>) y coloca un proxy delante de este, nunca delante de --rpc (JSON-RPC). Una unidad heredada de v0.6.7 no debe pasar --prover-accept-spend-key, que v0.6.8 rechaza al arrancar.

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

5. Unirse al conjunto de validadores

Una clave nueva no está en el conjunto de ninguna época. En la chain 20 primero debe ser admitida por votación: su génesis establece staking.admission_by_vote, de modo que los validadores que reúnan más de dos tercios del peso de voto la firman cada uno con rand-node admit sign --candidate <key or registration> --key <validator key> --genesis-hash <chain 20's hash>, y uno envía los votos con rand-node admit submit; después rand_getAdmitted la incluye en su lista. A continuación, vincule al menos 1,000 RAND a ella: imprima un registro con rand-node register --key /root/keys/node.key.json --payout rand1… --v2 (la chain 20 rechaza un registro v1) y luego vincule desde una wallet con rand bond <address> 1000 --registration <hex>. La vinculación espera a su época de activación, como mínimo tres fronteras de 1,000 bloques después de confirmarse, y como máximo el 2,500 bps del peso activo se convierte en peso nuevo por frontera (la chain 19 lo limitaba a 10,000 RAND fijos). Staking lo explica paso a paso.

6. Actualización

Esto se aplica a una compilación que ejecuta la misma chain. Pasar de una chain anterior a la chain 20 no es una actualización: requiere el binario nuevo, el génesis nuevo y un directorio de datos limpio, y el directorio de datos de la chain anterior puede eliminarse después (deploy/retire-chain-dirs.sh; la flota lo conserva un día por si hay que revertir). Para desplegar una compilación nueva sin cortar la chain, compile una vez, compare el sha256 de rand-node y de rand, detenga el servicio, instale y reinicie, un nodo a la vez. Algunas versiones se despliegan con parada total y arranque total (la regla de nivel de llamada de v0.5.6, el cambio de formato de Status en v0.5.7, la verificación de pruebas más estricta de v0.6); las notas de cada versión indican cuál. v0.6.7 se desplegó sobre la chain 18 un nodo a la vez; v0.6.8 llegó con la chain 20, con parada total y arranque total, porque sus cambios de consenso CON-4 y CH-1 no deben desplegarse nunca nodo por nodo. Espere a que cada nodo se reincorpore antes de pasar al siguiente, de modo que el quórum nunca quede corto por más de uno. deploy/update-droplet.sh <ip> [build-host] hace exactamente esto por SSH.

Las versiones hasta v0.6.8 se compilaron a mano en un solo host y no están firmadas. La versión v0.6.8 de GitHub incluye rand-node, rand, rand-prover y SHA256SUMS, compilados en el nodo E; esa suma de comprobación detecta una descarga corrupta, pero no avala el host de compilación. v0.6.8 incluye un flujo de trabajo de publicación que compila los binarios a partir de la etiqueta, y deploy/update-droplet.sh rechaza una instalación sin un SHA256SUMS firmado, salvo que se establezca ALLOW_UNSIGNED=1. deploy/release-signers aún no lista ninguna clave, por lo que la vía firmada no se ha usado.

Las chains 15, 16, 17 y 18 entraron en funcionamiento en 2.7 días (2026-09-26 a 2026-09-29), cada una con una parada total de la flota. La chain 19 siguió el 2026-10-01 a las 03:43 UTC, un nuevo génesis de la chain 18 con la misma compilación, y la chain 20 el mismo día a las 06:17 UTC, cortada a partir de una instantánea de la chain 19 en la bifurcación dura v0.6.8; todos los nodos se detuvieron en la altura 7,700 de la chain 19. Desde la chain 20 se aplica una política de corte escrita (2026-09-30); el registro de corte de la chain 20 renunció a la recompilación por un segundo operador, porque un solo operador posee todas las claves. Un corte requiere un motivo que una actualización progresiva no pueda satisfacer, una lista publicada de lo que incorpora y lo que elimina, una lista de verificación de recompilación de clientes completada de antemano, un segundo operador que reconstruya el génesis hasta el mismo hash, un plan de reversión y un identificador de chain nunca usado antes.