Exécuter un nœud Rand
Le full node de référence et son portefeuille sont écrits en Rust et se compilent depuis les sources. Deux binaires en résultent : rand-node, le nœud et ses outils d'opérateur, et rand, un portefeuille qui détient une clé de dépense shielded, dialogue avec n'importe quel nœud via JSON-RPC et exécute localement le prover zkVM pour chaque transfert et chaque appel confidentiel. Un testnet expérimental, la chaîne 21, est actif sur 26 validateurs hébergés sur des droplets DigitalOcean. Il n'est pas audité et ne porte aucune valeur réelle. Les binaires Linux x86_64 des deux sont joints à la version v0.8.0, celle sur laquelle la flotte a été déployée.
# 1. Rust (rustup récupère la toolchain 1.98.1 épinglée) et les dépendances de compilation 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. Cloner et compiler (10 à 20 min la première fois)
git clone https://github.com/randprotocol/fullnode.git
cd fullnode
cargo build --release # target/release/rand-node, target/release/rand
# 3. Une chaîne à deux validateurs sur cette machine (RPC sur 8545 et 8546)
scripts/local-testnet.sh
target/release/rand --rpc http://127.0.0.1:8545 status
# 4. Tests ; en release, car la preuve STARK est lente en debug (678 tests, environ 43 minutes, mesurées le 2026-09-14)
cargo test --workspace --release
# La version v0.8.0 (c0878c3f) exécute la chain 21, et aucune version antérieure ne le fait : la chain 21 exécute le jeu de contraintes 9, dont aucune version plus ancienne ne porte les clés de vérification ni l'encodage des preuves. Compilez-la depuis le tag, ou sous Linux x86_64
# prenez les binaires de la version et vérifiez-les avec le SHA256SUMS publié avec elle.
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 clé de vérification multisig épinglée : rand-node la charge depuis le répertoire de son binaire et refuse de démarrer sans elle
sha256sum rand-node rand msauth-vk-production.bin # doit afficher les valeurs de la version (SHA256SUMS, signé en tant que SHA256SUMS.sig) :
# 324a4ab1029d39e67fc2de36b036341b0f88f13089997d7fe24c596363a58278 rand-node
# e3a38e74ee28743a960fc1c3eb1ac6c538e18dc259411e10afff7f54e268bbf4 rand
# 68facb06c7f321aaf1d4d541acf6b5c0e9d7f17788ed1c9add6c5a8a8f7acd30 msauth-vk-production.bin
# L'identité de votre nœud : clé de validateur Dilithium2 et identifiant de pair p2p dans un seul fichier. Générez la vôtre
# et conservez-la en dehors du checkout ; le dépôt ne suit plus aucune clé
rand-node keygen --out node.key.json
# Le genesis est livré dans le dépôt ; chaque nœud doit détenir un fichier identique.
# init affiche son hash, qui doit correspondre à celui ci-dessous
rand-node init --datadir ./data --genesis deploy/genesis-chain21.json
# Connectez-vous aux validateurs publics (la chain 21 a conservé les clés de la chain 14, donc ses identifiants de pair et ses IP).
# Omettez --validator : votre clé ne figure pas dans l'ensemble de validateurs. Un validateur a aussi besoin de 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
# Un portefeuille est une clé distincte, blindée. Son adresse rand1… représente environ 1,6 Ko de texte
rand keygen && rand address
# Un mint du faucet est signé par un validateur ; il faut donc le RPC d'un validateur : il fonctionne tel quel sur la
# chain locale à deux validateurs ; un observateur répond « ask a validator node ». Sur la chain 21
# le faucet ne crée de jetons que pour les 16 portefeuilles que son genesis autorise, et uniquement depuis les validateurs qu'il nomme
rand faucet # 100 RAND dans une note que vous seul pouvez ouvrir
rand balance # analyse l'arbre avec votre clé ; nul autre ne le peut
rand send <rand1 address> 1.5 # demande confirmation, produit la preuve (~2 min), attend le commit
# Assembler un guest intégré : payer l'excédent au-delà de 1000 si quatre soldes privés le couvrent
rand program build --guest private_payment --arg 1000 --out pp.json
rand program deploy pp.json # affiche l'identifiant du programme (son hash de contenu)
# Prouver localement ; seuls la preuve, huit mots de sortie et une transcription d'entrée scellée vont sur la chaîne
rand call <program id> --input 400 --input 250 --input 300 --input 75
rand receipt <tx> # sorties [1, 0, 25, 0, ...] : l'excédent, publié en tant que donnée
# Plus tard, ouvrir la transcription et la comparer au H_IN publié par la preuve
rand open-call <tx> # entrées : [400, 250, 300, 75] — verdict : faithful
Prérequis
- Système
- Linux x86_64 ou macOS arm64
- Rust
- 1.98.1, épinglé par rust-toolchain.toml ; rustup l'installe
- Dépendances de compilation
- Compilateur C++, cmake, pkg-config, en-têtes OpenSSL (RocksDB)
- Première compilation
- 10 à 20 minutes : RocksDB et Plonky3 depuis les sources
- Ports
- TCP 30303 en entrée sur les nœuds publics ; RPC sur 127.0.0.1:8545
- Serveur
- Une instance cloud de 1 à 2 vCPU fait tourner un validateur testnet
- Horloge
- NTP (chrony) sur un validateur : il retient son vote pour un bloc en avance de plus de 15 s sur sa propre horloge, si bien qu'une horloge en retard cesse de voter sans bruit
- Preuve
- Uniquement sur CPU pour l'instant : un transfert shielded prend environ deux minutes sur un ordinateur portable (une preuve d'autorisation de 7 s et une preuve de bundle d'environ 110 s) et environ 6 Go de mémoire ; un petit appel ajoute environ 30 s
Choisir un rôle
- Observateur ouvert à tous
Le même binaire sans --validator. Il synchronise la chaîne, vérifie chaque certificat ainsi que chaque preuve de bundle et d'appel, ré-exécute chaque bloc, compare les reçus et sert du JSON-RPC. C'est ce qu'exécute une nouvelle clé sur le testnet public.
- Validateur avec mise en caution
Vote et propose sous HotStuff chaîné. Sur la chain 21, comme sur la chain 20, un nouveau validateur est d'abord admis par vote : des validateurs détenant plus des deux tiers de la mise signent une action AdmitValidator pour sa clé. Il enregistre ensuite la clé du nœud (rand-node register --v2), immobilise au moins 1 000 RAND depuis un portefeuille, et entre dans l'ensemble à la troisième frontière d'époque de 1 000 blocs après l'immobilisation (le délai d'immobilisation de deux époques de la chain 18). La chain 18 est partie de 26 validateurs à 1 000 RAND chacun ; plus des deux tiers de la mise, soit 18 sur 26, doivent être en ligne et voter pour qu'un bloc soit validé. Générez votre propre clé : aucune clé de validateur n'est plus conservée dans le dépôt, et les fichiers de clés commités pour les chaînes précédentes sont des seeds publiées.
- Portefeuille et prover local
Le client rand détient une clé de dépense de 256 bits et ne signe rien : deux preuves tiennent lieu d'autorisation, une petite produite avec la clé de dépense et la preuve de bundle 4-en-4-sorties. Il parcourt l'arbre à la recherche de ses propres notes, prouve les deux sur votre machine, selon la même forme pour RAND et pour tout jeton RPL, et pour un appel confidentiel prouve aussi le programme. Seuls des preuves, des engagements, des nullifiers et des enveloppes scellées atteignent la chaîne.
Vous n'exécutez pas de nœud ? Le même portefeuille existe sous forme d'application pour iOS, Android, Chrome et Firefox : Portefeuilles.
Chaque nœud vérifie tout
Un nœud qui se synchronise revérifie chaque certificat, ré-exécute chaque bloc, preuves comprises, et compare les reçus avant d'accepter. Au démarrage, il contrôle sa propre base de données, tronque tout ce qui est incohérent tout en conservant son état de sûreté de vote, et récupère à nouveau l'intervalle manquant auprès de ses pairs.
# Nœud arrêté : hashes, QC, signatures, preuves, rejeu
rand-node verify --datadir ./data --mode full
rand-node verify --datadir ./data --repair
Des tests de pannes sont exécutés sur le testnet en production
- ›Arrêter un validateur sur quatre : la chaîne continue de valider des blocs et le nœud rattrape son retard en quelques secondes à son retour.
- ›Arrêter deux validateurs sur quatre : la chaîne s'arrête faute de quorum et reprend sans fork à leur retour.
- ›Corrompre la base de données d'un nœud : détecté au démarrage, tronqué, resynchronisé depuis les pairs, identique octet pour octet ensuite.
- ›Transferts passant par différents nœuds : tous validés, soldes identiques partout, offre inchangée.
- ›Un lien de pair interrompu est rétabli par la logique de recomposition en 30 secondes environ.
Pas encore implémenté
Énumérés pour que l'écart entre l'article et le nœud soit lisible plutôt que déduit.
- ݃tat persistant par programme et appels entre programmes
- ›Un compilateur dans le wallet lui-même : un programme est soit un guest assemblé intégré, soit une image construite avec la chaîne d'outils distincte rand-guest
- ›Le slashing et le jailing, les récompenses de bloc, les marchés de frais, la balise de leader par tirage au sort par hachage
- ›Un accumulateur de nullifiers, l'élagage des preuves après finalité, le regroupement de preuves par lots
- ›Une preuve de niveau 20 du transfert SPL Token, et le marché de provers GPU du livre blanc