Utilisez cette page pour voir qui fait quoi lorsqu’un transfert traverse Rand. Prouver coûte cher et vérifier coûte peu, si bien que le travail est réparti selon cette frontière. Le côté de l’expéditeur produit les preuves. Les validateurs se contentent de les vérifier, de les ordonner et de voter. Un agrégateur, une fois activé, replierait de nombreuses preuves en une seule. La figure suit un transfert depuis le portefeuille jusqu’à un bloc final ; les sections suivantes reprennent chaque rôle tour à tour.
Le parcours d’un transfert
- Le portefeuille construit le transfert. Il choisit ses notes en entrée, récupère leurs témoins de Merkle, construit quatre sorties et scelle chacune dans une enveloppe ML-KEM-768. Il calcule ensuite le binding de la transaction, un hachage portant sur tout sauf les preuves (Transactions).
- Le portefeuille prouve lui-même l’autorisation. Il s’agit d’une preuve de palier 10 portant sur la clé de dépense et un sel frais, l’affaire de quelques secondes. C’est la seule preuve qui touche à la clé de dépense, et elle est toujours produite sur la machine du portefeuille.
- La preuve de bundle est produite là où la mémoire le permet. Cette preuve de palier 14 établit la propriété, l’appartenance, les nullifiers et l’équilibre, et culmine à environ 6 GB. L’application de bureau et un téléphone disposant d’environ 8 GB la produisent eux-mêmes. Tout appareil plus modeste confie la tâche à un prover auquel il est apparié : un prover que vous exploitez, ou le pool des validateurs à
prover.randprotocol.org. L’un comme l’autre reçoit la clé de visualisation et le sel, jamais la clé de dépense (Proofs). - Un nœud RPC la vérifie. Le nœud auquel le portefeuille soumet la transaction recalcule le condensé du bundle, vérifie les deux preuves par rapport au binding, contrôle les frais, et ne diffuse la transaction à ses pairs qu’ensuite (Proofs, Mempool).
- Les validateurs l’ordonnent et la finalisent. Le leader de la vue prend les transactions encore applicables, celles dont les frais par KiB sont les plus élevés en premier, et propose un bloc. Chaque validateur revérifie chaque preuve qu’il contient et vote. Le bloc est validé une fois que trois certificats de quorum s’enchaînent sur lui dans des vues consécutives, ce qui exige que 18 des 26 validateurs de la chain 20 soient en ligne (Consensus).
- Le bloc est final, et chacun peut le vérifier. Une transaction est finale lorsque
rand_getTransactionrenvoie un bloc. Un nœud qui se synchronise plus tard revérifie chaque certificat et chaque preuve au lieu de se fier aux signatures.
Les rôles
| rôle | ce qu’il fait | prouve ? | ce qu’il voit | exécute |
|---|---|---|---|---|
| portefeuille | construit, autorise et soumet les transferts et les appels ; analyse la chaîne avec ses propres clés | toujours la preuve d’autorisation ; la preuve de bundle lorsque l’appareil dispose de la mémoire | tout ce qui concerne ses propres notes | les applications de la page Clients, ou rand ; sur la chain 20, Rand Wallet ou rand v0.6.8 ou ultérieure |
| prover délégué | produit la preuve de bundle pour un portefeuille apparié ; chaque réponse est vérifiée par le portefeuille avant toute soumission | preuves de bundle uniquement | la clé de visualisation du portefeuille apparié : tout son historique, passé et futur ; il ne peut pas dépenser | rand-prover run, ou rand-node run --prover |
| pool de provers des validateurs | un prover délégué exploité par quatre hôtes, deux validateurs et deux machines qui ne font que prouver, derrière un seul nom et une seule clé, pour les portefeuilles sans prover propre ; sans frais | preuves de bundle uniquement | la même chose que tout prover délégué, pour chaque portefeuille qui l’apparie | prover.randprotocol.org, empreinte RGTF-7HKJ-XZFV-GQ1J |
| nœud RPC (observateur) | se synchronise, revérifie chaque preuve, sert le JSON-RPC, diffuse les transactions vérifiées ; ne vote pas | non | champs publics uniquement : engagements, nullifiers, enveloppes scellées, preuves | rand-node run |
| validateur | tout ce que fait un observateur, plus la proposition de blocs dans ses vues et le vote dans HotStuff | non | champs publics uniquement | rand-node run --validator |
| agrégateur | produit une preuve récursive unique couvrant une fenêtre de preuves de bundle finalisées et la soumet pour un bloc de scellement | oui, les plus grandes preuves du réseau | champs publics et preuves uniquement | rand-node aggregate --watch, sur une chaîne dotée d’une section aggregation |
Prouver et valider sont deux tâches distinctes, et un validateur n’a pas besoin de matériel de prover. Deux des quatre membres du pool sont des validateurs qui exécutent aussi un prover, en tant que service ; les deux autres sont des machines dédiées à la preuve, qui ne détiennent aucune clé de validateur. Faire fonctionner le pool ne fait pas partie de la validation. Les dimensionnements de chaque rôle, ainsi que la mémoire de preuve mesurée par palier, figurent dans Validator and aggregator hardware.
Ce que chaque rôle peut apprendre
La confidentialité d’un transfert dépend de qui détient quelle clé, et non de la confiance accordée au réseau :
- Les validateurs, les nœuds RPC et l’explorateur voient ce que voit tout nœud : engagements, nullifiers, enveloppes scellées, frais et preuves. Ni le montant, ni l’actif, ni l’expéditeur, ni le destinataire.
- Un prover délégué, pool compris, reçoit la clé de visualisation. Avec elle, il peut lire tout l’historique du portefeuille apparié. Il ne peut jamais dépenser, car la preuve d’autorisation portant sur la clé de dépense est produite sur la machine du portefeuille. Apparier le pool revient à choisir de montrer cet historique à ses opérateurs. Si vous souhaitez le garder privé, prouvez sur votre propre appareil ou exploitez votre propre prover.
- Un prover délégué ne peut pas tromper le portefeuille. Le portefeuille lit le condensé de chaque preuve reçue, vérifie la taille et la valide localement, de sorte qu’une preuve erronée n’atteint jamais un nœud.
Agrégation : construite, mais inactive
Aujourd’hui, chaque bloc contient chaque preuve brute, soit environ 2.85 MB pour un transfert, si bien qu’un bloc de 20 MiB contient environ sept transferts. L’agrégation de blocs est la réponse du fullnode. Un agrégateur prend les preuves de bundle d’une fenêtre de blocs finalisés (rand_getUnsealed), produit une preuve récursive qui les vérifie toutes, et la soumet. Le bloc qui l’inclut scelle la fenêtre. Les validateurs vérifient alors un seul agrégat au lieu de N preuves, et les nœuds peuvent supprimer les preuves brutes couvertes. Les agrégateurs sont cautionnés et sans permission, s’exécutent sur des machines de classe GPU, et sont rémunérés par la part de preuve des bundles couverts, plus une subvention de bloc en nouveaux RAND.
Elle est construite et fusionnée, mais n’est pas active. Elle requiert une section aggregation dans le genesis, et la chain 20 n’en a aucune, si bien que rand_status indique zéro pour tous les compteurs d’agrégation. Avant de pouvoir l’activer, il faut re-mesurer la forme de son bundle selon le jeu de contraintes actuel, et mener un exercice d’agrégat falsifié contre le vérificateur de récursion. Sur une chaîne à autorisation séparée, elle ne scellerait en outre que les preuves de bundle, et non les preuves d’autorisation (Proofs).