Fusaka en bonne voie : fourchette mainnet fixée au 3 décembre

Points clés

• Les développeurs visent un fork mainnet le 3 décembre, conditionnel à la finalisation d’un testnet cette semaine.
• Les candidats release pour les clients mainnet sont attendus le 3 novembre, donnant un mois aux opérateurs de nœuds pour migrer.
• La montée en charge des blobs se fera par paliers via des Blob Parameter Override (BPO) les 9 décembre et 7 janvier.
• Peer Data Availability Sampling (PeerDAS) — un nouveau mode de vérification des données — pourrait fortement réduire les coûts pour les rollups et l’écosystème L2.

Le calendrier technique d’Ethereum pour l’upgrade baptisée Fusaka avance et, à ce stade, les équipes clients ont donné leur feu vert. Le passage en production reste soumis à la validation finale des derniers testnets, mais les jalons annoncés (candidats de release, dates de fork, activations graduelles des paramètres de blob) sont désormais visibles et rapprochent la chaîne principale d’une évolution majeure de la gestion des données.

Pourquoi c’est important

Fusaka n’est pas qu’un changement de paramètre : il introduit un mécanisme opérationnel pour faire évoluer la capacité des blobs, ces paquets de données apparus avec EIP-4844 (proto-danksharding) lors de l’upgrade précédente. Le nouveau procédé, appelé Blob Parameter Override (BPO), permet d’ajuster dynamiquement la quantité de blobs après le fork, au lieu de rester sur une configuration statique.

Autre avancée : Peer Data Availability Sampling (PeerDAS) — un système qui autorise les nœuds à vérifier la disponibilité des données par échantillonnage plutôt que par téléchargement complet. Concrètement, cela peut réduire drastiquement les coûts d’infrastructure pour les fournisseurs et les rollups (solutions de mise à l’échelle de couche 2, ou L2) et accélérer la mise à jour des oracles.

Impacts pour les utilisateurs

La première conséquence visible concerne les opérateurs de nœuds : ils devront tester et adopter les candidats de release publiés début novembre pour être opérationnels au 3 décembre. Les fournisseurs d’infrastructure et les équipes de rollups surveillent de près les activations BPO, qui sont conçues pour limiter le risque de dégradation des performances en augmentant la capacité par paliers et en offrant la possibilité de la réduire si nécessaire.

Pour les utilisateurs finaux, l’effet attendu est une baisse des coûts de transaction via des blobs moins onéreux, des opérations de rollup plus efficaces et des mises à jour d’oracles plus rapides. Ces gains restent toutefois conditionnels : si des problèmes de performance apparaissent lors des étapes de test, les paramètres pourront être ajustés.

Calendrier et prochaines étapes

• Fin de la validation des testnets (Hoodi/Hoodie) attendue cette semaine ; confirmation finale du fork mainnet dépendante de cette étape.
• Candidats de release pour clients mainnet : 3 novembre — période de préparation pour les opérateurs de nœuds.
• Fork mainnet visé : 3 décembre, sous réserve d’absence de blocages lors des tests finaux.
• Activations BPO planifiées : première étape le 9 décembre, seconde le 7 janvier.
• Des forks tests (Sepolia, Holesky) poursuivent leur déroulé : Sepolia montre une forte participation des validateurs, Holesky sera mis hors service prochainement.

Le détail technique

Les blobs sont des unités de données externes à l’état principal de la blockchain, conçues pour améliorer l’efficacité des rollups. EIP-4844 a introduit une forme instrumentale de danksharding (appelée proto-danksharding) pour gérer ces blobs. Avec Fusaka, l’innovation tient à la gouvernance opérationnelle des blobs : les BPO permettent d’ajuster la capacité en production sur la base de métriques réelles (bande passante, latence, stabilité).

PeerDAS change la manière dont la disponibilité des données est vérifiée : au lieu de forcer le téléchargement complet, les nœuds vérifient des échantillons, réduisant fortement le besoin de stockage et de bande passante. Les tests en cours incluent des benchmarks, des analyses de bande passante et des simulations d’instabilité pour s’assurer que l’augmentation des blobs reste supportable par l’écosystème.

En pratique, Fusaka est une étape technique prudente : elle cherche à concilier montée en capacité et maîtrise des risques, via des activations graduelles et des mécanismes de repli si nécessaire.

Partager sur vos réseaux !