L'évolution « en une seconde » d'Ethereum : de la confirmation rapide à la compression du règlement, comment Interop élimine-t-il le temps d'attente ?

Si vous naviguez fréquemment entre Base, Arbitrum ou Optimism, vous avez sûrement ressenti une certaine « discontinuité » subtile.

Bien que les transactions sur une seule L2 soient presque instantanées, lorsque vous essayez de transférer des actifs de la chaîne A vers la chaîne B, il faut souvent attendre plusieurs minutes, voire plus longtemps. Ce n’est pas que la L2 elle-même soit trop lente, mais dans le processus traditionnel, une transaction impliquant plusieurs couches ou chaînes doit suivre un chemin long et rigoureux :

Ordonnancement par le séquenceur L2 → soumission à L1 → consensus et finalité sur L1, en résumé, dans l’architecture actuelle d’Ethereum, la finalité sur L1 nécessite généralement deux Epochs (environ 13 minutes). C’est essentiel pour la sécurité, mais pour l’interopérabilité (Interop), cela paraît bien trop lent.

Après tout, selon la grande vision d’Ethereum, il y aura à l’avenir des centaines, voire des milliers de L2, qui ne devraient pas être des îlots d’exécution isolés, mais fonctionner comme un tout coordonné. La question clé est donc de savoir s’il est possible de réduire au maximum ce temps d’attente. 

C’est dans ce contexte que la feuille de route Interop d’Ethereum, lors de la phase d’accélération (Acceleration), a clairement défini trois axes d’amélioration hautement coordonnés : Fast L1 Confirmation Rule (règle de confirmation rapide sur L1), Shorter L1 Slots (réduction du temps de slot sur L1), Shorter L2 Settlement (réduction du cycle de règlement sur L2). 

On peut dire qu’il ne s’agit pas d’optimisations isolées, mais d’une refonte systémique autour de la « confirmation, du rythme et du règlement ».

I. Règle de confirmation rapide : donner au système une « réponse fiable » avant la finalité

Comme chacun le sait, dans l’architecture actuelle d’Ethereum, l’intervalle entre les blocs du réseau principal est d’environ 12 secondes, les validateurs votent sur l’état de la chaîne à chaque slot, et la finalité intervient plusieurs slots plus tard.

En résumé, même si la transaction a déjà été incluse dans un bloc, le système doit encore attendre un certain temps pour s’assurer qu’elle ne sera pas réorganisée ou annulée. Actuellement, il faut environ deux Epochs (environ 13 minutes) avant qu’une transaction ne soit considérée comme irréversible, ce qui est bien trop long pour la plupart des scénarios financiers on-chain. 

Pouvons-nous avant la finalité, fournir aux applications et aux systèmes cross-chain un signal de confirmation « suffisamment rapide et fiable » ? C’est précisément l’objectif du Project #4 de la feuille de route Interop d’Ethereum : Fast L1 Confirmation Rule (règle de confirmation rapide sur L1).

L’objectif principal est simple : permettre aux applications et aux systèmes cross-chain d’obtenir un signal de confirmation L1 « fort et vérifiable » en 15 à 30 secondes, sans attendre les 13 minutes nécessaires à la finalité complète.

Sur le plan du mécanisme, la règle de confirmation rapide n’introduit pas un nouveau processus de consensus, mais réutilise les votes des attesteurs qui ont lieu à chaque slot dans le système PoS d’Ethereum. Lorsqu’un bloc a déjà accumulé suffisamment de votes de validateurs diversifiés dans les premiers slots, il peut être considéré comme « extrêmement improbable d’être annulé dans un modèle d’attaque raisonnable », même s’il n’a pas encore atteint la finalité.

En clair, ce niveau de confirmation ne remplace pas la finalité, mais fournit avant celle-ci une forte confirmation reconnue par le protocole. Pour l’Interop, c’est crucial : les systèmes cross-chain, les Intent Solvers et les wallets n’ont plus besoin d’attendre aveuglément la finalité, mais peuvent avancer en toute sécurité vers l’étape suivante en 15 à 30 secondes, sur la base d’un signal de confirmation au niveau du protocole.

Actuellement, le concept de pré-confirmation (Preconfirmation) promu par le récit Based Rollup joue un rôle de transition technique important dans cette direction. Sa logique est simple, comme son nom l’indique, imaginez : 

Lorsque nous achetons un billet de train sur 12306, une fois le trajet choisi et la commande passée (transaction signée), le système de réservation fournit d’abord une pré-confirmation, vous informant que l’achat (chaque transaction) a été accepté et est en cours de traitement. À ce stade, nous pouvons déjà planifier notre voyage, préparer nos bagages, etc. Ce n’est qu’une fois le billet confirmé (transaction publiée sur L1) que l’achat est officiellement terminé.

En résumé, dans Based Rollup, la pré-confirmation consiste à s’engager à inclure la transaction dans un bloc avant qu’elle ne soit officiellement soumise à L1 pour confirmation, fournissant ainsi à l’utilisateur un premier signal de confirmation et l’informant que la transaction a été acceptée et est en cours de traitement.

« Je te donne d’abord un engagement verbal fort, la confirmation finale viendra plus tard. » Grâce à cette logique de confirmation en couches, la feuille de route Interop d’Ethereum segmente habilement différents niveaux de confiance entre « sécurité » et « rapidité », afin de construire une expérience d’interopérabilité aussi fluide que possible. 

II. Réduction du slot L1 : accélérer le « rythme cardiaque » d’Ethereum

En complément de la règle de confirmation rapide, qui est une « refonte logique au niveau du consensus », il existe une modification plus fondamentale et physique : la réduction de la taille du slot.

Si la confirmation rapide consiste à « émettre une reconnaissance de dette » avant que le consensus ne soit atteint, la réduction du temps de slot L1 revient à raccourcir directement le « cycle de règlement » du registre. Dans la feuille de route Interop, l’objectif du Project #5 est clair : réduire le temps de slot du réseau principal d’Ethereum de 12 secondes à 6 secondes.

Cet « halving » apparemment simple déclenchera en réalité une réaction en chaîne sur tout le réseau. C’est facile à comprendre : plus le slot est court, plus l’inclusion des transactions dans les blocs, leur distribution aux validateurs et leur confirmation sont rapides, ce qui réduit la latence globale du protocole.

L’impact sur l’expérience utilisateur est direct : interactions L1 (comme les transferts ETH) confirmées plus rapidement, soumission d’état L2 vers L1 plus fréquente, et la combinaison de slots plus courts et de la règle de confirmation rapide aboutit à un « feedback on-chain quasi instantané », permettant aux DApp, wallets et protocoles cross-chain de proposer une « expérience de confirmation en quelques secondes ».

Pour les protocoles d’interopérabilité cross-chain, la réduction du temps signifie aussi une utilisation accrue des fonds. Actuellement, les bridges ou market makers doivent supporter le risque de « fonds en transit » pendant plusieurs minutes ou plus lors du transfert d’actifs entre chaînes. Pour compenser ce risque de volatilité, ils doivent facturer des frais plus élevés.

Mais lorsque le cycle de règlement L1 est raccourci et que la rotation des fonds double de vitesse, l’immobilisation de capital en transit diminue considérablement. Le résultat est évident : des coûts de friction plus faibles, des frais utilisateurs réduits et des délais de réception plus courts, ce qui incitera fortement développeurs et utilisateurs à revenir vers la couche de règlement sécurisée L1, plutôt que de dépendre de relais tiers fragiles.

Bien sûr, doubler la « fréquence cardiaque » n’est pas une tâche facile. Plusieurs équipes de la Ethereum Foundation travaillent en parallèle sur ce chantier complexe :

• Analyse réseau : Les équipes de recherche (dont Maria Silva) mènent des analyses de données rigoureuses pour s’assurer que des slots plus courts n’entraînent pas de risques de réorganisation (Reorg) dus à la latence réseau, ni de pression à la centralisation pour les nœuds domestiques à faible bande passante ;
• Implémentation client : Il s’agit d’une refonte profonde touchant à la fois la couche de consensus et la couche d’exécution. Il est à noter que ce travail est indépendant de l’EIP-7732 (séparation native staker-builder ePBS), ce qui signifie que, quel que soit l’avancement d’ePBS, le plan d’accélération du rythme cardiaque peut progresser de façon autonome ;

Dans l’ensemble, lorsque le slot de 6 secondes sera combiné à la règle de confirmation rapide, Ethereum pourra véritablement offrir un « feedback on-chain quasi instantané », permettant aux dApp et wallets de proposer une expérience de confirmation en quelques secondes inédite.

III. Réduction du cycle de règlement L2 : permettre le retrait instantané des actifs

Dans la feuille de route Interop, le Project #6 : Shorter L2 Settlement est l’un des aspects les plus controversés, mais aussi les plus prometteurs.

Dans l’architecture actuelle, les Optimistic Rollup reposent généralement sur une période de contestation de 7 jours, et même les ZK Rollup sont limités par le rythme de génération et de vérification des preuves. En toute objectivité, cette conception est irréprochable en termes de sécurité, mais au niveau de l’interopérabilité, elle pose un problème concret :

Les actifs et états sont « verrouillés dans le temps » entre les chaînes. Cela augmente non seulement le coût du cross-chain, mais alourdit aussi la charge de rééquilibrage des Solvers, ce qui se traduit finalement par des frais plus élevés pour l’utilisateur. C’est pourquoi la réduction du cycle de règlement est considérée comme un levier clé pour l’adoption à grande échelle d’Interop. Les principales pistes techniques actuelles incluent (voir aussi « ZK Dawn : la feuille de route finale d’Ethereum s’accélère-t-elle ? ») :

• Preuves ZK en temps réel : avec l’accélération matérielle et la maturité des preuves récursives, le temps de génération des preuves passe de la minute à la seconde ;
• Mécanismes de règlement plus rapides : par exemple, l’introduction d’un modèle de règlement sécurisé 2-out-of-3 ;
• Couches de règlement partagées : permettre à plusieurs L2 de modifier l’état sous une sémantique de règlement unifiée, au lieu de « retrait — attente — dépôt » ;

Bien sûr, dans la discussion sur Interop, une question centrale demeure : pour obtenir une confirmation cross-chain plus rapide, si l’on réduit la période de contestation de 7 jours à 1 heure, cela laisse-t-il une fenêtre d’attaque aux malfaiteurs ?

En théorie, cette inquiétude n’est pas infondée. Contrairement à la « censure forte » (collusion des validateurs), le vrai danger réside dans ce type d’attaque de censure douce menée par les block builders : l’attaquant n’a pas besoin de contrôler le consensus, il lui suffit de surenchérir en permanence pour empêcher les transactions critiques d’être incluses dans la chaîne. 

Fait intéressant, la seule analyse économique systémique de ce scénario provient de Offchain Labs, dans leur article de février 2025 « Economic Censorship Games in Fraud Proofs », qui propose trois modèles, du plus pessimiste au plus optimiste, en supposant respectivement : 

• Modèle G¹ : le contenu du bloc est entièrement déterminé par l’enchérisseur le plus élevé ;
• Modèle G¹ₖ : certains validateurs construisent toujours localement leurs blocs ;
• Modèle Gᵐ : plusieurs validateurs décident ensemble du contenu du bloc, il suffit qu’un seul choisisse la transaction du défenseur.

En pratique, comme les validateurs peuvent rater des slots (miss slots), certains designs peuvent même dégénérer en scénario G¹ plus pessimiste, d’où l’analyse à partir du pire cas. 

Sur cette base, les chercheurs proposent une stratégie défensive très pragmatique : un mécanisme de défense différée « petit pari, gros gain », dont la logique centrale est que le défenseur dispose d’un « bouton de délai » : il n’a pas besoin de terminer tout le processus de vérification complexe en peu de temps, mais seulement de soumettre une transaction clé.

Le rôle de cette transaction clé est très clair : une fois incluse dans la chaîne, elle prolonge automatiquement la période de contestation de 1 heure à 7 jours. Par exemple, si le défenseur détecte une anomalie sur L2, il n’a pas besoin de terminer toutes les vérifications complexes en 1 heure, il lui suffit de soumettre à L1 une transaction spéciale, qui, comme une alarme, prolonge instantanément la période de contestation à 7 jours.

Cela signifie que l’attaquant est contraint à une guerre d’usure très asymétrique : pour empêcher cette transaction d’être incluse, il doit payer en permanence des frais de priorité supérieurs à ceux du défenseur à chaque bloc, et ce pendant toute la période de contestation.

Les résultats quantitatifs de l’article sont très parlants : selon les calculs, si un attaquant puissant prévoit de dépenser 10 milliards de dollars pour une attaque de censure continue, alors :

• Pendant la fenêtre d’1 heure, le défenseur n’a besoin que d’un budget gas de 33 millions de dollars pour riposter ;
• Si le mécanisme de délai est déclenché, prolongeant la période à 7 jours, le coût de défense chute à environ 200 000 dollars ;

En d’autres termes, il s’agit d’un avantage structurel clé : le coût de l’attaque est linéaire, alors que le défenseur n’a besoin que d’une seule inclusion réussie.

C’est précisément ce rapport coût d’attaque / coût de défense (Cost to Attack vs. Cost to Defend) très déséquilibré qui garantit qu’Ethereum conserve une forte robustesse économique même si le cycle de règlement est considérablement raccourci. 

Pour Interop, c’est aussi crucial : confirmation rapide et cycle de règlement plus court ne signifient pas nécessairement sacrifier la sécurité, et dans un design institutionnel raisonnable, confirmation cross-chain en quelques secondes et sécurité économique peuvent coexister, offrant au moins la base la plus solide pour réaliser l’Interop cross-chain en quelques secondes.

En conclusion

Certains se demanderont peut-être pourquoi s’évertuer à optimiser ces quelques secondes ou minutes de latence ?

À l’ère geek du Web3, nous étions habitués à attendre, voire à considérer que « l’attente » était le prix à payer pour la décentralisation. Mais sur la voie de la démocratisation du Web3, les utilisateurs ne devraient pas, et n’ont pas besoin, de se soucier de la chaîne sur laquelle ils opèrent, encore moins de calculer la logique de finalité de L1.

Confirmation rapide, rythme cardiaque de 6 secondes et mécanisme de défense asymétrique visent essentiellement à faire disparaître la variable « temps » de la perception utilisateur.

Pour reprendre une phrase que j’aime répéter ces derniers temps : la meilleure forme de la technologie, c’est quand la complexité disparaît totalement dans une confirmation ultra-rapide.