Ethereum entre dans la phase finale du testnet avant la mise à jour Fusaka

Ethereum s’apprête à franchir un cap décisif dans sa refonte technique. À l’approche du déploiement de Fusaka, le réseau entre dans la dernière phase de test d’une mise à jour clé. Derrière ce changement discret se joue pourtant un tournant stratégique : poser les fondations de l’exécution parallèle, attendue en 2026. Plus qu’un simple gain de performance, Ethereum amorce une transformation structurelle, conçue pour soutenir durablement sa montée en charge face aux enjeux croissants de scalabilité.

Une nouvelle limite pour plus de stabilité

La mise à jour Fusaka introduit une nouveauté de taille : la mise en place d’un plafond de gaz par transaction fixé à 16,78 millions d’unités, conformément à la proposition EIP-7825.

Jusqu’à présent, une transaction unique pouvait consommer l’ensemble du gaz disponible dans un bloc, soit environ 45 millions d’unités, ce qui exposait le réseau à des risques de congestion ou d’attaques par déni de service (DoS). La limite de gaz par transaction vise à améliorer l’efficacité des blocs, à réduire les risques de DoS et à poser les bases de l’exécution parallèle.

Cette limitation est d’ores et déjà active sur les testnets Holesky et Sepolia, dans le cadre des phases préparatoires au déploiement sur le réseau principal.

En instaurant cette limite, Ethereum cherche à améliorer la résilience du protocole tout en fluidifiant le traitement des transactions. Ce changement technique s’accompagne également d’une augmentation de la capacité globale des blocs, qui passe de 45 à 60 millions d’unités de gaz.

Concrètement, cette évolution permet :

• D’éviter qu’une seule transaction monopolise les ressources d’un bloc entier ;
• De favoriser l’inclusion simultanée de plusieurs transactions de moindre intensité ;
• De réduire les risques de saturation ou d’attaques ciblées sur la consommation de gaz ;
• D’optimiser la prévisibilité de la construction des blocs pour les validateurs et développeurs.

Cette refonte du fonctionnement interne du réseau marque une étape clé dans la professionnalisation de l’infrastructure Ethereum, en vue d’accueillir de futures évolutions comme l’exécution parallèle.

Des testnets au mainnet, vers une exécution parallèle à grande échelle

Au-delà de cette nouvelle architecture des blocs, Fusaka introduit une innovation centrale baptisée PeerDAS, pour « Peer Data Availability Sampling ». Ce système permet aux nœuds Ethereum de ne stocker qu’une portion aléatoire des données « blob » issues des couches 2, plutôt que l’intégralité du dataset.

L’objectif est de réduire les exigences matérielles tout en conservant la sécurité du réseau. Cette avancée vise à renforcer l’adoption des solutions de type rollups, qui reposent justement sur cette disponibilité des données. En effet, cette innovation PeerDAS « permet de réduire les besoins matériels tout en maintenant la sécurité, et de favoriser une scalabilité plus économique et à haut débit pour les réseaux de layer 2 ».

La mise en œuvre de PeerDAS ouvre la voie à la prochaine étape de la feuille de route Ethereum  : la mise à jour « Glamsterdam », prévue en 2026, qui introduira l’EIP-7928, première itération concrète de l’exécution parallèle des transactions. Cette évolution permettra de traiter plusieurs opérations simultanément, au lieu de les exécuter de manière séquentielle comme c’est encore le cas aujourd’hui.

Dans cette perspective, Fusaka agit comme un préalable indispensable : sans limitation de gaz par transaction ni infrastructure optimisée pour les données, l’exécution parallèle ne pourrait être déployée de manière sécurisée. Pour Gabriel Trintinalia, ingénieur chez Consensys, « ces mises à jour des testnets sont essentielles pour renforcer la confiance avant le fork du mainnet ».

À terme, cette série d’améliorations, prévue pour le 3 décembre , pourrait profondément transformer le fonctionnement interne d’Ethereum. Le réseau s’oriente vers une architecture plus modulaire, plus scalable et mieux adaptée aux usages futurs, notamment ceux des solutions de seconde couche. Elles permettent de valider les performances, d’identifier les cas limites et d’affiner les paramètres techniques avant activation.