rayls

@Rayls 의 스테이킹 APY를 볼 때 단순히 표시된 수익률만 확인하면 충분할까?
실제 수익률을 이해하려면 한 가지를 더 살펴봐야 한다.
수익이 어떻게 기록되고, APY로 계산되며, 실제 보상 지급까지 연결되는가?
이번에는 Rayls 공식 저장소의 "RewardCurve"와 "RewardDistributor" 코드를 직접 비교해 봤다.
1. 스테이킹 APY에 네트워크 수익이 자동으로 반영될까?
"RewardCurve"는 기본 월간 배출량과 변동 배출량을 합산해 연간 APY를 계산하도록 설계돼 있다.
여기서 중요한 부분은 "recordRevenue()"다.
이 함수는 네트워크 수익을 자동으로 가져오는 기능이 아니다. "REVENUE_REPORTER_ROLE" 권한을 가진 계정이 직접 호출해야 변동 배출량에 반영된다.
즉, 수수료를 처리하는 "FeeAggregator"가 존재한다고 해서 그 수익이 자동으로 "RewardCurve"에 기록되는 것은 아니다.
수익 처리와 APY 계산에 반영하는 과정은 별개다.
2. 계산된 APY가 실제 보상 지급액을 보장할까?
그렇지는 않다.
"RewardCurve"는 APY를 계산하지만 RLS를 직접 보관하거나 지급하지 않는다.
실제 보상 분배는 "RewardDistributor"가 담당한다.
코드를 보면 보상 목표액을 계산한 뒤, 부족한 경우 "RLSAccumulator"에 있는 사용 가능한 잔액으로 보충을 시도한다.
따라서 APY가 계산된다는 사실만으로 해당 수익률이 그대로 지급된다고 볼 수는 없다.
실제 지급은 보상 재원과 분배 조건에도 영향을 받는다.
3. 그렇다면 RewardCurve는 실제 메인넷에 적용됐을까?
이번 분석에서 가장 중요했던 부분이다.
Rayls 공식 저장소의 RewardCurve 배포 안내서를 확인해 보니, 해당 문서에는 RewardCurve가 고정된 배포 주소와 "deployments.json" 등록 항목을 갖고 있지 않으며, 아직 어디에도 배포되지 않았다고 명시돼 있다.
또한 배포 스크립트는 Rayls 메인넷에서 실행을 거부하도록 작성돼 있다.
물론 "RewardDistributor"에는 RewardCurve 주소를 연결하는 설정 기능이 존재한다.
하지만 코드에 연결 기능이 있다는 것과 실제 메인넷에서 연결돼 작동한다는 것은 다른 이야기다.
따라서 공개 저장소만으로 현재 메인넷에서 수익 연동 APY가 활성화됐다고 판단할 수는 없다.
4. 이번 코드 분석으로 확인한 내용
- 코드에서 확인: RewardCurve는 기본 배출량과 변동 배출량을 바탕으로 APY를 계산한다.
- 코드에서 확인: 수익 기록과 월간 초기화에는 별도 권한을 가진 계정의 호출이 필요하다.
- 코드에서 확인: 실제 보상 분배는 RewardDistributor가 담당한다.
- 공식 문서에서 확인: RewardCurve의 배포 상태에 관한 안내와 메인넷 배포 제한이 기록돼 있다.
- 아직 확인하지 못한 것: 현재 메인넷에서 RewardCurve가 실제로 배포되고 RewardDistributor에 연결돼 있는지 여부다.
이번에 코드를 살펴보면서 느낀 점은 명확하다.
스테이킹 APY를 평가할 때는 숫자만 보는 것이 아니라, 그 숫자가 어떤 데이터로 계산되는지, 실제 보상 재원은 어디서 나오는지, 그리고 해당 기능이 실제 네트워크에 적용됐는지까지 확인해야 한다.
코드가 존재한다는 것과 실제로 작동한다는 것은 다르다.
이 차이를 구분하는 것이 스테이킹 수익률을 제대로 이해하는 첫걸음이라고 생각한다.
참고 자료
RewardCurve 코드
https://github.com/raylsnetwork/axyl/blob/main/rayls-contracts/src/fees/RewardCurve.sol
RewardDistributor 코드
https://github.com/raylsnetwork/axyl/blob/main/rayls-contracts/src/fees/RewardDistributor.sol
RewardCurve 공식 배포 안내서
https://github.com/raylsnetwork/axyl/blob/main/rayls-contracts/script/interactions/reward-curve/README.md
RewardCurve 배포 도구 관련 PR
https://github.com/raylsnetwork/axyl/pull/174
#Rayls $RLS

Dans mes derniers articles, je mesurais le temps nécessaire pour calculer les preuves de Rayls. Mais pour les banques, une question plus fondamentale se pose : à quel moment l’argent est-il réellement arrivé à destination et ne peut-il plus être récupéré ? Cette semaine, j’ai changé d’approche : j’ai demandé aux serveurs de GitHub de surveiller simultanément Ethereum et la blockchain publique de Rayls pendant deux heures, pour voir comment elles répondent elles-mêmes à cette question.
Commençons par la réponse courte. Pour les banques, « arrivé à destination » a deux sens : irrévocable sur le plan juridique et impossible à annuler sur le plan technique. Sur le plan technique, les blocs qu’un nœud Ethereum marque lui-même comme « finalisés » ont entre 12,6 et 19,2 minutes de retard sur le bloc le plus récent, avec une médiane de 16 minutes. La blockchain publique de Rayls, elle, marque chaque bloc comme finalisé dès qu’il est produit ; il y en a environ un toutes les 1,35 seconde. Cette « finalité déterministe » (deterministic finality) a aussi un coût : lorsque le consensus ne peut plus progresser, la chaîne s’arrête au lieu de se diviser. Depuis son lancement, la blockchain publique de Rayls s’est arrêtée au moins deux fois : une fois pendant 11,72 heures et une autre pendant 9,15 heures. Après chaque reprise, elle a directement enchaîné avec le bloc qui suivait celui où elle s’était arrêtée.

Les blockchains publiques offrent de la transparence, mais les banques ne peuvent pas traiter chaque transaction financière comme une publication sur les réseaux sociaux. Les soldes des clients, les montants des paiements et les contreparties peuvent être sensibles sur le plan commercial ou personnel.
La vraie question n’est donc pas de savoir si les banques devraient utiliser la blockchain, mais comment elles peuvent profiter des avantages du règlement on-chain sans exposer d’informations financières confidentielles.
1. Pourquoi les blockchains publiques classiques posent problème
Sur une blockchain transparente classique, les transactions peuvent révéler des adresses de portefeuilles, des montants de jetons et des habitudes d’activité financière. Même lorsque les vrais noms ne sont pas directement associés aux adresses, des transactions répétées peuvent parfois aider des observateurs à relier ces activités à des entités précises.

Si un transfert échoue sur Rayls, mes jetons me seront-ils restitués ?
Que deviennent les jetons traités sur la chaîne source si la transaction échoue sur la chaîne de destination lors d’un transfert interchaînes ? $RLS
Lorsqu’un jeton est transféré vers une autre chaîne, les actifs peuvent être verrouillés ou brûlés sur la chaîne source. Mais si le traitement échoue sur la chaîne de destination, une procédure de récupération des actifs est nécessaire.
La documentation officielle de Rayls décrit un mécanisme de récupération prévu pour ce type de situation. Toutefois, l’examen du code public fait apparaître d’autres points à vérifier.

Ce que j’ai découvert en examinant le consensus de Rayls, son architecture de règlement et ses reçus de transaction.
J’ai commencé par une question simple :
Si une blockchain promet une finalité en moins d’une seconde, cela signifie-t-il que la transaction entière est terminée en moins d’une seconde ?
À première vue, la réponse peut sembler évidente. Une transaction est confirmée, le réseau parvient à un consensus et l’opération est terminée.
Mais les infrastructures financières sont plus complexes que cela.
Une transaction peut être validée sur un registre alors qu’une opération plus vaste dépend encore d’un autre registre, d’un relais, de la vérification d’une preuve ou de son exécution sur le réseau de destination.

$RLS
En reconsidérant le code du Relayer de Rayls, j’ai découvert un point étrange.
Si Relayer est l’entité qui transmet le message, ne devrait-il pas aussi avoir l’autorisation RELAYER pour "executeMessage()" ?
Cependant, en suivant le code réel, je me suis rendu compte que non.
Au contraire, Rayls a séparé l’autorisation de transmettre le message et l’exécution réelle.
Sur la Public Chain, l’endroit où le Relayer intervient pour la première fois est "PublicRNEndpoint.receivePayload()".
Ici, au lieu d’exécuter directement le message,

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.

À 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.

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.

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.

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.

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 亿雷亚尔).

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.

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.