Cette page consigne la justification de chaque grande décision de conception de Rand : la propriété qu’un composant doit fournir, l’hypothèse sous laquelle il la fournit, et le coût accepté en contrepartie. Elle a été rédigée le 29 septembre 2026 à partir de ce site, du résumé du livre blanc et du nœud complet de référence (github.com/randprotocol/fullnode : son README, docs/ et docs/superpowers/specs/). Chaque réponse cite le document dans lequel la justification est énoncée ; les chemins renvoient au dépôt fullnode, sauf s’ils commencent par randprotocol.org.
Statut. Rand fonctionne sur un testnet exploité par l’équipe fondatrice, et le protocole n’a pas fait l’objet d’un audit indépendant. Plusieurs des décisions ci-dessous sont mises en œuvre par étapes, au fil des chain cuts. Tous les chiffres sont des mesures du nœud en fonctionnement au moment de la rédaction ; ils sont appelés à évoluer et doivent être mesurés à nouveau avant d’être cités.
Primitives cryptographiques
1. Pourquoi ML-KEM-768 (Kyber) pour le chiffrement des notes ?
Le texte en clair d’une note est chiffré pour son destinataire dans une enveloppe qui reste indéfiniment sur le registre public. Sa confidentialité est donc une propriété irrévocable (question 8) : un adversaire qui disposerait, à un moment ultérieur quelconque, d’un ordinateur quantique pertinent du point de vue cryptographique pourrait déchiffrer toutes les enveloppes historiques scellées par un KEM sur courbe elliptique, puisque l’algorithme de Shor résout le logarithme discret en temps polynomial. ML-KEM est normalisé dans la norme NIST FIPS 203 et sa sécurité se réduit à Module-LWE, problème pour lequel aucun algorithme quantique efficace n’est connu. Le jeu de paramètres 768 (catégorie 3 du NIST) a été retenu comme compromis entre la marge de sécurité et la clé d’encapsulation de 1 184 octets que chaque adresse doit porter. L’enveloppe combine ML-KEM-768 et ChaCha20-Poly1305 : 1 348 octets, ou 1 860 octets avec le champ de mémo fixe.
Source : randprotocol.org (section post-quantique) ; README de fullnode ; docs/shielded.md §2
2. Pourquoi des engagements Poseidon2 plutôt que Pedersen ?
Les engagements de Pedersen sont parfaitement masquants mais seulement calculatoirement liants, et leur propriété de liaison se réduit à l’hypothèse du logarithme discret, qu’un adversaire quantique met en échec ; un adversaire capable de calculer des logarithmes discrets peut ouvrir un engagement vers une valeur différente. Un engagement publié aujourd’hui devant rester sûr et masquant pendant toute la durée de vie du registre, le schéma doit reposer sur des hypothèses réputées tenir face à des adversaires quantiques, ce qui, en pratique, signifie une fonction de hachage. Poseidon2 est une fonction de hachage orientée arithmétisation, définie sur le corps Goldilocks ; son évaluation à l’intérieur du STARK coûte donc peu de contraintes. La même fonction de hachage instancie l’engagement de note, l’arbre de Merkle de profondeur 32 et le nullifier.
Source : randprotocol.org (section post-quantique) ; docs/shielded.md §1–2
3. Pourquoi deux fonctions de hachage — BLAKE3 et Poseidon2 ?
Les deux fonctions sont optimisées pour des modèles de coût différents. Poseidon2 est utilisée partout où un hachage doit être évalué à l’intérieur d’une preuve — notes, arbre d’engagements, nullifiers et tables internes de la zkVM — parce que son coût se mesure en contraintes. BLAKE3 est utilisée partout où aucune preuve n’intervient et où le débit natif est déterminant : hachages de blocs, racine d’état portant sur l’arbre, l’ensemble des nullifiers, le registre des validateurs et la table des programmes, ainsi que les adresses des validateurs (le condensat BLAKE3 de la clé publique). Poseidon2 est comparativement lente sur un CPU ; BLAKE3 est comparativement coûteuse à arithmétiser. Chacune n’est employée que là où son modèle de coût s’applique.
Source : README de fullnode (ligne signatures / hachages) ; docs/architecture.md
4. Pourquoi Dilithium2 (ML-DSA) pour les signatures des validateurs ?
Les signatures de consensus fournissent une propriété renouvelable (question 8) : une rupture ultérieure du schéma permet de forger des messages futurs mais n’invalide pas rétroactivement les blocs déjà finalisés ; le schéma pourrait donc, en principe, être remplacé avant l’existence d’un adversaire quantique. Un schéma à base de réseaux euclidiens a néanmoins été adopté dès la genèse afin que les votes de consensus, les cosignatures des gardiens du bridge et le registre des validateurs partagent un seul type de clé post-quantique. Le nœud implémente le jeu de paramètres Dilithium2 du round 3 (le crate crystals-dilithium), qui diffère de la norme finale FIPS 204 ML-DSA-44 ; les clés publiques font 1 312 octets et les signatures 2 420 octets.
Source : docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §2 ; randprotocol.org
5. Pourquoi un STARK transparent (FRI sur Goldilocks) plutôt qu’un SNARK ?
Ce choix découle de trois exigences. Premièrement, l’absence de trusted setup : la robustesse repose uniquement sur la résistance aux collisions d’une fonction de hachage, et non sur une chaîne de référence structurée ni sur une courbe compatible avec les couplages. Deuxièmement, une robustesse plausiblement post-quantique : l’argument ne fait aucune hypothèse de logarithme discret ni de couplage. Troisièmement, la compatibilité avec le schéma d’engagement à base de hachage de la question 2. Le coût est la taille de la preuve : la preuve d’un bundle fait environ 1,3 MB, soit 300 à 600 fois la taille d’une transaction protégée de Zcash ou de Monero. Ce coût a été accepté et il est traité séparément par l’agrégation au niveau du bloc (questions 31 et 34).
Source : randprotocol.org ; docs/block-space.md §1 ; docs/zkvm.md
6. Pourquoi le profil FRI à 80 requêtes plutôt qu’à 27 ?
Le profil de production (80 requêtes, facteur de blowup 8, 20 bits de grinding par preuve de travail) procure environ 86 bits de robustesse démontrable, contre environ 42 bits pour le profil à 27 requêtes, pour une taille de preuve multipliée par 2,75. Le temps de vérification est presque inchangé : de 809 ms à 838 ms à froid, et environ 16 ms à chaud. La robustesse démontrable a été privilégiée par rapport à la taille de la preuve, et le coût en taille a été reporté sur la conception de l’espace de bloc et de l’agrégation.
Source : docs/block-space.md §1, §3
7. Pourquoi l’affirmation post-quantique est-elle énoncée par primitive plutôt que sous la forme « 128 bits à l’échelle du protocole » ?
Des versions antérieures affirmaient une sécurité post-quantique de 128 bits pour l’ensemble du protocole. Cette affirmation est incompatible avec la borne de Brassard–Høyer–Tapp, selon laquelle un adversaire quantique trouve des collisions dans une fonction de hachage de 256 bits en environ 2^85 requêtes ; elle a donc été retirée plutôt que nuancée. L’article énonce désormais la sécurité par primitive et par rôle — un hachage de transcript de 384 bits, des hachages de 256 bits utilisés uniquement là où la résistance aux préimages est requise, Dilithium2, ML-KEM-768 et FRI sur un corps d’extension — sous les hypothèses Module-LWE et Module-SIS, les fonctions de hachage étant modélisées comme des oracles aléatoires quantiques. Le hachage de transcript du nœud est actuellement Poseidon2 ; la documentation recense cet écart comme une lacune de configuration ouverte.
Source : randprotocol.org (section post-quantique)
8. Qu’est-ce que la classification « irrévocable ou renouvelable », et pourquoi guide-t-elle les choix ?
Une propriété de sécurité est irrévocable si un adversaire qui acquiert une nouvelle capacité à un moment futur quelconque peut la violer rétroactivement pour des données déjà publiées ; la confidentialité des notes et le caractère masquant des engagements sont de cette nature, et ils doivent donc résister aux attaques quantiques au moment de la publication. Une propriété est renouvelable si elle est rétablie à chaque utilisation, de sorte qu’un schéma peut être remplacé avant que la menace ne se concrétise ; les signatures et la robustesse des preuves sont de cette nature. Chaque choix de primitive dans cette section découle de la classification de la propriété qu’elle protège.
Source : randprotocol.org (section post-quantique)
Le pool protégé
9. Pourquoi un modèle de notes/UTXO, sans comptes ni soldes ?
Un registre à comptes publie les soldes par construction ; les dissimuler exige de chiffrer l’état et de prouver des énoncés portant sur les chiffrés, ce qui est nettement plus coûteux. Un pool de notes ne stocke que des engagements et des nullifiers, dont aucun ne révèle ni propriétaire ni montant ; l’état public ne contient donc aucune information sur les soldes. La seule exception est le registre des validateurs, dont les poids de mise doivent être publics pour que les réplicas s’accordent sur la composition du quorum (question 29).
Source : docs/shielded.md §1–2 ; docs/staking.md §1
10. Pourquoi l’adresse fait-elle ~1,6 KB ?
Une adresse protégée se compose du champ propriétaire pk de 32 octets et de la clé d’encapsulation ML-KEM-768 de 1 184 octets dont l’expéditeur a besoin pour sceller l’enveloppe ; encodée en base58, elle compte environ 1 667 caractères. Cette longueur est une conséquence directe du KEM post-quantique. Une conception approuvée (adresses protégées courtes, 2026-09-17) remplace l’adresse par un identifiant de destinataire d’environ 256 bits, qui renvoie à un enregistrement actualisable, signé avec la clé de dépense et servi par l’explorateur, de sorte que la clé d’encapsulation soit récupérée plutôt que retranscrite.
Source : docs/shielded.md §1 ; docs/superpowers/specs/2026-09-17-short-shielded-address.md
11. Pourquoi toutes les clés dérivent-elles d’une seule clé de dépense de 256 bits ?
Tout autre matériel de clé est une fonction déterministe d’un unique secret sk : la clé de visualisation nk = H(NK, sk), le champ propriétaire pk = H(PK, nk), le nullifier H(NF, nk, cm), la clé de visualisation sortante et la clé de décapsulation ML-KEM, chacune sous son propre séparateur de domaine. Le fichier de clé ne stocke donc que sk, une sauvegarde tient en une seule valeur, et un nouveau balayage de l’arbre depuis la feuille 0 permet de retrouver toutes les notes. Comme il n’existe aucune seconde copie à partir de laquelle récupérer, le wallet refuse d’écraser un fichier de clé existant.
Source : docs/shielded.md §1
12. Pourquoi une forme de bundle fixe à 4 entrées et 4 sorties ?
Une forme fixe donne à tous les bundles la même taille et la même structure, quoi qu’ils déplacent. Chaque bundle publie exactement quatre nullifiers et quatre engagements ; les emplacements inutilisés sont des notes factices de valeur nulle, et la sortie de monnaie rendue est publiée même lorsque sa valeur est nulle, car l’absence de cette sortie distinguerait la transaction. La spécification d’origine était à 2 entrées et 2 sorties, à la manière de Sapling. Elle a été élargie à 4 entrées et 4 sorties avec le bundle d’actif caché, de sorte que les emplacements 0–1 portent un actif privé et les emplacements 2–3 portent du RAND pour les frais ; quatre emplacements plutôt que trois permettent à un transfert de jeton de financer ses frais à partir d’au plus deux notes RAND.
Source : docs/shielded.md §2 ; docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §3
13. Pourquoi une seule preuve déplace-t-elle n’importe quel actif (RAND, zUSD, jetons RPL) ?
Avant la chaîne 14, un transfert de jeton comportait deux bundles, l’un pour les frais en RAND et l’autre pour l’actif, ce qui exigeait deux preuves et révélait à tout observateur quel jeton avait été déplacé. Le guest à actif masqué prend l’identifiant de l’actif en entrée privée : un transfert de zUSD est donc indiscernable d’un paiement en RAND. Le guest tient au tier 14 (environ 100 s et 5,7 GB de mémoire) uniquement parce qu’il lit ses entrées dans une boucle et fusionne la vérification d’appartenance à l’arbre de Merkle ; une implémentation entièrement déroulée exige le tier 16 (environ 400 s et 21 GB), ce qui dépasse la mémoire d’une machine de 16 GB.
Source: docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3
14. Pourquoi les frais sont-ils publics et versés au proposeur ?
Des frais publics sont cohérents avec le registre de stake public et rendent l’admission peu coûteuse : un nœud peut vérifier le plancher de frais avant d’effectuer toute vérification. La preuve du bundle impose l’équation d’équilibre Σ entrées = Σ sorties + frais + destruction, de sorte que les frais sont payés à partir de notes masquées sans révéler lesquelles. Le coût accepté est que le montant des frais peut révéler la classe de la transaction (transfert ou appel de programme).
Source: docs/superpowers/specs/2026-09-11-shielded-pool-design.md (rulings table); docs/fees.md §1
15. Pourquoi les dépôts (mint, bridge attest) ont-ils un montant public ?
La valeur entrant dans le pool doit être comptabilisée publiquement, et l’attestation du bridge est la preuve publique qu’un verrouillage correspondant a eu lieu sur la chaîne source. La visibilité qui en résulte se limite à l’étape d’entrée, de façon analogue à une transaction transparent-vers-protégé (t-to-z) dans Zcash ; les dépenses ultérieures de la note déposée sont masquées.
Source: docs/superpowers/specs/2026-09-11-shielded-pool-design.md; docs/shielded.md (what is public table)
16. Pourquoi le mémo est-il un champ fixe de 512 octets ?
Un champ de longueur fixe garantit que le registre ne révèle ni la présence d’un mémo ni sa longueur : sur une chaîne compatible avec les mémos, chaque enveloppe créatrice de note, y compris les notes factices et la monnaie rendue, fait exactement 1 860 octets. Le mémo n’est transporté qu’à l’intérieur de l’enveloppe chiffrée, jamais dans la note, l’engagement ou la preuve, et il est lisible exactement par les parties qui peuvent déjà déchiffrer la note. Un mémo malformé est décodé comme un mémo vide, afin qu’il ne puisse pas rendre la note elle-même irrécupérable.
Source: docs/shielded.md §2; docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md
17. Pourquoi la preuve est-elle produite localement, et en quoi le prover délégué ne remet-il pas cela en cause ?
La preuve elle-même est l’autorisation de dépense : un bundle ne comporte ni signature ni champ expéditeur, de sorte que la clé de dépense n’a jamais besoin de quitter le portefeuille. Une preuve de bundle de tier 14 requiert environ 5,7 GB de mémoire, ce qui dépasse ce que les téléphones et les navigateurs peuvent fournir, d’où le prover délégué. L’autorisation scindée (bundle guest v3, paramètre de genèse hc_auth) sépare les deux rôles : le prover ne reçoit que la clé de visualisation nk et produit la preuve du bundle, tandis que le portefeuille produit une petite preuve d’autorisation de tier 10 à l’aide de sk. Un prover peut donc construire une preuve de bundle, mais ne peut pas autoriser une dépense (question 36).
Source: docs/prover.md §1; docs/shielded.md (split authorisation); docs/superpowers/specs/2026-09-28-delegated-proving-design.md
18. Pourquoi une fenêtre d’ancrage de 256 blocs ?
Une preuve est construite par rapport à une racine particulière de l’arbre d’engagements (son ancrage), et la construction d’une preuve de bundle de tier 14 prend environ 100 s. Le registre doit donc accepter des ancrages vieux de plusieurs minutes au moment de la soumission. La fenêtre était de 64 blocs dans la spécification initiale et a été élargie à 256 blocs à mesure que l’intervalle entre blocs diminuait, de façon à maintenir sa durée en temps réel au-dessus du temps de preuve.
Source: docs/shielded.md; docs/superpowers/specs/2026-09-11-shielded-pool-design.md
Le zkVM et le calcul confidentiel
19. Pourquoi RV32I comme ISA du guest (et non RV64) ?
Un mot de 32 bits se décompose en exactement quatre limbes d’octet, et le nombre premier de Goldilocks p = 2^64 − 2^32 + 1 est assez grand pour que le produit de deux valeurs de 32 bits ne déborde jamais du corps. RV64 doublerait le nombre de colonnes de limbes dans les tables d’ALU et de mémoire. RISC-V est en outre une cible existante des compilateurs courants, de sorte que les programmes guest sont de simples binaires compilés et non des programmes écrits dans un langage conçu sur mesure.
Source: docs/zkvm.md §2; research/docs/01-isa.md (‘Why RV32, not RV64’)
20. Pourquoi Goldilocks plutôt qu’un corps de 256 bits ?
Goldilocks est un nombre premier de 64 bits dont l’arithmétique se traduit efficacement en instructions CPU natives de 64 bits, et dont le groupe multiplicatif possède un grand sous-groupe de puissance de deux, comme l’exige FRI. Associé à des mots de 32 bits, il maintient chaque ligne de la trace étroite, ce qui rend faisable la production de preuves au profil de production sur un ordinateur portable. La sécurité perdue en travaillant sur un petit corps est récupérée en tirant les défis FRI dans un corps d’extension.
Source: docs/zkvm.md §2; randprotocol.org (performance section)
21. Pourquoi des tiers de gas plutôt qu’une mesure du gas par opcode ?
Le gas par opcode existe dans Ethereum parce que chaque nœud ré-exécute chaque transaction et que la durée d’exécution n’est pas bornée à l’avance. Dans Rand, aucun nœud n’exécute de programme : l’expéditeur l’exécute une seule fois, hors chaîne, et les nœuds vérifient une unique STARK dont le coût de vérification ne dépend que du tier, et non du calcul effectué. La terminaison est imposée par le tier, puisqu’une exécution qui ne s’arrête pas en 2^t cycles n’admet aucune preuve au tier t. La tarification se compose d’un plancher forfaitaire et d’une estimation de gas bornée par l’en-tête, et la capacité d’un bloc est un budget en octets. Le gas n’apparaît qu’à l’intérieur des guests interpréteurs EVM et sBPF, comme état privé, où il est nécessaire pour reproduire la sémantique de la chaîne source.
Source: docs/fees.md §3–4; docs/superpowers/specs/2026-09-28-gas-model-design.md
22. Pourquoi la trace est-elle scindée en neuf tables reliées par des bus LogUp ?
Une table unique et monolithique remplirait chaque ligne jusqu’à la largeur de l’opération la plus large. Séparer la trace en neuf tables — CPU, mémoire, ALU, range, nibble, Poseidon2, programme, entrée et publique —, chacune complétée seulement jusqu’à sa propre hauteur, maintient la trace totale petite. Des arguments LogUp établissent les relations de multiensembles entre les tables. Les tables Keccak et SHA-256 sont facultatives et ne sont incluses que lorsque le guest invoque l’appel système correspondant.
Source: docs/zkvm.md §5
23. Pourquoi un appel de programme ne publie-t-il que huit mots de sortie ?
Un appel de programme est une preuve que du code public a été exécuté correctement sur des entrées privées ; le registre n’enregistre que le reçu. Huit mots de 32 bits suffisent à lier un résultat, un engagement ou une décision, et une taille de sortie fixe garantit que la forme du reçu ne révèle rien du programme. Les sorties sont actuellement de simples données : un programme ne peut pas lui-même transférer de la valeur.
Source: randprotocol.org/usecases (platform note); docs/confidential.md
24. Pourquoi une enveloppe d’entrées d’appel ?
Un appelant qui conserve les entrées privées peut ensuite démontrer sur quoi un appel a été calculé. L’enveloppe d’entrées d’appel rend cette démonstration durable en stockant les entrées, chiffrées, à côté de l’appel, où un auditeur désigné peut les déchiffrer à l’aide d’une clé. Cela étend la divulgation sélective — confidentielle pour le marché, ouverte à un régulateur désigné — des paiements à l’exécution de programmes.
Source: docs/confidential.md (‘Call input envelopes’)
25. Pourquoi une modification de l’ensemble de contraintes est-elle un hard fork ?
Chaque nœud revérifie chaque preuve lors de la synchronisation, et une preuve n’est valide que par rapport à l’ensemble de contraintes (AIR) sous lequel elle a été produite. Une modification de l’AIR change donc l’ensemble des chaînes valides, et elle est introduite lors d’une coupure de genèse plutôt qu’adoptée nœud par nœud.
Source: docs/architecture.md (‘Why a constraint-set change is a hard fork’)
26. Pourquoi l’émulateur est-il la référence, et non l’AIR ?
L’émulateur est la spécification lisible de la machine, et l’AIR est un encodage de cette spécification sous forme de contraintes polynomiales. Lorsque les deux divergent, l’AIR est par définition fautive. La définition normative se trouve ainsi dans l’artefact le plus pratique à auditer pour des humains.
Source: docs/zkvm.md §5
Consensus et le nœud
27. Pourquoi HotStuff BFT chaîné ?
HotStuff chaîné offre une finalité déterministe : avec des quorums pondérés par le stake de plus de deux tiers, un bloc est final dès que trois certificats de quorum consécutifs ont été formés au-dessus de lui, et un bloc final n’est jamais réorganisé. L’intervalle entre blocs mesuré est de 1,2 s et le délai de finalité d’environ 3,6 s. Les utilisateurs institutionnels visés exigent une finalité de règlement sur laquelle ils puissent inscrire des écritures, ce qu’une chaîne à finalité probabiliste ne fournit pas.
Source: fullnode README; randprotocol.org (performance section); docs/architecture.md §6
28. Pourquoi la vérification des preuves est-elle hors de la boucle de consensus ?
Un nœud vérifie chaque STARK lorsqu’il admet la transaction (environ 32 ms à chaud), avant de la relayer, de sorte que la vérification ne se trouve jamais sur le chemin critique de la proposition de bloc. L’intervalle entre blocs est donc déterminé par la latence du consensus et non par la taille des preuves. Les contrôles sont ordonnés par coût, la STARK étant vérifiée en dernier, afin qu’une transaction malformée soit rejetée avant l’étape la plus coûteuse.
Source: randprotocol.org; docs/architecture.md (‘How it works’)
29. Pourquoi le registre des validators est-il public alors que tout le reste est protégé ?
Tous les réplicas doivent s’accorder sur les validators autorisés à proposer et sur les votes qui constituent un quorum, ce qui exige que les poids de stake soient publics. Le registre contient donc les montants de stake en clair. Le lien avec la propriété reste masqué : une garantie (bond) est financée à partir d’une note protégée et un retrait est versé dans une telle note, et aucune de ces opérations ne révèle à qui appartient la note.
Source: docs/staking.md §1
30. Pourquoi un nœud en cours de synchronisation ré-exécute-t-il chaque bloc au lieu de se fier aux certificats ?
Un nœud qui rejoint le réseau tardivement vérifie chaque certificat de quorum, revérifie chaque bundle et chaque preuve d’appel, puis compare les reçus obtenus avant d’accepter la chaîne. Comme la validité est établie par les preuves et non par les seules signatures, cette procédure n’est pas exposée aux attaques à longue portée (long-range attacks) qui touchent les chaînes sécurisées uniquement par des signatures. L’élagage des preuves dans l’historique a été écarté, car il supprimerait cette garantie.
Source : docs/architecture.md ; docs/aggregation.md (introduction)
31. Pourquoi conserver un plafond de bloc de 4 MiB alors qu’une preuve dépasse 1 Mo ?
Avec un plafond fixe, la taille des blocs ne peut pas croître ; lorsque la demande dépasse la capacité, c’est le débit qui est limité (à trois transferts protégés par bloc avec le profil à 80 requêtes). Une limite de débit a été jugée un mode de défaillance plus sûr qu’une croissance illimitée des blocs. Le remède retenu est l’agrégation au niveau du bloc, une preuve récursive par bloc, plutôt que le relèvement du plafond ou la réduction du niveau de solidité.
Source : docs/block-space.md §1, §6
32. Pourquoi le testnet élague-t-il l’historique à un jour ?
Un certificat de quorum portant 18 signatures Dilithium2 pèse environ 44 Ko et est stocké deux fois par bloc. Avec des blocs le plus souvent vides toutes les 1,4 s, cela représentait environ 6,6 Go par nœud et par jour ; les disques des nœuds se sont remplis et la chaîne a perdu son quorum à la hauteur 248 953. Les nœuds complets du testnet conservent désormais un jour d’historique, un unique nœud d’archive le conserve intégralement, et les nœuds du mainnet le conserveront intégralement. L’état du registre — l’arbre, l’ensemble des nullifiers, le registre et les programmes — n’est jamais élagué.
Source : docs/superpowers/specs/2026-09-24-history-pruning-design.md
33. Pourquoi libp2p ?
Le nœud utilise TCP avec Noise et Yamux, gossipsub pour les transactions et les votes, Kademlia avec une liste d’amorçage pour la découverte des pairs, mDNS sur les réseaux locaux, et requête-réponse pour la synchronisation des blocs. Ces composants sont standard et largement déployés ; le nœud hérite ainsi de la notation des pairs, de la reconnexion et des mises à niveau de transport, au lieu de maintenir ses propres implémentations.
Source : README du fullnode (ligne « networking »)
Marché de la preuve et agrégation
34. Pourquoi une agrégation de preuves au niveau du bloc ?
L’espace de bloc croît linéairement avec le nombre de bundles si chacun porte sa propre preuve d’environ 1,3 Mo. Une seule STARK récursive par bloc, qui vérifie les N preuves de bundle, maintient le coût de la preuve on-chain constant en N. Les validateurs vérifient alors une seule preuve agrégée (environ 16 ms à chaud) sur un CPU : un matériel standard suffit donc toujours pour valider, tandis que les agrégateurs équipés de GPU se font concurrence, sur un marché distinct et sans permission, pour la part des frais dévolue à la preuve et pour une subvention de bloc.
Source : docs/aggregation.md §1
35. Pourquoi trois rôles — validateur, agrégateur, prover délégué ?
Les trois rôles ont des exigences matérielles différentes et sont rémunérés par des parties différentes. Un validateur ordonne et vérifie les transactions sur un CPU et est rémunéré par la part des frais consacrée à la vérification. Un agrégateur produit la preuve récursive du bloc sur un GPU et est rémunéré par la part consacrée à la preuve et par la subvention. Un prover délégué produit une preuve de bundle unique pour un expéditeur dont l’appareil ne le peut pas (un téléphone ou un navigateur) et est rémunéré de façon privée par cet expéditeur. La séparation des rôles maintient une validation peu coûteuse et rend la preuve concurrentielle.
Source : docs/prover.md §1
36. Pourquoi un prover délégué ne peut-il pas dérober des fonds ?
Sous autorisation scindée, le prover reçoit la clé de visualisation nk mais non la clé de dépense sk. La preuve de bundle s’engage sur c = H(AUTH, nk || salt), et la preuve d’autorisation distincte du portefeuille démontre la connaissance de sk pour ce même c. Sans sk, le prover peut calculer la preuve de bundle mais ne peut pas produire d’autorisation valide, et le portefeuille vérifie la preuve renvoyée avant de la soumettre.
Source : docs/shielded.md (autorisation scindée) ; docs/prover.md §8
Le pont et zUSD
37. Pourquoi verrouiller des USDT/USDC sur leurs chaînes d’origine au lieu d’émettre un nouveau stablecoin ?
Une émission native sur Rand ferait dépendre la capacité de réserve des décisions de déploiement des émetteurs, qui échappent au contrôle du projet. Verrouiller des USDT et des USDC sur Ethereum, BSC, Tron et Solana puise les réserves dans les chaînes où ces actifs circulent déjà et n’introduit aucun nouvel émetteur : chaque unité de zUSD est une créance sur des USDT ou des USDC détenus dans un contrat de conservation lisible publiquement.
Source : randprotocol.org (section sur les réserves)
38. Pourquoi un ensemble de gardiens t-sur-n, et pourquoi le dire clairement ?
L’attestation est la seule preuve dont dispose Rand qu’un verrouillage a eu lieu sur une autre chaîne ; elle doit donc être signée par un groupe à seuil, et une attestation valide exige les signatures de plus des deux tiers des gardiens. L’hypothèse de confiance qui en résulte est énoncée explicitement. La garantie effective est la plus faible entre la solvabilité des réserves et l’intégrité du pont ; une coalition de t gardiens peut autoriser une émission sans verrouillage correspondant ; et l’exposition est bornée par les fonds en conservation sur chaque chaîne. Cette hypothèse constituait à l’origine l’argument contre la construction d’un pont. Elle n’est pas retirée, mais acceptée en échange de capacité de réserve.
Source : randprotocol.org (section sur les réserves, « Ce que cela coûte »)
39. Pourquoi une cosignature Dilithium2 à côté de l’attestation ECDSA ?
Les chaînes sources ne fournissent aucun vérificateur de signatures à base de réseaux euclidiens ; les libérations sur ces chaînes restent donc sécurisées par l’ECDSA classique, avec une exposition bornée par les fonds en conservation et par des plafonds. Tout message que le registre de Rand accepte de la part des gardiens — dépôts et rotations de l’ensemble de gardiens — doit en outre porter un quorum de signatures Dilithium2 des mêmes gardiens. Le chemin de mint est donc post-quantique, même si les points d’extrémité externes ne le sont pas. Les cosignatures sont transmises avec l’attestation et n’exigent aucune modification des contrats déployés.
Source : docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1
40. Pourquoi le facteur d’aveuglement de la note de dépôt est-il dérivé plutôt que choisi ?
Auparavant, l’engagement de la note de dépôt n’était déterminé qu’au moment où un relayeur soumettait l’attestation ; deux relayeurs pouvaient donc soumettre la même attestation avec des notes différentes. Dériver de façon déterministe le facteur d’aveuglement r à partir de l’attestation fixe l’engagement : les soumissions concurrentes entrent alors en collision sur un seul engagement, et le dépôt ne peut pas être émis deux fois.
Source : docs/bridge.md (F1, chain 14)
41. Pourquoi des USDT verrouillés sur Tron peuvent-ils sortir en USDT sur Ethereum ?
Le zUSD est fongible : chaque unité est une créance sur la réserve agrégée, et non sur la chaîne par laquelle elle est entrée. Découpler l’entrée de la sortie permet à la liquidité de se déplacer là où elle est demandée, à condition que la chaîne de destination détienne des réserves suffisantes. L’article sur les stablecoins démontre que l’invariant S ≤ Σ_c R_c, c’est-à-dire l’offre totale bornée par la somme des réserves par chaîne, est préservé par chaque transition d’état.
Source : randprotocol.org (section sur les réserves)
42. Pourquoi le blindage masque-t-il la répartition mais pas la quantité ?
L’offre totale de zUSD est publique dans le registre des tokens et la réserve de chaque chaîne est un solde public ; la solvabilité peut donc être vérifiée par n’importe qui. Ce qui est masqué, c’est la répartition des avoirs entre les propriétaires. Une limite s’applique : les quatre soldes de réserve ne peuvent pas être observés de façon atomique à un même instant ; pour ces chaînes, la vérification détecte donc l’insolvabilité a posteriori au lieu de l’empêcher.
Source : randprotocol.org (section sur les réserves)
43. Pourquoi une destruction (burn) est-elle la seule transaction qui désigne son actif ?
Un burn libère un actif précis sur une chaîne précise ; le contrat de conservation doit donc savoir de quel actif et de quelle chaîne il s’agit. Toute autre transaction transfère un actif non identifié. Le burn porte aussi les frais du pont, car c’est la seule transaction du pont dont l’expéditeur est le bénéficiaire.
Source : docs/architecture.md ; docs/shielded.md §2
Conformité et divulgation
44. Pourquoi des clés de visualisation plutôt qu’un « privé pour tous » ?
Les régulateurs n’ont pas accepté les systèmes de confidentialité dans lesquels la divulgation dépend de la coopération de la partie visée par l’enquête, comme l’illustre le cas de Tornado Cash. Rand traite donc la divulgation comme un objet du protocole. Le titulaire, ou un intermédiaire régulé, conserve une clé de visualisation ; un auditeur peut déchiffrer les transactions désignées dans une demande légale ; et l’objectif de conception est de disposer de clés à portée limitée qui révèlent la contrepartie et le montant sans révéler la stratégie de négociation. Pour des applications comme la paie, cette auditabilité est une exigence et non une limitation.
Source : randprotocol.org/usecases (section sur la réglementation ; cas de la paie)
45. Pourquoi la clé de visualisation sortante est-elle distincte de la clé entrante ?
La séparation permet à un expéditeur de prouver ce qu’il a payé sans accéder à l’historique du destinataire, et inversement. La clé de visualisation sortante ovk déchiffre les enveloppes que le portefeuille a envoyées ; la clé de décapsulation ML-KEM déchiffre les enveloppes qui lui sont adressées ; et une clé propre à chaque transaction divulgue exactement une sortie à un tiers.
Source : docs/shielded.md §1–2
Limitations connues
46. Que révèlent les preuves aujourd’hui, et pourquoi est-ce documenté ?
La revue du 2026-09-27 a constaté que, sous le guest v1 (chaînes 14–15), chaque preuve de bundle révèle quels emplacements d’entrée contiennent de vraies notes ainsi que le poids de Hamming de l’indice de chaque feuille dépensée. La cause est double : les totaux LogUp par table sont publiés sans aveuglement, et le flot de contrôle du guest se ramifie selon qu’une entrée est factice ou non. Le remède est un guest sans branchement (v2), qui sera retenu au prochain genesis. Ce constat est publié parce que le réseau est un testnet et que la documentation tient lieu de registre d’audit.
Source : docs/shielded.md (« Ce que les preuves révèlent aujourd’hui »)
47. Pourquoi la croissance de l’état est-elle sous-tarifée ?
Ethereum tarife les écritures de stockage parce que l’état stocké impose un coût permanent à chaque nœud. Rand ne tarife actuellement la croissance de l’arbre d’engagements, de l’ensemble des nullifiers et du stockage des programmes qu’au moyen des frais de déploiement par mot et des frais forfaitaires par bundle. Cela convient pour un testnet, mais cette question de tarification reste ouverte et doit être tranchée avant le mainnet ; sa résolution ne requiert pas de mesure par opcode.
Source : docs/fees.md §3 (caveats)
48. Pourquoi aucun audit indépendant n’a-t-il encore été réalisé ?
Le protocole est en cours de développement actif sur un testnet exploité par l’équipe, et d’autres jeux de contraintes et d’autres coupes de la chaîne sont attendus avant que la conception ne soit stable. Le site web l’indique sur chaque page. Les cycles d’audit internes (v3–v5) sont publiés dans docs/consensus.md et dans les spécifications de conception, afin que l’audit externe à venir dispose d’un dossier complet sur lequel s’appuyer.
Source : randprotocol.org (footer) ; docs/consensus.md