Les développeurs qui maintiennent le code de consensus du nœud Cardano ont fusionné le cœur d’Ouroboros Leios, la mise à niveau de débit plus connue sous le nom de Cardano Leios, dans leur branche principale le 9 octobre 2026. La modification figure dans la pull request n° 2386 du dépôt IntersectMBO/ouroboros-consensus, qui introduit un protocole baptisé Praos2, décrit dans son titre comme « Praos plus la couche Leios ». Le rapport hebdomadaire de l’équipe consensus daté du 23 octobre confirme la fusion et indique que deux briques réseau l’ont rejointe dans la branche principale.
Le code est un vrai progrès. Le chiffre qui lui est accolé, lui, n’est pas un résultat. CryptoSlate, qui a relayé la fusion le 26 octobre, titre sur une « avancée de x15 », mais ce x15 est le haut d’une fourchette conditionnelle publiée par Input Output (IOG) : Leios doit démarrer à trois à cinq fois la capacité actuelle et n’atteindre environ 10 à 15 fois qu’après au moins deux mises à jour de paramètres ultérieures, chacune soumise à un vote de gouvernance. Aucune date n’existe pour ces étapes, et un morceau du logiciel, la sélection des blocs endorseurs, n’est pas encore écrit.
Le mainnet de Cardano (ADA) tourne toujours sous Praos classique. Entre le code fusionné et une chaîne plus rapide, blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il reste un testnet qui n’a pas encore basculé sur les nouvelles règles, un amendement constitutionnel à l’état de brouillon, un vote de hard fork, l’enregistrement de clés par plusieurs centaines de pools de staking et au moins deux votes de paramètres supplémentaires.
Cardano Leios : ce qui a été fusionné le 9 octobre
La pull request n° 2386 a été ouverte par l’utilisateur GitHub nfrisby, puis approuvée par les relecteurs ch1bo et jasagredo avant d’être fusionnée sous le commit 35d0289. ch1bo avait d’abord demandé des modifications. Le texte avait été rédigé comme alternative à une proposition antérieure, la n° 2354, que ch1bo disait dans la discussion vouloir fermer. Concrètement, Praos2 est le protocole Ouroboros Praos existant, celui qui produit aujourd’hui les blocs de Cardano, doté d’une couche supplémentaire qui permet à la chaîne de transporter beaucoup plus de données de transactions.
Plusieurs fusions plus modestes ont suivi sur le même dépôt au cours des deux semaines suivantes :
- n° 2400, « Leios : integrate latest changes for 2026w41 », fusionnée le 11 octobre.
- n° 2415, qui empêche Praos2 de certifier au-delà des frontières d’époque, fusionnée le 16 octobre.
- n° 2278, qui adapte la spécification formelle à Linear Leios, la conception actuelle, fusionnée le 20 octobre.
Une quatrième fusion, la n° 2427 du 21 octobre, ajoute une vue du registre pour Peras, un projet distinct de finalité plus rapide. Elle est étiquetée Peras sur GitHub, pas Leios, et ne doit pas être comptée comme un progrès de Leios.
Les briques réseau étaient dans la branche principale le 23 octobre
Le rapport de développement hebdomadaire du 23 octobre, publié par Essential Cardano, indique que Praos2 « a été fusionné dans main » et que les clients LeiosNotify et les serveurs LeiosFetch l’ont rejoint. Ce sont les deux moitiés du mécanisme par lequel les nœuds s’annoncent l’existence de nouvelles données Leios, puis les téléchargent. Le rapport précise aussi que le prototype applique désormais des contrôles plus stricts sur ce que les pairs annoncent et sur les certificats qu’ils envoient, ce qui rapproche la diffusion des blocs endorseurs sur le réseau de la conception prévue pour la production.
Deux détails du rapport comptent pour qui suit un réseau de test. Le prototype n’utilise le format d’en-tête Leios qu’à partir de l’ère Dijkstra, nom de la prochaine ère de Cardano et du hard fork qui l’accompagne. Et le testnet du prototype Leios doit repartir de son bloc de genèse, les opérateurs de nœuds devant mettre leur logiciel à jour. Le mainnet n’est pas touché par ce redémarrage, assure le rapport. La même semaine, l’équipe a publié la version 5.1.0.1 d’ouroboros-consensus.
La sélection des blocs endorseurs reste à écrire
Le rapport est tout aussi net sur ce qui n’est pas fait. Son prochain point est la sélection et la récupération des blocs endorseurs. C’est le cœur du dispositif : dans Leios, les blocs ordinaires que produisent les pools environ toutes les 20 secondes peuvent pointer vers des blocs endorseurs, qui listent des transactions supplémentaires (par référence, pas les transactions elles-mêmes, explique IOG), dès lors que des pools détenant au moins 75 % du stake actif les ont certifiés par leur vote. Un nœud qui ne sait pas encore choisir quel bloc endorseur aller chercher, ni le récupérer, ne fait pas tourner Leios de bout en bout.
Fin octobre, la coque du protocole est donc fusionnée, les briques de messagerie sont en place et la spécification formelle a rattrapé la conception Linear Leios. La logique qui décide quels blocs supplémentaires un nœud prend réellement reste le chantier suivant, et le rapport hebdomadaire n’annonce aucune date cible.
D’où vient le chiffre de x15
Les chiffres viennent d’IOG lui-même. Dans un article publié le 20 octobre, « Leios is coming : How it reaches Cardano mainnet », Ivan Irakoze, responsable de la communication de l’écosystème chez Input Output, situe le plafond actuel de Praos à environ 4,5 kilooctets de transactions par seconde (TxkB/s). L’objectif initial de Leios est de trois à cinq fois ce niveau. Après au moins deux mises à jour de paramètres ultérieures, indique l’article, le débit pourrait atteindre environ 10 à 15 fois.
L’avertissement d’IOG est sans détour : « Le hard fork marque le début du déploiement, pas le moment où Cardano fonctionne soudain à pleine capacité Leios. »
Le même article cite une estimation tirée de la CIP-164, la proposition d’amélioration de Cardano qui définit Linear Leios : les revenus de frais n’atteindraient l’équilibre qu’avec un trafic soutenu d’environ 50 à 70 TxkB/s, soit, selon IOG, plus de dix fois ce que Praos peut porter aujourd’hui. La CIP-164 affirme aussi, en transactions par seconde et non en kilooctets, que la rentabilité des pools s’améliore nettement dès que le débit soutenu dépasse 30 à 50 TPS. Les deux unités ne mesurent pas la même chose et ne se convertissent pas sans connaître la taille moyenne d’une transaction, donc nous les gardons séparées.
Le tableau ci-dessous traduit les multiples d’IOG en kilooctets par seconde. Le calcul est de notre fait (4,5 multiplié par chaque multiple, puis 50 à 70 divisé par 4,5 pour la dernière ligne) ; les multiples, la base de 4,5 TxkB/s et la fourchette de 50 à 70 TxkB/s sont ceux d’IOG.
| Étape (IOG, 20 octobre 2026) | Multiple de Praos | Débit approximatif (TxkB/s) |
|---|---|---|
| Praos aujourd’hui | x1 | 4,5 |
| Leios à l’activation (objectif initial) | x3 à x5 | 13,5 à 22,5 (notre calcul) |
| Après au moins deux mises à jour de paramètres | x10 à x15 | 45 à 67,5 (notre calcul) |
| Trafic dont la CIP-164 dit que les frais ont besoin pour l’équilibre | environ x11 à x16 (notre calcul) | 50 à 70 |
Lu ainsi, le palier de x10 (45 TxkB/s) reste sous la zone d’équilibre, et seul le haut de la fourchette d’IOG, 67,5 TxkB/s, y entre. Et la fourchette décrit une capacité, pas une demande : une chaîne qui peut porter 15 fois plus de données doit encore être utilisée à ce niveau pour que l’argument des frais tienne.
Un article plus ancien d’IOG, du 17 avril 2025, partait d’une base légèrement différente, environ 4,4 ko/s, et disait que des simulations laissaient penser que Leios pourrait dépasser 1 000 TPS grâce au traitement parallèle dans le nœud. C’était un résultat de simulation, pas une mesure sur le mainnet, et ce n’est pas le chiffre qu’IOG avance aujourd’hui pour le déploiement.
Qu’est-ce que Cardano Leios, en bref
Leios change la quantité de données que la chaîne de base de Cardano peut porter, pas l’endroit où vont les transactions. C’est une modification de la couche 1 elle-même, à l’inverse des rollups et des canaux de paiement qui déplacent l’activité hors de la chaîne principale (notre guide sur la différence entre couche 1 et couche 2 détaille les deux approches). Cardano conserve ses producteurs de blocs en proof-of-stake et leur rythme d’environ 20 secondes pour classer les blocs ; Leios ajoute des blocs endorseurs qui référencent les transactions supplémentaires, ainsi que des votes des pools qui les certifient.
La CIP-164, « Ouroboros Linear Leios – Greater transaction throughput », a été créée le 7 mars 2025 et porte toujours le statut Proposed dans le dépôt des CIP. Parmi ses auteurs figurent William Wolff, Brian W Bush, Sebastian Nagel et Nicolas Frisby, et elle désigne Input Output Engineering comme réalisateur. L’explication publiée par IOG en 2025 affirmait que la conception conserve la résistance face à 50 % de stake adverse.
Roadmap de Cardano Leios : six étapes entre le code fusionné et le mainnet
L’article d’IOG du 20 octobre et la mise à jour hebdomadaire n° 134 d’Intersect du 24 octobre décrivent ensemble la route. Aucune des étapes ci-dessous n’a de date au calendrier.
1. Un testnet Dijkstra qui n’applique pas encore les règles Dijkstra
Intersect a relancé le testnet public Dijkstra le 21 octobre. Il fonctionne toujours en version de protocole 11, l’ère Conway actuelle, sur le nœud 11.1.3. Une action d’initiation de hard fork vers la version de protocole 12, Dijkstra, sera soumise dès qu’une préversion du nœud 11.2 sera disponible. Ce testnet utilise des époques d’un jour, dispose d’un explorateur Kleioscan et est ouvert dès maintenant aux opérateurs de pools. Les règles Dijkstra elles-mêmes ne sont pas encore testées.
2. Le reste du code Leios
La sélection et la récupération des blocs endorseurs, décrites plus haut, sont inachevées d’après le rapport du 23 octobre.
3. CAP-12, l’amendement constitutionnel, en quatrième brouillon
CAP-12 inscrirait dans la constitution de Cardano les plages autorisées pour les paramètres de l’ère Dijkstra. Le 19 octobre, le président du Comité de pilotage technique a publié sept commentaires au nom du Comité des paramètres. Selon Intersect, il a soutenu l’idée de décrire l’interrupteur de Leios comme une désactivation ordonnée plutôt que comme une mesure d’urgence, demandé une voie rapide écrite pour les incidents réels de gravité 1 ou 2, relayé le conseil de sortir les paramètres de Peras dans un amendement distinct, et remplacé son plafond initial sur l’ampleur d’un changement du levier de pledge en une fois par une limite sur la fréquence de ces changements.
L’auteur a posté un quatrième brouillon deux jours plus tard. Peras en est sorti, et le texte énumère désormais les cinq dispositions constitutionnelles qu’il modifie. Restent ouverts, selon Intersect : la plage du levier de pledge, les valeurs provisoires, une courte description de l’interrupteur et la question de savoir si la CIP-23 est livrée dans la première ou la seconde phase de Dijkstra. La relecture éditoriale a aussi relevé une erreur de copie, un nouveau garde-fou de voie rapide rattaché au mauvais paramètre. Modifier la constitution exige 75 % du stake des DReps et les deux tiers du Comité constitutionnel ; les pools de staking ne votent pas, d’après le tableau d’IOG.
4. Le vote du hard fork
Le hard fork Dijkstra lui-même requiert 60 % du stake des DReps, 51 % du stake des pools et les deux tiers du comité, d’après IOG. Leios ne voyagerait pas seul. IOG cite dans le même lot les transactions imbriquées, des améliorations de comptes, les guard scripts, Plutus V4, des récompenses de staking librement retirables et un paramètre de levier de pledge. Ni IOG ni Intersect ne donnent de date pour le fork.
5. Des clés BLS pour 90 à 95 % du stake
Après le fork, chaque opérateur de pool doit générer une clé BLS et soumettre un certificat d’enregistrement de pool mis à jour qui la contient ; la clé devient active à la frontière d’époque suivante. Aucun vote n’est en jeu, et IOG indique que les pools renouvelleront ces clés environ chaque trimestre, au même rythme que leurs clés KES. Dans les mots d’IOG : « Leios a besoin que 90 à 95 % environ du stake soit enregistré avant de s’activer. » Intersect chiffre cela à peu près aux 500 à 900 premiers pools sur environ 2 700. Un certificat Leios exige ensuite les votes de 75 % du stake actif. Les pools sans clé continuent de produire des blocs Praos ordinaires, mais ne peuvent pas voter sur les blocs endorseurs.
6. Tests de charge, puis deux votes de paramètres
IOG prévoit des exercices de charge sur le mainnet avant de relever le débit : des rafales de trafic programmées, assez grosses pour déborder des blocs ordinaires, afin que blocs endorseurs, votes et certificats soient produits et chronométrés sur le vrai réseau. Ces exercices n’exigent aucun vote. Viennent ensuite au moins deux mises à jour de paramètres, chacune exigeant 67 % du stake des DReps, 51 % du stake des pools et les deux tiers du comité. Tant que les nouvelles valeurs restent dans les limites fixées par la constitution, aucun autre hard fork n’est nécessaire. C’est à ce stade que la fourchette de 10 à 15 fois pourrait être atteinte.
| Décision | Stake des DReps | Stake des pools | Comité constitutionnel |
|---|---|---|---|
| Mise à jour de la constitution (CAP-12) | 75 % | pas de vote | 2/3 |
| Hard fork Dijkstra | 60 % | 51 % | 2/3 |
| Chaque mise à jour de paramètre de débit | 67 % | 51 % | 2/3 |
Source : IOG, 20 octobre 2026. L’enregistrement des clés BLS n’est pas un vote mais a son propre seuil : environ 90 à 95 % du stake délégué.
Cardano Leios : la date de sortie est-elle connue ?
Non. L’article d’IOG, la mise à jour d’Intersect et le rapport consensus n’en donnent aucune, ni pour le hard fork Dijkstra, ni pour l’enregistrement des clés BLS, ni pour les tests de charge. Le seul calendrier conditionnel des sources est celui d’Intersect : l’action de hard fork sur le testnet attend la préversion du nœud 11.2, qui n’a elle-même pas de date publiée. Des synthèses d’actualité Cardano avancent quelle version du nœud portera Leios, mais aucune source primaire ne le confirme, et nous ne le reprenons pas ici.
L’ordre des événements, lui, est fixé par les règles. Code et testnet d’abord, puis l’amendement constitutionnel, puis le vote du fork, puis l’enregistrement des clés par les pools, puis les tests de charge et les votes de paramètres. Les DReps et le comité qui voteront ces étapes sont les mêmes instances qui approuvent déjà les retraits de la trésorerie de Cardano, évoqués dans notre article sur les 42,6 M d’ADA restants de la trésorerie Cardano sous son plafond de dépenses.
Ce que cela change pour les détenteurs d’ADA et les opérateurs de pools
Pour les opérateurs de pools de staking, le message pratique est de rejoindre le testnet Dijkstra, qu’Intersect dit ouvert dès maintenant, et d’attendre une mise à jour de clé BLS et de certificat après le fork. Un pool qui s’en dispense produit toujours des blocs, mais n’a aucune voix pour certifier les blocs endorseurs, et Leios ne peut pas s’activer tant que 90 à 95 % du stake n’est pas enregistré.
Pour les DReps et le Comité constitutionnel, le travail est CAP-12, puis le vote du fork, puis les votes de débit. Notre lecture de l’article d’IOG et de la mise à jour d’Intersect : aucune des étapes listées ne donne de tâche à celui qui détient simplement des ADA. Développeurs, opérateurs de pools, DReps et comité font le travail, et les détenteurs n’interviennent qu’à travers le pool et le DRep auxquels ils délèguent.
L’ADA s’échangeait vers 0,2047 $ à 11 h 46 UTC le 26 octobre, en hausse de 0,63 % sur 24 heures et en baisse de 7,19 % sur sept jours. Rien dans ces données ne relie ce mouvement à l’actualité de Leios.
Prochaines dates à suivre
- 27 octobre, 16 h 00 UTC : réunion des éditeurs de CIP (Intersect).
- 29 octobre, 15 h 00 UTC : revue CAP du quatrième brouillon de CAP-12 (Intersect).
- Sans date : la préversion du nœud 11.2, qui déclenche l’action d’initiation du hard fork sur le testnet Dijkstra.
- Sans date : la sélection et la récupération des blocs endorseurs dans le code de consensus, désignées comme prochaine tâche dans le rapport du 23 octobre.