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 est sur le point de subir 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), qui sont comme 12 pièces de précision : elles amélioreront ensemble la scalabilité, la sécurité et l’efficacité d’exécution d’Ethereum. Ci-dessous, l’auteur décrypte, dans un langage accessible, ce que chacune de ces 12 EIP résout et pourquoi elles sont cruciales pour l’avenir d’Ethereum.

Scalabilité ! Pour qu’Ethereum aille plus vite et en fasse plus

C’est le thème central de la mise à niveau Fusaka. Pour qu’Ethereum puisse porter l’économie numérique mondiale, il doit résoudre les problèmes de congestion des transactions et de frais élevés. Les EIP suivantes visent précisément cet objectif, en particulier en se concentrant sur la réduction des coûts et l’amélioration de l’efficacité du scaling pour Layer 2.

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

Point douloureux : depuis que la mise à niveau Dencun a introduit le « Blob » de données pour fournir à Layer 2 un stockage de données à faible coût, un problème clé est apparu : comment s’assurer que ces volumes massifs de données sont réellement disponibles ? Actuellement, la méthode consiste à demander à chaque nœud validateur de télécharger et de vérifier tous les blob d’un bloc. Lorsque chaque bloc peut contenir au maximum 9 Blob, cette approche reste viable. Mais si, à l’avenir, le nombre de Blob augmente encore (par exemple 128), télécharger et vérifier l’ensemble des blob entraînerait des coûts élevés, ce qui augmenterait le seuil de participation des nœuds validateurs et menacerait la décentralisation du réseau.

Solution : PeerDAS (Peer Data Availability Sampling) transforme la vérification traditionnelle « tout vérifier » en « échantillonnage ». Dit simplement :

2. Le réseau découpe les données de blob complètes en tranches.

3. Chaque validateur n’a pas besoin de télécharger l’ensemble des blob ; il lui suffit de télécharger et de vérifier au hasard quelques fragments de données.

4. Ensuite, tout le monde confirme collectivement l’intégrité et la disponibilité de l’ensemble des blob en procédant à des contrôles mutuels et en échangeant les résultats de validation.

C’est comme un grand jeu de puzzle : chacun n’a que quelques pièces en main, mais tant que tout le monde vérifie les connexions clés entre les pièces, on peut déterminer si l’image complète est intacte. À noter : PeerDAS n’est pas une invention entièrement nouvelle ; l’idée centrale de DAS a déjà été mise en pratique avec succès dans des projets tiers de DA comme Celestia. L’implémentation de PeerDAS ressemble davantage à un « dette technique » essentiel qu’on viendrait combler pour la feuille de route de scalabilité à long terme d’Ethereum.

Signification : PeerDAS réduit considérablement la charge de stockage des validateurs et lève les obstacles qui pourraient affaiblir la décentralisation pour permettre à Ethereum d’atteindre une scalabilité massive des données. À l’avenir, chaque bloc pourrait contenir des centaines de Blob, ce qui soutiendrait la vision Teragas revendiquant jusqu’à 10 millions de TPS, tout en permettant aussi aux utilisateurs ordinaires d’exécuter facilement des validateurs, maintenant ainsi la décentralisation du réseau.

EIP-7892 : Hard fork BPO - Mise à jour allégée des paramètres

Point douloureux : la demande du marché en capacité de données pour Layer 2 évolue à une vitesse fulgurante. Si, à chaque ajustement de la limite supérieure du nombre de Blob, il faut attendre une grande mise à jour comme Fusaka, ce serait trop lent et cela ne suivrait pas le rythme du développement de l’écosystème.

Solution : cet EIP définit un mécanisme spécial de « hard fork dédié aux paramètres des Blob » ( Blob Parameter Only Hardfork, BPO ). Cette mise à jour est très légère : elle modifie seulement quelques paramètres liés aux Blob (par exemple le nombre cible de Blob par bloc), sans impliquer de changements de code complexes. Les opérateurs de nœuds n’auraient même pas besoin de mettre à niveau le logiciel client : ils n’auraient qu’à accepter de nouveaux paramètres à l’heure indiquée, comme mettre simplement à jour un fichier de configuration en ligne pour un logiciel.

Signification : le mécanisme BPO permet à Ethereum de régler rapidement et en toute sécurité la capacité du réseau. Par exemple, après cette mise à niveau Fusaka, la communauté prévoit d’exécuter deux mises à niveau BPO consécutives sur une période courte, augmentant progressivement la capacité des Blob jusqu’au double. Cela permet à Ethereum de scaler l’espace de Blob de manière élastique, à la demande et progressivement, afin d’améliorer de façon plus fluide les coûts du L2 et le débit, tout en gardant le risque sous contrôle.

EIP-7918 : Marché des frais de Blob stabilisé

Point douloureux : le mécanisme d’ajustement des frais de Blob était trop « suiveur du marché », ce qui entraîne certains problèmes inattendus. D’abord, lorsque la demande de Blob est très faible, les frais chutent à presque zéro, ce qui ne stimule pas efficacement une nouvelle demande : cela crée au contraire un prix historiquement « plancher » anormal. Inversement, lorsque la demande est forte, le blob fee grimpe fortement, créant un autre extrême : un prix très élevé. Cette « concurrence par les prix » (internalisation) fait que la planification des frais du Layer 2 devient difficile.

Solution : l’idée centrale de l’EIP-7918 est de ne plus laisser les frais de Blob fluctuer sans limite, mais de leur définir une plage de prix raisonnable, c’est-à-dire une « consommation minimale » élastique. Concrètement, les limites supérieure et inférieure (limits) du blob fee sont liées aux frais d’exécution (execution fee) du Layer 2 sur Layer 1. Que ce soit la mise à jour d’une racine d’état (state root) ou la vérification d’une preuve ZK, ces frais d’exécution sont relativement stables et ont peu de rapport avec la relation entre le blob fee et le volume de transactions dans les blocs du L2. Ainsi, l’ancrage des bornes du blob fee à ce « repère » stable évite qu’il ne fasse le yo-yo.

Signification : l’avantage direct de cette amélioration est d’empêcher la « concurrence par les prix » du marché des frais de Blob, et de rendre les modèles de coûts d’exploitation des projets Layer 2 plus prévisibles. Ainsi, le Layer 2 peut fixer aux utilisateurs finaux des frais de transaction plus stables et plus raisonnables, évitant l’expérience de montagnes russes « gratuit aujourd’hui, demain hors de prix ».

EIP-7935 : Augmenter la capacité de transactions du réseau principal

Point douloureux : le nombre total de transactions que chaque bloc Ethereum peut contenir est déterminé par « la limite de Gas du bloc » (actuellement environ 30 millions) et n’a pas été ajustée depuis des années. Pour augmenter le débit global du réseau, le moyen le plus direct consiste à relever cette limite, mais il faut s’assurer de ne pas augmenter le seuil matériel des nœuds validateurs et de ne pas affaiblir la décentralisation.

Solution : la proposition recommande d’augmenter la limite de Gas par défaut du bloc vers un nouveau niveau (valeur précise à déterminer ; possiblement 45 millions ou plus). Il ne s’agit pas d’un verrouillage obligatoire : il s’agit de fournir une nouvelle valeur par défaut recommandée, afin d’amener progressivement les validateurs de la couche de consensus à accepter une limite de Gas plus élevée.

Signification : cela signifie que chaque bloc Layer 1 peut regrouper davantage de transactions. Les TPS du réseau principal d’Ethereum seront donc améliorés directement, et la congestion du réseau ainsi que l’explosion des frais Gas seront atténuées. Bien sûr, cela impose aussi des exigences matérielles plus élevées aux validateurs ; c’est pourquoi la communauté procédera à des tests et à une progression prudente.

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

En parallèle de la scalabilité, il faut garantir la sécurité et la stabilité du réseau. La Fondation Ethereum a lancé en mai 2025 le « plan de sécurité de un billion de dollars » (Trillion Dollar Security, 1TS), visant à établir un réseau Ethereum capable de supporter en toute sécurité des actifs de l’ordre du billion de dollars. Plusieurs EIP dans Fusaka participent à la progression du plan 1TS, un peu comme installer des freins plus fiables et des garde-fous sur un Ethereum roulant à grande vitesse.

EIP-7934 : Définir une limite de taille physique des blocs

Point douloureux : la « limite de Gas du bloc » d’Ethereum ne s’intéresse qu’à la quantité totale de calcul de toutes les transactions dans le bloc, sans définir la taille physique du bloc. Cela crée une faille : un attaquant peut construire soigneusement un grand nombre de transactions « faible coût, grande taille » (par exemple transférer 0 ETH à un grand nombre d’adresses : la charge de calcul est très faible, mais la quantité de données est énorme). Il peut ainsi générer un bloc qui n’est pas en dépassement de calcul, mais dont le volume physique est anormalement grand. Ces blocs « bombe de données » se propagent très lentement sur le réseau, et peuvent empêcher certains nœuds de recevoir les données à temps et de décrocher, créant un risque sérieux d’attaque DoS (refus de service).

Solution : fixer une limite stricte de 10 MB à la taille de chaque bloc. Tout bloc dépassant ce volume sera rejeté par le réseau.

Signification : c’est comme fixer la taille maximale des camions sur l’autoroute afin d’empêcher des véhicules trop larges ou trop longs d’entraver la circulation. Cela garantit que les blocs se propagent rapidement dans le réseau, réduit la latence et améliore la stabilité du réseau ainsi que sa résistance aux attaques.

EIP-7825 : Définir une limite de Gas pour une transaction unique

Point douloureux : actuellement, bien que les blocs aient une limite totale de Gas, les transactions individuelles n’en ont pas. En théorie, quelqu’un pourrait construire une transaction qui consomme presque toutes les ressources du bloc, éjectant ainsi les transactions de tous les autres participants. C’est injuste et cela comporte aussi un risque pour la sécurité.

Solution : fixer une limite stricte de 16 770 000 Gas pour chaque transaction. Les opérations complexes dépassant cette taille doivent être préalablement découpées en plusieurs transactions avant d’être soumises.

Signification : cela améliore l’équité et la prévisibilité du réseau, en s’assurant qu’aucune transaction ne puisse « prendre toute la place ». Les transactions ordinaires des utilisateurs ne seront pas excessivement retardées à cause d’un « gros dossier » (super grosse commande).

EIP-7823 & EIP-7883 : Renforcement de la sécurité du ModExp via précompilé

Point douloureux : ModExp est une fonctionnalité d’Ethereum utilisée pour traiter des opérations modulaires d’exponentiation de grands nombres, courantes dans certaines applications cryptographiques. Mais il présente deux risques : d’une part, la longueur des nombres en entrée n’a pas de limite, ce qui permet de fabriquer des entrées extrêmement grandes par malveillance « pour exploser » ; d’autre part, le barème de frais Gas de ModExp est trop bas, ce qui peut permettre à un attaquant de l’appeler massivement à faible coût et de consommer les ressources des nœuds.

Solution :

• EIP-7823 : fixer une limite de 8192 bits pour la longueur des entrées de ModExp ; cette longueur est largement suffisante pour les besoins des applications réelles.

• EIP-7883 : augmenter les frais Gas de ModExp, en particulier pour des entrées plus grandes : les frais augmentent de façon drastique, afin que le coût de calcul corresponde aux ressources consommées.

Signification : ces deux améliorations prennent le problème à la fois sur la longueur et sur les coûts, en supprimant un vecteur d’attaque potentiel. C’est comme définir à un service de calcul à la fois un « volume maximum de tâches » et ajuster les « tarifs par paliers », afin d’empêcher les abus et ainsi renforcer la robustesse globale du réseau.

Mise à niveau fonctionnelle ! Fournir des outils plus puissants aux développeurs

Outre la scalabilité et la sécurité, Fusaka apporte aux développeurs de nouveaux outils et fonctionnalités pratiques, rendant la construction d’applications sur Ethereum plus efficace et plus puissante.

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

Point douloureux : les appareils que nous utilisons au quotidien, comme les téléphones (par exemple iPhone), les U-dispositifs de banque (U盾), les modules de sécurité matériels, etc., intègrent généralement une puce de sécurité utilisant un standard cryptographique nommé secp256r1 (aussi appelé P-256). Or, par défaut, Ethereum utilise un autre standard : secp256k1. Cela empêche ces appareils grand public d’interagir directement de manière sécurisée avec Ethereum, ce qui limite l’adoption massive de Web3.

Solution : ajouter un contrat précompilé afin qu’Ethereum puisse nativement prendre en charge et valider des signatures provenant de la courbe secp256r1.

Signification : c’est une amélioration marquante. Elle ouvre la porte d’Ethereum à des milliards d’appareils matériels dans le monde. À l’avenir, vous pourrez directement signer des transactions Ethereum avec la puce de sécurité de votre téléphone, sans application de portefeuille supplémentaire ni conversions complexes. L’expérience sera plus fluide et la sécurité meilleure. Cela réduit fortement le seuil d’accès d’une partie du monde réel à Ethereum, et constitue un avantage majeur pour la convergence entre Web2 et Web3.

EIP-7939 : Ajout d’une instruction de calcul efficace CLZ

Point douloureux : dans les applications de contrats intelligents et de cryptographie, il faut souvent calculer combien de bits nuls consécutifs se trouvent au début d’un nombre sur 256 bits (par exemple dans des scénarios comme des algorithmes de hachage, des algorithmes de compression, des preuves à connaissance nulle, etc.). À l’heure actuelle, l’EVM d’Ethereum ne dispose pas d’un Opcode direct pour cette opération. Les développeurs doivent donc utiliser un code Solidity complexe, ce qui coûte cher et est inefficace.

Solution : ajouter dans l’EVM un Opcode nommé « CLZ » (Count Leading Zeros), permettant d’effectuer le calcul en une seule étape.

Signification : c’est comme fournir aux développeurs un outil professionnel qui fait gagner du temps et des efforts. Il peut réduire de manière significative les coûts Gas des opérations concernées, afin que des applications qui s’appuient sur des calculs mathématiques complexes (notamment les ZK Rollups) fonctionnent de façon moins coûteuse et plus efficace.

Optimisation du réseau ! Des améliorations invisibles, pour un écosystème plus sain

Les deux dernières EIP ont une perception faible côté utilisateur, mais sont cruciales pour la bonne santé à long terme du réseau et pour l’efficacité de la coordination.

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

Point douloureux : avec le temps, Ethereum accumule d’énormes quantités de données historiques. Un nouveau nœud qui rejoint le réseau doit télécharger et synchroniser toutes ces données, ce qui prend beaucoup de temps et rend l’accès de plus en plus difficile, augmentant le seuil. De plus, depuis la transition de Ethereum vers le consensus PoS après The Merge, certains champs des anciens enregistrements de réception de transactions ne sont plus nécessaires, ce qui crée une redondance.

Solution : introduire une stratégie « expiration des données historiques », afin que les nouveaux nœuds puissent sauter certaines données trop anciennes pendant la synchronisation ; en parallèle, simplifier le format des receipts de transaction en retirant les champs redondants qui ne sont plus nécessaires. Ainsi, lorsqu’un nouveau nœud synchronise depuis le bloc de genèse, il peut éviter de télécharger une grande quantité de données inutiles.

Signification : cette amélioration permet de faire « maigrir » l’exécution des nœuds : à chaque synchronisation full node, environ 530GB de transfert de données peuvent être réduits. Un seuil plus bas signifie que davantage de personnes pourront exécuter des nœuds, et la décentralisation ainsi que la robustesse du réseau seront renforcées.

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

Point douloureux : pour comprendre l’importance de cet EIP, il faut d’abord parler d’un problème central actuel des Rollups de Layer 2 : les séquenceurs centralisés (Sequencer). À l’heure actuelle, la plupart des Rollups s’appuient sur une entité unique pour recevoir et ordonner les transactions L2 des utilisateurs. Cela lui confère le pouvoir de censurer des transactions et d’extraire du MEV, ce qui va à l’encontre de l’esprit de décentralisation. Pour résoudre ce problème, la communauté a proposé l’idée de Based Rollup : abandonner tout simplement le séquenceur propre au L2, et utiliser directement le Proposer du bloc de l’Ethereum L1 pour ordonner les transactions L2, afin d’hériter de la décentralisation et de la neutralité de L1.

Cependant, ce schéma a un défaut fatal : être lent. Layer2 doit attendre que les blocs soient enregistrés sur L1 avant de commencer l’exécution des transactions : la latence est très importante, et l’expérience est médiocre. La seule solution consiste à introduire un mécanisme de « pré-confirmation » : le Gateway du L2 peut obtenir à l’avance un engagement auprès des futurs Proposer de L1, « je garantis que je publierai sur la chaîne les transactions que vous soumettez, sinon je verserai une compensation », ce qui permet au Layer 2 de mettre à jour son état plus tôt (par exemple les soldes de comptes) afin de réduire l’attente des utilisateurs. Mais dans le mécanisme actuel qui décide aléatoirement du proposer, le gateway ne sait tout simplement pas qui contacter pour “négocier”, et une pré-confirmation fiable ne peut donc pas être obtenue.

Solution : l’EIP-7917 modifie le protocole de consensus afin que, pour une période à venir, l’ordre des Proposer puisse être calculé à l’avance de manière déterministe et rendu public. Il transforme le « tirage au sort sur le moment » en une « feuille de service de production de blocs » consultable par tous et pré-ordonnée.

Signification : cette amélioration est une pierre angulaire clé pour réaliser des solutions décentralisées de nouvelle génération comme Based Rollup. Grâce à cette « feuille de service », le gateway L2 peut identifier à l’avance le proposer d’un bloc futur, et négocier directement avec lui afin d’obtenir une pré-confirmation fiable garantie par une pénalité de Slash. Cela permet à Based Rollup de bénéficier, tout en profitant de la décentralisation et de la sécurité de niveau L1, d’une expérience de transaction quasi instantanée, semblable à celle d’un sequencer centralisé, pour les utilisateurs. On peut dire que l’EIP-7917 apporte à l’écosystème Ethereum un « scaling par décentralisation » plus profond, ouvrant une porte cruciale.

Pourquoi la mise à niveau Fusaka arrive-t-elle au bon moment ?

Cette mise à niveau Fusaka n’est pas seulement une itération technique ; c’est aussi, dans le contexte d’une ère où la finance traditionnelle s’embarque massivement sur la blockchain grâce aux RWA et aux stablecoins, une mise à niveau stratégique importante. À l’heure actuelle, Ethereum, en tant que champ de bataille principal, supporte plus de 56 % de l’offre totale de stablecoins du réseau, et est devenu le niveau de règlement central de l’économie mondiale du « dollar numérique ». L’objectif de Fusaka est de se préparer à accueillir des actifs et un volume de transactions de niveau « Wall Street ».

• Des chaînes Layer 2 sur mesure pour les institutions, avec du « carburant » pour une scalabilité illimitée

Avec l’entrée des institutions de finance traditionnelle, nous allons voir apparaître de plus en plus de Layer 2 « chaînes dédiées » personnalisées pour des besoins spécifiques (par exemple la conformité KYC). Ces chaînes dédiées nécessitent que le réseau principal Ethereum leur fournisse un espace massif, bon marché et sûr pour stocker les données (c’est-à-dire la Data Availability).

Dans Fusaka, les EIP-7594, EIP-7892 et EIP-7918 répondent précisément à ce besoin. Leur objectif central est unique : réduire fortement le coût de publication des données pour Layer 2 et fournir une élasticité de scalabilité à la demande.

En fait, après la mise à niveau Pectra, les frais de Blob sont déjà très bas. Pourquoi continuer à les réduire ? Parce que Fusaka applique une stratégie de « sacrifier les revenus de frais à court terme pour obtenir des activités économiques à plus grande échelle ». L’objectif est de faire grandir le GDP de l’ensemble du réseau, afin que davantage de transactions se transforment en davantage de mises en jeu (staking) et en ETH brûlé, soutenant ainsi la valeur globale du réseau.

• Vers la « sécurité d’un billion de dollars » : bâtir une infrastructure financière incassable

Pour les institutions financières qui gèrent des actifs de l’ordre du billion, la sécurité est une ligne rouge incontournable. La communauté Ethereum a également proposé l’objectif ambitieux de « sécurité d’un billion de dollars ». Les EIP-7934, EIP-7825, EIP-7823 et EIP-7883 dans Fusaka servent à renforcer les remparts, à éliminer les risques de sécurité potentiels, et à avancer vers cet objectif.

En résumé, la ligne principale de la mise à niveau Fusaka est claire et résolue : scalabilité et sécurité. Avec le double moteur constitué par les bonnes nouvelles réglementaires et la vague d’enthousiasme du marché, la mise à niveau Fusaka arrive au moment opportun. Elle aidera Ethereum à saisir l’élan des politiques publiques, à consolider sa position dominante dans les domaines des stablecoins et des actifs on-chain, et à transformer encore davantage Ethereum d’une « crypto d’opportunité spéculative » en une infrastructure financière grand public.

Conclusion : une transformation en eaux calmes

En tant que grande mise à niveau de fin 2025, Fusaka injecte discrètement une forte motivation interne à Ethereum, sans couvrir le marché d’un battage médiatique écrasant. Les 12 améliorations qu’elle contient ciblent directement les trois grandes douleurs : scalabilité, sécurité et efficacité. Ce qu’elle fait, c’est élargir « l’autoroute de la valeur » d’Ethereum, augmenter sa capacité et sa fiabilité, et préparer l’avenir pour d’énormes volumes d’utilisateurs, d’actifs et d’applications.

Pour les utilisateurs ordinaires, ces changements peuvent sembler « presque silencieux », mais leur impact sera profond. Un Ethereum plus puissant, plus efficace et plus sûr sera capable de réaliser des visions grandioses qui n’étaient jusque-là que des rêves : que ce soit un réseau mondial de règlement quasi instantané, ou « Wall Street on-chain ». Fusaka est précisément une étape solide vers ce futur.

• Cet article est basé sur une analyse d’informations publiques et ne constitue pas un conseil en investissement. L’investissement en cryptomonnaies comporte de grands risques : veuillez prendre vos décisions avec prudence et faire votre propre recherche (DYOR).

• Si vous aimez cet article, n’hésitez pas à vous abonner, à aimer et à partager pour le soutenir !