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

Auteur : @ChromiteMerge

Ethereum s’apprête à recevoir une mise à niveau de hard fork appelée « Fusaka » 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 amélioreront ensemble 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 l’économie numérique mondiale, Ethereum doit résoudre les problèmes de congestion des transactions et de coûts élevés. Les EIP suivants visent précisément cet objectif, notamment en réduisant les coûts pour la scalabilité Layer 2.

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

Problème : Après 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. Quand un bloc peut contenir jusqu’à 9 blobs, cette méthode reste viable. Mais si le nombre de blobs augmente (par exemple à 128), télécharger et vérifier tous les 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 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 à jour légère des paramètres

Problème : La demande de capacité de données Layer 2 fluctue rapidement. Attendre une mise à niveau majeure comme Fusaka pour ajuster la limite de blobs est lent et ne suit 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). Ce type de mise à jour est 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 client, ils acceptent simplement les nouveaux paramètres à une date précise, comme une mise à jour de configuration en ligne.

Signification : Le mécanisme BPO donne à Ethereum la capacité d’ajuster rapidement et en toute sécurité la capacité du réseau. Par exemple, après Fusaka, la communauté prévoit d’effectuer deux BPO successifs pour doubler la capacité des blobs. Cela permet à Ethereum d’étendre la capacité blob de façon « élastique » et progressive, avec un risque maîtrisé, pour faire croître la capacité et le débit Layer 2 en douceur.

EIP-7918 : Marché stable des frais de blobs

Problème : Le mécanisme précédent d’ajustement des frais blobs était trop « dicté par le marché », ce qui causait des extrêmes : lorsque la demande était faible, les frais tombaient presque à zéro, sans stimuler la demande nouvelle, créant un « prix plancher » historique. Lorsqu’elle était forte, les frais montaient en flèche, créant une volatilité extrême. Ce « jeu de montagnes russes » compliquait la planification des coûts pour Layer 2.

Solution : L’EIP 7918 propose de fixer une fourchette de prix raisonnable pour les frais blobs, avec un « coût minimum » flexible. La clé est de lier ces limites (minimum et maximum) aux frais d’exécution (execution fee) sur Layer 1, qui eux, restent relativement stables et peu liés au volume de transactions Layer 2. En attachant la fourchette des frais blobs à cette « ancre » stable, on évite les fluctuations excessives.

Signification : Cette amélioration empêche le marché des frais blobs de devenir une « course à l’abîme », rendant les coûts Layer 2 plus prévisibles. Les opérateurs de Layer 2 peuvent ainsi proposer des frais plus stables et raisonnables, évitant des expériences de « gratuit aujourd’hui, prix exorbitant demain ».

EIP-7935 : Augmentation de la capacité transactionnelle principale

Problème : La capacité de transaction par bloc Ethereum est limitée par le « plafond de gas » (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 n’exige du matériel trop puissant 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 progressivement l’acceptation d’un plafond plus élevé par les validateurs.

Signification : Cela permettrait d’inclure plus de transactions par bloc, augmentant le TPS d’Ethereum, et réduisant congestion et coûts. Cependant, cela exige aussi que les validateurs disposent d’un matériel plus performant, ce qui sera testé avec prudence.

Sécurité et stabilité ! Renforcer la défense du réseau

Tout en scalant, 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 à construire un réseau capable de sécuriser des actifs d’un trillion de dollars. Plusieurs EIP de Fusaka soutiennent cette ambition, comme des « freins » et « garde-fous » pour la sécurité.

EIP-7934 : Fixer la taille physique maximale d’un bloc

Problème : La limite de gas d’un bloc ne concerne que la charge de calcul, pas la taille physique du bloc. Un attaquant pourrait créer un « bloc bombes à données » : beaucoup de transactions à faible coût mais volumineuses (par exemple, des transferts de 0 ETH vers de nombreux adresses), qui, tout en respectant la limite de gas, seraient énormes en taille physique. Ces blocs ralentiraient la propagation, risquant de faire perdre des nœuds ou de provoquer des attaques DoS.

Solution : Fixer une limite physique stricte 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, pour éviter qu’un « véhicule surdimensionné » ne bloque la circulation. Cela garantit une propagation rapide, réduit la latence et renforce la résilience du réseau.

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 17,77 millions de gas par transaction. Les transactions complexes doivent être divisées en plusieurs parties si elles dépassent cette limite.

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

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

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

Solution :

• EIP-7823 : Limiter la longueur de l’entrée à 8192 bits, ce qui est suffisant pour la plupart des usages.

• EIP-7883 : Augmenter le coût en gas pour les grands calculs, pour dissuader les abus.

Signification : Ces deux mesures éliminent une vulnérabilité potentielle, comme fixer une « taille maximale de tâche » et appliquer une « tarification progressive » pour éviter l’abus, renforçant la robustesse du réseau.

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

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

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

Problème : Les appareils courants comme iPhone, tokens de banque, modules de sécurité hardware utilisent souvent la norme de cryptographie secp256r1 (P-256). Mais Ethereum utilise par défaut secp256k1, ce qui empêche ces appareils de signer directement sur Ethereum, limitant la diffusion de Web3.

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 porte à une intégration plus facile avec des milliards d’appareils hardware. À 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, favorise la fusion Web2/Web3, et améliore la sécurité.

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

Problème : Dans les applications cryptographiques et de compression, 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) dans l’EVM, pour faire cette opération en une seule étape.

Signification : C’est comme fournir un outil spécialisé pour les développeurs, réduisant la consommation de gas et rendant les calculs mathématiques complexes plus abordables, notamment pour les ZK Rollups.

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

Les deux derniers EIP, moins perceptibles pour l’utilisateur, sont essentiels pour la santé à long terme et la coordination du réseau.

EIP-7642 : Réduire 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 difficile. 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 des données historiques, permettant aux nouveaux nœuds de sauter certains vieux blocs, et simplifier le format des reçus pour supprimer les champs inutiles. Ainsi, la synchronisation depuis la genèse sera plus rapide.

Signification : Cela « allège » le nœud, réduisant d’environ 530 Go la quantité de données à télécharger, rendant plus accessible l’opération de validation complète, renforçant la décentralisation.

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

Problème : La centralisation du séquencement (sequencer) dans Layer 2 est un problème : un seul acteur contrôle la réception et le tri des transactions, ce qui peut mener à la censure ou à l’exploitation de 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 solution est la « pré-confirmation » : le gateway Layer 2 peut obtenir une promesse du proposeur L1, garantissant que la transaction sera incluse, permettant d’anticiper la mise à jour de l’état.

Mais, dans le mécanisme actuel de sélection aléatoire, le gateway ne sait pas à qui s’adresser pour cette promesse.

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

Signification : Cette avancée est clé pour réaliser des solutions comme Based Rollup. Avec cette « grille », le gateway peut identifier à l’avance le proposeur, négocier une pré-confirmation fiable, et ainsi rapprocher Layer 2 d’un fonctionnement décentralisé et instantané, tout en conservant la sécurité de L1.

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

Ce dernier Fusaka n’est pas seulement une mise à jour technique, c’est aussi une étape stratégique dans le contexte où Ethereum, via RWA et stablecoins, devient la couche de règlement principale pour l’économie mondiale. Ethereum détient plus de 56 % de l’offre mondiale de stablecoins, devenant la plateforme de référence pour le dollar numérique.

L’objectif de Fusaka est de préparer Ethereum à accueillir des actifs et des volumes de transactions « Wall Street » :

• Créer des chaînes Layer 2 sur mesure pour les institutions, avec une capacité d’expansion 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, 7892, 7918 de Fusaka répondent à cette demande. Leur but est de réduire drastiquement le coût de publication des données Layer 2, tout en offrant une scalabilité flexible.

• Vers un « sécurité d’un trillion de dollars », pour une infrastructure financière invulnérable

Les institutions gérant des actifs d’un trillion de dollars ont besoin d’une sécurité absolue. La vision « sécurité d’un trillion » est une ambition. Les EIP 7934, 7825, 7823, 7883 de Fusaka renforcent cette ambition, en consolidant la sécurité et en éliminant les vulnérabilités potentielles.

En résumé, Fusaka repose sur deux axes : scalabilité et sécurité. Avec le soutien des politiques et du marché, cette mise à jour arrive à point nommé. Elle aidera Ethereum à saisir les opportunités réglementaires, à renforcer sa position dans la finance stable et d’actifs, et à évoluer d’un « actif spéculatif » vers une infrastructure financière principale.

Conclusion : une transformation profonde en douceur

En tant que mise à jour majeure de fin 2025, Fusaka, sans fanfare ni hype, insuffle une dynamique forte à Ethereum. Ses 12 améliorations ciblent directement les trois grands défis : scalabilité, sécurité, efficacité. Elle élargit la « voie rapide » de la valeur d’Ethereum, augmente sa capacité et sa fiabilité, pour accueillir un futur avec des millions d’utilisateurs, actifs et 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 imaginables : un réseau mondial de règlements instantanés, ou une « Wall Street chainée » sur la blockchain. Fusaka est une étape solide vers ce futur.

• Cet article repose sur des informations publiques, ne constitue pas un conseil en investissement. La cryptomonnaie comporte des risques importants, faites preuve de prudence et DYOR._

• Si vous avez aimé cet article, n’hésitez pas à suivre, liker et partager !