Auteur : imToken
Si vous effectuez fréquemment des transferts inter-chaînes entre Base, Arbitrum ou Optimism, vous avez sûrement ressenti une subtile « sensation de coupure ».
Bien que chaque transaction sur L2 soit désormais presque instantanée, lorsque vous essayez de transférer des actifs de la chaîne A à la chaîne B, vous devez souvent attendre plusieurs minutes voire plus longtemps. Ce n’est pas que la L2 elle-même soit lente, mais parce que dans le processus traditionnel, une transaction impliquant des couches et des chaînes doit suivre un parcours long et rigoureux :
Tri par L2 → Soumission à L1 → Consensus et finalisation (Finality), en résumé, dans l’architecture actuelle d’Ethereum, la finalisation sur L1 nécessite généralement deux Epochs (environ 13 minutes). Cela est indéniablement nécessaire pour la sécurité, mais pour l’interopérabilité (Interop), cela paraît excessivement lent.
Après tout, selon la vision d’ensemble d’Ethereum, à l’avenir, il existera des centaines, voire des milliers de L2. Elles ne doivent pas être des îlots isolés d’exécution, mais plutôt fonctionner en synergie comme un tout. La clé du problème réside donc dans la possibilité de réduire au maximum ce temps d’attente.
C’est dans ce contexte qu’Ethereum, dans sa feuille de route pour l’Interop, lors de la phase d’accélération, a clairement défini trois axes d’amélioration hautement coordonnés : Règle de confirmation rapide (Fast L1 Confirmation Rule), Réduction de la durée des slots L1 (Shorter L1 Slots), Compression du cycle de règlement des réseaux de couche deux (Shorter L2 Settlement).
On peut dire que ce n’est pas une optimisation dispersée, mais une reconstruction systémique autour de « confirmation, rythme et règlement ».
1. Règle de confirmation rapide : donner une « réponse fiable » au système avant la Finality
Comme tout le monde le sait, dans l’architecture actuelle d’Ethereum, l’intervalle entre deux blocs principaux est d’environ 12 secondes. Les nœuds de validation votent sur l’état actuel de la chaîne à chaque slot, et la finalisation (Finality) intervient après plusieurs slots.
En résumé, même si une transaction a été incluse dans un bloc, le système doit attendre un certain temps pour être sûr qu’elle ne sera pas réorganisée ou annulée. Actuellement, il faut environ deux Epochs (13 minutes) pour que la transaction soit considérée comme irrévocable. Pour la majorité des scénarios financiers sur la chaîne, 13 minutes, c’est indéniablement trop long.
Mais peut-on avant la Finality, fournir aux applications et aux systèmes inter-chaînes un « signal de confirmation » à la fois rapide et fiable ? C’est précisément l’objectif du Projet #4 dans la feuille de route d’Interop : la Règle de confirmation rapide (Fast L1 Confirmation Rule).
Son objectif central est très simple : permettre aux applications et aux systèmes inter-chaînes d’obtenir en 15–30 secondes un « signal de confirmation L1 fort et vérifiable », sans attendre les 13 minutes nécessaires à la Finality complète.
Sur le plan mécaniste, cette règle ne consiste pas à introduire un nouveau processus de consensus, mais à réutiliser le vote des attesters qui se produit à chaque slot dans le système PoS d’Ethereum. Lorsqu’un bloc accumule suffisamment de votes dispersés dans les premiers slots, même s’il n’est pas encore finalisé, il peut être considéré comme « extrêmement improbable à faire l’objet d’un rollback sous un modèle d’attaque raisonnable ».
En clair, ce niveau de confirmation ne remplace pas la Finality, mais fournit avant elle un « fort signal de confirmation » explicitement reconnu par le protocole. Pour l’interopérabilité, c’est crucial : les systèmes inter-chaînes, les Intent Solvers et les portefeuilles n’ont plus besoin d’attendre passivement la finalité, mais peuvent avancer en toute sécurité en 15–30 secondes, sur la base d’un signal de confirmation au niveau du protocole.
Actuellement, la pré-confirmation (Preconfirmation), fortement promue par la narration autour des Rollups Based, joue un rôle de transition technique dans cette direction. Son principe est simple : imaginez :
Lorsque vous achetez un billet de train sur 12306, une fois votre itinéraire choisi et la transaction signée, le système vous donne une « pré-confirmation » indiquant que votre achat a été accepté et qu’il entre dans le processus de confirmation. Vous pouvez alors commencer à planifier votre voyage, préparer vos bagages, etc. Ce n’est qu’après la confirmation finale du train (publication de la transaction sur L1) que la réservation est considérée comme définitivement effectuée.
En résumé, dans le contexte des Rollups Based, la pré-confirmation consiste à inclure la transaction dans un bloc avant sa soumission officielle à L1. C’est comme donner à l’utilisateur un premier signal de confirmation, lui indiquant que la transaction a été acceptée et est en cours de traitement.
« Je vous donne une promesse forte à l’oral, la confirmation finale viendra plus tard », avec cette logique de confirmation en couches, la feuille de route d’Ethereum pour l’Interop construit une différenciation fine entre « sécurité » et « rapidité », créant une expérience d’interopérabilité aussi fluide que possible.
2. Réduction de la durée des slots L1 : accélérer le « rythme cardiaque » d’Ethereum
En complément de la règle de confirmation rapide, il y a une modification plus fondamentale, plus physique : réduire la taille des slots.
Si la confirmation rapide consiste à « faire une reconnaissance de dette » avant la finalité, la réduction du temps de slot L1 revient à raccourcir directement le cycle de règlement du registre. Dans la feuille de route d’Interop, l’objectif du Projet #5 est clair : ramener le temps de slot d’Ethereum mainnet de 12 secondes à 6 secondes.
Ce « simple » découpage en deux, en réalité, entraînera une réaction en chaîne sur toute la chaîne. Plus le slot est court, plus le processus d’inclusion, de validation et de confirmation des transactions sera rapide, ce qui réduit la latence globale du protocole.
L’impact sur l’expérience utilisateur est direct : confirmation plus rapide lors des interactions L1 (par ex. transfert ETH), soumission d’état L2 à L1 plus fréquente, et surtout, la combinaison de slots plus courts avec la règle de confirmation rapide aboutit à une « rétroaction quasi instantanée sur la chaîne », permettant aux DApps, portefeuilles et protocoles inter-chaînes de construire une expérience de confirmation en « secondes ».
Pour les protocoles d’interopérabilité, cette réduction de temps signifie aussi une utilisation plus efficace des fonds. Actuellement, lors de l’utilisation de ponts ou de market makers, le capital en transit doit couvrir plusieurs minutes, voire plus, de risque de « fonds en transit ». Pour couvrir cette volatilité, ils facturent des frais plus élevés.
Lorsque le cycle de règlement L1 sera raccourci et la vitesse de rotation du capital augmentée, cette immobilisation de fonds en transit sera considérablement réduite. Résultat : coûts de friction plus faibles, frais utilisateur plus bas, délais de réception plus courts. Cela encouragera fortement les développeurs et utilisateurs à revenir à une couche de règlement L1 plus sûre, plutôt que de dépendre de relais tiers vulnérables.
Bien sûr, doubler la fréquence du « battement de cœur » n’est pas une tâche facile. Plusieurs groupes de travail de la Fondation Ethereum travaillent simultanément sur cette ingénierie complexe :
- Analyse réseau : des équipes (dont Maria Silva et d’autres chercheurs) mènent des analyses rigoureuses pour s’assurer que des slots plus courts ne provoquent pas de risques graves de réorganisation (Reorg) ou de centralisation, notamment pour les nœuds domestiques à bande passante limitée ;
- Implémentation client : il s’agit d’une reconstruction profonde de la couche de consensus et de la couche d’exécution. Notons que ce travail est indépendant de l’EIP-7732 (séparation du staker natif et du constructeur ePBS), ce qui signifie que, peu importe l’avancement de ePBS, le plan d’accélération du battement de cœur peut avancer de façon autonome.
Globalement, lorsque des slots de 6 secondes seront combinés avec la règle de confirmation rapide, Ethereum pourra réellement disposer d’un « retour quasi instantané sur la chaîne », permettant aux dApps et portefeuilles de construire une expérience de confirmation en secondes sans précédent.
3. Réduction du cycle de règlement L2 : faire que les actifs soient « instantanés et transférables »
Dans la feuille de route d’Interop, le Projet #6 : Shorter L2 Settlement, est la partie la plus contestée mais aussi la plus imaginative.
Actuellement, les Optimistic Rollups dépendent d’une période de contestation de 7 jours, et même les ZK Rollups sont limités par la vitesse de génération et de vérification des preuves. En toute honnêteté, cette conception est irréprochable en termes de sécurité, mais pose un problème pratique pour l’interopérabilité :
Les actifs et états sont « verrouillés dans le temps » entre chaînes. Cela augmente le coût des opérations inter-chaînes et alourdit la charge de rééquilibrage des Solvers, ce qui se traduit par des frais plus élevés pour les utilisateurs. Réduire le cycle de règlement est donc une étape clé pour la scalabilité de l’Interop. Les principales directions techniques sont :
- Preuves ZK en temps réel : avec l’accélération matérielle et la preuve récursive, le temps de génération de preuve passe de minutes à quelques secondes ;
- Mécanismes de règlement plus rapides : par exemple, introduire un modèle de règlement sécurisé 2-out-of-3 ;
- Couches de règlement partagées : permettre à plusieurs L2 de changer d’état sous une sémantique commune, plutôt que de faire « retrait — attente — dépôt ».
Une question centrale dans la discussion sur l’Interop est : si l’on réduit le délai de règlement de 7 jours à 1 heure, cela laissera-t-il une fenêtre exploitable par des attaquants ?
Théoriquement, cette crainte n’est pas infondée. Contrairement à la « censure forte » (attaque par le groupe de validateurs), la menace la plus sérieuse est une attaque de censure douce menée par des constructeurs de blocs : l’attaquant n’a pas besoin de contrôler le consensus, il suffit de faire pression sur les défenseurs en proposant en permanence des transactions de faible priorité, empêchant ainsi leur inclusion.
Fascinantement, la seule analyse économique systématique de ce scénario provient d’un article publié par Offchain Labs en février 2025, intitulé « Economic Censorship Games in Fraud Proofs ». Il modélise trois scénarios, du plus pessimiste au plus optimiste :
- G¹ : le contenu du bloc est entièrement décidé par le plus offrant ;
- G¹ₖ : certains validateurs construisent toujours le bloc localement ;
- Gᵐ : plusieurs validateurs décident collectivement du contenu, tant qu’un d’eux choisit de défendre.
Dans la pratique, comme certains validateurs peuvent choisir de sauter des slots (miss slots), certains modèles se dégradent vers le scénario G¹. L’étude part donc du pire cas.
Face à cela, les chercheurs proposent une défense pragmatique — une stratégie de « petite mise pour gros gain » : un mécanisme de retardement où le défenseur peut, d’un clic, prolonger la période de contestation. En pratique, il n’a pas besoin de faire tout le processus de vérification en une fois, mais simplement de soumettre une transaction clé.
Cette transaction clé, une fois inscrite sur la chaîne, prolonge automatiquement la période de contestation de 1 heure à 7 jours. Par exemple, si le défenseur détecte une anomalie, il n’a pas besoin de tout vérifier en 1 heure, il suffit de soumettre une transaction spéciale à L1. Cela déclenche une alarme, prolongeant instantanément la période de contestation.
Cela oblige l’attaquant à engager une guerre d’usure asymétrique : pour empêcher cette transaction, il doit payer en permanence des frais plus élevés que le défenseur, sur chaque bloc, durant toute la période de contestation.
Les résultats quantitatifs sont clairs : si un attaquant puissant dépense 100 milliards de dollars pour une attaque continue, alors :
- En 1 heure, le défenseur doit prévoir un budget de 33 millions de dollars en Gas pour contrer ;
- Si la mécanique de retardement est déclenchée, prolongeant la période à 7 jours, le coût de défense tombe à environ 20 000 dollars.
En d’autres termes, c’est un avantage structurel crucial : le coût pour l’attaquant croît linéairement, tandis que le défenseur n’a qu’à réussir une seule transaction pour faire échouer l’attaque.
Ce rapport de coûts (coût d’attaque vs. coût de défense) garantit qu’en dépit de la réduction du cycle de règlement, Ethereum conserve une robustesse économique forte.
Pour l’interopérabilité, c’est aussi essentiel : cela montre que confirmation rapide et cycles de règlement plus courts ne doivent pas forcément sacrifier la sécurité. Avec une conception de système raisonnable, la confirmation en secondes et la sécurité économique peuvent coexister, offrant une base solide pour réaliser une interopérabilité en temps réel.
En conclusion
Certains pourraient se demander : pourquoi s’embêter à optimiser ces quelques secondes ou minutes de latence ?
Dans l’ère des geeks Web3, nous sommes habitués à attendre, et même à considérer que « attendre » est le prix à payer pour la décentralisation. Mais sur la voie de la démocratisation de Web3, les utilisateurs ne devraient pas, ne peuvent pas, se soucier de la chaîne sur laquelle ils opèrent, ni de la logique de finalité de L1.
Les mécanismes de confirmation rapide, de battements de 6 secondes, et de défense asymétrique, ont en réalité un objectif commun : éliminer la variable « temps » du ressenti utilisateur.
Je le répète souvent : la meilleure technologie, c’est celle qui fait disparaître la complexité dans une confirmation ultra-rapide.
