Mise à l'échelle et sécurité en parallèle : analyse complète de la mise à niveau Fusaka d'Ethereum et des 12 EIP

Auteur : @ChromiteMerge

Ethereum s’apprête à recevoir une mise à niveau appelée « Fusaka » avec une hard fork le 3 décembre 2025. Cette mise à jour comprend 12 propositions d’amélioration d’Ethereum (EIP), comme 12 pièces de précision qui travailleront ensemble pour améliorer la scalabilité, la sécurité et l’efficacité opérationnelle d’Ethereum. Ci-dessous, l’auteur classe ces 12 EIP, en expliquant simplement quels problèmes ils résolvent et pourquoi ils sont cruciaux pour l’avenir d’Ethereum.

Scalabilité ! Faire fonctionner Ethereum plus vite, avec plus de capacité

C’est le thème central de la mise à niveau Fusaka. Pour supporter une économie numérique mondiale, Ethereum doit résoudre les problèmes de congestion des transactions et de coûts élevés. Plusieurs EIP ci-dessous visent précisément cet objectif, notamment en réduisant les coûts liés à l’extension de Layer 2.

EIP-7594 : PeerDAS - Échantillonnage de disponibilité des données

Problème : Après l’introduction des « Blob » lors de la mise à niveau Dencun, qui offrent un stockage de données peu coûteux pour Layer 2, une question clé est apparue : comment garantir que ces données massives sont réellement disponibles ? Actuellement, chaque nœud validateur doit télécharger et vérifier toutes les données blob d’un bloc. Lorsqu’un bloc contient jusqu’à 9 blobs, cela reste faisable. Mais si le nombre de blobs augmente (par exemple à 128), télécharger et vérifier tous ces blobs devient coûteux, augmentant la barrière à la participation des validateurs et menaçant la décentralisation du réseau.

Solution : PeerDAS (Peer Data Availability Sampling) transforme la vérification exhaustive en un « échantillonnage aléatoire ». En résumé :

2. Le réseau divise les blobs complets en segments.

3. Chaque validateur n’a pas besoin de télécharger tous les blobs, il suffit de télécharger et vérifier aléatoirement quelques segments.

4. Ensuite, par échange de résultats de vérification et vérification mutuelle, tous peuvent confirmer l’intégrité et la disponibilité de l’ensemble des blobs.

C’est comme un grand puzzle : chacun ne détient que quelques pièces, mais en vérifiant les connexions clés, tout le monde peut s’assurer que le puzzle est complet. Il est important de noter que PeerDAS n’est pas une invention totalement nouvelle, son principe central de DAS a été testé avec succès dans des projets tiers comme Celestia. La mise en œuvre de PeerDAS comble une « dette technique » essentielle dans la vision à long terme d’extension d’Ethereum.

Signification : PeerDAS réduit considérablement la charge de stockage pour les validateurs, facilitant une extension massive des données sur Ethereum. À l’avenir, chaque bloc pourrait contenir des centaines de blobs, soutenant la vision de 10 millions de TPS, tout en permettant à des utilisateurs ordinaires de faire fonctionner facilement des validateurs, maintenant ainsi la décentralisation.

EIP-7892 : Hard fork BPO - Mise à niveau légère des paramètres

Problème : La demande de capacité de données Layer 2 fluctue rapidement. Attendre une grande mise à jour comme Fusaka pour ajuster la limite de blobs est trop lent, ne suivant pas le rythme de l’écosystème.

Solution : Cet EIP définit un mécanisme de « hard fork dédié aux paramètres de blobs » (Blob Parameter Only Hardfork, BPO). Très léger, il ne modifie que quelques paramètres liés aux blobs (par exemple, le nombre cible de blobs par bloc), sans changer le code complexe. Les opérateurs de nœuds n’ont même pas besoin de mettre à jour leur logiciel, ils acceptent simplement les nouveaux paramètres à une date précise, comme une mise à jour de configuration en ligne.

Signification : La mécanique BPO permet à Ethereum d’ajuster rapidement et en toute sécurité la capacité du réseau. Par exemple, après Fusaka, la communauté prévoit deux BPO successifs pour doubler la capacité des blobs, permettant une extension « élastique et progressive » de la capacité, avec un risque maîtrisé.

EIP-7918 : Marché stable des frais de blobs

Problème : Le mécanisme précédent d’ajustement des frais de blobs était trop « sujet à la spéculation ». Lorsqu’il y a peu de demande, les frais tombent presque à zéro, ce qui ne stimule pas la demande et crée un « prix plancher historique ». Lorsqu’il y a beaucoup de demande, les frais s’envolent, créant des extrêmes de prix. Cette « course à la baisse et à la hausse » rend la planification des coûts Layer 2 difficile.

Solution : L’EIP-7918 propose de fixer une fourchette de prix raisonnable pour les frais de blobs, avec un « minimum de consommation » flexible. La limite supérieure et inférieure des frais de blobs sera liée aux frais d’exécution (execution fee) sur Layer 2, qui restent relativement stables et peu dépendants du volume de transactions dans le bloc. En liant la fourchette des frais de blobs à cette « ancre », on évite les fluctuations extrêmes.

Signification : Cette amélioration empêche la « course à la baisse et à la hausse » des frais de blobs, rendant les coûts opérationnels Layer 2 plus prévisibles. Les projets Layer 2 pourront ainsi proposer des frais plus stables et raisonnables, évitant des expériences de « gratuité aujourd’hui, prix exorbitants demain ».

EIP-7935 : Augmentation de la capacité transactionnelle principale

Problème : La capacité d’un bloc Ethereum est limitée par le « limite de gas » (environ 30 millions actuellement), qui n’a pas été ajusté depuis longtemps. Pour augmenter le débit global, il faut augmenter cette limite, tout en garantissant que cela ne renforce pas la centralisation ni n’exige du matériel trop puissant pour les validateurs.

Solution : Cet EIP propose d’augmenter la limite de gas par défaut à un nouveau niveau (par exemple 45 millions ou plus). Ce n’est pas une obligation, mais une recommandation pour encourager progressivement l’acceptation d’une limite plus haute par les validateurs.

Signification : Plus de transactions par bloc, donc un TPS plus élevé, moins de congestion et de frais élevés. Cependant, cela exige aussi que les validateurs disposent d’un matériel plus performant, ce qui sera testé avec prudence.

Sécurité et stabilité ! Construire une défense solide pour le réseau

En parallèle de l’extension, il faut garantir la sécurité et la stabilité du réseau. En mai 2025, l’Ethereum Foundation a lancé le « Plan de sécurité d’un trillion de dollars » (Trillion Dollar Security, 1TS), visant à bâtir un réseau capable de sécuriser des actifs d’un trillion de dollars. Plusieurs EIP dans Fusaka soutiennent cette vision, comme des « freins et barrières » renforçant la sécurité.

EIP-7934 : Fixation d’une limite physique à la taille des blocs

Problème : La limite de gas ne concerne que la charge de calcul, pas la taille physique du bloc. Un attaquant peut créer un « bloc-bombe » avec beaucoup de données peu coûteuses (par exemple, des transferts de 0 ETH vers de nombreux adresses), qui, tout en respectant la limite de gas, occupe énormément d’espace. Ces « blocs-données » ralentissent la propagation, risquant de provoquer des attaques DoS.

Solution : Fixer une limite physique de 10 Mo par bloc. Tout bloc dépassant cette taille sera rejeté.

Signification : C’est comme fixer la taille maximale d’un camion sur la route, évitant que des « véhicules démesurés » perturbent la circulation. Cela garantit une propagation rapide, réduit la latence et renforce la résistance aux attaques.

EIP-7825 : Limite de gas par transaction

Problème : Bien que la limite de gas par bloc existe, aucune limite n’est imposée à une seule transaction. Un utilisateur malveillant pourrait soumettre une transaction consommant presque tout le gas disponible, empêchant les autres de passer.

Solution : Fixer une limite de 16,77 millions de gas par transaction. Les opérations complexes doivent être divisées en plusieurs transactions.

Signification : Cela favorise l’équité et la prévisibilité, empêchant une seule transaction de monopoliser la capacité du bloc.

EIP-7823 & EIP-7883 : Sécurisation du précompilé ModExp

Problème : ModExp, pour le calcul de puissances modulaires, est utilisé en cryptographie. Mais il présente deux risques : pas de limite sur la longueur des nombres d’entrée, et un coût en gas trop faible, ce qui peut être exploité pour des attaques par déni de service.

Solution :

• EIP-7823 : Limiter la longueur des nombres d’entrée à 8192 bits.

• EIP-7883 : Augmenter le coût en gas pour les grands calculs, pour que le coût reflète la consommation réelle de ressources.

Signification : Ces mesures éliminent une voie d’attaque potentielle, en imposant des limites et en ajustant le prix du calcul, renforçant la robustesse du réseau.

Fonctionnalités pour les développeurs ! Outils améliorés pour la construction d’applications

Au-delà de la scalabilité et de la sécurité, Fusaka apporte de nouveaux outils pour les développeurs, rendant la création d’applications plus efficace et plus puissante.

EIP-7951 : Compatibilité avec les signatures matérielles courantes

Problème : Les appareils courants comme iPhone, tokens U2F, modules de sécurité hardware utilisent souvent la norme de cryptographie secp256r1 (P-256). Or, Ethereum utilise principalement secp256k1, ce qui limite l’interopérabilité avec ces appareils.

Solution : Ajouter un contrat précompilé permettant à Ethereum de supporter et vérifier directement les signatures sur la courbe secp256r1.

Signification : C’est une avancée majeure. Elle ouvre la voie à une intégration plus fluide avec des milliards d’appareils. À l’avenir, vous pourrez signer des transactions Ethereum directement avec la puce de sécurité de votre téléphone, sans applications supplémentaires, avec plus de sécurité et de simplicité. Cela réduit considérablement la barrière d’accès pour le grand public et favorise la convergence Web2/Web3.

EIP-7939 : Instruction efficace pour compter les zéros en tête (CLZ)

Problème : Dans la cryptographie et le traitement de données, il est souvent nécessaire de compter le nombre de bits consécutifs à zéro en tête d’un nombre de 256 bits. Actuellement, l’EVM ne possède pas d’opcode dédié, obligeant à des calculs coûteux en Solidity.

Solution : Ajouter un opcode « CLZ » (Count Leading Zeros) pour effectuer cette opération en une seule étape.

Signification : Un outil spécialisé qui réduit la consommation de gas pour ces opérations, rendant plus efficaces les applications dépendant de mathématiques complexes, notamment ZK Rollups.

Optimisation du réseau ! Améliorations invisibles pour une meilleure santé

Enfin, deux EIP moins visibles pour l’utilisateur mais essentielles pour la santé à long terme du réseau.

EIP-7642 : Réduction de la charge de synchronisation des nouveaux nœuds

Problème : Avec l’accumulation de données historiques, un nouveau nœud doit télécharger énormément de données, ce qui augmente la barrière à l’entrée. Après la transition vers PoS, certains champs dans les reçus de transaction sont devenus inutiles, créant de la redondance.

Solution : Introduire une stratégie d’expiration des données historiques, permettant aux nouveaux nœuds de sauter certains vieux contenus, et simplifier le format des reçus pour réduire la taille des données à télécharger.

Signification : Cela « allège » le fonctionnement des nœuds, réduisant d’environ 530 Go la quantité de données à synchroniser, rendant le réseau plus décentralisé et robuste.

EIP-7917 : Ordre déterministe des blocs et pré-confirmation

Problème : La centralisation du séquencement (sequencer) dans Layer 2 pose problème. La majorité des Rollups dépendent d’un seul séquencer, ce qui peut conduire à la censure ou à l’exploitation du MEV. La solution « Based Rollup » propose d’utiliser le proposeur L1 pour ordonner les transactions, hérité de la décentralisation de L1.

Mais cela introduit un délai : Layer 2 doit attendre que le bloc L1 soit publié, ce qui nuit à l’expérience utilisateur. La pré-confirmation, où le Gateway Layer 2 reçoit une promesse du proposeur, permettrait de réduire ce délai. Cependant, dans le mécanisme actuel, il est difficile de savoir qui sera le proposeur à l’avance.

Solution : EIP-7917 modifie le protocole de consensus pour rendre l’ordre des proposeurs futur déterminé et public, en établissant une « table de rotation » prévisible.

Signification : Avec cette « table de rotation », le Gateway Layer 2 pourra anticiper le proposeur d’un futur bloc, négocier à l’avance, et obtenir une pré-confirmation fiable, renforçant la décentralisation tout en offrant une expérience proche de celle d’un séquencer centralisé.

Pourquoi Fusaka arrive-t-il à point nommé ?

Ce lancement n’est pas seulement une évolution technique, mais aussi une étape stratégique pour Ethereum dans le contexte de la finance traditionnelle, avec le déploiement massif d’actifs via RWA et stablecoins. Aujourd’hui, Ethereum supporte plus de 56 % de l’offre mondiale de stablecoins, devenant la couche de règlement principale de l’économie dollar numérique mondiale. Fusaka vise à préparer cette infrastructure pour accueillir des actifs et des volumes de transactions de « niveau Wall Street ».

• Pour des Layer 2 institutionnels, avec une capacité d’extension infinie

Avec l’arrivée des institutions financières, on verra émerger des Layer 2 « spécialisés » pour répondre à des besoins précis (KYC, conformité). Ces chaînes nécessitent un stockage de données massif, peu coûteux et sécurisé, fourni par la chaîne principale Ethereum.

Les propositions EIP-7594, EIP-7892 et EIP-7918 répondent à cette demande. Leur objectif est de réduire drastiquement le coût de publication des données Layer 2, tout en offrant une extension flexible à la demande.

Après Pectra, le coût des blobs est déjà très bas. Pourquoi continuer à le réduire ? Parce que Fusaka adopte une stratégie de « casser la recette à court terme pour stimuler une activité économique plus grande ». L’objectif est d’accroître le PIB global du réseau, en favorisant plus de transactions, de staking, et de destruction d’ETH, pour soutenir la valeur du réseau.

• Pour atteindre la sécurité d’un trillion de dollars, bâtir une infrastructure financière invulnérable

Pour les institutions gérant des actifs d’un trillion de dollars, la sécurité est essentielle. Le « Plan de sécurité d’un trillion de dollars » d’Ethereum vise à renforcer cette sécurité. Plusieurs EIP dans Fusaka, comme des « barrières et protections », participent à cette ambition.

En résumé, la ligne directrice de Fusaka est claire : scalabilité et sécurité. Avec un contexte réglementaire favorable et une forte dynamique de marché, cette mise à jour arrive à point nommé. Elle aidera Ethereum à saisir les opportunités réglementaires, à consolider sa position dans la finance décentralisée et à évoluer vers une infrastructure financière principale, loin de l’image de simple actif spéculatif.

Conclusion : une transformation discrète mais profonde

En cette fin d’année 2025, Fusaka, sans fanfare ni hype, insuffle une dynamique forte à Ethereum. Les 12 améliorations ciblent directement les trois grands défis : scalabilité, sécurité, efficacité. Elles élargissent la « route de la valeur » d’Ethereum, augmentant sa capacité et sa fiabilité, pour accueillir un volume massif d’utilisateurs, d’actifs et d’applications.

Pour l’utilisateur lambda, ces changements peuvent sembler « silencieux », mais leur impact sera profond. Un Ethereum plus puissant, plus efficace, plus sûr, pourra réaliser des visions autrefois inimaginables — que ce soit un réseau mondial de règlements instantanés ou une « Wall Street chainée ». Fusaka est une étape solide vers ce futur.