Les développeurs principaux d'Ethereum se disputent sur le processus et le calendrier de Fusaka

La dernière réunion All Core Devs d’Ethereum s’est concentrée sur le processus, et pas seulement sur le code : il s’agissait de savoir s’il fallait respecter le délai de 30 jours précédemment annoncé entre les versions des clients et le premier fork sur testnet, alors que la mise à niveau Fusaka progresse. Certains participants ont insisté pour réaffirmer cet engagement afin que les équipes d’infrastructure et d’applications aient le temps de s’adapter ; d’autres ont plaidé pour plus de flexibilité afin d’éviter un glissement plus large de la feuille de route.

Le débat s’est déroulé sur fond de résultats mitigés sur les devnets. Sur Devnet-3, un exercice planifié de non-finalité a duré plus longtemps que prévu, selon Barnabas Busa de l’équipe Dev Ops. « Nous voulions faire environ deux jours au départ, et maintenant nous en sommes au cinquième jour », a-t-il déclaré, notant que la participation avait chuté puis était remontée au-dessus de 50 %. La finalité requiert l’accord de plus des deux tiers de la mise effective totale.

En revanche, un autre testnet s’est rétabli rapidement après un redémarrage coordonné : « La chaîne s’est rétablie en, je pense, deux heures », a indiqué Busa. Cet exercice teste la résistance de la chaîne à la manière dont les variables interagissent lors d’un incident réel, ce qui peut aider Ethereum à se remettre d’une crise.

Lire plus : La mise à niveau Fusaka d’Ethereum pourrait être retardée

Avec des correctifs attendus dans les prochains jours, le plan à court terme est de restaurer Devnet-3 à pleine capacité, de relancer le test puis de lancer Devnet-5.

Mais le principal point de tension concernait la discipline de planification pour les réseaux publics. Lightclient a souligné la promesse en vigueur : « Il est bien indiqué 30 jours avant le premier testnet. » Il a mis en garde contre le déplacement des objectifs par commodité, sur la base de l’évaluation des développeurs principaux concernant le temps nécessaire aux autres équipes absentes de l’appel.

La préoccupation pratique est d’améliorer la cadence des hard forks. Réduire les intervalles entre les tests peut accélérer les forks, mais augmente le risque que les équipes en aval publient des mises à jour précipitées. L’argument inverse est qu’un pipeline prolongé retarde tout le reste dans la file d’attente, ce qui pourrait déplaire à la communauté Ethereum au sens large.

« Je ne pense pas que nous devrions choisir les délais en fonction de ce que la communauté souhaite nécessairement », a déclaré Lightclient. « Les personnes qui livrent le logiciel ont dit qu’elles voulaient 30 jours pour fournir un logiciel de haute qualité que la communauté va utiliser. »

Malgré tout, l’échange quelque peu tendu a évolué vers le respect du processus écrit, à moins que les parties prenantes ne demandent explicitement un changement.

Il y avait également une frustration à devoir revenir sur la même question à chaque cycle. « Je pense que c’est vraiment un mauvais précédent de continuer à laisser les décisions changer », a déclaré Lightclient, notant que les développeurs d’applications et les L2 ne participent généralement pas aux appels principaux et comptent sur des délais prévisibles pour planifier leurs propres sorties.

Pour l’instant, le consensus est de procéder comme si la période tampon de 30 jours restait en vigueur, tout en sollicitant activement de nouveaux avis, a indiqué le coordinateur Tim Beiko. « Nous devrions préparer le calendrier selon ce qui est dans le document [de processus] et en parallèle vérifier auprès des parties prenantes concernées. » Si une accélération bénéficie réellement d’un large soutien, le groupe le formalisera par écrit.