Fusaka : Le saut évolutif d'Ethereum vers une scalabilité infinie après Pectra

Après le succès de la mise à jour Pectra, la communauté Ethereum se prépare pour la prochaine grande étape. Le 3 décembre 2025 arrivera Fusaka, un hard fork incarnant la vision du réseau d’atteindre une scalabilité pratiquement illimitée. Le nom lui-même reflète cette ambition : Fusaka combine « Fulu » (layer d’exécution) et « Osaka » (layer de consensus), symbolisant l’intégration des deux piliers du protocole.

Pourquoi Fusaka est crucial pour l’avenir des Layer 2

Les dernières années ont montré comment les Rollup Layer 2 sont devenus la solution principale pour les coûts élevés sur le mainnet Ethereum. Cependant, ces protocoles rencontrent encore des obstacles importants : les frais restent trop élevés en période de congestion, et l’architecture du réseau n’est pas encore optimisée pour gérer des volumes massifs de données. Fusaka aborde directement ces problèmes via neuf propositions d’amélioration (EIP), chacune conçue pour renforcer un aspect spécifique du réseau.

PeerDAS (EIP-7594): Comment Ethereum vérifiera les données sans surcharger les nœuds

L’introduction de l’EIP-4844 a révolutionné la disponibilité des données, mais a créé une nouvelle contrainte : chaque nœud doit télécharger d’énormes quantités de blobs pour en vérifier l’authenticité. Cela menace la décentralisation du réseau. Les exigences en bande passante augmentent, le niveau de décentralisation diminue, et les petits validateurs peinent à suivre.

PeerDAS (EIP-Data Availability Sampling) résout ce dilemme en permettant aux nœuds de vérifier l’intégrité des données en ne téléchargeant que des fragments aléatoires, plutôt que l’ensemble du dataset. Le mécanisme fonctionne en divisant chaque blob en petites unités appelées « cellules », organisées en colonnes. Chaque nœud est responsable de certaines colonnes spécifiques et en échantillonne d’autres auprès des pairs. Si un nœud collecte au moins 50 % des colonnes totales (par exemple, 32 sur 64), il peut reconstruire entièrement le blob grâce à un code de correction d’erreurs qui ajoute de la redondance aux données.

Cette approche crée un équilibre : les validateurs, équipés de matériel plus puissant, peuvent stocker des volumes plus importants et servir de points d’ancrage du réseau. Les nœuds ordinaires restent des participants actifs sans supporter tout le poids computationnel. La conséquence ? Ethereum peut augmenter significativement la capacité des blobs tout en maintenant des exigences matérielles faibles pour les participants.

Une règle importante accompagne cette nouveauté : aucune transaction ne peut contenir plus de 6 blobs. Cette limite protège le système contre les abus et répartit mieux la charge sur le réseau.

Repricing du gas : MODEXP et limites de sécurité

Trois EIP abordent le sujet sensible du pricing du gas, chacun traitant de problèmes spécifiques dans le mécanisme de précompilation MODEXP.

EIP-7823 : Mettre un frein aux données MODEXP

La précompilée MODEXP d’Ethereum a historiquement accepté des entrées de taille théoriquement illimitée. Cela a causé de nombreuses vulnérabilités de consensus : chaque client implémentait la fonction différemment, les tests devenaient impossibles, et la formule de tarification était imprévisible.

L’EIP-7823 introduit une règle simple mais fondamentale : la base, l’exposant et le module ne peuvent pas dépasser 1024 octets (8192 bits). Cette limite est sûre pour toutes les applications pratiques — la cryptographie RSA utilise des clés jusqu’à 4096 bits, les courbes elliptiques encore moins. En analysant l’historique de la blockchain de 2018 à janvier 2025, aucune appel MODEXP réussi n’a jamais dépassé 513 octets. Le changement, donc, n’invalide pas les transactions historiques ni n’introduit de nouveaux risques, mais élimine plutôt des cas pathologiques qui menaçaient la stabilité du réseau.

EIP-7825 : Limite maximale de gas par transaction

Une autre vulnérabilité structurelle : une seule transaction peut consommer presque tout le gas disponible dans un bloc (40 millions). Si quelqu’un envoie une transaction avec 38 millions de gas, le bloc devient pratiquement inutilisable pour d’autres transactions, créant un effet de type attaque de déni de service.

L’EIP-7825 fixe une limite stricte de 16.777.216 gas (2²⁴) par transaction, indépendamment de la limite globale du bloc. Cela garantit que chaque bloc contiendra naturellement plus de transactions, empêchant le monopole d’une seule opération. Le choix de 2²⁴ n’est pas arbitraire : c’est une puissance de 2 (facile à implémenter), suffisamment grande pour des contrats complexes, et environ la moitié de la taille typique d’un bloc.

L’impact sur la communauté est minimal — presque toutes les transactions actuelles consomment bien moins de 16 millions de gas. Seules des opérations extrêmes rares devront être divisées en plusieurs étapes.

EIP-7883 : Recalculer le coût réel de MODEXP

Les opérations MODEXP ont historiquement été sous-prépayées par rapport à leur coût computationnel réel. Cela crée un goulot d’étranglement : les producteurs de blocs traitent des calculs très lourds pour des rémunérations faibles, et les attaquants peuvent remplir des blocs avec des opérations coûteuses sans dépenser beaucoup.

En utilisant une formule empirique mise à jour, l’EIP-7883 augmente le coût minimum de 200 à 500 gas et triple les coûts globaux, avec des pénalités encore plus élevées pour les opérations avec des entrées supérieures à 32 octets. Le coût des opérations sur de grands nombres peut augmenter jusqu’à 76-80 fois. 99,69 % des appels historiques verront au moins un triplement. Cela ne modifie pas le fonctionnement de MODEXP, mais aligne le prix sur le travail effectivement requis.

Stabilité des blobs et prévision des proposeurs

EIP-7918 : Lier la fee des blobs au coût d’exécution

Les fees des blobs (introduits par EIP-4844) fluctuent énormément. Lorsque le gas d’exécution domine le coût total pour les Rollup, baisser la fee de base des blobs n’augmente pas la demande — un phénomène économique appelé demande inélastique. Le protocole continue de réduire le prix jusqu’à 1 gwei (le minimum absolu), moment où le mécanisme cesse de fonctionner.

L’EIP-7918 introduit un « prix de réserve » minimum calculé comme BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB. Cela garantit que la fee de base des blobs maintient toujours une relation cohérente avec le coût d’exécution, créant une stabilité prévisible pour les Rollup. Une analyse empirique de quatre mois de données blockchain confirme que ce nouveau mécanisme évite les chutes à 1 gwei et réduit drastiquement la volatilité.

EIP-7917 : Rendre la planification des proposeurs entièrement déterministe

La sélection des validateurs proposeurs pour les epochs futurs n’est actuellement pas prévisible. Même en connaissant la seed RANDAO, des changements dans les soldes effectifs (EB) durant un epoch peuvent modifier la liste des proposeurs de l’epoch suivant. Cela pose problème pour les protocoles de pré-confirmation et ouvre la voie à des manipulations.

L’EIP-7917 résout ce problème en introduisant un mécanisme déterministe qui calcule et stocke la planification des proposeurs pour les deux epochs suivantes dès le début de chaque epoch. Une fois déterminée, la liste ne change plus en raison de mises à jour EB tardives. Cette prévisibilité est essentielle pour la stabilité des Layer 2 et empêche le « balance brushing» — tentatives des validateurs de manipuler leurs soldes après avoir vu le RANDAO.

Sécurité et efficacité du réseau

EIP-7934 : Limite à la taille des blocs

Sans limite sur la taille RLP des blocs, un attaquant peut créer des blocs gigantesques qui paralysent les nœuds et ralentissent la propagation. L’EIP-7934 fixe la limite maximale à 10 Mo (avec une marge de sécurité de 2 Mo), en accord avec la limite déjà en vigueur dans le protocole gossip de la couche de consensus. Cela élimine les incohérences entre les couches et prévient les attaques DoS basées sur des tailles excessives.

EIP-7939 : L’opcode CLZ pour opérations bit rapides

Les développeurs ont historiquement dû implémenter manuellement des fonctions de comptage des zéros initiaux en Solidity, consommant trop de gas et générant un bytecode encombrant. L’EIP-7939 introduit un nouvel opcode natif CLZ (0x1e) au coût de 5 gas, identique à ADD. Cela accélère les bibliothèques mathématiques, algorithmes de compression, bitmap, schémas de signature et opérations cryptographiques, réduisant les frais et coûts des preuves à divulgation zéro.

EIP-7951 : Support natif pour les signatures hardware modernes

Apple Secure Enclave, Android Keystore, FIDO2/WebAuthn et dispositifs hardware de sécurité utilisent la courbe secp256r1 (P-256). L’EIP-7951 introduit une précompilation P256VERIFY à l’adresse 0x100, permettant à Ethereum de vérifier en toute sécurité et de manière native des signatures ECDSA sur la courbe P-256, au coût de 6900 gas. Cela corrige les vulnérabilités de sécurité de la proposition précédente (RIP-7212) et permet enfin aux utilisateurs d’accéder à des wallets supportés par du hardware moderne avec la même simplicité qu’Ethereum.

Conclusion : L’infrastructure scalable de demain

Fusaka n’est pas un changement révolutionnaire unique, mais une série d’améliorations coordonnées qui traitent des contraintes spécifiques du réseau. PeerDAS permet la scalabilité des données, la revalorisation du gas assure la stabilité économique, la détermination des proposeurs renforce la prévisibilité, et les nouvelles primitives optimisent l’efficacité.

Le résultat est une Ethereum prête pour l’avenir : Layer 2 Rollup pourra fonctionner à moindre coût et à une vitesse supérieure, les nœuds restent décentralisés grâce aux mécanismes d’échantillonnage, et la sécurité du réseau est consolidée par des limites et des incitations bien calibrées. Lorsque Fusaka sera activé le 3 décembre 2025, il marquera officiellement la transition vers l’infrastructure de scalabilité infinie qu’Ethereum a toujours promise.