Les développeurs Ethereum ont finalisé le calendrier des prochaines mises à jour du réseau. Des changements majeurs sont prévus les 24 février, 5 mars et 8 avril. Les décisions clés ont été prises lors de la réunion ACDE 205 (All Core Developers Execution Call 205), qui s'est tenue le 13 février 2025.
bihebdomadaires via Zoom discussions étaient animées par Ethereum (EF). Les développeurs ont confirmé que la mise à jour Pectra serait activée sur le réseau de test Holesky le 24 février. Le réseau de test Sepolia sera ensuite déployé le 5 mars.
Si les deux déploiements se déroulent sans problème, le réseau principal d' Ethereumrecevra la mise à jour aux alentours du 8 avril.
Beiko a déclaré qu'il se coordonnerait avec les équipes pour trouver un volontaire pour déployer lestracdu système Pectra sur les deux réseaux de test.
Débats sur les futures bifurcations Ethereum et la vitesse de mise à jour
Par ailleurs, l'équipe de développeurs a discuté de la prochaine mise à jour prévue après Pectra et Fusaka. Beiko a proposé de geler le périmètre de Fusaka jusqu'au lancement de Pectra sur le réseau principal.
Ce calendrier permet aux développeurs de commencer à travailler sur Fusaka tout en planifiant la future bifurcation Glamsterdam.
L'équipe de développement de Geth ne souhaite pas travailler avec ce calendrier. Elle estime qu'il était prématuré de définir le périmètre de Fusaka. L'intégration de l'EOF ( Ethereum Improvement Proposal - EIP) à Fusaka a suscité un vif débat. Une partie des développeurs plaide pour son exclusion de la prochaine mise à jour.
EOF (Ethereum Object Format) est une mise à jour intelligentstracsont structurés et exécutés sur la Ethereum blockchain
Lightclient, développeur de Geth, s'est opposé à l'accélération du gel du périmètre de Fusaka. Il soutient que Ethereumpourraient évoluer au cours des deux prochaines années. Il a souligné que, bien que les développeurs visent des cycles de mise à jour de six mois, des retards concrets pourraient les porter à huit mois, voire plus. De ce fait, des améliorations importantes pourraient ne pas être implémentées avant des années.
Lightclient a exprimé des inquiétudes quant à l'intégration d'EOF, soulignant les progrès rapides de la technologie de rollup à connaissance nulle d' Ethereum(zkEVM). Les développeurs ignorent encore comment ces changements interagissent avec la machine virtuelle.
Au cours de la discussion, Marius van der Wijden, développeur Geth, a exposé ses préférences concernant le périmètre de Fusaka, incluant PeerDAS, FOCIL, EOF et des limites supérieures pour l'expression des modules. Parithosh Jayanthi, ingénieur en opérations de développement chez EF, a rétorqué que FOCIL n'était pas aussi prêt à être implémenté que PeerDAS et EOF.
Mises à jour du réseau de test logiciel Pectra et retours de la communauté
Les développeurs ont mis de côté leurs désaccords concernant Fusaka pour exprimer leur confiance dans le déploiement en cours de Pectra. Parithosh Jayanthi, ingénieur en développement et opérations chez EF, a indiqué que Pectra Devnet 6 fonctionnait bien, avec des taux de participation des validateurs quasi parfaits.
De plus, le réseau de test Ephemery d' Ethereuma activé la mise à niveau Pectra quelques heures après l'appel de l'ACDE, permettant aux développeurs de mener des tests supplémentaires.
Beiko a demandé aux auteurs du projet EIP Pectra de faire passer leurs propositions à la phase « dernier appel » sur GitHub. Cela marque les dernières étapes avant le déploiement sur le réseau principal. Il a également examiné les retours de la Ethereum et a constaté que la demande la plus fréquente était d'accélérer les cycles de mise à niveau.
En réponse, il a suggéré que les développeurs Ethereum s'efforcent de finaliser la portée de chaque mise à jour dès que la précédente est mise en service sur le réseau principal.
par Beiko proposé pour la finalisation du périmètre de Fusaka prévoit que, d'ici le 13 mars, les développeurs devront soumettre des EIP (améliorations d'extension) à inclure dans la mise à niveau. Deux semaines plus tard, le 27 mars, les équipes clientes indiqueront leurs préférences quant aux EIP à prendre en compte pour Fusaka. Enfin, le périmètre de la mise à niveau sera finalisé d'ici le 10 avril.
Cependant, Ansgar Dietrichs, chercheur chez EF, a émis une exception concernant le calendrier. Il a souligné que les améliorations apportées au code de PeerDAS, composante essentielle de la mise à niveau Pectra, devraient être déployées sur le réseau principal Ethereum dès qu'elles seraient finalisées. Cette exigence n'a suscité aucune objection.
Préoccupations concernant les normes d'essai EELS et EIP
Un autre point soulevé lors de la réunion de l'ACDE concernait une proposition de Mario Vega, ingénieur de test chez EF. Cette proposition portait sur le cadre de test de la couche d'exécution Ethereum . Vega suggérait de rendre obligatoires les spécifications EELS (Ethereum Execution Layer Specifications) et EEST (Ethereum Execution Specification Test cases) pour toute EIP incluse dans un hard fork.
Il a suggéré que cela améliorerait le flux de travail des tests et normaliserait la manière dont les EIP sont évalués avant leur adoption.
Cependant, plusieurs développeurs s'opposaient à la proposition. La raison ? Cette exigence risquait de ralentir le processus de mise à niveau. Van der Wijden a fait valoir que les responsables de la maintenance d'EELS pourraient devenir de facto les garants de l'intégration des EIP. Pourquoi ? Tous les développeurs ne sont pas capables d'implémenter leurs propositions en Python.
Wijden a proposé une autre approche : l’ETH devrait disposer d’implémentations EELS pouvant être soumises sous forme de demandes de fusion non acceptées. Cela empêcherait l’équipe EELS d’avoir le pouvoir d’approbation finale sur les mises à jour.
Justin Florentine, du Ethereum Besu, a suggéré à la communauté d'envisager la création d'un langage de script supplémentaire. Cela permettrait de déterminer si une EIP peut être intégrée sans les cas de test EELS ou EEST.
