rayls

$RLS
Rayls Relayer 코드를 다시 보다가 이상한 점 하나를 발견했습니다.
Relayer가 메시지를 전달하는 주체라면 "executeMessage()"에도 RELAYER 권한이 있어야 하는 것 아닌가?
그런데 실제 코드를 따라가 보니 아니었습니다.
오히려 Rayls는 메시지를 전달하는 권한과 실제 실행을 분리해 놓고 있었습니다.
Public Chain에서 Relayer가 처음 들어가는 곳은 "PublicRNEndpoint.receivePayload()"입니다.
여기서 메시지를 직접 실행하지 않고,
messageExecutor.executeMessage(...)
로 Executor에게 넘깁니다.
그래서 "RNMessageExecutorV1.executeMessage()"를 확인했습니다.
여기에는 RELAYER 권한이 없습니다.
"MESSAGE_EXECUTOR"도 아닙니다.
대신 "onlyEndpoint"로 보호되어 있습니다.
if (msg.sender != authorizedEndpoint) {
revert UnauthorizedEndpoint(msg.sender);
}
즉 호출 흐름은
Relayer → Endpoint → Executor
로 나뉩니다.
그리고 Executor가 최종 목적지에
to.call(data)
를 실행합니다.
이때 목적지 컨트랙트가 보는 "msg.sender"는 Relayer가 아니라 RNMessageExecutor입니다.
그래서 목적지의 "MESSAGE_EXECUTOR" 권한과 연결됩니다.
여기까지는 코드를 따라가면 확인할 수 있었습니다.
그런데 여기서 또 하나가 궁금해졌습니다.
그렇다면 같은 메시지가 다시 들어오면 어디에서 막을까?
"RNMessageExecutorV1"에는
mapping(bytes32 => bool) public executed;
가 있습니다.
Executor가 "messageId"를 기억하고 이미 처리한 메시지는 다시 실행하지 않는 구조입니다.
여기까지만 보면 흔한 replay protection처럼 보입니다.
그래서 테스트 코드까지 찾아봤습니다.
그리고 이번 조사에서 가장 중요한 부분을 발견했습니다.
Rayls에는
"ReplayProtection_ExecutorSingleSourceOfTruth.t.sol"
이라는 별도의 보안 테스트가 있습니다.
이 테스트는 단순히 같은 메시지를 두 번 보내는 것만 확인하지 않습니다.
같은 "messageId"로 목적지를 바꿔 재실행하는 경우,
그리고 Endpoint 자체를 교체한 뒤 기존 "messageId"를 다시 실행하는 경우까지 테스트합니다.
Endpoint를 바꿔도 결과는 똑같이 차단됩니다.
왜 이게 중요할까요?
재전송 방지의 상태가 Endpoint에 있는 게 아니라 Executor에 있기 때문입니다.
기존 Endpoint에서 메시지를 한 번 실행한 뒤 새로운 Endpoint를 연결해도,
Executor의
executed[messageId]
에는 이미 실행 기록이 남아 있습니다.
따라서 Endpoint가 바뀌어도
“이 메시지는 이미 실행됐다”
라는 판단은 바뀌지 않습니다.
이 테스트를 보고 제가 확인한 건 단순한 replay protection의 존재가 아니었습니다.
Rayls가 cross-chain 메시지 실행의 신뢰 경계를 Executor에 두고 있다는 것입니다.
Endpoint는 메시지를 전달하는 경로이고,
Executor가 실제 실행과 "messageId"의 실행 상태를 가지고 있습니다.
그래서 Endpoint가 교체되는 상황에서도 과거의 실행 기록이 이어집니다.
코드 흐름을 한 줄로 정리하면:
Relayer
→ "receivePayload()"
→ "executeMessage()"
→ "to.call()"
→ "MESSAGE_EXECUTOR"
→ "executed[messageId]"
처음 가졌던 질문,
“Relayer가 메시지를 실행한다면 왜 "executeMessage()"에는 RELAYER 권한이 없지?”
에 대한 답은 명확했습니다.
Rayls는 전달 경로와 실행 주체, 그리고 replay protection의 기준점을 하나로 묶지 않았습니다.
특히 이번에 확인한 “Endpoint를 교체해도 기존 "messageId"는 다시 실행되지 않는다”는 테스트는,
Rayls의 cross-chain 실행 구조를 이해할 때 꽤 중요한 단서라고 생각합니다.
#Rayls

La blockchain offre aux institutions financières quelque chose dont elles ont cruellement besoin : un règlement vérifiable sans dépendre entièrement d’une base de données fermée.
Mais il y a un problème évident.
Les banques ne peuvent pas simplement inscrire tous les détails de chaque transaction sur une blockchain publique.
Les soldes, les contreparties, les montants des transactions et d’autres informations sensibles doivent parfois rester confidentiels, tandis que les autorités de régulation, les contreparties et le réseau ont toujours besoin de suffisamment d’éléments pour vérifier qu’une opération a bien eu lieu.
Alors, comment concilier confidentialité et vérifiabilité ?

Dans le billet précédent, j’avais fait tourner le code de preuve publié par Rayls : j’avais mesuré 1,96 seconde par preuve pour l’ensemble d’anonymat à 6 participants. Mais dans cet article, il y avait trois phrases qui étaient des déductions et non des mesures ; je le savais. Cette semaine, j’ai changé la machine en 2 cœurs et ajouté quelques jeux de données, pour y revenir et compléter ces trois phrases.
Je précise d’abord la relation entre cet article et le précédent, pour éviter que les lecteurs pensent qu’il s’agit d’une simple re-publication. Le billet précédent mesurait le temps de preuve dans un environnement mono-cœur pour les groupes à 2 et à 6 participants ; ces deux chiffres ont été re-mesurés cette fois et ils ont presque inchangé. Tout le contenu nouveau de cet article, ce sont ces trois points que le billet précédent n’avait pas pu mesurer et n’avait donc pu que déduire.

Dans le tableau de comparaison des fournisseurs sur le site Rayls, il y a neuf lignes ; j’en ai choisi « confidentialité ». La raison est très simple : la confidentialité est importante et Besu est open source ; je peux donc vérifier sa documentation et son code.
Dans le tableau de comparaison, Rayls coche les deux lignes « confidentialité isolée » et « confidentialité cryptographique », tandis que Besu ne coche que la première. Je prévois de vérifier dans la documentation de l’autre côté : j’ai donc consulté la documentation de Besu, puis j’ai récupéré son code et compté une par une.
La conclusion n’est pas « Besu ne fonctionne pas ». La vraie différence est la suivante : ces deux sociétés placent la confidentialité à des niveaux différents, et le déplacement effectué par Besu est intervenu plus tôt que ce que beaucoup de gens pensaient.

Le 19 septembre, Rayls a publié un article (Privacy has a price) ; le titre mentionne « honest math », mais tout l’article ne fournit qu’un intervalle de chiffres : combien de centaines de millisecondes à quelques secondes pour une preuve. J’ai passé plusieurs semaines à écrire sur l’architecture de confidentialité de Rayls ; cette fois, je partage du nouveau contenu : j’ai téléchargé le code de preuve qu’il a rendu public, l’ai exécuté en pratique une cinquantaine de fois, et je vous partage ces conclusions intéressantes !
D’abord, voyons ce que le blog raconte. Son argument central peut se résumer en deux phrases. La première explique où se situe le coût : les transactions confidentielles coûtent plus cher que les transactions transparentes ; la partie chère, c’est la génération des preuves à connaissance nulle (ZK) ; la vérification, elle, est au contraire bon marché. Une preuve de transfert confidentiel de base prend plusieurs centaines de millisecondes à quelques secondes sur du matériel commercial courant. La seconde phrase dit quoi demander : les institutions ne devraient pas seulement regarder le TPS ; elles devraient mesurer quel est le débit nécessaire, à leur propre niveau de confidentialité et d’audit, face à une charge métier réelle. Le blog pense que le volume du règlement interbancaire n’est pas élevé et qu’il est totalement dans la capacité des systèmes de règlement confidentiel.

J’ai commencé à miser RLS dès la phase de pré-engagement ; lire les documents officiels, c’est juste une habitude. Lorsque le nom « Sovereign » est apparu, les discussions se sont surtout arrêtées à : « est-ce juste un changement de nom ? ». Je pense que cette question est inversée. Ce qui compte n’est pas le nom : c’est ce qui a été modifié dessous, et la quantité de choses vérifiables par une institution lors d’une due diligence. Dans cet article, pour chaque chiffre, je fournis des sources exactes : vous pouvez les reproduire une par une.
Je précise une chose d’abord : la semaine dernière, j’ai écrit un article sur l’auditable, et certains lecteurs l’ont peut-être vu.
La majorité du contenu de cet article est nouveau : provenant du dépôt de code Axyl, des répertoires d’audit dans le dépôt, et de la page « benchmark de performance Axyl ». Ces trois endroits, je n’y avais pas touché auparavant. Seule la petite section qui parle de la gestion des clés poursuit la conclusion de l’article précédent ; je l’indiquerai clairement à cet endroit. En séparant « nouveau » et « ancien », c’est parce que « ce que j’ai vérifié cette semaine » et « ce que j’avais vérifié avant » devraient permettre aux lecteurs de distinguer facilement.

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.

Franchement, la première fois que j’ai vu ces trois abréviations alignées, je me suis dit qu’elles étaient trois réponses à la même question : lequel est le plus rapide, lequel est le plus sûr, et basta. Puis j’ai compris : les mettre dans un classement, c’est comme demander « quelle est la meilleure, la marteau, le tournevis ou la clé », alors que la réponse dépend de savoir si tu as un clou, une vis ou un boulon sous la main.
En réalité, ce que chacun résout, ce sont trois problèmes différents qui ont été confondus.
Le premier problème, c’est : je veux prouver qu’une chose est vraie, mais les données nécessaires à la preuve sont sensibles, et je ne veux pas te les montrer. La banque veut expliquer au régulateur que « cette transaction est légale, l’autorisation est correcte, et il n’y a pas de doublon », mais elle ne veut pas inscrire les montants et les parties payeuses/bénéficiaires dans le grand livre. Cette exigence de prouver que c’est vrai sans divulguer les données, c’est le domaine du ZK. Son génie : assurer une validité fondée sur les mathématiques, et non sur « je t’ai promis, donc tu n’as pas besoin de voir ». Le régulateur ou l’auditeur qui obtient la clé de vérification peut vérifier la conclusion, sans pouvoir toucher aux données sous-jacentes. Le prix à payer est lui aussi réel : il excelle à prouver des propriétés des données, mais il est moins doué pour faire en sorte que plusieurs parties calculent ensemble quand aucune n’a toutes les données, et il consomme plus de puissance de calcul que le texte en clair.

À propos des annonces de verrouillage, je remarque qu’elles se concentrent généralement sur une seule chose : est-ce que cette promesse peut être vérifiée. Dans la plupart des projets, le “verrouillage de l’équipe” finit par se résumer à une phrase : vous n’avez qu’à croire ou à ne pas croire. Cette fois, ce n’est pas tout à fait pareil, alors j’ai vérifié en consultant la chaîne.
D’abord, clarifions les faits. Parfin est le partenaire technologique central derrière Rayls : il est responsable du développement des nœuds de confidentialité, du réseau privé, du cadre Enygma Privacy Framework et de la chaîne publique Rayls. En tant que rémunération pour son travail effectué avant le TGE, il a reçu 1 070 493 535 unités de RLS, soit 11 % de l’offre totale initiale de 10 milliards d’unités.
Cette série de jetons était auparavant détenue par une institution auprès d’un dépositaire sur Ethereum. La raison est très concrète : au moment du TGE, la chaîne publique Rayls n’était pas encore opérationnelle, il fallait donc d’abord les mettre en dépôt. Aujourd’hui, la chaîne fonctionne, et cette série de jetons a été migrée sur la chaîne publique Rayls, enfermée dans un contrat intelligent dont l’authenticité peut être vérifiée publiquement, tandis que le calendrier de déverrouillage a été repoussé de décembre 2026 à décembre 2027.

Frères, je me suis toujours tenu en embuscade dans la communauté Rayls. Je sais que vous êtes très mécontents de l’équipe. Moi aussi, je le suis. Mais l’équipe fait vraiment son travail, elle s’efforce sans relâche. Il faut juste dire que l’équipe Rayls suit une voie conforme. Frères, surtout ne renoncez pas. Tout laisser au temps. Je crois que l’équipe Rayls finira par livrer les copies qui nous satisferont. Je vais partager avec vous une bonne nouvelle : c’est à propos du fait que récemment l’équipe Rayls a intégré le RPC. C’est une chose très importante！！
Aperçu rapide
Qu’est-ce que le RPC
Vous pouvez comprendre le RPC comme une ligne directe dédiée (ligne privée) entre une application et la blockchain.

Chaque semaine, le milieu de la crypto ne manque pas de voir défiler : « tel ou tel grand acteur de la finance traditionnelle se lance dans la blockchain ». Pour ma part, je fais pratiquement systématiquement glisser ce genre de titres de côté, car la grande majorité finissent dans des laboratoires d’innovation : un communiqué de presse est publié, puis plus rien. Pour juger de la véracité, il y a un critère très simple : pour un client ordinaire, dans son application, peut-on cliquer directement pour l’utiliser ?
XP Inc. Cette fois, ce critère a été validé.
D’abord, clarifions de quelle entreprise il s’agit, car l’ampleur détermine le poids de la question. XP est une plateforme d’investissement brésilienne cotée au Nasdaq, et son code boursier est XP. J’ai vérifié sur sa page Relations investisseurs les données du T1 2026 : les actifs clients, de l’ordre de 152,9 milliards de reais (R$1,529 billion), pour être exact 1 529 milliards de reais (R$1.529 trillion) ; plus de 18 000 conseillers ; sur les douze derniers mois, un chiffre d’affaires total de 19,8 milliards de reais (R$198 亿雷亚尔) et un bénéfice avant impôts de 5,8 milliards de reais (R$58 亿雷亚尔).

Lors de ma dernière publication sur l'article avec XP, j'étais toujours curieux d'une question : une fois que des stablecoins de type « institutionnel » comme USDXP sont émis, comment participent-ils vraiment au règlement transfrontalier ? Cet article vient combler cette interrogation. Et en passant, il m'a aussi fait comprendre pour la première fois un mot : « sandwich de stablecoins ».
D'abord, expliquez ce mot : il est en fait très parlant. Un paiement transfrontalier en un seul trait de plume : aux deux extrémités, il y a la monnaie locale, et au milieu se glisse une couche de stablecoin public. Le payeur convertit la monnaie locale en stablecoin en dollars ; le stablecoin effectue ensuite la compensation transfrontalière sur la blockchain ; puis le bénéficiaire le reconvertit à nouveau en sa propre monnaie locale. Ça ressemble à deux tranches de pain avec la couche du milieu, non ? C'est exactement la façon dont l'industrie commence à décrire les règlements transfrontaliers en stablecoins.

J’ai commencé à miser à partir de la série d’engagements préalables de juin. Donc, j’ai déjà suivi ce processus une fois. Cette fois, c’est ouvert à tout le monde. Beaucoup de gens autour de moi me demandent comment procéder et à quoi faire attention. Autant tout expliquer clairement, une bonne fois pour toutes.
Parlons d’abord du changement en lui-même.
Rayls utilise une preuve d’enjeu déléguée : les validateurs exécutent les nœuds, produisent les blocs et garantissent la sécurité de la blockchain publique, tandis que les détenteurs ordinaires n’ont pas besoin de faire tourner eux-mêmes des nœuds. Ils peuvent déléguer leurs RLS à un certain validateur et partager une partie des récompenses de mise.
Ce mécanisme a été mis en ligne dès juin, mais à l’époque, il n’était accessible qu’aux portefeuilles ayant participé au programme d’engagement préalable et aux activités de seed de liquidité. Les personnes de cette première vague avaient déjà verrouillé leurs jetons avant la mise en ligne du mainnet. La version officielle leur offrait trois mois de bonus d’annualisation de 55 %, et même de 1 USDr envoyé dans chaque portefeuille éligible, juste pour s’assurer qu’ils n’aient même pas besoin de payer du gas.

J’ai commencé à miser sur RLS dès l’étape de l’engagement préalable. En temps normal, je lis le blog officiel, en général pour savoir si ma position pourrait être affectée. Mais l’article d’août 30 qui parle de quantique est différent : tout au long, il enseigne aux institutions comment faire leurs achats, ce n’est pas directement lié à quelqu’un comme moi, un petit investisseur. Pourtant, je l’ai lu jusqu’au bout, parce qu’il a posé dès le début une règle assez ferme, et cette règle, par la suite, m’a ramené au sujet de l’article lui-même, à moi-même.
Voici à quoi ressemble cette règle : une affirmation de « sécurité quantique » — si elle ne précise pas clairement quel algorithme de standardisation est utilisé et à quel niveau de paramètre — n’est pas une revendication, mais seulement une étiquette.

Dans l’article précédent, j’ai parlé du fait de rendre la mise en jeu (staking) ouverte. Mais en coulisses, beaucoup de frères m’ont surtout demandé la même chose : concrètement, comment procéder ? Donc cette fois, j’ai refait tout le parcours depuis le début jusqu’à la fin, en notant chaque étape et tous les endroits où l’on peut facilement se bloquer. Vous n’avez qu’à suivre.
Le lien de l’article précédent se trouve ici :质押开放给所有人了,但有几件事最好先知道
Commencez par bien préciser à qui s’adresse cet article. Si vous n’avez jamais vraiment touché à Rayls, voire que vous connaissez peu des termes comme wallet ou pont (bridge), alors c’est exactement pour vous. Pour chaque terme professionnel, je l’expliquerai brièvement au passage.

Je parcourais la documentation Rayls, et une chose qui m’a d’abord semblé confuse était la différence entre un nœud de confidentialité, un réseau privé et une chaîne publique.
Après avoir observé la manière dont elles se connectent, il est devenu beaucoup plus facile de comprendre.
Chacune a un rôle différent.
1. Nœud de confidentialité : la blockchain propre de l’institution
Un nœud de confidentialité Rayls est une chaîne compatible EVM exploitée par une seule institution.
Ce qui se passe à l’intérieur de l’institution reste dans son propre environnement.
Il peut émettre des jetons, gérer des soldes, exécuter des contrats intelligents et gérer son activité interne.

Honnêtement, quand il s’agit d’actualités sur la coopération, je les survole en général et je passe à autre chose : sur dix, neuf se contentent de s’afficher des logos croisés. Mais cette fois, je me suis arrêté pour lire jusqu’au bout, parce qu’elle touche à l’étape la plus basique — et la plus coûteuse — des paiements transfrontaliers.
Les virements internationaux sont lents, et beaucoup de gens pensent que c’est parce que « le réseau est lent ». La vraie raison est beaucoup plus terre à terre : ce n’est pas « l’argent » qui est « envoyé » ailleurs, c’est qu’il est déjà « déposé » quelque part. Quand une banque veut payer un pays donné, elle doit généralement ouvrir un compte dans la banque locale à l’avance, en y déposant une grosse somme ; dans le jargon, on appelle cela un compte nostro. Chaque couloir de paiement à l’échelle mondiale doit immobiliser une partie des fonds, un peu comme si, chez chacun de tes amis, tu laissais une liasse d’argent en dépôt, au cas où tu passerais un jour. L’argent reste sur le compte sans bouger ; les fluctuations de taux de change, c’est la banque qui les supporte. Un seul paiement transfrontalier peut ainsi prendre souvent plusieurs jours à s’exécuter entièrement.

Rayls est un projet que je suis depuis longtemps. Récemment, il a lancé un projet communautaire : The Rail. Le gameplay est assez différent des « activités de farm de points » habituelles. Il ne récompense pas le fait de spammer, mais reconnaît plutôt les personnes qui produisent réellement et de façon continue. Je vous explique simplement comment ça marche ! Famille, si vous trouvez ça aussi bien, rejoignez-nous : remplissez le formulaire et montez à bord !
https://tally.so/r/dWgdrA
1. Qu’est-ce que The Rail
The Rail est le programme d’ambassadeur communautaire de Rayls. Son objectif est de reconnaître des contributions significatives et de les transformer en identité, autorisations et récompenses. La position officielle est : « une communauté fondée sur de vraies contributions, plutôt qu’un jeu de farm de points ». Elle est décrite comme « une petite pièce où tout le monde se préoccupe vraiment les uns des autres ». Le mécanisme fonctionne ainsi : vous contribuez → vous gagnez des points → vous améliorez votre rôle → vous êtes reconnu.

Je ne regarde généralement la réglementation que d’un coup d’œil et je passe à autre chose, car la plupart n’ont aucun rapport avec les détenteurs ordinaires. Cette fois, en revanche, les règles britanniques m’ont fait changer d’avis : elles comportent un mécanisme assez peu visible, qui influencera concrètement la future décision des institutions quant à la chaîne à utiliser.
Commencez par clarifier la chronologie, car c’est elle qui détermine le niveau d’urgence.
Le Parlement britannique a adopté les réglementations concernées le 4 février 2026, et la FCA a publié le contenu central de ce dispositif le 30 juin. Au total, il s’agit de cinq documents de politique. Le canal d’habilitation ouvre le 30 septembre, tandis que l’ensemble complet des activités réglementées n’entrera pleinement en vigueur que le 25 octobre 2027.