J’ai commencé à mettre en jeu des RLS dès la phase de promesse préalable, et lire le blog officiel est une habitude. Le 12 septembre, l’article sur l’auditabilité : dans la seconde moitié, il énumère six critères et affirme que, par construction, les critères mathématiques sont satisfaits intégralement. Je suis d’accord avec cette idée, mais « satisfaits par construction » est une affirmation vérifiable, pas quelque chose qu’il faudrait seulement croire. Alors j’y ai passé une semaine : j’ai pris ces six points un par un pour chercher les correspondances dans le code source public, la documentation technique et les interfaces en chaîne, et maintenant je partage avec vous.
D’abord, parlons de sa classification : je pense qu’elle est plus utile que la plupart des discussions du type « confidentialité ou transparence ». L’auditabilité se décline en trois voies : l’exigence mathématique, avec les preuves intégrées dans la construction cryptographique ; la confiance matérielle, reposant sur l’intégrité d’environnements d’exécution de confiance ; et le contrôle d’accès par politique, où la question de savoir qui peut voir quoi dépend de la configuration du responsable de l’exploitation du réseau.
À partir de là, il établit six critères d’auditabilité au niveau institutionnel, puis affirme que les mathématiques forcent à les satisfaire tous par construction.
Pour ne pas rester dans le flou, fixons un scénario : une banque participe à un pilote de monnaie numérique de banque centrale, et l’auditeur de la banque centrale veut vérifier les transactions de cette banque sur le réseau. Le cas de Drex au Brésil correspond exactement à ce scénario ; Rayls y fait un pilote. La seule question à répondre est : pourquoi ce que l’auditeur voit est-il digne de confiance ?
La première et la deuxième : divulgation sélective et limitation de portée.
Le résultat de ces deux points est la même chose : la clé d’observation.
Le GitHub de Rayls est public : dans le répertoire cryptography du dépôt relayer, il y a un mlkem.go. Il contient GenerateSalt, qui utilise l’encapsulation de la clé publique d’observation ML-KEM-768 du destinataire pour partager la clé secrète ; RecoverSalt utilise la clé privée d’observation ML-KEM-768 locale pour déchiffrer l’encapsulation ; l’appel se fait aux fonctions de la bibliothèque standard Go NewEncapsulationKey768 et NewDecapsulationKey768. Les noms de variables indiquent clairement view public key et view secret key.
Ainsi, la base cryptographique des clés d’observation est ML-KEM-768, et cette affirmation est vérifiable.
Encore une remarque sur l’importance de ce point. Le 30 août, l’article de Rayls sur la « préparation quantique » a insisté sur ceci : si une affirmation de sécurité quantique ne donne pas de paramètres au niveau des valeurs, ce n’est pas une prise de position mais un simple label. Et les exemples donnés sont justement que ML-KEM-512 et ML-KEM-1024 ne sont pas la même chose. Dans cet article sur sa propre mise à niveau, ils n’ont écrit que « remplacé par ML-KEM ». Mais le code indique 768. Ce n’est pas un défaut : 768 est le paramètre officiel NIST, et c’est aussi la valeur par défaut recommandée par l’industrie pour le déploiement en entreprise. C’est simplement un fait qu’on devait auparavant lire dans le code pour connaître, mais qui peut maintenant être cité directement.
Puisque les paliers sont déterminés, le coût de changement de palier peut être calculé. FIPS 203 fige les tailles : 768 bits pour la clé publique d’encapsulation, soit 1184 octets ; le chiffré fait 1088 octets ; et 1024, les deux, font 1568 octets.
Le point clé, c’est la fréquence, et la documentation de gestion des clés le dit aussi : l’encapsulation se fait une fois pour chaque paire de parties participantes lors de la mise en place du réseau ; le chiffré est stocké sur le hub du réseau privé ; ensuite, chaque message ne porte qu’un petit étiquette. Donc cela ne croît pas avec le volume de transactions. Un réseau de 30 institutions a 435 paires, et la différence entre deux paliers est d’environ 215 KB ; même pour 60 institutions et 1770 paires, l’écart est inférieur à 1 MB, et c’est unique.
Cette taille est si petite qu’elle n’a aucun sens ; et c’est précisément la conclusion : si un déploiement exige un palier plus élevé, les résistances ne viendront pas de la bande passante ou du stockage, c’est simplement une modification de code. Dans la discussion générale de migration post-quantique, le choix des paramètres correspond souvent à des compromis de performance ; mais à ce niveau-là, ce n’est pas le cas.
La portée est limitée à cette seule fois : la documentation technique en a ajouté l’autre moitié : la capacité d’observation peut être restreinte selon une fenêtre temporelle, et selon le compte.
Troisième : séparation de la visibilité et des droits
La formulation du document technique est plus ferme que celle du billet : la clé de dépense et la clé d’observation sont mathématiquement indépendantes, et on ne peut pas déduire l’une à partir de l’autre. Dans le résumé d’audit de sécurité, la phrase est encore plus directe : les droits d’observation et les droits de dépense sont séparés par la cryptographie plutôt que par la configuration ; donc une erreur de configuration ne peut pas transformer un droit de lecture en droit d’écriture.
Le document de gestion des clés m’a aussi corrigé une hypothèse que je faisais par défaut. Côté institution, tout le matériel de clé est traité de façon unifiée par un composant appelé Cryptographic Trust Suite, qui s’exécute à l’intérieur des propres frontières de l’institution. Le Relayer ne détient jamais de clés : il se contente de réaliser le chiffrement/déchiffrement pour le compte du système. Les droits de lecture de l’auditeur proviennent de ceci : chaque institution chiffre sa propre clé d’observation avec la clé publique de l’opérateur et stocke, avec un code d’authentification, le tout dans le hub du réseau privé, en tant que partie des enregistrements de la partie participante ; le service d’audit récupère cela au démarrage.
Il y a aussi un sous-produit de cette idée, que la documentation elle-même met en évidence : une institution peut voir sur le hub quelles entrées de parties participantes existent ; elle sait donc quelles choses ont été configurées comme lisibles. Le fait même d’accorder la visibilité est visible.
Au passage, ces trois types de tableaux de clés de cette page confirment aussi ce que j’ai vu dans le code : clés de signature ECDSA sur secp256k1, clés d’observation ML-KEM, et clés de paiement Baby JubJub sur BN254. La documentation et le code source concordent parfaitement.
Quatrième : vérifiabilité de la correction.
Ce billet repose sur des preuves à connaissance nulle ; Rayls dispose d’un service spécifique gnark-api pour générer et vérifier les preuves Groth16.
La documentation sur les transactions Enygma fournit quelques paramètres précis que personne ne cite d’habitude. La taille de l’ensemble d’anonymat est de 2 ou 6 : autrement dit, chaque transfert est regroupé avec un autre transfert ou avec cinq autres ; les observateurs ne peuvent pas distinguer qui initie. Un crossTransfer pointe au maximum vers 5 chaînes cibles et emporte 5 actions invoquables. L’atomicité des lots est garantie par le contrat Enygma sur le hub du réseau privé : il valide d’abord les preuves de tout le lot ; ce n’est qu’alors que toute destination est encasée.
Il y a aussi un coût opérationnel, que le document décrit de façon très directe : additionnez traitement par lots, génération de preuves et vérification par le hub, et vous obtenez un ordre de grandeur de plusieurs dizaines de secondes. Il faut donc planifier cela, et non comme une finalité sub-fois par seconde pour les transactions internes à une institution. La vérifiabilité de la correction n’est pas gratuite : son prix, ce sont ces dizaines de secondes.
Mais il y a un point de formulation qui mérite d’être mis en évidence séparément, car il implique quatre documents.
Le document technique dit que l’engagement Pedersen « cache une valeur tout en liant le prometteur à cette valeur, de sorte qu’il ne soit plus possible de la modifier après coup ». Il traite la propriété de liage comme un attribut dans l’énoncé. L’article quantique de août marque cet aspect comme ne nécessitant « aucun traitement », ce qui signifie qu’il est déjà résistant aux attaques quantiques. Dans le code, enygma_math.go montre qu’il utilise deux générateurs indépendants sur la courbe BabyJubJub : calcule v × G + r × H ; c’est une construction Pedersen standard et correcte. Et dans les deux articles académiques de Rayls, IACR 2025/1639 et 2025/1638, le terme utilisé pour décrire la conception entière est « quantum-private », c’est-à-dire « confidentialité quantique ». L’explication est qu’un adversaire quantique ne peut pas inférer l’expéditeur, le destinataire et le montant de la transaction. C’est une affirmation purement sur la confidentialité.
Ma lecture est la suivante : parmi les quatre documents, seul le vocabulaire de l’article est précis. BabyJubJub est construit sur le champ scalaire de BN254, donc la dissimulation tient face à un adversaire quantique ; c’est exactement la partie que l’article affirme. Le lien (liage) dépend des logarithmes discrets ; c’est précisément la partie que l’article n’affirme pas.
Pour une institution qui doit prouver un cadre de conformité résistant à un audit contradictoire, « un adversaire quantique ne peut pas voir mon solde » et « un adversaire quantique ne peut pas forger un solde fictif » sont deux choses différentes ; et pourtant, dans le document et le billet, elles sont présentées comme une seule et même chose. L’article ne commet pas cette fusion.
Cinquième : révocable.
J’ai cherché très longtemps cette question : la documentation de Rayls contient une page intitulée « Options de conception du réseau privé » où la réponse se trouve. Mais ce n’est pas la même chose que ce qui est dit dans le billet, et je pense que c’est précisément ce qui est plus intéressant.
L’auditeur est un rôle assigné par l’opérateur ; à côté, il y a aussi la partie participante et la partie émettrice. L’essentiel est que la visibilité de l’auditeur n’est pas un interrupteur, mais un palier : ce document illustre les paliers avec trois exemples.
Pour le palier du réseau de monnaie numérique de la banque centrale, l’auditeur peut déchiffrer les transactions entre nœuds. Pour le palier de la plateforme d’échanges d’actifs tokenisés, l’auditeur surveille en s’appuyant sur la vérification des engagements de Pedersen publiés par chaque nœud vers le hub ; le document précise noir sur blanc que l’auditeur n’a pas le droit d’accès direct aux données chiffrées des transactions : il ne voit que les preuves, pas le contenu. Le palier le plus extrême est le marché NFT opéré par une DAO : le rôle d’audit est tenu par le vérificateur prouvé par la blockchain ; par défaut, aucun droit d’accès. Ce n’est activé que lorsque la vérification des preuves indique une fraude pour cette transaction, déclenchant alors le déchiffrement de la transaction concernée.
Les trois paliers sont présentés ensemble : la phrase « Le niveau de déchiffrement peut être configuré pendant la mise en place » pour le navigateur de l’auditeur est mise en œuvre.
Revenons à ce que dit le billet. Le billet dit que la visibilité peut être retirée, et que le retrait est forcé par la cryptographie. Le document propose un autre design : la visibilité est définie par palier lors de la construction du réseau, et non pas révoquée après coup. Dans les deux cas, on limite l’auditeur : l’un est une contrainte préalable, l’autre une annulation après coup.
Oui, il existe un moyen de révocation côté gouvernance : les rôles peuvent être mis à jour, l’état des membres peut passer actif, gelé, désactivé ; le gel est exécuté par l’opérateur via le contrat de gouvernance ParticipantStorage. En revanche, révoquer la visibilité déjà obtenue par un auditeur : je n’ai trouvé aucune description de mise en œuvre. Un détail rend cette question très concrète : le document dit que l’auditeur reçoit, lors de l’ajout de chaque nouveau nœud, une fois un échange de clés Diffie-Hellman ; la capacité d’accès est fournie sous forme de matériel de clé. La révocation peut empêcher l’attribution future ; mais peut-elle rendre invalide le matériel de clé déjà livré ? Je suis encore en train d’étudier cela.
Sixième : persistance.
Contrairement à cette quatrième règle : le billet s’est sous-estimé lui-même.
Il dit que la persistance appartient à la gestion des clés, qui est « résoluble » ; à la lecture, ça ressemble à un espace vide. Mais la documentation de gestion des clés a transformé ce « résoluble » en une solution concrète. La conservation des clés est branchable sur ce que l’institution utilise déjà : AWS KMS, Google Cloud KMS, Azure Key Vault, un HSM local ; l’environnement de développement n’utilise que des fichiers locaux. Le chiffrement se fait via l’enveloppe statique : ce qui est persisté, c’est le chiffré, pas le matériel de clé.
Le plus crucial est cette phrase-là. Parce que chaque opération de chiffrement/déchiffrement passe par le service de gestion des clés de l’institution ; les traces d’audit que ces services génèrent existent déjà. Couvrir les opérations de clé de Rayls revient donc à couvrir les autres choses que l’institution fait fonctionner elle-même. La conclusion pour le service de conformité donnée dans le document est : il n’est pas nécessaire de construire une nouvelle « surface d’audit » pour cela. C’est précisément ce que la persistance veut : les pistes d’audit sont attachées au propre système de l’institution, et pas à un journal propriétaire de quelque fournisseur.
La rotation est aussi décrite très précisément : chaque chaîne peut avoir plusieurs clés de signature, elles tournent selon l’usage ; chaque clé conserve son propre nonce. Les clés qui ont signé les transactions en attente restent valides jusqu’à ce que ces transactions soient réglées. C’est justement ce que cela résout : l’interstice le plus facile à faire tourner pendant la rotation.
Cependant, il y a une exception : la section qui décrit la rotation parle des clés de signature ; je ne vois pas, dans ces pages, la rotation des clés d’observation. Et la persistance concerne précisément le fait de pouvoir lire, des années après, la piste d’audit : cela dépend davantage du côté de la clé d’observation.
L’outil réellement utilisé par l’auditeur
Au début, tout le monde lit la cryptographie ; mais ce que l’auditeur fait vraiment lorsqu’il s’assoit, c’est utiliser un outil. La documentation indique clairement que le navigateur de l’auditeur du réseau privé n’est accessible qu’aux auditeurs, et ni l’opérateur ni les autres parties participantes ne peuvent y accéder ; il fournit une vue rétrospective déchiffrée des transactions inter-chaînes.
Limitation de portée : seulement les transactions inter-chaînes dont les enregistrements sont faits jusqu’au hub du réseau privé ; les transactions à l’intérieur du propre grand livre souverain d’une institution, l’auditeur n’y a pas accès. Donc la « face visible » de l’audit concerne des relations entre institutions, pas à l’intérieur d’une institution.
Alors y a-t-il un exemple qui peut être vérifié entièrement ?
Oui, et il n’y en a qu’une : l’architecture elle-même détermine que la plupart des choses ne sont pas visibles.
La documentation officielle explique la raison : les transactions Enygma sont émises depuis le propre grand livre souverain de chaque institution ; chaque institution déploie son propre navigateur pour surveiller ce grand livre. La partie inter-chaînes retombe sur le hub du réseau privé, qui est consultée par le navigateur de l’auditeur. Les activités des institutions ne sont donc pas, par conception, sur la chaîne publique ; c’est pourquoi on ne trouve pas les transactions Enygma sur le navigateur de la chaîne publique. Ce n’est pas une omission : c’est un résultat inévitable d’une architecture en trois niveaux.
Mais le contrat de verrouillage de Parfin est sur la chaîne publique, et c’est justement un exemple complet de « la contrainte par les mathématiques ».
Ceux qui commencent par l’adresse 0x1463889D, le nom du contrat RlsTokenLock : le code source est vérifié, ce n’est pas un contrat proxy. Cela signifie que c’est l’un des rares objets à la fois lisibles dans le code et dont l’état actuel peut être vérifié. J’ai recoupé les deux côtés.
Le constructeur déclare totalAmount = 1 070 493 535 RLS. Les RLS actuellement réellement détenus par le contrat sont 1 070 493 535. Un wei près, aucun écart : parfaitement suffisant.
Là, le calendrier de déverrouillage mérite d’être mentionné. Le constructeur contient 48 horodatages ; je les ai tous décodés : le premier palier est le 1er décembre 2027, puis un palier le 1er de chaque mois ; le dernier palier est le 1er novembre 2031. L’écart est d’environ 3,92 ans, et chaque palier correspond à environ 22,3 millions de RLS. Les matériaux rendus publics insistaient sur un verrouillage jusqu’au 1er décembre 2027 : c’est le premier palier, c’est exact ; le constructeur donne une vue complète : juste après le premier palier, il y a encore presque quatre ans de libération mensuelle.
Les commentaires propres au contrat disent très clairement l’intention de conception : impossible à mettre à niveau ; les conditions du déploiement sont des conditions valables pour toujours ; sans déverrouillage préalable, aucune clé ne peut passer à un autre palier avant la date d’échéance. J’ai fait correspondre ces deux points un par un dans le code : le calendrier est écrit dans le constructeur sans setter, et le contrat n’est effectivement pas un proxy.
C’est à quoi ressemble « la contrainte par les mathématiques » sur un exemple que je peux vérifier entièrement : l’affirmation est cohérente avec le code, et le code est plus concret que le discours. Dans les six critères, tout ce que je ne pouvais trouver qu’à l’état de traces dans le code source et la documentation peut ici être suivi de bout en bout.
Deux autres références externes.
Quand le billet parle de TEE, il dit qu’il existe des vulnérabilités enregistrées qui ont brisé les garanties d’isolation de l’Intel SGX. Cette phrase est juste, mais elle affaiblit l’argument du billet. Les vulnérabilités de type isolation incluent Foreshadow, Plundervolt, EPIC Leak, SmashEx, avec pour numéros respectifs CVE-2018-3615, CVE-2019-11157, CVE-2022-21233, CVE-2021-0186 et CVE-2021-33767. Le vrai coup le plus grave est SGAxe en 2020 : il utilise CVE-2020-0549 pour extraire la clé de certification elle-même depuis l’enclave de certification de l’environnement de production Intel, puis il peut émettre n’importe quelle déclaration que les services de certification d’Intel considèrent comme légitime.
L’argument du billet est que la garantie du TEE est fournie par des preuves émises par le matériel, et que SGAxe brise précisément le mécanisme qui émet la preuve. La défaillance la plus grave n’est pas que les données ont été volées, mais que la garantie elle-même a été contrefaite. Pour dire les choses équitablement : tout cela a été corrigé via des mises à jour de microcode et le TCB recovery ; aujourd’hui, le SGX n’est plus celui de 2018. Formulé correctement : la racine de confiance matérielle a une surface de vulnérabilités en rotation.
Une autre partie dit que le Project Agora de BIS converge vers la même architecture. Je relis le rapport de prototype BIS du 27 mai : topologiquement, c’est effectivement similaire — structure à double couche, un grand livre partagé plus des grands livres indépendants par juridiction. Mais la frontière d’Agora est tracée par la juridiction : le rapport ne précise pas comment le contrôle d’accès à l’intérieur des grands livres de juridiction est mis en œuvre. Donc, si cette convergence s’étend jusqu’au niveau du modèle de confiance, les informations publiques disponibles ne le montrent pas.
Qu’est-ce qui est confirmé et qu’est-ce que je déduis
Confirmé : ML-KEM-768 utilisé pour les clés d’observation, voir relayer/cryptography/mlkem.go ; Pedersen construit avec deux générateurs pour BabyJubJub, voir enygma_math.go ; la clé secrète d’audit chiffrée et distribuée via le relayer, voir cryptography/service.go dans le service de gouvernance ; la mathématique entre clé de dépense et clé d’observation est indépendante ; la portée d’observation peut être limitée par le temps et le compte ; le navigateur de l’auditeur ne couvre que les transactions inter-chaînes et le niveau de déchiffrement peut être configuré pendant la mise en place ; tout cela se trouve dans la documentation technique officielle. Cryptographic Trust Suite détient unifié les clés et Relayer ne détient jamais de clés ; le stockage des clés est branchable sur KMS ou HSM ; chiffrement statique en enveloppe ; les journaux d’audit de l’activité de manipulation de clés via le service de gestion des clés propre à l’institution constituent la piste d’audit des opérations de clé ; les clés de signature tournent selon l’usage et restent valides jusqu’à ce que les transactions signées en attente soient réglées ; l’encapsulation est réalisée une seule fois, au moment où le réseau est construit, par partie participante ; la taille de l’ensemble d’anonymat est de 2 ou 6 ; un crossTransfer cible au plus 5 chaînes ; la finalité est de l’ordre de dizaines de secondes ; le gel des parties participantes est exécuté via le contrat de gouvernance ParticipantStorage par l’opérateur ; tout cela se trouve dans la documentation technique officielle. Le statut de vérification de RlsTokenLock, l’attribut non-proxy, le calendrier de 48 paliers, la déclaration du montant et le solde réel : tout cela est lu via l’interface publique à la date du 12 septembre 2026. Les identifiants des vulnérabilités SGX proviennent des enregistrements CVE et de l’article SGAxe. La structure et les données d’Agorá proviennent des documents publics de BIS.
Mes déductions : parmi les quatre documents, seul l’article emploie des termes précis à propos de Pedersen. La description « la frontière est forcée par les mathématiques » concerne l’exécution et non la distribution. SGAxe soutient davantage l’argument du billet que les vulnérabilités de type isolation. Dans ces trois documents, il n’est pas écrit quelque chose comme ça.
Non vérifiable : le mécanisme de révocation a posteriori de la cinquième règle. J’ai consulté cinq documents : gestion des clés, navigateur de l’auditeur, fondations cryptographiques d’Enygma, gel côté partie participante, options de conception du réseau privé, et hub du réseau privé ; plus deux dépôts de code pour relayer et services de gouvernance. J’ai trouvé la configuration en trois paliers de la visibilité, le mécanisme d’octroi, ainsi que le gel et la désactivation des parties participantes ; mais je n’ai pas trouvé une mise en œuvre qui permette de révoquer une visibilité déjà accordée et imposée par la cryptographie. Je n’ai pas non plus trouvé, pour la rotation à long terme de la clé d’observation : la section qui décrit la rotation parle des clés de signature.
Enfin, une chose sans lien avec la technique
La semaine même où ce billet a été rédigé, l’annonce officielle a indiqué que 55 % des paliers de mise en gage étaient prolongés jusqu’au 15 septembre, et a précisé qu’au cours de la période d’ajustement du mécanisme de mise en gage, les premiers soutiens continueraient à recevoir ces revenus. Les mises à jour ultérieures sur le staking et sur l’économie de jetons plus large, y compris la destruction, seraient publiées séparément.
Je suis déjà mis en gage dès la phase de pré-engagement, et j’ai participé intégralement pendant trois mois. À l’origine, le palier se terminait le 9 septembre ; ces jours-là, sur l’interface, je voyais le plafond atteindre sa limite et je ne pouvais pas ajouter, ce qui m’a fait penser à un problème du front-end. Maintenant, je vois que c’est le mécanisme qui est en train d’être ajusté.
Voici mon avis personnel, pas une assertion factuelle : pendant la fenêtre de modification du mécanisme, ils ont choisi d’étendre plutôt que de couper directement, et ils ont écrit les dates clairement. Je trouve que c’est une démarche de bonne foi. La période d’ajustement du mécanisme est le moment où l’on voit le plus souvent des formulations vagues ; donner une date exacte signifie que l’échéance exigera soit l’exécution, soit une nouvelle explication.
Ceci n’est qu’un événement concret et ne constitue pas un jugement sur un quelconque aménagement à long terme. Je ne prédis pas les rendements et je ne conseille à personne de prendre une décision sur cette base.
Sources de référence : blog officiel de Rayls « Auditability without surveillance: why mathematical enforcement beats trusting the code », 12 septembre 2026 ; deux pages du document technique officiel de Rayls : « fondations cryptographiques d’Enygma » et « navigateur d’auditeur pour le réseau privé » ; dépôts GitHub de l’organisation raylsnetwork : rayls-sovereign-relayer et rayls-sovereign-pnh-governance ; l’explorer.rayls.com du réseau public Rayls pour les addresses et l’interface des smart-contracts, extraction des données le 12 septembre 2026 ; NIST FIPS 203 ; enregistrements CVE 2018-3615, 2019-11157, 2020-0549, 2021-0186, 2021-33767, 2022-21233 et l’article SGAxe ; rapport de prototype BIS Project Agorá othp110 ; archives électroniques cryptographiques IACR 2025/1638 et 2025/1639 ; annonce du 12 septembre 2026 du compte X officiel de Rayls.
