Fusaka et le débat des core devs : pourquoi le délai de 30 jours compte

En bref

• Les développeurs centraux d’Ethereum discutent de l’application d’une règle écrite : 30 jours entre une sortie de client et le premier testnet.
• Des devnets (réseaux de développement) ont rendu des résultats mitigés, avec un Devnet-3 qui a dépassé la durée prévue d’un exercice sans finalité (finality).
• La décision provisoire : conserver le tampon de 30 jours mais solliciter rapidement les parties prenantes pour valider ou formellement changer le processus.
• La dépréciation du testnet Holesky est prévue après le fork de test Fusaka, fin septembre ; un billet explicatif est attendu sous peu.

Le débat a tourné moins autour du code que de l’ordonnancement : faut-il respecter strictement un délai de 30 jours entre la publication d’un client (le logiciel qui implémente le protocole Ethereum) et le premier fork sur un testnet (réseau de test public) ? Ou peut-on raccourcir cette fenêtre pour accélérer la cadence des mises à jour ?

Impacts pour les utilisateurs

La question n’est pas administrative : elle a des conséquences pratiques pour les intégrateurs. Les clients — les implémentations logicielles — publient des versions que des équipes en aval doivent intégrer et tester. Parmi ces équipes se trouvent les fournisseurs d’infrastructure, les portefeuilles, les rollups (un type de solution de couche 2 ou L2 visant à regrouper et traiter des transactions hors-chaîne pour alléger la blockchain principale) et les applications décentralisées.

Si le délai est comprimé, ces équipes peuvent être contraintes de livrer des mises à jour rapidement, ce qui augmente le risque de bugs et de portages incomplets. À l’inverse, maintenir un tampon de 30 jours facilite la planification : les équipes non présentes dans les réunions techniques ont une fenêtre prévisible pour adapter leurs stacks.

L’incident sur Devnet-3 (réseau de développement) illustre le besoin de temps pour tester des scénarios réels : un exercice prévu pour deux jours a duré cinq, la participation fluctuant en dessous du seuil de finalité (le moment où une chaîne est considérée comme irréversible, souvent atteint lorsque plus des deux tiers du stake total s’accordent). D’autres testnets ont récupéré rapidement après un redémarrage coordonné, montrant que les drills d’incident peuvent réussir, mais exigent des ressources et du temps.

Calendrier et prochaines étapes

La position de travail pour l’instant est conservatrice : préparer le calendrier selon le document de processus en vigueur (donc en respectant le tampon de 30 jours) et, en parallèle, vérifier auprès des parties prenantes affectées si un rythme plus rapide serait vraiment soutenu. Si un consensus émerge pour accélérer, la modification sera formalisée par écrit.

Concrètement, les équipes d’exploitation visent à restaurer Devnet-3, relancer les tests et lancer ensuite Devnet-5. Parallèlement, la dépréciation du testnet Holesky est planifiée après le fork de test Fusaka, attendu fin septembre ; un billet expliquant le calendrier et les migrations à prévoir doit être publié prochainement.

En pratique, ce message s’adresse aux équipes qui ne suivent pas les réunions des développeurs centraux : c’est le moment de se manifester. La fenêtre entre sorties clients et forks de test conditionne le travail d’intégration — et les développeurs centraux ont explicitement demandé un retour avant de verrouiller les dates.

Au final, l’équilibre recherché est simple : éviter les changements de règles improductifs tout en gardant la possibilité d’adapter le processus si l’ensemble des acteurs le demande formellement. Pour l’instant, la prédictibilité prime, mais la pression pour accélérer reste palpable.

Partager sur vos réseaux !