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.
Deux types de « finalité », et les banques ont besoin des deux
Le principe 8 des Principes pour les infrastructures de marchés financiers (PFMI), publiés en 2012 par le Comité sur les paiements et les infrastructures de marché de la Banque des règlements internationaux et l’Organisation internationale des commissions de valeurs, stipule que les infrastructures de marchés financiers doivent assurer un « règlement définitif clair et certain », au plus tard à la fin du jour de valeur et, si nécessaire, en cours de journée ou en temps réel. L’un des critères essentiels est que les règles du système définissent clairement le moment où le règlement devient définitif. L’article 5 de la Directive européenne concernant le caractère définitif du règlement, adoptée en 1998, repose sur le même principe : à partir du moment défini par les règles du système, ni les participants ni les tiers ne peuvent révoquer les ordres de transfert.
Il s’agit de la finalité juridique, définie par les règles et le droit. La finalité technique pose une autre question : le bloc qui contient cette transaction peut-il encore être remplacé ?
Les blockchains publiques se répartissent ici en deux catégories. Bitcoin relève de la finalité probabiliste : plus il y a de blocs ajoutés après le vôtre, moins celui-ci risque d’être remplacé, mais ce risque n’est jamais nul. C’est pourquoi les plateformes d’échange demandent d’attendre un certain « nombre de confirmations ». Les chaînes à finalité déterministe utilisent un consensus tolérant les fautes byzantines : dès qu’un nombre suffisant de validateurs a signé un bloc, celui-ci ne changera plus. Ethereum se situe aujourd’hui entre les deux : le bloc le plus récent peut encore être remplacé ; il faut attendre que les validateurs votent sur un point de contrôle pour qu’il soit considéré comme finalisé.
Il faut considérer ensemble ces deux niveaux de finalité, car les règles bancaires ont besoin d’un moment précis à inscrire. La finalité déterministe fournit ce moment : le bloc est produit, et le règlement est final. La finalité probabiliste ne fournit qu’un processus au cours duquel le risque diminue progressivement.
Méthode de mesure, reproductible par tous
Le code de test se trouve dans le dossier finality du dépôt public hansonhan0520-lang/enygma-bench. Il est exécuté par GitHub Actions et les résultats sont automatiquement enregistrés dans le dépôt. C’est la première fois que je mesure la finalité ; les articles précédents portaient tous sur la puissance de calcul des preuves à divulgation nulle de connaissance et ne se recoupent pas avec celui-ci.
Le script d’échantillonnage a surveillé les deux chaînes simultanément, pendant une heure à chaque fois, au cours de deux sessions : une requête toutes les 0,25 seconde pour la blockchain publique Rayls et toutes les secondes pour Ethereum. À chaque requête, un appel groupé récupérait les blocs « latest », « safe » et « finalized », afin que les trois valeurs correspondent au même instant. Le hachage de chaque bloc a été enregistré lors de sa première apparition. À la fin, chaque bloc a été vérifié individuellement, puis l’ensemble a été vérifié de nouveau quelques heures plus tard, pour voir si l’un d’eux avait été remplacé.
Les deux échantillonnages correspondent aux exécutions Actions 40642493952 et 40649630038, effectuées le 28 octobre 2026, de 06:12 à 08:22 (UTC). Pour Ethereum, j’ai utilisé le nœud public de PublicNode ; pour Rayls, le nœud public officiel mainnet-rpc.rayls.com.
Ethereum : le nœud indique qu’il faut attendre environ 16 minutes
En deux heures, Ethereum a produit 599 blocs, à raison d’environ un toutes les 12 secondes, avec trois créneaux manqués. Le bloc marqué « finalized » par le nœud a toujours eu entre 62 et 95 blocs de retard sur le dernier bloc, soit entre 12,6 et 19,2 minutes ; la médiane était de 16 minutes sur les deux heures. Le bloc « safe » avait entre 30 et 63 blocs de retard.
Cela concorde avec les informations d’ethereum.org : un bloc Ethereum n’est finalisé qu’au bout d’environ 15 minutes, car les validateurs doivent voter pendant deux périodes (epochs).
Les 605 blocs d’Ethereum produits pendant ces deux heures ont été vérifiés après coup : aucun n’avait été remplacé. Mais cela ne signifie pas qu’Ethereum ne connaît jamais de réorganisations. Le remplacement de blocs récents est rare, et un échantillon de deux heures est trop limité pour en déterminer la fréquence. La vraie différence entre Ethereum et Rayls tient à ce que leurs nœuds sont prêts à garantir.
Rayls : dès qu’un bloc est produit, il est finalisé
Côté Rayls, j’ai envoyé 27 788 requêtes en deux heures. À chaque fois, le bloc « finalized » était identique au dernier bloc, tout comme le bloc « safe ». En moyenne, un bloc était produit toutes les 1,35 seconde, pour un total de 5 325 hauteurs observées. Toutes les valeurs ont été vérifiées de nouveau entre 0,3 et 1,4 heure après la fin de l’échantillonnage : aucun hachage n’avait changé.
Ce résultat tient à la conception du nœud, et non au hasard. Le client de consensus de la blockchain publique Rayls s’appelle Axyl et son code est publié sur GitHub. Le nœud public indique la version 1.4.1 (6909618), qui correspond exactement à l’étiquette mainnet-v1.4.1 du dépôt public. Dans le déroulement de cette version, chaque fois que la couche de consensus soumet un lot de résultats, le nœud les exécute, définit le bloc comme dernier bloc, puis appelle immédiatement finalize_block à la ligne suivante, en désignant ce bloc à la fois comme « finalized » et « safe ». Autrement dit, le nœud n’attend pas de voir « ce qui se passe après quelques blocs » : la soumission du consensus vaut finalité.
Un autre chiffre, du point de vue d’un observateur : un bloc Rayls apparaît sur le nœud public environ 2 secondes après l’horodatage qu’il contient ; pour Ethereum, c’est également autour de 2 secondes. Les horodatages des blocs étant précis à la seconde, ce chiffre donne seulement un ordre de grandeur.
Le prix à payer : mieux vaut s’arrêter que bifurquer
L’autre face de la finalité déterministe, c’est que la chaîne doit s’arrêter lorsque le consensus ne peut plus progresser. La documentation d’Axyl le dit sans détour : la production des blocs et leur finalité dépendent du bon fonctionnement des validateurs actifs ; sans eux, rien n’est soumis.
J’ai utilisé une recherche dichotomique pour repérer le plus long intervalle entre deux blocs sur la chaîne et j’ai trouvé deux interruptions. La première a duré 11,72 heures, du 5 mai 2026 à 21:59:32 au 6 mai à 09:42:29 (UTC). La deuxième a duré 9,15 heures, du 21 juin à 01:05:33 à 10:14:47. Pour chacune, le hachage parent du premier bloc produit après l’interruption correspond exactement à celui du dernier bloc précédant l’interruption. Cela montre que la chaîne a repris là où elle s’était arrêtée, sans bifurcation ni remplacement de bloc.
Le dépôt Axyl contient un rapport d’incident sur la deuxième interruption. Au 52e changement de période, un lot de transactions dont l’exécution avait été différée a été intégré au dernier bloc, mais avec un numéro de tour plus ancien. Le proposant a alors estimé que l’exécution avait pris un retard critique et a continuellement limité le débit. Les sept validateurs ont fini par s’arrêter, et même un redémarrage n’a pas suffi. Le correctif a été soumis sous le commit 3a71a1a. La première interruption n’est pas documentée dans le dossier des incidents du dépôt public.
Ce sont les interruptions les plus longues que j’ai trouvées dans chacune des deux périodes examinées. Je n’ai pas analysé chaque bloc de toute la chaîne ; je ne peux donc pas exclure qu’il y ait eu des arrêts plus courts.
L’intervalle entre les blocs a changé deux fois
L’analyse rétrospective du rythme de production des blocs sur l’ensemble de la chaîne révèle aussi une information absente de la documentation publique. J’ai échantillonné uniformément 61 segments, du bloc de genèse à aujourd’hui, et calculé l’intervalle moyen entre les blocs pour chacun. Du lancement, le 30 avril, jusqu’aux alentours du 9 septembre, cet intervalle est resté stable entre 1,29 et 1,32 seconde, à l’exception des deux segments comprenant les interruptions. Du 11 septembre au 5 octobre, il est tombé entre 0,69 et 0,70 seconde. À partir du 7 octobre, il est revenu entre 1,33 et 1,38 seconde.
Cela explique un chiffre plus ancien. Le 12 septembre, j’avais relevé sur l’explorateur de blocs un temps moyen de production de 568 millisecondes : c’était pendant la période accélérée. Citer ce chiffre aujourd’hui serait dépassé.
Je n’ai pas pu déterminer la cause de ces changements. Les trois versions du réseau principal publiées publiquement sont datées des 27 juillet, 25 août et 2 octobre ; aucune nouvelle version n’est sortie autour du premier changement. Une version du 2 octobre est sortie quelques jours avant le deuxième changement, mais la proximité des dates ne prouve pas qu’elle en soit la cause. Dans le code, les paramètres relatifs au rythme de production des blocs sont configurés par l’opérateur. Les valeurs par défaut prévoient un intervalle maximal de 10 secondes et un intervalle minimal de 5 secondes entre les propositions ; sur le réseau principal, les blocs sont produits bien plus rapidement que ne le prévoit cette configuration par défaut.
Par ailleurs, la mention d’une « finalité en moins d’une seconde » dans la documentation de Rayls figure sur la page de présentation du registre institutionnel Sovereign. Sovereign et la blockchain publique utilisent tous deux le consensus Axyl, mais leurs déploiements diffèrent. J’ai mesuré la blockchain publique : ce chiffre ne permet donc ni de confirmer ni d’infirmer l’affirmation concernant Sovereign.
Ce que cela signifie pour les banques
Cette section relève de l’interprétation, pas de la mesure.
Premièrement, la finalité déterministe permet de faire correspondre directement le « moment final » des règles à un bloc. Les PFMI exigent que les règles du système définissent le moment où le règlement devient définitif. Sur la blockchain publique Rayls, le bloc constitue naturellement un tel moment, tandis qu’avec Ethereum, il faut attendre environ un quart d’heure.
Deuxièmement, les banques doivent surtout s’interroger sur la disponibilité. Au Royaume-Uni, le système CHAPS règle les paiements chaque jour ouvré de 06:00 à 18:00. Une interruption de 9 à 12 heures peut occuper la majeure partie d’une journée de règlement. Elle n’annule pas les transactions déjà réglées, mais empêche les nouveaux règlements. Pour évaluer ce type de réseau, il faut donc s’intéresser non seulement à la finalité, mais aussi à la fréquence et à la durée des interruptions, ainsi qu’aux procédures de reprise : ce sont des questions qui relèvent de la résilience opérationnelle et intéressent les autorités de régulation.
Troisièmement, la finalité technique n’équivaut pas à la finalité juridique. Le fait qu’un bloc ne puisse pas être remplacé est un fait technique ; le moment où une transaction devient juridiquement irrévocable dépend toujours des règles du système et du droit applicable.
Ce qui reste à déterminer
J’ai mesuré la blockchain publique Rayls, pas le registre Sovereign ni le hub de réseau privé réellement utilisés par les banques. Vers la fin du deuxième échantillonnage, le nœud public officiel de Rayls a commencé à renvoyer « trop de requêtes » (HTTP 429), ce qui indique qu’il applique une limitation de débit ; les données Rayls de cette période avaient déjà été enregistrées et les résultats récapitulatifs ont été recalculés à partir des données brutes. D’après la documentation de Rayls, le hub fonctionne toujours sur un réseau de preuve d’autorité Besu ; elle indique aussi que la finalité des transactions Enygma entre institutions nécessite plusieurs dizaines de secondes. Aucun de ces deux éléments n’a été mesuré cette fois-ci. Les observations proviennent d’un seul nœud public et d’un seul exécuteur GitHub. Le fait qu’aucune réorganisation n’ait été observée sur Ethereum pendant deux heures ne signifie pas que sa fréquence de réorganisation est négligeable. Pour les interruptions, je n’ai recherché que la plus longue dans chacune des deux périodes examinées.
Mon point de vue
Sur Ethereum, il faut attendre environ un quart d’heure pour pouvoir considérer que les fonds sont « arrivés » ; sur la blockchain publique Rayls, c’est le cas dès qu’un bloc est produit, et le code du nœud le confirme. Mais la finalité déterministe s’accompagne d’un autre risque : l’arrêt. La blockchain publique Rayls s’est arrêtée au moins deux fois en six mois, chaque fois pendant plus de 9 heures.
Le critère est simple : n’importe qui peut lancer les deux workflows, finality et finality-halt, dans le dépôt enygma-bench pour vérifier si le statut « finalisé » de Rayls correspond toujours au dernier bloc et si la chaîne a connu de nouvelles longues interruptions. Si Rayls publie des données sur la finalité et la disponibilité de Sovereign et du hub, la même méthode pourra servir à les comparer.
Sources :
CPMI-IOSCO (Principes pour les infrastructures de marchés financiers), principe 8, 16 avril 2012 : https://www.bis.org/committees/cpmi/pfmi/overview
Union européenne (Directive concernant le caractère définitif du règlement), 98/26/CE, 19 mai 1998 : https://legislation.gov.uk/eudr/1998/26/data.html
ethereum.org, Single slot finality (page mise à jour le 23 juillet 2026) : https://ethereum.org/roadmap/single-slot-finality/
Code source du client de consensus Axyl, étiquette mainnet-v1.4.1 (2 octobre 2026), rapport d’incident doc/incidents/2026-06-21-mainnet-halt.md : https://github.com/raylsnetwork/axyl
Code d’échantillonnage et journaux complets de cet article, exécutions Actions 40642493952 et 40649630038, vérifications ultérieures et repérage des interruptions (28 octobre 2026) : https://github.com/hansonhan0520-lang/enygma-bench
