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

Auteur : @ChromiteMerge

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

Scalabilité ! Faire fonctionner Ethereum plus vite et accueillir plus de transactions

C’est le thème central de la mise à niveau Fusaka. Pour supporter l’économie numérique mondiale, Ethereum doit résoudre les problèmes de congestion 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 à la scalabilité de Layer 2.

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

Problème : Depuis l’introduction des « blobs » 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), le téléchargement et la vérification de tous ces blobs entraîneront des coûts élevés, augmentant la barrière à la participation des validateurs et menaçant la décentralisation.

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

2. Le réseau divise les blobs en fragments.

3. Chaque validateur n’a pas besoin de télécharger tous les blobs, mais seulement quelques fragments choisis aléatoirement.

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 détient quelques pièces, mais en vérifiant les connexions clés, tout le puzzle peut être confirmé comme 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 de la scalabilité d’Ethereum.

Signification : PeerDAS réduit considérablement la charge de stockage pour les validateurs, facilitant la scalabilité massive d’Ethereum tout en préservant la décentralisation. À l’avenir, chaque bloc pourrait contenir des centaines de blobs, soutenant la vision de Teragas avec jusqu’à 10 millions de TPS, tout en permettant à des utilisateurs ordinaires de faire fonctionner facilement des validateurs.

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

Problème : La demande de capacité de données pour Layer 2 évolue rapidement. Attendre une mise à niveau majeure 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 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 : Le mécanisme 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 expansion « à la demande » et « élastique » de l’espace blob, 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 « flottant », provoquant des fluctuations extrêmes. 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 prix excessifs. Cette « compétition interne » des prix complique la planification des coûts pour Layer 2.

Solution : L’EIP 7918 propose de fixer une fourchette de prix pour les frais de blobs, en la liant aux frais d’exécution (execution fee) sur Layer 1. Peu importe si l’on met à jour la racine d’état ou si l’on vérifie une preuve ZK, ces frais restent relativement stables et peu dépendants du volume de transactions L2. En liant la fourchette des frais de blobs à cet « ancrage » stable, on évite les fluctuations extrêmes.

Signification : Cette amélioration empêche la « compétition interne » des frais de blobs, rendant les coûts opérationnels de Layer 2 plus prévisibles. Les projets Layer 2 peuvent ainsi fixer des frais plus stables pour les utilisateurs, évitant une expérience de type « gratuit aujourd’hui, prix exorbitant demain ».

EIP-7935 : Augmentation de la capacité transactionnelle principale

Problème : La capacité maximale d’un bloc Ethereum dépend du « plafond de gas » (actuellement environ 30 millions), qui n’a pas été ajusté depuis longtemps. Pour augmenter le débit global, il faut augmenter ce plafond, tout en garantissant que cela ne renforce pas la centralisation ni ne nécessite du matériel plus coûteux pour les validateurs.

Solution : La proposition recommande d’augmenter le plafond 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 une acceptation progressive par les validateurs.

Signification : Chaque bloc pourra contenir plus de transactions, augmentant directement le TPS d’Ethereum, et atténuant congestion et coûts. Cependant, cela exige aussi des validateurs plus puissants, donc la communauté procédera prudemment.

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

En même temps que la scalabilité, il faut garantir la sécurité et la stabilité du réseau. En mai 2025, la Fondation Ethereum 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 ce plan, comme des « freins » et « garde-fous » pour une conduite sûre.

EIP-7934 : Fixation d’une limite physique de taille de bloc

Problème : Le « plafond de gas » ne limite que la charge de calcul dans un bloc, mais pas sa taille physique. Un attaquant peut ainsi créer un « bloc bombe » avec beaucoup de données peu coûteuses (par exemple, des transferts 0 ETH vers de nombreux adresses), qui, bien que peu coûteux en calcul, sont énormes en volume. Ces blocs ralentissent la propagation du réseau et peuvent 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 trop volumineux n’entravent 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 le plafond de gas par bloc existe, il n’y a pas de limite pour une seule transaction. Un utilisateur pourrait soumettre une transaction consommant presque tout le gas disponible, bloquant ainsi les autres.

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

Signification : Cela améliore l’équité et la prévisibilité, empêchant une seule transaction de monopoliser le réseau ou de causer des retards excessifs.

EIP-7823 & EIP-7883 : Renforcement de la sécurité de ModExp

Problème : ModExp, utilisé pour les opérations cryptographiques, peut être exploité par des entrées de longueur illimitée ou des coûts de calcul faibles, ce qui peut entraîner des attaques par déni de service.

Solutions :

• EIP-7823 : Limiter la longueur des entrées à 8192 bits.

• EIP-7883 : Augmenter le coût en gas pour les grandes entrées, pour que le coût reflète la consommation de ressources.

Signification : Ces deux mesures éliminent une vulnérabilité potentielle, en fixant une « taille maximale » et en ajustant le prix, pour rendre l’utilisation de ModExp plus sûre et plus robuste.

Fonctionnalités pour les développeurs ! Outils puissants 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 sur Ethereum plus efficace et plus puissante.

EIP-7951 : Compatibilité avec les signatures matérielles grand public

Problème : Les appareils courants comme iPhone, U-Shield bancaire ou modules de sécurité hardware utilisent souvent la norme de cryptographie secp256r1 (P-256), alors qu’Ethereum utilise par défaut secp256k1. Cela limite l’interopérabilité avec ces appareils.

Solution : Ajouter un contrat précompilé permettant à Ethereum de supporter et de 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 matériels. À l’avenir, vous pourrez signer des transactions Ethereum directement avec la puce de sécurité de votre téléphone, sans applications supplémentaires ou conversions compliquées. Cela réduit la barrière d’accès et favorise la fusion Web2/Web3.

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

Problème : Dans les applications cryptographiques et de ZK, il est souvent nécessaire de compter le nombre de bits zéro en tête d’un nombre 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 : Cela fournit aux développeurs un outil spécialisé, réduisant considérablement le coût en gas pour ces opérations, et rendant plus efficaces les applications dépendant de mathématiques complexes, notamment ZK Rollups.

Optimisation du réseau ! Améliorations invisibles pour un écosystème plus sain

Les deux dernières EIP, moins perceptibles pour l’utilisateur, sont essentielles pour la santé à long terme et la coordination du réseau.

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

Problème : Avec le temps, Ethereum accumule une énorme quantité de données historiques. Synchroniser un nouveau nœud devient long et coûteux. Après la transition vers PoS (The Merge), certains champs dans les reçus de transaction sont devenus inutiles, créant de la redondance.

Solution : Introduire une stratégie d’expiration de l’historique, permettant aux nouveaux nœuds de sauter certains vieux données, et simplifier le format des reçus pour supprimer les champs inutiles. La synchronisation depuis le bloc genesis sera ainsi plus légère.

Signification : Réduire la taille de la synchronisation d’environ 530 Go, rendant plus facile la participation de plus de nœuds, renforçant la décentralisation et la résilience du réseau.

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

Problème : La centralisation du séquencement (sequencer) dans Layer 2 Rollup pose problème. La majorité dépend d’un seul acteur pour ordonner les transactions, ce qui va à l’encontre de la décentralisation. La solution « Based Rollup » propose d’utiliser le proposer L1 pour ordonner, mais cela introduit un délai important.

Pour réduire ce délai, il faut une « pré-confirmation » : que le gateway Layer 2 puisse obtenir à l’avance une promesse du proposeur L1, garantissant qu’il inclura la transaction, permettant ainsi de mettre à jour l’état en avance.

Problème actuel : La sélection du proposeur est aléatoire, le gateway ne sait pas à l’avance qui sera le proposeur.

Solution : EIP-7917 modifie le protocole de consensus pour rendre la séquence des proposeurs future déterministe et publique, en établissant une « grille » de propositions à l’avance.

Signification : Cette avancée est essentielle pour réaliser des solutions comme Based Rollup. La « grille » permet aux passerelles Layer 2 d’identifier à l’avance le proposeur, de négocier et d’obtenir une pré-confirmation fiable, tout en conservant la sécurité et la décentralisation de L1. Cela ouvre la voie à une nouvelle génération de solutions de scalabilité décentralisées, avec une expérience utilisateur quasi instantanée.

Pourquoi Fusaka arrive-t-il au bon moment ?

Cette mise à jour Fusaka n’est pas seulement une évolution technique, c’est aussi une étape stratégique dans un contexte où Ethereum voit une adoption massive de RWA (actifs réels) et de stablecoins en chaîne. Ethereum supporte déjà 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 Ethereum à accueillir des actifs et des volumes de transactions de niveau « Wall Street ».

• Pour des Layer 2 institutionnels, avec une scalabilité infinie

Avec l’arrivée des institutions financières, on verra apparaître des Layer 2 « dédiés » à des besoins spécifiques (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 principal : réduire drastiquement le coût de publication des données Layer 2, tout en permettant une expansion flexible à la demande.

Après Pectra, les frais de blobs sont déjà très faibles, pourquoi continuer à les réduire ? Parce que Fusaka adopte une stratégie de « sacrifice des revenus à court terme pour une croissance économique plus grande », visant à augmenter le PIB global du réseau, en transformant plus de transactions en staking et en destruction d’ETH, soutenant ainsi la valeur du réseau.

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

Pour les institutions détenant des actifs d’un trillion de dollars, la sécurité est une priorité absolue. La communauté Ethereum a fixé l’objectif d’une « sécurité d’un trillion de dollars ». Les EIP dans Fusaka, comme EIP-7934, EIP-7825, EIP-7823 et EIP-7883, renforcent cette ambition en consolidant la sécurité du réseau.

En résumé, la ligne directrice de Fusaka est claire : scalabilité et sécurité. Avec le soutien des politiques et du marché, Fusaka arrive à point nommé. Elle aidera Ethereum à saisir les opportunités réglementaires, à renforcer sa position dans le domaine des stablecoins et des actifs en chaîne, et à évoluer d’un « actif spéculatif » vers une infrastructure financière principale.

Conclusion : Une transformation discrète mais profonde

En tant que mise à jour majeure de fin 2025, Fusaka, sans fanfare ni hype, injecte silencieusement une forte dynamique à Ethereum. Les 12 améliorations ciblent directement les trois grands défis : scalabilité, sécurité et efficacité. Elles élargissent l’autoroute de la valeur d’Ethereum, augmentent sa capacité et sa fiabilité, et préparent le terrain pour une adoption massive future.

Pour l’utilisateur lambda, ces changements peuvent sembler « silencieux », mais leur impact sera profond. Un Ethereum plus puissant, plus efficace et 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 sur chaîne ». Fusaka est une étape solide vers cet avenir.