Les développeurs Ethereum ont finalisé le calendrier des mises à niveau du réseau à venir. Les changements majeurs devraient avoir lieu le 24 février, 5 mars et le 8 avril. Les décisions clés ont été finalisées lors de l’appel récent All Core Developers Execution (ACDE), qui s’est tenue le 13 février 2025.
La réunion de zoom bihebdomadaire discussions ont été dirigés par le support du protocole de la Fondation Ethereum (EF), Tim Beiko. Les développeurs ont confirmé que la mise à niveau de Pectra serait activée sur le Holesky Testnet le 24 février. Par la suite, le SEPOLIA Testnet augmentera le 5 mars.
Si les deux déploiements se déroulent en douceur, le MainNet d’Ethereum recevra la mise à niveau vers le 8 avril.
Beiko a déclaré qu’il se coordonnerait avec les équipes pour trouver un bénévole pour déployer des contrats de système PECTRA sur les deux tests de temps.
Débats sur les futures fourches Ethereum et vitesse de mise à niveau
En outre, l’équipe de développeurs a discuté de la mise à niveau prévue suivante après PECTRA et FUSAKA. Beiko proposé Géler la portée de Fusaka au moment du lancement de Pectra sur le MainNet.
Le calendrier permet aux développeurs de commencer à travailler sur Fusaka tout en planifiant le hardfork glamsterdam ultérieur.
L’équipe de développement Geth ne veut pas travailler avec ce calendrier. Ils soutiennent qu’il était prématuré de cimenter la portée de Fusaka. L’inclusion de la proposition d’amélioration Ethereum (EIP) dans Fusaka a suscité un débat considérable. Une faction de développeurs plaide pour son exclusion de la prochaine mise à niveau.
Eof (format d’objet Ethereum) est un mise à niveau visant à améliorer la façon dont les contrats intelligents sont structurés et exécutés sur la blockchain Ethereum.
Le développeur de Geth Lightclient s’est opposé à la vitesse du lycé de la portée Fusaka. Le développeur soutient que les priorités d’Ethereum pourraient changer au cours des deux prochaines années. Il a souligné que si les développeurs visent des cycles de mise à niveau de six mois, les retards du monde réel pouvaient les étirer à huit mois ou plus. Cela signifie que des améliorations importantes pourraient ne pas être mises en œuvre pendant des années.
LightClient a soulevé des préoccupations concernant l’incorporation de l’EOF, mettant en évidence les progrès rapides de la technologie Rollup à connaissance zéro d’Ethereum (ZKEVMS). Les développeurs restent dans l’obscurité concernant l’interaction de ces changements avec la machine virtuelle.
Au cours de la discussion, le développeur de Geth, Marius van der Wijden, a répertorié sa portée préférée pour Fusaka, qui comprenait Peerdas, Focil, EOF et les limites supérieures pour Modexp. L’ingénieur des opérations du développeur EF Parithosh Jayanthi a repoussé, déclarant que Focil n’était pas aussi prêt pour la mise en œuvre que Peerdas et EOF.
Mises à niveau des tests de logiciel PECTRA et commentaires de la communauté
Les développeurs ont dépassé leurs désaccords sur Fusaka pour exprimer sa confiance dans le Déploiement de PECTRA. L’ingénieur du développement et des opérations EF Parithosh Jayanthi a rapporté que Pecctra Devnet 6 fonctionnait bien, avec des taux de participation des validateurs presque parfaits.
De plus, Ephemery TestNet d’Ethereum a activé la mise à niveau de PECTRA quelques heures après l’appel ACDE, permettant aux développeurs d’effectuer d’autres tests.
Beiko a demandé aux auteurs de PECTRA EIP de déplacer leurs propositions vers la phase «Dernier appel» sur Github. Cela signale les étapes finales avant l’implémentation MainNet. Il a également examiné les commentaires de la communauté Ethereum. À cette fin, il a noté que la demande la plus courante était d’accélérer les cycles de mise à niveau.
En réponse, il a suggéré que les développeurs d’Ethereum devraient viser à finaliser la portée de chaque mise à niveau dès que la précédente sera mise en ligne sur le MainNet.
Le calendrier proposé de Beiko pour finaliser la portée de Fusaka indique que, d’ici le 13 mars, les développeurs doivent proposer des EIP pour l’inclusion dans la mise à niveau. Deux semaines plus tard, le 27 mars, les équipes clients partageront leurs préférences sur lesquelles les EIP devraient être prises en compte pour Fusaka. Enfin, d’ici le 10 avril, la portée de la mise à niveau sera finalisée.
Cependant, le chercheur de l’EF, Ansgar Dietrichs, a ajouté une exception au moment. Il a noté que les améliorations du code Peerdas, un composant critique de la mise à niveau de PECTRA, devraient être téléchargés sur le maint d’Ethereum dès qu’ils sont terminés. Personne ne s’est opposé à cette exigence.
Préoccupations concernant les normes de test des anguilles et des EIP
Un autre point de préoccupation lors de l’appel de l’ACDE a été une proposition de l’ingénieur des tests EF Mario Vega. Cela concernait le cadre de test de couche d’exécution Ethereum. Vega a suggéré de faire des anguilles (spécifications de la couche d’exécution Ethereum) et d’Eest (cas de test de spécification d’Ethereum d’exécution) obligatoire pour tout EIP inclus dans une fourche dure.
Il a suggéré que cela améliorerait le flux de travail de test et standardiserait comment les EIP sont évalués avant l’adoption.
Cependant, plusieurs développeurs étaient contre la proposition. La raison? L’exigence pourrait ralentir le processus de mise à niveau. Van der Wijden a fait valoir que les responsables des anguilles pourraient devenir les gardiens de facto de l’inclusion de l’EIP. Pourquoi? Tous les développeurs ne sont pas capables d’écrire des implémentations basées sur Python de leurs propositions.
Wijden a suggéré une approche alternative. Eth devrait avoir Implémentations d’anguilles Cela pourrait être soumis sous forme de demandes de traction non fusionnées. Cela empêche l’équipe EELS d’avoir un pouvoir d’approbation final sur les mises à niveau.
Justin Florentin avec Ethereum Client Besu a conseillé à la communauté d’envisager de créer une langue de script supplémentaire. Cela clarifierait si un EIP peut être inclus sans EELS ou cas de test ELS.
