Ethereum : Zoom sur les nouveautés de la mise à jour Fusaka

Contexte

Depuis The Merge en 2022, la roadmap d’Ethereum se concentre sur l’amélioration de la scalabilité, de l’expérience utilisateur et de la réduction des coûts de transaction tout en conservant la décentralisation qui caractérise le réseau.

Au cours des deux dernières années, Ethereum a connu deux mises à jour majeures qui y ont fortement contribué : Dencun et Pectra.

Dencun, introduite en mars 2024, a amené plusieurs améliorations significatives, dont l’ajout des blobs, un nouveau format de données pensé pour les L2. En effet, face à la l’essor de ces réseaux de seconde couche ces dernières années, Ethereum a progressivement orienté une partie de ses efforts vers la facilitation de leur développement.

Les blobs contribuent à cet objectif en proposant une nouvelle forme de stockage temporaire dont les données sont effacées après 4096 epochs, soit 18 jours. Cette durée est largement suffisante pour les L2 qui conservent uniquement des preuves de ces données une fois ce délai écoulé. En pratique, ce caractère éphémère permet de réduire les coûts de transaction sur ces réseaux avec un impact supérieur à un facteur dix.

Pectra, déployée en mai 2025, a prolongé cette dynamique en augmentant le nombre de blobs de 3 à 6 par bloc. En effet, depuis novembre 2024, l’usage des L2 était tel que la totalité des blobs étaient utilisés à chaque bloc, ce qui a nécessité une réhausse du seuil initial. À ce jour, la cible de 6 blobs par bloc établie par Pectra n’a pas encore été atteinte, mais la tendance s’en rapproche.

Pectra a également introduit l’EIP-7702, qui permet à n’importe quelle adresse de bénéficier de fonctionnalités liées à l’account abstraction, ainsi que l’EIP-7251, qui autorise désormais les validateurs à staker un montant compris entre 32 et 2048 ETH (contre seulement 32 ETH initialement).

La mise à jour Fusaka poursuit cette trajectoire en renforçant l’usage des blobs, principalement grâce à l’implémentation de PeerDAS. Elle inclut aussi plusieurs optimisations techniques dont l’impact pourrait être significatif à long terme.

→ Relire notre étude sur les principales EIP de Pectra sur Ethereum :

Qu’est-ce que la mise à jour Fusaka sur Ethereum ?

Fusaka est la troisième grande mise à jour d’Ethereum orientée vers la scalabilité des L2 après Dencun (2024) et Pectra (2025). Comme les deux précédentes, elle combine en réalité deux mises à jour :

• Osaka, qui concerne la couche d’exécution et définit les règles de traitement des transactions au sein de l’EVM,
• Fulu, qui met à jour la couche de consensus et détermine la manière dont les nœuds s’accordent sur l’ordre et la validité des blocs.

Elle regroupe 13 EIP qui prolongent directement les évolutions amorcées avec Dencun et Pectra. L’objectif est d’améliorer la gestion des données produites par les layer 2, tout en optimisant certains paramètres du réseau lui-même.

L’une des avancées majeures est PeerDAS, un mécanisme qui répartit les données de stockage des blobs entre un grand nombre de validateurs plutôt que de leur demander d’en conserver l’intégralité. Cela permet d’améliorer la scalabilité des blobs sans imposer de contraintes matérielles trop élevées aux validateurs.

La mise à jour introduit aussi plusieurs ajustements destinés à encadrer l’usage des blobs, notamment une procédure plus flexible pour modifier leur nombre et un prix plancher pour garantir que leur traitement reste rentable pour les validateurs. Ces mécanismes stabilisent le marché des blobs et préparent le réseau à une croissance progressive des layer 2.

Fusaka apporte en parallèle plusieurs optimisations liées au gas et au fonctionnement interne des nœuds. L’extension de la limite de gas par bloc se poursuit pour augmenter la capacité du réseau sans altérer son niveau de décentralisation. De nouvelles precompiles, dont l’une destinée aux signatures secp256r1, simplifient certaines opérations on-chain et réduisent leur coût.

Enfin, la mise à jour intègre divers ajustements visant à faciliter le travail des validateurs : des paramètres plus prévisibles, des limites de données mieux définies et des mécanismes destinés à prévenir les désynchronisations entre clients.

En résumé, Fusaka n’apporte pas de changement visible pour les utilisateurs, mais constitue une étape clé dans la progression de la scalabilité d’Ethereum. Elle prépare l’infrastructure aux besoins croissants des layer 2 et contribue à un fonctionnement plus robuste, plus stable et plus prévisible du réseau.

---

Blobs et PeerDAS

PeerDAS : scalabilité des blobs

Le PeerDAS (EIP-7594) constitue la principale évolution apportée par Fusaka. Concrètement, PeerDAS (Peer Data Availability Sampling) est un protocole qui permet de répartir la charge de stockage des données des blobs en le distribuant entre de nombreux validateurs.

Aujourd’hui, chaque validateur doit pouvoir accéder à l’intégralité des données des blobs. Avec PeerDAS, chaque validateur ne stocke qu’une fraction aléatoire de chaque blob. Grâce au très grand nombre de validateurs sur Ethereum (environ 1,12 million), il devient pratiquement certain que l’ensemble des données reste disponible à tout moment.

Dans sa configuration initiale, PeerDAS impose que chaque validateur stocke au moins 1/8 de chaque blob (il conserve la possibilité d’en stocker davantage), ce qui suggère qu’à bande passante constante, les validateurs actuels pourraient théoriquement gérer huit fois plus de blobs qu’aujourd’hui. À terme, ce seuil pourra être abaissé à 1/16 voire 1/32.

Historiquement, décentralisation et scalabilité sont en général deux concepts qui s’opposent. En effet, si certains réseaux comme Solana parviennent à traiter autant de transactions, c’est car y faire fonctionner un validateur nécessite une bande passante et des ressources informatiques importantes. À l’inverse, faire tourner un nœud sur Bitcoin ne nécessite presque aucune ressource grâce à sa lenteur qui permet même aux nœuds les moins puissants et avec une faible bande passante de se synchroniser.

Ethereum cherche continuellement à trouver des solutions qui permettent un équilibre entre ces deux notions. Le développement des L2 est un exemple de scalabilité qui sacrifie une partie de la décentralisation, certes, mais tout en gardant certaines garanties cryptographiques.

Le PeerDAS en est un bon exemple : en apparence, il sacrifie partiellement la décentralisation du réseau dans la mesure où chaque validateur doit compter sur plusieurs pairs pour reconstruire l’information complète. Mais en contrepartie, le PeerDAS profite du nombre très important de validateurs sur Ethereum qui offre une sécurité statistique élevée. En pratique, le tout améliore grandement la scalabilité du réseau en réduisant très peu la décentralisation.

EIP relatives à l’amélioration des blobs

Parmi les autres EIP notables concernant l’évolution des blobs, l’EIP-7918 (Blob base fee bounded by execution cost), introduit un prix plancher pour ces derniers. Avant Fusaka, les blobs disposaient de leur propre marché du gas, dont le prix évoluait en fonction de la demande des L2.

Lorsque ce seuil des 6 blobs par bloc était dépassé, le prix du gas pour les blobs augmentait au prochain bloc. Si la demande était plus faible, le prix diminuait. Le problème de ce système est que, si la demande est trop faible sur une longue période, le prix du gas peut chuter au point où le prix payé par les L2 devient inférieur au coût d’exécution pour les validateurs. Ce n’est donc plus rentable pour eux d’effectuer ces calculs. Pour éviter cela, cette EIP fixe un prix plancher censé couvrir les coûts opérationnels des validateurs.

La seconde est l’EIP-7892 (Blob Parameter Only Hardforks), qui définit les hard forks BPO (Blob Parameter Only), un nouveau type de hard fork permettant de faire évoluer le nombre de blobs plus rapidement.

Pour comprendre cette EIP, il convient de rappeler la différence entre un soft et un hard fork :

• Soft fork : une mise à jour rétrocompatible pouvant être déployée progressivement,
• Hard fork : une mise à jour où la nouvelle version n’est plus compatible avec l’ancienne, qui requiert une mise à jour simultanée des nœuds.

Aujourd’hui, la modification de l’objectif de blobs par bloc, un paramètre crucial pour l’évolution du prix du gas, nécessite un hard fork, puisqu’elle n’est pas rétrocompatible. Cette contrainte rend les ajustements très lourds à mettre en œuvre, alors même que ce paramètre doit pouvoir évoluer rapidement pour suivre la demande des L2.

L’EIP-7892 propose une solution en créant un hard fork simplifié, limité à la modification des paramètres liés aux blobs, ce qui rend ces ajustements beaucoup plus faciles à coordonner.

Avec ces trois EIP, Fusaka assemble les fondations nécessaires pour accompagner la montée en charge des blobs et soutenir la croissance continue des L2.

Gas et optimisations

Extension de la limite de gas par bloc

La principale évolution concernant le gas sur Ethereum est l’EIP-7935 (Set Default Gas Limit to 60M), qui augmente la limite de gas par bloc de 36 à 60 millions d’unités, soit une hausse de 66 %. Cela se traduit directement par un nombre supérieur de transactions pouvant être incluses par bloc.

Ce n’est pas la première fois que ce genre de mise à jour est déployée. En 2022, la limite avait été doublée de 15 à 30 millions d’unités par bloc. Plus tôt cette année, elle était passée de 30 à 36 millions. Ces modifications permettent un scaling immédiat de la blockchain, mais au prix d’une partie de la décentralisation, puisqu’elles viennent réduire le matériel minimum nécessaire pour faire fonctionner un validateur. La croissance de cette limite reste très conservatrice au regard de l’évolution du matériel informatique ces dernières années.

Precompile pour la courbe secp256r1

L’EIP-7951 n’est pas, à proprement parler, une optimisation du gas, mais son importance est bien plus grande qu’il n’y paraît. Les precompiles sont des smart contracts spéciaux intégrés au protocole, conçus pour exécuter efficacement des opérations courantes on-chain.

Ces tâches pourraient être réalisées par un smart contract classique, mais ce serait l’équivalent de réparer une voiture en commençant par fabriquer soi-même ses outils. Les precompiles constituent justement cette boîte à outils native, plus simple, plus standardisée et plus sûre pour les développeurs comme pour les utilisateurs.

L’EIP-7951 ajoute un precompile dédié à la vérification des signatures ECDSA basées sur la courbe elliptique secp256r1. À titre informatif, ce type de signatures est pris en charge par les puces sécurisées de nombreux appareils Android, Apple ou encore par différentes clés de sécurité.

Grâce à cette précompilation, leur vérification peut être effectuée via un code plus optimisé que les solutions existantes, ce qui réduit potentiellement le coût en gas tout en renforçant la sécurité. Cette amélioration ouvre la voie à une adoption plus fluide d’Ethereum sur un large éventail d’appareils disposant de modules de sécurité matériels.

Autres EIP relatives à l’optimisation du gas

Fusaka contient cinq autres EIP liées de près ou de loin à l’optimisation de l’usage du gas :

• EIP-7825 : impose une limite de 16.7 M de gas maximum par transaction (2^24) afin de réduire le risque d’attaque par déni de service ;
• EIP-7939 : un nouvel opcode (fonction directement intégrée à l’EVM qui permet de compter le nombre de zéro qui précédent le premier “1” dans un nombre de 256 bits. Très utile pour de nombreuses opérations mathématiques, son implémentation va réduire la consommation de gas de certains smart contracts ;
• EIP-7823 : MODEXP est un precompile important pour la vérification de la plupart des signatures sur Ethereum. Cette EIP vient fixer une limite sur la taille des données qu’on peut fournir à MODEXP, principalement pour régler des bugs récurrents liés à des données trop longues ;
• EIP-7883 : modifie la méthode de calcul du prix du gas de MODEXP pour s’assurer qu’il couvre toujours les coûts réels pour les validateurs ;
• EIP-7934 : fixe une limite maximale de 10 Mo pour qu’un bloc soit propagé et accepté par le réseau. Cette limite protège indirectement la décentralisation du réseau puisqu’elle fixe un plafond au volume de données qui doit être reçu et vérifié par l’ensemble des nœuds du réseau. Elle ajoute aussi une sécurité supplémentaire contre les attaques par déni de service.

Autres améliorations de Fusaka

Fusaka inclut trois autres EIP diverses :

• EIP-7917 : permet de déterminer de manière déterministe les proposeurs des 32 blocs de la prochaine epoch. Depuis l’implémentation de l’EIP-7251 (MaxEB), la quantité d’ETH stakée par un validateur peut dépasser 32 ETH et évoluer au cours d’une epoch. Or, l’algorithme qui sélectionne les proposeurs tient partiellement compte de ces variations de stake à l’epoch précédente. L’EIP-7917 vise à simplifier le travail des validateurs en leur donnant une visibilité claire et anticipée sur leurs rôles à venir ;
• EIP-7642 : suppression d’une partie des données antérieures à The Merge, ce qui permet d’économiser plusieurs centaines de gigocters de stockage sur l’ensemble des nœuds du réseau ainsi que de la bande passante. Cela n’efface pas la blockchain elle-même mais des données liées qui restent accessibles via des noeuds archives ;
• EIP-7910 : ajoute une nouvelle méthode JSON-RPC destinée à éviter les désynchronisations entre clients, comme cela avait été observé lors de l’implémentation de Pectra sur le testnet Holesky.

Conclusion

Fusaka introduit avant tout le PeerDAS, une avancée majeure qui devrait avoir un effet déterminant sur la scalabilité des L2 au cours des prochains mois, avec un potentiel d’augmentation de capacité de plusieurs ordres de grandeur.

À côté de cette innovation, la mise à jour rassemble une série d’ajustements techniques qui, pris individuellement, ont un impact limité à court terme mais qui, combinés, renforcent l’efficacité générale du réseau. En définitive, les EIP allègent les exigences matérielles pour les validateurs et soutiennent une progression plus linéaire de la scalabilité grâce à l’augmentation graduelle de la limite de gas par bloc.