Ethereum pourrait bientôt fonctionner à une vitesse deux fois supérieure à sa vitesse actuelle, suite à une proposition de Barnabé Monnot, développeur principal, visant à réduire de moitié le temps d'exécution des slots, le faisant passer de 12 à 6 secondes. La proposition d'amélioration Ethereum (EIP) 7782 pourrait être intégrée à la prochaine mise à jour « Glamsterdam », prévue pour 2026.
D'après un article Ethereum Magicians , la mise en œuvre de la modification du temps d'exécution des transactions pourrait réduire le temps nécessaire à la Ethereum pour finaliser les transactions et ajouter de nouveaux blocs au réseau principal. Ceci améliorerait les performances et l'ergonomie de la blockchain pour les applications décentralisées (dApps), les portefeuilles et defi .
Réduire de moitié le temps d'attente pour accélérer les confirmations
Ethereum fonctionne actuellement avec un cycle de traitement de 12 secondes. La modification proposée réduirait ce cycle à seulement 6 secondes, doublant ainsi le nombre de blocs produits par minute.
Monnot affirme que cette accélération pourrait améliorer l'expérience utilisateur en fournissant des données plus récentes et des confirmations plus rapides , avec des avantages évidents pour defi , tels que des fenêtres d'arbitrage plus courtes, des frais de transaction réduits et une liquidité accrue.
« Pour les marchés de preuves, le travail peut être fortement parallélisé, de sorte qu’un seul démonstrateur logique pourrait obtenir des sous-preuves de nombreux autres démonstrateurs. Néanmoins, la réduction du temps d’exécution signifie offrir davantage d’opportunités par unité de temps de concourir pour le droit de fournir la preuve d’un bloc », a-t-il écrit.
L'ajustement réseau proposé divise le créneau de 6 secondes en trois sous-processus : 3 secondes pour les propositions de blocs, 1,5 seconde pour les attestations et 1,5 seconde pour l'agrégation. Il préserverait la fonctionnalité globale du créneau tout en augmentant le débit au niveau du protocole.
Le développeur d'Ether a réaffirmé que cette modification n'affecterait pas le volume total de jetons distribués aux validateurs. En revanche, les détenteurs de jetons recevraient des récompenses plus faibles mais plus fréquentes grâce à une variance de récompense réduite et à des incitations moindres pour les pools de staking. Il a ajouté que cela favoriserait les détenteurs de jetons individuels ou les opérateurs locaux confrontés à des rendements imprévisibles dans le système actuel.
Compromis et difficultés techniques
Monnot a indiqué que la réduction des temps d'attente obligera les développeurs à implémenter une logique conditionnelle au sein des clients Ethereum et de l'infrastructure associée pour assurer la rétrocompatibilité.
Le réseau fonctionnant avec des intervalles de 12 secondes depuis son passage à la preuve d'enjeu, il doit rejouer les blocs plus anciens avec une synchronisation constante. Il pourrait être nécessaire de passer d' tracen secondes à un suivi en millisecondes, comme cela a été fait sur la chaîne Gnosis.
« Certains clients commencent à construire des blocs dès le début d'un créneau horaire. Avec seulement trois secondes pour la phase de proposition, toute latence peut empiéter sur le temps de production », a-t-il expliqué.
Monnot a toutefois noté que la part relative du temps de production des blocs au sein d'un créneau augmente en réalité, passant de 4 secondes sur 12 actuellement à 3 secondes sur 6 avec le nouveau modèle.
Échelle versus vitesse et préconfirmations
La communauté de développement d' Ethereumdébat de l'intérêt d'augmenter le débit de la couche 1 par rapport à l'optimisation de la vitesse de finalisation. Monnot a reconnu que des intervalles de temps plus courts n'augmentent pas directement le débit de gaz, mais peuvent améliorer la réactivité de la chaîne. Il a également cité des exemples montrant que les utilisateurs privilégient des confirmations plus rapides à des blocs de taille plus évolutive.
Les mécanismes de préconfirmation, solutions permettant une confirmation provisoire plus rapide en dehors du protocole principal, sont une option, mais Monnot a affirmé que les développeurs préfèrent les modifications au sein du protocole comme l'EIP-7782.
L'une des tâches les plus complexes liées à la mise en œuvre de cette proposition consiste à mettre à jour les logiciels clients et les outils d'infrastructure tels que les explorateurs de blocs. Ces outils doivent prendre en charge les deux durées d'intervalle de 12 secondes (ancienne) et de 6 secondes (nouvelle). Les développeurs devront s'assurer que les clients appliquent la logique appropriée selon qu'ils traitent des blocs historiques ou de nouveaux blocs. Au moment de la publication, la définition complète de ces modifications n'était pas encore finalisée.
