Mise à niveau Fusaka d'Ethereum à la fin de l'année, analyse complète de 12 EIP : ciblant directement les trois points sensibles de l'évolutivité, de la sécurité et de l'efficacité.

Ethereum lancera bientôt le hard fork de Fusaka à la fin de 2025, renforçant l’évolutivité et la sécurité grâce à 12 propositions d’amélioration, et se préparant à l’avenir à l’utilisation d’actifs on-chain à grande échelle. (Synopsis : Tom Lee crie avec confiance : Ethereum est une « blockchain vraiment neutre » à 12 000 à la fin de l’année, et Bitcoin se précipitera à 250 000 $) (Supplément de contexte : Les analystes de Tom Lee : Ethereum 4 000 $ pour défendre la guerre et stabiliser l’offensive haussière à long terme de 5 500 $) Ethereum est sur le point d’inaugurer une mise à niveau du hard fork appelée « Fusaka » le 3 décembre 2025. Cette mise à niveau contient un total de 12 propositions d’amélioration d’Ethereum (EIP), qui sont comme 12 pièces sophistiquées qui fonctionneront ensemble pour améliorer l’évolutivité, la sécurité et l’efficacité opérationnelle d’Ethereum. Ci-dessous, je vais catégoriser ces 12 EIP et expliquer en langage clair les problèmes qu’ils résolvent chacun et pourquoi ils sont essentiels à l’avenir d’Ethereum. Développer! Faire fonctionner Ethereum plus vite et en emporter plus C’est le thème central de la mise à niveau de Fusaka. Pour qu’Ethereum puisse héberger l’économie numérique mondiale, il doit s’attaquer à la congestion des transactions et aux frais élevés. Les EIP suivants sont conçus pour atteindre cet objectif, en particulier en ce qui concerne la mise à l’échelle de la couche 2 afin de réduire les coûts et d’augmenter l’efficacité. EIP-7594 : PeerDAS – Échantillonnage de la disponibilité des données Point sensible : Depuis que la mise à niveau de Dencun a introduit des « blobs » de données pour fournir un stockage de données bon marché pour la couche 2, une question centrale se pose : comment s’assurer que cette énorme quantité de données est réellement disponible ? La pratique actuelle consiste à demander à chaque nœud de validation de télécharger et de vérifier toutes les données d’objet blob transportées par un bloc. Cela est possible lorsqu’un bloc transporte jusqu’à 9 blobs. Cependant, si le nombre d’objets blob augmente encore à l’avenir (par exemple 128), le téléchargement et la vérification de tous les objets blob entraîneront une surcharge élevée, ce qui augmentera le seuil de participation des validateurs et menacera la décentralisation du réseau. Solution : PeerDAS (Peer Data Availability Sampling) transforme les traditionnels « tous les contrôles » en « contrôles ponctuels ». En termes simples : le réseau découpe l’intégralité des données d’objets blob. Chaque validateur n’a pas besoin de télécharger tous les blobs, il suffit de télécharger et de vérifier aléatoirement quelques données. Ensuite, en se vérifiant mutuellement et en échangeant les résultats de la vérification, tout le monde peut confirmer conjointement l’intégrité et la disponibilité de l’ensemble des données blob. C’est comme un grand puzzle où tout le monde n’a que quelques pièces dans ses mains, mais tant que vous vérifiez les connexions clés de chacun, vous pouvez être sûr que tout le puzzle est intact. Il convient de souligner que PeerDAS n’est pas une invention entièrement nouvelle, et que ses idées de base DAS ont été mises en pratique avec succès dans des projets DA tiers tels que Celestia. La mise en œuvre de PeerDAS s’apparente davantage à un rattrapage d’une « dette technique » clé pour le plan de mise à l’échelle à long terme d’Ethereum. Importance : PeerDAS réduit considérablement la charge de stockage des validateurs, éliminant ainsi la barrière permettant à Ethereum de réaliser une expansion des données à grande échelle, ce qui peut affaiblir la décentralisation. À l’avenir, chaque bloc devrait contenir des centaines de blobs, prenant en charge jusqu’à 10 millions de TPS comme le prétend la vision de Teragas, tandis que les gens ordinaires peuvent facilement exécuter des validateurs et maintenir le réseau décentralisé. EIP-7892 : BPO Hard Fork - Mise à niveau légère des paramètres Point douloureux : La demande du marché pour la capacité de données de couche 2 évolue rapidement, et si vous devez attendre une mise à niveau importante comme Fusaka chaque fois que vous ajustez le nombre maximum de blobs, elle sera trop lente pour suivre le rythme du développement écologique. Solution : Cet EIP définit un mécanisme spécial de « Blob Parameter Only Hard Fork » (BPO). Cette mise à niveau est très légère, elle ne modifie que quelques paramètres liés aux objets blob (tels que les objets blob cibles par bloc) et n’implique pas de modifications de code complexes. L’opérateur de nœud n’a même pas besoin de mettre à niveau le logiciel client, il suffit d’accepter les nouveaux paramètres à un moment donné, aussi simple que de mettre à jour un fichier de configuration pour le logiciel en ligne. Ce que cela signifie : Le BPO donne à Ethereum la possibilité d’ajuster rapidement et en toute sécurité la capacité du réseau. Par exemple, après cette mise à niveau de Fusaka, la communauté prévoit d’effectuer deux mises à niveau BPO dans un court laps de temps afin de doubler progressivement la capacité de l’objet blob. Cela permet à Ethereum de faire évoluer l’espace blob à la demande, de manière élastique et progressive, en lissant les coûts et le débit L2, et en rendant les risques plus gérables. EIP-7918 : Stabilisation du marché des dépenses d’Blob Point sensible : Le mécanisme d’ajustement d’origine pour les frais d’Blob était trop « prêt pour le marché », ce qui a entraîné des problèmes inattendus. Tout d’abord, lorsque la demande du marché pour les blobs est faible, le coût tombera à un niveau proche de zéro, mais cela ne stimulera pas efficacement la nouvelle demande, mais créera un « creux historique » anormal. À l’inverse, lorsque la demande est élevée, les Blob Fee montent à nouveau en flèche, créant un autre prix extrêmement élevé. Cette « involution » drastique des prix rend difficile la planification des dépenses de la couche 2. Solution : L’idée centrale de l’EIP-7918 est de ne plus laisser les frais de blob fluctuer indéfiniment, mais de définir une fourchette de prix raisonnable, une « dépense minimale » flexible. L’implémentation consiste à lier les limites supérieure et inférieure des frais d’objet blob aux frais d’exécution de la couche 2 sur la couche 1. Qu’il s’agisse de mettre à jour la racine d’état ou de vérifier une preuve ZK, ces frais d’exécution sont relativement stables et n’ont pas grand-chose à voir avec le volume de transactions au sein du bloc L2. Par conséquent, lier les limites supérieure et inférieure des frais de blob à cette « ancre » stable peut empêcher son prix de monter et de descendre. Importance : L’avantage immédiat de cette amélioration est d’empêcher « l’involution » du marché des frais de blob et de rendre le modèle de coûts d’exploitation du projet de couche 2 plus prévisible, afin que la couche 2 puisse formuler des frais de transaction plus stables et plus raisonnables pour les utilisateurs finaux, évitant ainsi l’expérience des montagnes russes de « gratuit aujourd’hui, prix exorbitants demain ». EIP-7935 : Augmenter la capacité de transaction du réseau principal Point sensible : Le nombre total de transactions pouvant être prises en charge par bloc Ethereum est déterminé par le « plafond de gaz de bloc » (actuellement environ 30 millions) et n’a pas été ajusté depuis de nombreuses années. Le moyen le plus direct d’augmenter le débit de l’ensemble du réseau est d’augmenter cette limite supérieure, mais vous devez vous assurer que le seuil matériel du nœud de validation n’est pas élevé et que le degré de décentralisation n’est pas affaibli. Solution : Cette proposition propose d’augmenter la limite de gaz par défaut des blocs à un nouveau niveau (la valeur exacte reste à déterminer, elle peut être de 45 millions ou plus). Il ne s’agit pas d’un verrouillage forcé, mais plutôt d’une nouvelle valeur par défaut recommandée qui guide les validateurs de couche de consensus pour accepter progressivement des plafonds de gaz plus élevés. Ce que cela signifie : Cela signifie qu’un plus grand nombre de transactions peuvent être regroupées par bloc de couche 1, et que le TPS du réseau principal Ethereum sera directement amélioré, et que la congestion du réseau et les pics de frais de gaz pourront être atténués. Bien sûr, cela impose également des exigences plus élevées au matériel du vérificateur, de sorte que la communauté testera et avancera prudemment. Sûr et stable ! Construisez une ligne de défense solide pour votre réseau…