Lisez cette page pour décider sur quoi construire et par où commencer : le modèle de la chaîne en quelques paragraphes, les paramètres du testnet en production, la façon d’obtenir des RAND de test, et une carte du reste de la documentation.
Ce qu’est Rand Protocol
Rand est une chaîne blindée post-quantique. Sa monnaie native est RAND, et RAND vit dans un pool entièrement blindé : il n’y a ni comptes ni soldes sur la chaîne, seulement des engagements de notes et des nullifiers, et un transfert est une preuve à divulgation nulle de connaissance que quatre notes sont devenues quatre autres notes (des notes factices occupent les emplacements inutilisés), sans révéler quel actif a circulé. RAND et chaque jeton du standard propre à la chaîne, RPL, partagent ce même pool. La même monnaie paie les programmes confidentiels : des programmes RISC-V qui s’exécutent hors chaîne dans une machine virtuelle à divulgation nulle de connaissance et se règlent sur la chaîne avec une preuve au lieu de leurs entrées.
Chaque primitive est choisie pour résister à un adversaire quantique :
| couche | ce qui s’exécute |
|---|---|
| Signatures | Dilithium2 (à base de réseaux euclidiens). Les validateurs y recourent pour signer les blocs et les votes ; le faucet, les actions de staking et les enregistrements du bridge sont signés avec lui. Un portefeuille ne signe jamais de transaction : un lot s’autorise lui-même par sa preuve. |
| Chiffrement des notes | Encapsulation de clé ML-KEM-768 et ChaCha20-Poly1305. Chaque note sur la chaîne est accompagnée d’une enveloppe que seul son destinataire (et son expéditeur) peut ouvrir. |
| Hachage | BLAKE3 avec séparation de domaines pour les adresses, les identifiants de transaction, la racine d’état et tout ce qui se trouve hors du système de preuve ; Poseidon2 sur le corps Goldilocks pour les notes, les nullifiers, l’arbre d’engagements et tout ce qui se trouve à l’intérieur d’une preuve. |
| Preuves | Un STARK par lots Plonky3 avec FRI à confidentialité (80 requêtes, facteur d’expansion de 8, 20 bits de preuve de travail). Transparent : pas de configuration de confiance, pas de courbe à couplage, et l’hypothèse est une fonction de hachage résistante aux collisions. |
| Calcul confidentiel | Le zkVM de Rand, une machine RV32IM prouvée sous ce STARK. Un programme est identifié par un condensat interne au circuit, et le vérifieur ne voit jamais un seul mot d’instruction. |
| Consensus | HotStuff BFT chaîné : quorums pondérés par la mise de plus des deux tiers, leaders en rotation circulaire, règle de validation sur trois vues consécutives. |
| Stockage et réseau | Une base RocksDB par nœud avec validations synchronisées sur disque (fsync) et contrôle d’intégrité au démarrage ; libp2p (TCP, Noise, Yamux, gossipsub, Kademlia, mDNS sur les réseaux locaux). |
L’implémentation de référence est randprotocol/fullnode, en Rust : le binaire rand-node est le nœud, le binaire rand est le portefeuille, et les méthodes JSON-RPC sont préfixées par rand_. L’explorateur est randscan.org.
Le testnet : chaîne 20
La flotte publique exécute la chaîne 20, en service depuis le 2026-10-01 06:17 UTC sur fullnode v0.6.8. Les chaînes 15 à 19 sont retirées. Quatre chaînes ont été créées en quatre jours, chacune pour une modification qui change toutes les preuves ou le format des transactions :
- Chaîne 16 (2026-09-28, fullnode v0.6.1) a fait passer le zkVM à l’ensemble de contraintes 7, qui masque ce qu’une preuve révélait auparavant des petites entrées privées, et a activé les règles
hardening_v6. - Chaîne 17 (2026-09-29, v0.6.3) a séparé l’autorisation d’un transfert de sa preuve : chaque lot porte une seconde petite preuve produite avec la clé de dépense, de sorte que la grosse preuve peut être produite par une machine qui ne détient qu’une clé de visualisation.
- Chaîne 18 (2026-09-29, v0.6.7) mesure les appels confidentiels en gaz (ensemble de contraintes 8) et active le mémo chiffré dans chaque enveloppe de note.
- Chaîne 20 (2026-10-01, v0.6.8) lie chaque preuve et chaque message signé au hachage de genèse, ajoute l’état des programmes (RPL-2), prélève des frais sur les frappes et les destructions de zUSD par le bridge, et active les règles audit-v6 énumérées dans le tableau ci-dessous.
La chaîne 19 (2026-10-01 03:43 UTC, v0.6.7) était une nouvelle genèse de la chaîne 18 sur la même version et n’a modifié aucune règle. La chaîne 18 a été arrêtée à la hauteur 143,776, et la chaîne 19 a été créée à partir d’un instantané à la hauteur 141,935. Sa genèse ne différait de celle de la chaîne 18 que par l’identifiant de chaîne, l’horodatage, les notes reportées et la section du bridge : de nouveaux émetteurs pour les points de terminaison Ethereum, Binance Smart Chain et Tron, et les compteurs de séquence reportés.
La chaîne 20 est un hard fork de la chaîne 19 : sa genèse a été créée à partir d’un instantané de la chaîne 19 à la hauteur 7,258, la chaîne 19 a été arrêtée à la hauteur 7,700, et les 26 validateurs ont tous été redémarrés ensemble sur la chaîne 20, avec les mêmes clés, les mêmes identifiants de pair et les mêmes nœuds d’amorçage. Les chaînes 19 et 18 sont retirées. Un portefeuille a besoin de la v0.6.8 pour envoyer sur la chaîne 20 : les preuves et les signatures d’un portefeuille plus ancien ne portent pas la liaison à la genèse, et la chaîne les refuse.
Chacune est une chaîne neuve. Les soldes RAND des portefeuilles de l’opérateur et les zUSD en circulation ont été reportés dans la genèse suivante, et rien d’autre : un programme déployé sur une chaîne n’existe pas sur la suivante. C’est un logiciel expérimental : non audité, et les RAND qu’il porte n’ont aucune valeur.
Les programmes sur la chaîne 20 peuvent conserver un état : les cellules de programme, les coffres de programme et l’action Invoke de RPL-2 sont en service.
| identifiant de chaîne | 20 (rand_chainId) |
| hash de genèse | 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 |
| fichier de genèse | deploy/genesis-chain20.json dans le dépôt du fullnode |
| build | fullnode v0.6.8 (tag c9c9bd3c) ; un nœud indique son propre build dans rand_getVersion. Ce build refuse les chaînes 14 à 17, et un wallet antérieur à v0.6.8 ne peut pas envoyer sur la chaîne 20 |
| liaison à la genèse | binding_domain 1 : la liaison de preuve de chaque bundle et chaque message d’action signé incluent le hash de genèse, de sorte que rien de ce qui est prouvé ou signé pour une chaîne n’est valide sur une autre |
| marqueur testnet | testnet true : la genèse se déclare réseau de test, ce qui permet à un faucet de fonctionner à côté du bridge |
| validateurs | 26, chacun avec une mise de 1 000 RAND, le minimum de staking |
| quorum | 18 sur 26 : strictement plus des deux tiers de la mise |
| intervalle de bloc | la valeur par défaut --block-interval-ms 1000 ; environ un bloc par seconde |
| temps de bloc | un horodatage de plus de 60 s postérieur à celui de son parent est invalide, et un validateur ne vote pas pour un bloc en avance de plus de 15 s sur sa propre horloge ; les validateurs exécutent donc NTP |
| fenêtre de preuve | proof_window_blocks 1 024 : l’ancre d’un bundle doit être l’une des 1 024 dernières racines de fin de bloc, et son time ne doit pas être plus ancien (256 blocs sur les chaînes 18 et 19) |
| époques | 1 000 blocs ; un nouveau bond attend deux époques supplémentaires avant d’être pris en compte (bond_activation_epochs 2, activation à l’époque e + 3), la mise retirée du bond est libérée deux époques plus tard |
| staking | les enregistrements sont en v2 (rand-node register --v2), et une nouvelle clé ne s’enregistre qu’après que des validateurs détenant plus des deux tiers du poids l’ont votée (admission_by_vote) ; le poids d’un validateur est plafonné à 33,33 % ; la nouvelle mise entrant à une frontière d’époque est plafonnée à 25 % du poids actif (max_stake_entry_bps_per_epoch 2 500) ; pas de slashing |
| zkVM | jeu de contraintes 8, profil FRI de production (80 requêtes) |
| guest de bundle | hc_bundle 60af094acfe65d85fdb18fb3d06cf9085dcf28c96e59e87f1ee527226e6e3fce : le bundle d’actifs cachés 4 entrées-4 sorties, version 3, palier 14 |
| guest d’authentification | hc_auth 1e4e347f44cf86750b30a9a4bdf9ec9256efe353d4ff8017451eca7d195639c1 : l’autorisation de dépense que porte chaque bundle, palier 10 |
| gas | un appel déclare une limite de gas que le circuit applique et paie gas_price pour celle-ci : 100 unités par gas et 800 unités par KiB au plancher, tous deux évoluant à chaque bloc vers une cible de 262 144 gas et 10 485 760 octets, et jamais au-delà des plafonds de 10 000 par gas et 80 000 par KiB. Seuls les octets sur lesquels le prix à l’octet est facturé (la preuve d’un appel et son enveloppe d’entrée) comptent dans la charge en octets (byte_load: "paying"), de sorte qu’un bloc de transferts ne la fait pas monter. Chaque bundle déclare la limite fixée 20 479 et paie les 0,001 RAND forfaitaires |
| état de programme | RPL-2 activé : cellules de programme, coffres de programme et Invoke (Action 33) ; une cellule créée coûte 0,01 RAND (cell_fee 10 000 000 unités) ; un appel lit au plus 8 cellules, en écrit au plus 8 et effectue au plus 4 paiements (rand_getLimits.program_state) |
| enveloppe de note | envelope_bytes 1860 : l’enveloppe de chaque note fait 1 860 octets et porte un mémo chiffré |
| plafond de programme | max_program_words 65 535, mais sous hardening_v6 un déploiement qu’aucun appel de palier 14 ne pourrait contenir est refusé (ProgramUncallable) : 8 180 mots pour un programme sans segment public |
| plafond de preuve | max_proof_bytes 4 194 304 (4 MiB) ; il était de 8 MiB sur les chaînes 13 à 16 |
| plafond de bloc | max_block_bytes 20 971 520 (20 MiB) |
| plafond d’enveloppe d’appel | max_call_envelope_bytes 65 536 |
| entrée publique par programme | max_program_public_words 32 768, fixé au déploiement |
| faucet | activé, mais uniquement pour les 16 wallets de la liste d’autorisation de la genèse (staking.faucet_recipients), et uniquement depuis les 18 validateurs que la genèse désigne comme minters (staking.faucet_minters) : jusqu’à 100 RAND par appel, 10 000 RAND par époque au total |
| calcul confidentiel | activé ; la preuve d’un appel est plafonnée au palier 14. Les programmes ne sont pas conservés d’une coupure à l’autre ; les programmes d’exemple indiquent sur quelle chaîne chacun est déployé |
| tokens | le registre RPL est activé : frais d’enregistrement de 1 RAND, brûlés ; 4 096 tokens au plus ; toute valeur de note inférieure à 2⁶³. zUSD figure dans la genèse à l’indice 1 |
| bridge | activé : ensemble de gardiens 1 avec huit gardiens, huit gardiens PQ Dilithium2, une clé de pause, des émetteurs pour quatre chaînes sources, un plafond de mint quotidien de 100 000 zUSD par collatéral, et un plafond global de 4 000 zUSD par période glissante de 24 heures sur l’ensemble des collatéraux. zUSD a sept collatéraux ; son offre est ce qui est verrouillé, lu en direct depuis rand_getTokenSupply. Depuis la chaîne 20, des frais de 10 bps sont prélevés sur chaque mint et chaque burn, en zUSD, sous forme de note vers une adresse de trésorerie (bridge.fees) : un dépôt crédite le montant brut moins les frais, et un burn libère amount − fee sur la chaîne source. Une rotation des gardiens PQ ou de la clé de pause porte la signature propre à chaque nouvelle clé et prend effet 86 400 s après son acceptation (bridge.rotation) |
| historique | 24 validateurs conservent 24 heures de blocs (--prune-history 24h) et répondent -32010 en deçà ; deux nœuds d’archive conservent tous les blocs, et le RPC public https://rpc.randprotocol.org redirige vers une archive |
| agrégation de blocs | désactivée (pas de section aggregation dans la genèse ; le build refuse de démarrer sur une genèse qui en contient une) |
| valeur de genèse | 26 000 RAND misés dans le registre des validateurs plus sept notes de dépôt totalisant 5 184,243719258 RAND, reportées des wallets de l’opérateur sur la chaîne 19 : 31 184,243719258 RAND, avant les mints du faucet (rand_getSupply indique genesis_staked et genesis_deposited) ; plus deux notes de genèse totalisant 99 zUSD, correspondant aux 99 zUSD verrouillés sur leurs collatéraux |
Les nœuds d’amorçage (deploy/nodes.env) :
/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/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQLa chaîne 20 fonctionne avec les clés de validateur qu’utilisaient les chaînes 14 à 19 ; ces identifiants de pair n’ont donc pas changé depuis la rotation des clés de la chaîne 14.
L’explorateur sur randscan.org indexe la chaîne 20 et expose une API REST à https://randscan.org/api/v1 (API de l’explorateur). Le JSON-RPC du nœud complet écoute par défaut sur 127.0.0.1:8545 ; exécutez un nœud (Exécuter un nœud), utilisez-en un de confiance, ou utilisez le point d’accès public https://rpc.randprotocol.org (rand --rpc https://rpc.randprotocol.org …). Le point d’accès public sert tout ce dont un wallet a besoin, y compris sa première synchronisation et l’envoi de transactions, dans une limite de 1 200 lectures et 6 envois par minute et par adresse. Il ne sert pas le faucet.
Obtenir des RAND depuis le faucet
Le faucet est un type de transaction : un validateur mint une note d’un montant public vers une adresse shielded, et la note ne peut être ouverte que par le titulaire de l’adresse. Sur la chaîne 20, il ne paie que les 16 adresses de la liste d’autorisation de la genèse : un mint vers toute autre adresse est refusé avec the faucet may not mint to this recipient (not in staking.faucet_recipients), de sorte qu’un wallet qui n’y figure pas obtient des RAND de test en en recevant d’un autre. Chacune des trois voies ci-dessous demande un mint à un nœud validateur ; les observateurs répondent faucet mints are signed by validators; ask a validator node, et le point d’accès RPC public ne redirige pas du tout rand_mint.
Avec le wallet rand, pointé sur le RPC d’un validateur :
rand keygen # writes wallet.key.json; refuses to overwrite
rand address # the rand1… address on stdout (about 1,665 characters), its fingerprint on stderr
rand faucet # an allowlisted wallet: 100 RAND into a note only it can open
rand balance # scans the tree with this key; prints 100 RANDrand faucet [ADDRESS] --amount <RAND> mint vers une autre adresse ou pour un montant plus faible ; 100 RAND est à la fois la valeur par défaut et le plafond par appel. Via JSON-RPC, la même requête est rand_mint :
curl -s http://127.0.0.1:8545 -H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"rand_mint","params":["rand1…", "100000000000"]}'Le résultat est le hash de la transaction de mint ; interrogez rand_getTransaction jusqu’à ce qu’elle renvoie un bloc. Les montants sont des chaînes d’unités, et 1 RAND vaut 10⁹ unités. Les applications wallet offrent le même faucet en une seule pression ; envoyez depuis celles-ci avec Rand Wallet v0.6.8 ou une version ultérieure, la première version pour la chaîne 20. La page du faucet de ce site accepte les demandes de la liste d’attente pour les allocations devnet.
Le montant d’un mint est public sur la chaîne : la visibilité à un saut qu’a tout dépôt de transparent vers shielded. Ce que vaut ensuite la note, et pour qui, reste caché comme toute autre note.
Où aller ensuite
- Comptes et adresses : les deux types de clés, ce qu’est une adresse
rand1…, et pourquoi l’adresse de 54 caractères de la chain 11 a été annulée. - Notes et arbre d’engagements, Transactions et actions, Frais, Consensus et finalité, Offre : le modèle.
- Cryptographie et Preuves : les primitives, les paramètres STARK, la manière dont un bundle est prouvé et vérifié.
- Jetons et Déployer un jeton RPL : le standard RPL, un jeton comme entrée de registre avec un identifiant
rpl1…, et sa création depuis le wallet. - Programmes : déployer et appeler un programme confidentiel, et ce qui n’est pas encore possible.
- Bridge, Mint et burn, Staking, Exécuter un nœud.
- Écrire un programme en Rust ou en C : le guide complet, de la conception des entrées et des sorties d’un programme jusqu’à une enchère à offres scellées écrite dans les deux langages, le budget de preuve, le déploiement et la vérification d’un appel.
- Quatre programmes d’exemple : des applications complètes, chacune exécutée sur le testnet : un vote anonyme sur une liste d’autorisation Keccak, une preuve de passifs sur un arbre de sommes SHA-256, un registre hors chaîne dont l’état est transmis d’un appel à l’autre, et une décision de crédit privée issue d’un modèle publié.
- L’ISA RISC-V, Déployer un programme Rust, Déployer un programme RISC-V : construire et déployer vos propres programmes avec la chaîne d’outils
rand-guest. - Le transpileur Solana et Le transpileur Ethereum : SPL Token et un ERC-20, traduits en RISC-V et comparés mot à mot aux interpréteurs.
- Exécuter un validateur et un agrégateur : RAM, CPU et disque pour chaque rôle, et les bornes mesurées de mémoire de preuve.
- Développeurs : les dépôts, la pile technique, les jalons de la zkVM, ce qui est spécifié mais non livré, et comment compiler, tester et contribuer.
- JSON-RPC, Ligne de commande, API de l’explorateur : les références.
Le répertoire docs/ du dépôt fullnode est la source à laquelle ces pages sont comparées, et les papiers apportent le contexte cryptographique.