Une proposition préliminaire ouverte par des chercheurs d'Ethereum le 21 octobre vise à réduire le délai de finalité attendu des transactions du réseau d'environ 16 minutes à environ quatre, en transformant ses deux processus de vote du consensus en flux de messages distincts. Le projet Decoupled Consensus reste ouvert et non fusionné.

Ben Edgington, qui décrit son rôle comme la coordination des travaux d'Ethereum sur la finalité rapide, a ouvert la pull request et co-rédigé le projet avec Francesco D'Amato, Roberto Saltini, Yann Vonlanthen et Mikhail Kalinin. Sa note sur la demande indique que « de nombreux aspects restent à définir (TBD) » et que l'objectif immédiat est d'obtenir un numéro EIP. Un relecteur du dépôt EIPs a proposé le numéro 8453 le même jour et a demandé aux auteurs d'ouvrir un fil de discussion sur Ethereum Magicians, le forum où les propositions sont débattues. La pull request demeure ouverte et non fusionnée.

Pourquoi la finalité prend encore environ 16 minutes

La finalité marque le point avant lequel les validateurs d'Ethereum ne reviendront pas en arrière sur les blocs. L'atteindre nécessite deux tours de vote — l'un pour justifier un checkpoint, l'autre pour le finaliser — et chaque tour dure une époque de 32 slots de douze secondes. Dans un article du 11 mai publié sur le blog de consensus de protocole de la Ethereum Foundation, Edgington a fixé le minimum à 768 secondes et le temps attendu pour une transaction à environ 960, avec 63 à 95 des derniers blocs non finalisés dans des conditions normales.

Ces blocs récents encore être réorganisés : les nœuds peuvent basculer vers une séquence de blocs concurrente, renvoyant les transactions des blocs abandonnés vers le mempool pour être à nouveau incluses. Les blocs finalisés sont bien plus difficiles à modifier. Les annuler exigerait que des attaquants détiennent plus d'un tiers de l'ensemble de la mise, et cela leur coûterait au moins un tiers de l'ensemble de l'ETH misé via le slashing.

Le même article décrit une règle de confirmation rapide conçue pour fournir un signal plus précoce. Lorsque le réseau fonctionne correctement et qu'aucun attaquant n'est trop puissant, elle devrait indiquer en environ 13 secondes qu'un bloc ne sera pas réorganisé. Elle n'entraîne aucune pénalité économique pour les attaquants et ne tolère pas les retards du réseau, de sorte qu'en cas de problème réseau, elle revient à la finalité complète — précisément au moment où les services ont le plus besoin de certitude.

Les services qui agissent sur les transactions Ethereum choisissent donc la part du délai de finalité qu'ils acceptent. L'article cite plusieurs exemples, dont le Cross-Chain Transfer Protocol (CCTP) de Circle pour l'USDC. (Source : Ben Edgington, blog de consensus de protocole de la Ethereum Foundation, mai 2026.)

Une finalité plus rapide réduirait l'écart entre ces voies, tant pour les ponts de stablecoins que pour les produits tokenisés plus récents tels que les dépôts bancaires que JPMorgan apporte à Ethereum. Edgington estime que le bridging inter-chaînes montrera les gains les plus visibles.

Une attestation devient deux messages

Le design de consensus actuel d'Ethereum, Gasper, regroupe deux votes dans chaque attestation de validateur. L'un alimente LMD GHOST, la règle de choix de fork qui indique au prochain proposeur sur quel bloc construire. L'autre alimente Casper FFG, le processus plus lent qui finalise les checkpoints. Comme les deux voyagent ensemble, le choix de fork s'appuie sur des attestations d'environ 30 000 validateurs par slot, bien que les chercheurs à l'origine du projet estiment qu'un nombre bien plus faible suffirait.

Le projet d'EIP transforme ces votes en messages distincts qui circulent sur le réseau et sont traités indépendamment :

• Votes de tête. Un comité d'environ 512 validateurs par slot, tiré avec des probabilités proportionnelles au solde effectif de chaque validateur — la mise que le protocole lui crédite — décide quel bloc est la tête de la chaîne et quels blocs récents sont confirmés.
• Attestations de finalité. L'ensemble des validateurs décide quels bloc sont justifiés et finalisés, en tours selon leur propre calendrier, chaque étape exigeant au moins deux tiers de la mise active.

Avec son propre calendrier, le tour de finalité peut utiliser la bande passante sur toute la période de vote et être raccourci ultérieurement sans repenser le fonctionnement des slots. L'objectif initial des auteurs est une réduction d'au moins un facteur quatre du délai de finalité, sous réserve de paramètres qu'ils doivent encore préciser. Appliqué à l'attente actuelle de 16 minutes, une réduction d'un facteur quatre signifierait environ quatre minutes, bien que le projet lui-même ne donne aucun chiffre.

Où se situe la réduction d'un facteur quatre dans un plan plus large

Dans le même article de mai, Edgington a exposé une ambition à plus long terme : ramener le délai de finalité d'environ 1 000 secondes à environ 10. Il l'a présenté comme son opinion personnelle plutôt que comme une feuille de route officielle.

Il a écrit que des conceptions antérieures telles que la finalité en un seul slot ou en trois slots ont échoué parce qu'elles exigeaient de résoudre tous les problèmes à la fois. La nouvelle approche échelonne le travail. « La finalité découplée est le grand déverrouillage », a-t-il écrit, s'attendant à ce que cette seule étape apporte un gain de vitesse à un chiffre faible, conformément à l'objectif d'un facteur quatre du projet. Des gains supplémentaires proviendraient de mises à niveau distinctes :

• Consolidation des validateurs : depuis la mise à niveau Electra, les grands opérateurs peuvent fusionner jusqu'à 64 validateurs en un seul, réduisant le nombre de votes de finalité. Edgington a qualifié les progrès de lents.
• Regroupement des votes à la source : les opérateurs gérant de nombreux validateurs derrière un même nœud combineraient leurs votes avant de les diffuser.
• Rotation de l'ensemble des validateurs : seul un sous-ensemble de validateurs participerait à la finalité à un moment donné, sans exclure ni plafonner quiconque.
• Mise en réseau et agrégation plus rapides : les améliorations pair-à-pair et l'agrégation basée sur les SNARK déplaceraient les votes plus efficacement.
• Finalité en un seul tour : un tour de vote au lieu de deux réduirait presque de moitié l'attente, au prix d'une baisse de la tolérance aux pannes d'un tiers de la mise à peut-être 20 % ou 17 %.

Le projet lui-même n'inclut aucune de ces étapes. Selon le calcul d'Edgington, quatre améliorations apportant chacune un gain d'un facteur trois approcheraient l'ambition d'un facteur 100. Il a également noté que la feuille de route Strawmap listait le consensus découplé comme candidate vedette pour la mise à niveau provisoirement étiquetée I*, probablement en 2027, comme objectif ambitieux.

Pourquoi Ethereum ne s'arrêtera pas pour aller plus vite

Les protocoles classiques de tolérance aux fautes byzantins tels que Tendermint finalisent rapidement les blocs mais cessent de les produire lorsque trop de validateurs sont hors ligne. Le chercheur Luca Zanolini a soutenu dans un article de mars sur le forum Ethereum Research qu'un arrêt est incompatible avec la conception d'Ethereum. Il a pointé une limite démontrée connue sous le nom de dilemme disponibilité-finalité : aucun protocole unique ne peut continuer à croître tandis que la participation monte et descend tout en restant sûr lors d'une partition du réseau. La réponse d'Ethereum est une couche qui continue de construire des blocs avec les validateurs en ligne et une seconde qui finalise derrière elle.

Zanolini a cité le bilan du réseau. En mai 2023, des bugs dans les clients Prysm et Teku, qui géraient ensemble plus de la moitié des validateurs, ont perturbé la finalité et déclenché la première fuite d'inactivité sur le mainnet d'Ethereum. Les propositions de blocs n'ont jamais descendu en dessous d'environ 90 % des slots et les transactions ont continué d'être traitées. En revanche, Solana n'a produit aucun bloc pendant cinq heures lors de son arrêt de février 2024, laissant les protocoles DeFi du réseau dans l'incapacité de fonctionner.

Decoupled Consensus conserve cette organisation. La finalité nécessite toujours le quorum des deux tiers, de sorte qu'une panne suffisamment importante peut la bloquer tandis que les validateurs restants continuent de construire des blocs. La plupart des applications peuvent continuer à fonctionner, mais tout ce qui nécessite un règlement définitif doit attendre. Si la participation ne se rétablit pas, la fuite d'inactivité réduit progressivement la mise des validateurs hors ligne jusqu'à ce que la finalité puisse reprendre. La manière dont la fuite fonctionnerait dans la nouvelle conception reste à rédiger.

La raison post-quantique passe en premier

La finalité plus rapide attire l'attention, mais elle arrive en troisième position dans la liste des auteurs. La pull request cite d'abord une fondation pour une future transition post-quantique, puis la sécurité du choix de fork, et la motivation du projet suit le même ordre.

Le lien réside dans l'agrégation de signatures. Les validateurs signent avec BLS, un schéma permettant de fusionner de nombreuses signatures en une seule signature compacte. Zanolini a écrit qu'aucun schéma post-quantique n'offre une agrégation comparable à des tailles pratiques. Un comité de votes de tête de quelques centaines de validateurs évite le problème car ses signatures peuvent être envoyées côte à côte. Il a soutenu que cela pourrait permettre une version post-quantique de la couche de production de blocs avant que quiconque ne résolve l'agrégation des votes de finalité de l'ensemble des validateurs. Le projet prépare cette voie mais ne sélectionne aucun schéma de signature post-quantique.

De nouvelles défenses s'accompagnent d'une cible plus réduite

Le choix de fork actuel conserve le dernier vote de chaque validateur sans limite d'âge. Selon le projet, cela permet aux attaquants de retenir des votes et de les publier à des moments stratégiques pour orienter les nœuds vers une branche choisie. Selon la proposition, le choix de fork ne compte que les votes d'un slot récent, avec des délais précis pour leur arrivée.

Des verrous protègent les blocs que la chaîne a confirmés. Un bloc devient rapidement verrouillé lorsque au moins la moitié du comité du slot envoie des votes de tête opportuns pour lui, sans qu'aucun validateur ne vote dans les deux sens. Les verrous expirent, et des votes récents pour un bloc concurrent peuvent ramener un verrou à un bloc antérieur, permettant à la chaîne de se rétablir à mesure que les conditions évoluent. Les proposeurs porteraient également des votes récents dans leurs blocs pour aligner les vues des validateurs. Cette technique, appelée view-merge, remplace le proposer boost — le poids supplémentaire de choix de fork actuellement accordé à un bloc opportun — et cible les attaques d'équilibrage et de réorganisation.

Le comité plus petit constitue le compromis. Moins de votants signifie moins de travail de signature à chaque slot, mais cela augmente la probabilité qu'un tirage aléatoire donne à un attaquant une part disproportionnée d'un comité et offre aux attaquants un groupe plus restreint à mettre hors ligne par des attaques par déni de service. Le choix privé des comités via une fonction aléatoire vérifiable est une option à l'étude. La taille n'est pas non plus tranchée : des articles de recherche antérieurs esquissaient environ 256 validateurs, et le projet laisse ouverts tant son chiffre de 512 que la méthode de sélection.

Ce qui doit se produire avant toute mise à niveau

L'activation de Decoupled Consensus nécessiterait un hard fork de la couche de consensus, avec des clients de consensus et de validateurs prenant en charge de nouvelles tâches de vote, de nouveaux formats de blocs et d'état et de nouvelles règles de choix de fork. Récompenses et pénalités, conditions de slashing, paramètres de synchronisation et de verrouillage, règles de transition de fork, cas de test exécutables et une analyse complète de la sécurité et de la vivacité restent tous à rédiger. Une spécification en cours de rédaction se trouve dans une branche de fonctionnalité des spécifications de consensus d'Ethereum. Le projet maintient le budget total des récompenses des validateurs inchangé, bien que les paiements puissent être répartis entre les votes de tête et les tâches de finalité.

Le compromis le plus important se situe au-delà de ce projet. Edgington a écrit qu'il souhaitait une finalité suffisamment rapide sans exclure les stakers domestiques, les stakers solos ni ceux situés des régions éloignées, et que la communauté pourrait un devoir arbitrer entre une finalité encore plus rapide et la diversité du staking.

À surveiller ensuite

• Statut de l'EIP : savoir si la pull request est fusionnée en tant que Draft sous le numéro 8453 et si un fil de discussion s'ouvre sur Ethereum Magicians.
• Travail de spécification : l'avancement des sections sur les récompenses, le slashing et la fuite d'inactivité, toujours marquées TBD.
• Périmètre de la mise à niveau : si les développeurs principaux retiennent le consensus découplé comme candidate vedette pour I*. Une absence de cette liste repousserait l'objectif ambitieux de 2027.