L’appel ACDE d’Ethereum 205 : Les grandes mises à niveau d’Ethereum arrivent les 24 février, 5 mars et 8 avril
- La mise à niveau Pectra d’Etherea est prévue pour le 24 février sur le testnet Holesky, avec un déploiement sur le mainnet attendu pour le 8 avril 2025.
- Les désaccords concernant le calendrier de la mise à jour Fusaka et l'inclusion de l'EIP EOF ont été discutés, les développeurs de Geth appelant à plus de flexibilité.
- Des inquiétudes ont été exprimées concernant les tests obligatoires EELS et EEST pour les EIPs, certains développeurs craignant des retards dans le processus de mise à jour.
Les développeurs d’Ethereum ont finalisé le calendrier des prochaines mises à niveau 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é arrêtées lors du récent appel ACDE (All Core Developers Execution) 205, tenu le 13 février 2025.
La réunion Zoom bihebdomadaire discussions a été dirigée par Tim Beiko, responsable du soutien aux protocoles de la Fondation Ethereum. Les développeurs ont confirmé que la mise à niveau Pectra serait activée sur le testnet Holesky le 24 février. Par la suite, le testnet Sepolia sera mis en ligne le 5 mars.
Si ces deux déploiements se déroulent sans encombre, le mainnet d’Ethereum recevra la mise à niveau vers le 8 avril.
Beiko a déclaré qu’il coordonnerait avec les équipes pour trouver un volontaire pour déployer les contrats système de Pectra sur les deux testnets.
Débats sur les futures fourches Ethereum et la vitesse des mises à niveau
De plus, l’équipe de développeurs a discuté de la prochaine mise à niveau prévue après Pectra et Fusaka. Beiko projet a gelé la portée de Fusaka au moment du lancement de Pectra sur le mainnet.
Ce calendrier permet aux développeurs de commencer les travaux sur Fusaka tout en planifiant la fourche dure suivante, Glamsterdam.
L’équipe de développement Geth ne souhaite pas travailler selon ce calendrier. Ils estiment qu’il était prématuré de figer la portée de Fusaka. L’inclusion de la proposition d’amélioration d’Ethereum (EIP) EOF dans Fusaka a suscité un débat considérable. Une faction de développeurs plaide pour son exclusion de la prochaine mise à niveau.
EOF (Ethereum Object Format) est un modernisation projet visant à améliorer la manière dont les contrats intelligents sont structurés et exécutés sur la blockchain Ethereum.
Le développeur Geth Lightclient s’est opposé à l’accélération du gel de la portée de Fusaka. Le développeur fait valuer que les priorités d’Ethereum pourraient évoluer au cours des deux prochaines années. Il a souligné que, bien que les développeurs visent des cycles de mise à niveau de six mois, les retards réels pourraient les étendre à huit mois ou plus. Cela signifie que des améliorations importantes pourraient ne pas être implémentées pendant des années.
Lightclient a exprimé des préoccupations concernant l’incorporation de EOF, soulignant les progrès rapides de la technologie des rollups à zéro connaissance d’Ethereum (zkEVM). Les développeurs ignorent encore l’interaction de ces changements avec la machine virtuelle.
Pendant la discussion, le développeur Geth Marius van der Wijden a listé sa portée préférée pour Fusaka, qui comprenait PeerDAS, FOCIL, EOF et les bornes supérieures pour modexp. Parithosh Jayanthi, ingénieur des opérations de développement de la Fondation Ethereum, a fait remarquer que FOCIL n’était pas aussi prêt pour l’implémentation que PeerDAS et EOF.
Mises à niveau des testnets logiciels Pectra et retours de la communauté
Les développeurs ont dépassé leurs désaccords sur Fusaka pour exprimer leur confiance dans le déploiement de Pectra. Parithosh Jayanthi, ingénieur de développement et d’opérations de la Fondation Ethereum, a rapporté que Pectra Devnet 6 fonctionnait bien, avec des taux de participation des validateurs quasi parfaits.
De plus, le testnet Ephemery d’Etherea a activé la mise à niveau Pectra quelques heures après l’appel ACDE, permettant aux développeurs de poursuivre leurs tests.
Beiko a demandé aux auteurs des EIP de Pectra de déplacer leurs propositions vers la phase de « dernier appel » sur GitHub. Cela signale les étapes finales avant l’implémentation sur le mainnet. Il a également examiné les retours de la communauté Ethereum. À cet égard, il a noté 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 d’Ethereum devraient viser à finaliser la portée de chaque mise à niveau dès que la précédente est en ligne sur le mainnet.
Le calendrier proposé par Beiko pour finaliser la portée de Fusaka indique que, d'ici le 13 mars, les développeurs doivent proposer des EIP à inclure dans la mise à jour. Deux semaines plus tard, le 27 mars, les équipes de clients partageront leurs préférences sur les EIP qui devraient être considérés pour Fusaka. Enfin, d'ici le 10 avril, la portée de la mise à jour sera finalisée.
Cependant, le chercheur de la Fondation Ethereum Ansgar Dietrichs a ajouté une exception au calendrier. Il a noté que les améliorations du code PeerDAS, un composant critique de la mise à niveau Pectra, devraient être téléchargées sur le mainnet d’Etherea dès qu’elles sont terminées. Personne n’a objecté à cette exigence.
Préoccupations concernant les normes de test EELS et EIP
Un autre point de préoccupation lors de l’appel ACDE était une proposition de l’ingénieur de test de la Fondation Ethereum, Mario Vega. Cela concernait le framework de test de la couche d’exécution d’Etherea. Vega a suggéré de rendre EELS (Ethereum Execution Layer Specifications) et EEST (Ethereum Execution Specification Test cases) obligatoires pour toute EIP incluse dans une fourche dure.
Il a suggéré que cela améliorerait le flux de travail de test et standardiserait l’évaluation des EIP avant leur adoption.
Cependant, plusieurs développeurs étaient contre cette proposition. La raison ? L’exigence pourrait ralentir le processus de mise à niveau. Van der Wijden a fait valuer que les mainteneurs d’EELS pourraient devenir les gardiens de facto de l’inclusion des EIP. Pourquoi ? Tous les développeurs ne sont pas capables d’écrire des implémentations basées sur Python pour leurs propositions.
Wijden a suggéré une approche alternative. ETH devrait avoir des implémentations EELS qui pourraient être soumises en tant que demandes de tirage (pull requests) non fusionnées. Cela empêche l’équipe EELS d’avoir le pouvoir d’approbation finale sur les mises à niveau.
Justin Florentine avec blockchain le client Besu a conseillé à la communauté de considérer la création d’un langage de script supplémentaire. Cela clarifierait si une EIP peut être incluse sans cas de test EELS ou EEST.
Les esprits les plus brillants du secteur crypto lisent déjà notre newsletter. Vous aussi ? Rejoignez-les.
Avertissement. Les informations fournies ne constituent pas des conseils en matière d'investissement. Cryptopolitan.com ne saurait être tenue responsable des investissements réalisés sur la base des informations fournies sur cette page. Nous recommandons vivement de mener vos propres recherches et/ou de consulter un professionnel qualifié avant de prendre toute décision d'investissement.
Florence Muchai
Florence couvre depuis 6 ans l'actualité crypto, du jeu vidéo, de la technologie et de l'IA. Ses études en informatique à l'Université de sciences et technologies de Meru et sa formation en gestion des catastrophes et en diplomatie internationale à l'MMUST lui ont amplement permis de développer des compétences linguistiques, d'observation et techniques. Florence a travaillé au sein du groupe VAP et en tant qu'éditrice pour plusieurs médias spécialisés dans la crypto.
