La mise à niveau du réseau principal de Fusaka fournit un ensemble coordonné de modifications de protocole pour faire évoluer les blobs, augmenter la capacité d’exécution et améliorer l’UX cryptographique sur Ethereum ; Les opérateurs de nœuds et les développeurs doivent utiliser l’époque d’activation publiée et le calendrier BPO pour préparer leurs environnements.
Qu’est-ce que la mise à niveau du réseau principal de Fusaka et quelles fonctionnalités sont les plus importantes ?
Fusaka est une mise à jour du protocole qui suit Pectra et se concentre sur trois piliers : un débit de blob plus élevé, des optimisations de la couche d’exécution et des améliorations de l’expérience utilisateur.
Le plus remarquable est PeerDAS (EIP9594)qui permet un échantillonnage de la disponibilité des données pour vérifier les blobs sans téléchargements complets. De plus, Fusaka propose plusieurs EIP qui, ensemble, fixent des limites, ajustent la comptabilité du gaz et ajoutent des primitives cryptographiques natives.
Quand Fusaka sera-t-il activé sur le réseau principal et quelles sont les étapes du BPO ?
La Fondation Ethereum a défini l’activation de la mise à niveau au début de époque 411392ce qui est 3 décembre 2025 à 21:49:11 UTC. L’annonce officielle indique que Fusaka sera suivi de deux forks Blob Parameter Only (BPO) pour augmenter la capacité du blob en toute sécurité.
Plus précisément, le calendrier BPO sur le réseau principal est : BPO1 — Époque 412672 — 09/12/2025 14:21:11 UTC — Unix 1765290071et BPO2 — Époque 419072 — 07/01/2026 01:01:11 UTC — Unix 1767747671. Par conséquent, la cible et le maximum du blob par bloc passeront de 6 et 9 à 10 & 15 dans BPO1 puis à 14 & 21 en BPO2.
Comment le protocole PeerDAS modifie-t-il la disponibilité des objets blob et la mise à l’échelle L2 ?
PeerDAS (le protocole peer das) remplace les téléchargements fullblob par un échantillonnage pris en charge par le codage d’effacement, permettant aux nœuds de vérifier la disponibilité des données de manière probabiliste tout en préservant les garanties cryptographiques.
Ce modèle d’échantillonnage réduit la demande de bande passante par nœud, de sorte que les cumuls de layer 2 peuvent s’appuyer sur des cibles blob plus élevées sans obliger chaque nœud à transporter un trafic proportionnel.
En conséquence, les rollups devraient permettre de réduire les frais L2 et d’augmenter le débit à mesure que la capacité des blob augmente. Cependant, la mise à niveau introduit des forks de paramètres Blob uniquement, de sorte que les modifications des cibles et des maximums se produisent par étapes et configurables après l’activation de PeerDAS.
Comment l’échantillonnage préserve-t-il la sécurité ?
PeerDAS utilise un codage d’effacement afin que les fragments échantillonnés impliquent de manière cryptographique une disponibilité complète des données sur le réseau.
Cette conception vise à maintenir la décentralisation en évitant de lourdes charges de bande passante sur les nœuds individuels tout en gardant les preuves compactes pour les validateurs et les nœuds complets.
Quel est l’impact attendu sur les rollups ?
Les cumuls pourront soumettre davantage de données blob par bloc au fur et à mesure des étapes BPO, ce qui permettra des lots L2 plus importants et réduira potentiellement les coûts de maintenance. Pendant ce temps, les opérateurs de nœuds bénéficient de l’efficacité de la bande passante grâce à l’échantillonnage, ce qui réduit les barrières opérationnelles à la participation.
Quels EIP d’exécution et de consensus Fusaka inclut-il et que changent-ils ?
Fusaka regroupe un ensemble de base d’EIP (voir EIP7607 pour les spécifications complètes) qui touchent au consensus, à l’exécution, à la mise en réseau et à la comptabilité du gaz. Les principaux EIP répertoriés dans l’annonce comprennent : EIP7594 (PeerDAS), EIP7823 (limites supérieures pour ModExp), EIP7825 (plafond limite de gaz de transaction), EIP7883 (Augmentation du coût du gaz ModExp), EIP7917, EIP7918, EIP7934, EIP7939 (opcode CLZ), et EIP7951 (prise en charge de la précompilation secp256r1).
Les EIP pris en charge incluent EIP7642 (nettoyage du réseau eth/69), EIP7892 (Paramètre Blob uniquement hardforks), EIP7910 (eth_config JSONRPC), et EIP7935 (limite de gaz par défaut à 60 M). Pour obtenir des références techniques complètes, consultez la spécification de mise à niveau publiée : EIP7607.
Comment les coûts de ModExp et de gaz sont-ils ajustés ?
Fusaka postule EIP7883 augmenter les coûts du gaz ModExp afin que la tarification reflète mieux la complexité informatique, y compris un coût minimal plus élevé et un multiplicateur de coût général.
En même temps, EIP7823 impose des limites supérieures aux opérations ModExp pour limiter l’utilisation des ressources. Ensemble, ces changements protègent les nœuds des opérations cryptographiques trop coûteuses à mesure que la capacité de bloc augmente.
Quelles sont les évolutions du réseau et des limites de gaz ?
EIP7642 ajoute eth/69 pour supprimer les champs de préfusion et le reçu Bloom, réduisant ainsi la bande passante de synchronisation et simplifiant la publicité de l’historique.
Surtout, EIP7825 introduit un plafond limite de gaz par transaction fixé à 16 777 216 du gaz, et EIP7935 augmente la limite de gaz de bloc par défaut à 60 000 000 gaz pour permettre une capacité d’exécution L1 plus élevée.
Quels clients et outils doivent être mis à jour pour le réseau principal de Fusaka ?
L’annonce répertorie les versions client de consensus et d’exécution adaptées à Fusaka. Les clients consensuels nommés incluent Grandine 2.0.0, Phare 8.0.0, Lodestar 1.36.0, Nimbus 25.11.0, Téku 25.11.0et Prisme (à déterminer). Les clients d’exécution incluent Besu 25.11.0, Érigon 3.2.2, goethereum 1.16.7, Reth 1.9.0et Nethermind (à déterminer).
De plus, des outils tels que mevboost 1.10 et commitboost 0.9.2 sont répertoriés pour des raisons de compatibilité. Les validateurs doivent mettre à jour les nœuds balises et les clients du validateur vers les versions publiées pour éviter la déconnexion au point de fork.
Que doivent faire les utilisateurs, les opérateurs et les développeurs avant Fusaka ?
Pour la plupart des utilisateurs finaux et des détenteurs d’ETH, aucune action n’est requise ; les échanges et les portefeuilles communiqueront toutes les étapes spécifiques. Cependant, les opérateurs de nœuds et les intervenants doivent mettre à jour les clients des couches d’exécution et de consensus vers les versions répertoriées ci-dessus et valider leur infrastructure de signature tout au long de la fenêtre d’activation.
Les développeurs et les fournisseurs d’outils devraient examiner les EIP tels que EIP7594, EIP7951et EIP7939 pour identifier les opportunités d’intégration – par exemple, les natifs prise en charge de la précompilation secp256r1 et le Opcode CLZ peut simplifier l’intégration matérielle du chiffrement et réduire les coûts de preuve ZK. En effet, des tests minutieux sur les testnets reflètent l’approche utilisée lors des répétitions générales de Hoodi, Holesky et Sepolia.
Toutes les dates d’activation, époques, numéros EIP, versions client et horodatages BPO sont tirés de l’annonce du réseau principal Fusaka d’Ethereum Foundations et de la spécification Fusaka.
Consultez les notes de compatibilité du client et marquez les fenêtres de maintenance autour 3 décembre 2025.
