Ejecutar un nodo de Rand
El nodo completo de referencia y su wallet están escritos en Rust y se compilan desde el código fuente. El resultado son dos binarios: rand-node, el nodo y las herramientas del operador, y rand, una wallet que guarda una clave de gasto protegida, se comunica con cualquier nodo mediante JSON-RPC y ejecuta localmente el prover de zkVM en cada transferencia y en cada llamada confidencial. Hay un testnet experimental, la cadena 21, activo con 26 validadores en droplets de DigitalOcean. No está auditado y no tiene valor real. Los binarios para Linux x86_64 de ambos se adjuntan a la versión v0.8.0, la compilación con la que se actualizó la flota.
# 1. Rust (rustup instala la cadena de herramientas fijada, 1.98.1) y las dependencias de compilación de RocksDB
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
sudo apt install build-essential clang cmake pkg-config libssl-dev # Linux
# 2. Clonar y compilar (10–20 min la primera vez)
git clone https://github.com/randprotocol/fullnode.git
cd fullnode
cargo build --release # target/release/rand-node, target/release/rand
# 3. Una cadena de dos validadores en esta máquina (RPC en 8545 y 8546)
scripts/local-testnet.sh
target/release/rand --rpc http://127.0.0.1:8545 status
# 4. Pruebas; en modo release porque la generación de pruebas STARK es lenta en debug (678 pruebas, unos 43 minutos según la medición del 2026-09-14)
cargo test --workspace --release
# La versión v0.8.0 (c0878c3f) ejecuta la chain 21, y ninguna versión anterior lo hace: la chain 21 ejecuta el conjunto de restricciones 9, cuyas claves del verificador y codificación de pruebas no incluye ninguna versión más antigua. Compílela desde la etiqueta, o en Linux x86_64
# use los binarios de la versión y verifíquelos con el archivo SHA256SUMS publicado junto a ella
git checkout v0.8.0 && cargo build --release
curl -LO https://github.com/randprotocol/fullnode/releases/download/v0.8.0/rand-node -LO https://github.com/randprotocol/fullnode/releases/download/v0.8.0/rand \
-LO https://github.com/randprotocol/fullnode/releases/download/v0.8.0/msauth-vk-production.bin# la clave fijada del verificador multifirma: rand-node la carga desde junto a su binario y se niega a iniciar sin ella
sha256sum rand-node rand msauth-vk-production.bin # debe imprimir los valores de la versión (SHA256SUMS, firmado como SHA256SUMS.sig):
# 324a4ab1029d39e67fc2de36b036341b0f88f13089997d7fe24c596363a58278 rand-node
# e3a38e74ee28743a960fc1c3eb1ac6c538e18dc259411e10afff7f54e268bbf4 rand
# 68facb06c7f321aaf1d4d541acf6b5c0e9d7f17788ed1c9add6c5a8a8f7acd30 msauth-vk-production.bin
# La identidad de su nodo: la clave de validador Dilithium2 y el peer id p2p en un solo archivo. Genere la suya
# y manténgala fuera del checkout; el repositorio ya no incluye ninguna clave
rand-node keygen --out node.key.json
# El génesis se distribuye en el repositorio; todos los nodos deben tener el archivo idéntico.
# init imprime su hash, que debe coincidir con el siguiente
rand-node init --datadir ./data --genesis deploy/genesis-chain21.json
# Conéctese a los validadores públicos (la chain 21 conservó las claves de la chain 14, por lo que sus peer ids e IP).
# Omita --validator: su clave no está en el conjunto de validadores. Un validador también necesita NTP
rand-node run --datadir ./data --key node.key.json \
--listen /ip4/0.0.0.0/tcp/30303 --rpc 127.0.0.1:8545 --no-mdns \
--bootstrap /ip4/164.90.239.200/tcp/30303/p2p/12D3KooWEQEbUwZRgqhDPXhW7vNBmcRcnhUDGUADe81VFdv3ALYe \
--bootstrap /ip4/165.245.173.74/tcp/30303/p2p/12D3KooWJyc5oDHggAr89e9QrRFBy9Tg8TxXh18yzrb1SM6KKLYw \
--bootstrap /ip4/188.166.235.187/tcp/30303/p2p/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQ
# Una wallet es una clave separada y protegida (shielded). Su dirección rand1… ocupa unos 1,6 KB de texto
rand keygen && rand address
# Una emisión del faucet la firma un validador, por lo que necesita el RPC de un validador: funciona en la
# chain local de dos validadores tal cual; un observador responde "ask a validator node". En la chain 21
# el faucet solo emite a las 16 wallets que su génesis incluye en la lista de permitidos, y solo desde los validadores que nombra
rand faucet # 100 RAND en una nota que solo usted puede abrir
rand balance # analiza el árbol con su clave; nadie más puede
rand send <rand1 address> 1.5 # pide confirmación, genera la prueba (~2 min), espera la confirmación en la cadena
# Ensamblar un guest integrado: pagar el excedente sobre 1000 si cuatro saldos privados lo cubren
rand program build --guest private_payment --arg 1000 --out pp.json
rand program deploy pp.json # imprime el identificador del programa (su hash de contenido)
# Generar la prueba en local; solo la prueba, ocho palabras de salida y una transcripción de entrada sellada van a la cadena
rand call <program id> --input 400 --input 250 --input 300 --input 75
rand receipt <tx> # salidas [1, 0, 25, 0, ...]: el excedente, publicado como dato
# Más adelante, abrir la transcripción y compararla con el H_IN que publicó la prueba
rand open-call <tx> # entradas: [400, 250, 300, 75] — veredicto: faithful
Requisitos
- SO
- Linux x86_64 o macOS arm64
- Rust
- 1.98.1, fijado por rust-toolchain.toml; rustup lo instala
- Dependencias de compilación
- Compilador de C++, cmake, pkg-config, cabeceras de OpenSSL (RocksDB)
- Primera compilación
- 10 a 20 minutos: RocksDB y Plonky3 desde el código fuente
- Puertos
- TCP 30303 de entrada en los nodos públicos; RPC en 127.0.0.1:8545
- Servidor
- Una instancia en la nube de 1 a 2 vCPU ejecuta un validador del testnet
- Reloj
- NTP (chrony) en un validador: este retiene su voto en un bloque que adelante en más de 15 s a su propio reloj, así que un reloj atrasado deja de votar sin avisar
- Generación de pruebas
- Hoy solo con CPU: una transferencia protegida tarda unos dos minutos en un portátil (una prueba de autorización de 7 s y una prueba del paquete de unos 110 s) y usa unos 6 GB de memoria; una llamada pequeña añade unos 30 s
Elegir un rol
- Observador abierto a cualquiera
El mismo binario sin --validator. Sincroniza la cadena, verifica cada certificado y cada prueba de paquete y de llamada, vuelve a ejecutar cada bloque, compara los recibos y atiende JSON-RPC. Es lo que ejecuta una clave nueva en el testnet público.
- Validador con fianza
Vota y propone bajo HotStuff encadenado. En la chain 21, como en la chain 20, un nuevo validador se admite primero por votación: los validadores que poseen más de dos tercios del stake firman una acción AdmitValidator para su clave. Después registra la clave del nodo (rand-node register --v2), vincula al menos 1,000 RAND desde una wallet y entra en el conjunto en el tercer límite de época de 1,000 bloques posterior a la vinculación (el retraso de vinculación de dos épocas de la chain 18). La chain 18 partió de 26 validadores con 1,000 RAND cada uno; más de dos tercios del stake, 18 de 26, deben estar en línea y votando para confirmar. Genere su propia clave: ya no se conserva ninguna clave de validador en el repositorio, y los archivos de clave confirmados para cadenas anteriores son semillas publicadas.
- Wallet y prover local
El cliente rand guarda una clave de gasto de 256 bits y no firma nada: la autorización son dos pruebas, una pequeña generada con la clave de gasto y la prueba del paquete de 4 entradas y 4 salidas. Analiza el árbol en busca de sus propias notas, genera ambas pruebas en su máquina, con la misma forma para RAND y para cualquier token RPL, y en una llamada confidencial también prueba el programa. A la cadena solo llegan pruebas, compromisos, nullifiers y sobres sellados.
¿No ejecuta un nodo? La misma wallet está disponible como aplicación para iOS, Android, Chrome y Firefox: Wallets.
Cada nodo lo verifica todo
Un nodo que se sincroniza vuelve a verificar cada certificado, vuelve a ejecutar cada bloque, incluidas sus pruebas, y compara los recibos antes de aceptarlo. Al iniciarse comprueba su propia base de datos, trunca todo lo que sea inconsistente conservando su estado de seguridad de voto, y vuelve a obtener el tramo faltante de sus pares.
# Nodo detenido: hashes, QC, firmas, pruebas, repetición
rand-node verify --datadir ./data --mode full
rand-node verify --datadir ./data --repair
Pruebas de fallos en el testnet activo
- ›Se detiene uno de cuatro validadores: la cadena sigue confirmando y el nodo se pone al día en segundos cuando vuelve.
- ›Se detienen dos de cuatro: la cadena se detiene sin quórum y se reanuda sin bifurcación cuando vuelven.
- ›Se corrompe la base de datos de un nodo: se detecta al iniciar, se trunca, se resincroniza desde los pares y después queda idéntica byte a byte.
- ›Transferencias a través de nodos distintos: todas confirmadas, saldos idénticos en todas partes, suministro sin cambios.
- ›Un enlace caído con un par lo restablece la lógica de remarcado en unos 30 segundos.
Aún no implementado
Se enumera para que la distancia entre el artículo y el nodo sea legible y no deba deducirse.
- ›Estado persistente por programa y llamadas entre programas
- ›Un compilador en la propia wallet: un programa es un guest ensamblado integrado o una imagen construida con la herramienta independiente rand-guest
- ›Slashing y jailing, recompensas por bloque, mercados de comisiones, la baliza de líder por sorteo hash (hash-sortition)
- ›Un acumulador de nullifiers, poda de pruebas tras la finalidad, agrupación de pruebas por lotes
- ›Una prueba de nivel 20 de la transferencia de SPL Token, y el mercado de provers GPU del paper