TechFlow Résumé de la réunion des développeurs Ethereum : mise à niveau de Cancun, bifurcation dure et Prague
TechFlow SélectionTechFlow Sélection
TechFlow Résumé de la réunion des développeurs Ethereum : mise à niveau de Cancun, bifurcation dure et Prague
La réunion a également abordé les priorités concernant les modifications du code pour la prochaine mise à niveau par fourchette dure Prague/Electra, après Dencun.
Dédié à des analyses Web3 approfondiesRédaction : Christine Kim, vice-présidente de la recherche chez Galaxy
Traduction : Qin Jin, Valeur Chaîne Carbone
Le 4 janvier 2024, les développeurs d'Ethereum se sont réunis sur Zoom pour la réunion All Core Developers Execution (ACDE) #178. Ces appels ACDE, généralement animés par Tim Beiko, responsable du protocole à la Fondation Ethereum, constituent une série bimensuelle où les développeurs discutent et coordonnent les modifications apportées à la couche d'exécution (EL). Cette semaine, la réunion a été dirigée par un développeur EL Geth anonyme utilisant le pseudonyme « Lightclient ». Les développeurs ont confirmé à nouveau les trois prochaines dates d'activation publiques des tests nets pour la mise à niveau Cancun/Deneb (Dencun). Ils ont également abordé les priorités en matière de modifications de code (EIPs) pour la prochaine mise à niveau par fourchette dure après Dencun, Prague/Electra.
Mise à jour Dencun
Aucune mise à jour spécifique concernant la mise à niveau Dencun n’a eu lieu pendant les vacances. Depuis la dernière réunion ACDE du 21 décembre, les équipes clientes ont travaillé à préparer de nouvelles versions pour le réseau test Goerli. En raison de retards précédents dans les tests de mise à niveau causés par Prysm, le développeur Geth Marius van der Wijden a demandé à l’équipe cliente Prysm un point sur leur progression pour sortir une nouvelle version. Le développeur Prysm Terence Tsao a confirmé que l'équipe Prysm serait prête avec une nouvelle version pour la fourchette dure de Goerli la semaine suivante. Toutefois, cette version destinée à Goerli sera une version « préliminaire », ce qui signifie qu’elle ne sera pas la version recommandée pour fonctionner sur le réseau principal d’Ethereum. Après la fourchette dure de Goerli, l’équipe Prysm prévoit de publier une autre version incluant certains changements et mises à jour, destinée aux utilisateurs du réseau principal ainsi qu’aux tests sur Sepolia ou Holesky.
Bien que Tsao ait indiqué que l’équipe Prysm était satisfaite de la date d’activation de la fourchette dure de Goerli fixée au 17 janvier, comme discuté lors de ACDE #177, il a suggéré d’attendre après cette activation pour déterminer les dates d’activation des fourchettes dures de Sepolia et Holesky. Depuis ACDE #177, Tim Beiko, responsable du support protocolaire à la Fondation Ethereum, a proposé des dates d’activation pour les trois réseaux tests publics d’Ethereum : Goerli, Sepolia et Holesky. Les horodatages proposés sont les suivants :
-
Goerli — 17 janvier 2024 — Époque 231680 — Horodatage 1705473120
-
Sepolia — 30 janvier 2024 — Époque 132608 — Horodatage 1706655072
-
Holesky — 7 février 2024 — Époque 29696 — Horodatage 1707305664
Lightclient a interrogé les autres équipes clientes, en dehors de Prysm, pour savoir si elles acceptaient la date proposée par Beiko pour l’activation de la fourchette dure de Goerli. Toutes les équipes clientes présentes à l’appel (y compris Geth, Lodestar, Lighthouse, Teku et Besu) ont confirmé que le calendrier leur convenait, et qu’elles publieraient leurs versions au plus tard la semaine suivante pour les opérateurs de nœuds Goerli. L’équipe cliente Lighthouse a noté que sa version pourrait aussi être une version préliminaire, semblable à celle de Prysm, car elle teste encore certaines fonctionnalités réseau de son client.
Divergence sur le calendrier Dencun
Ensuite, Lightclient a lancé une discussion sur les dates d’activation proposées pour les réseaux tests Sepolia et Holesky. Un développeur Prysm utilisant le pseudonyme « Potuz » a suggéré de reporter la fixation des dates de mise à niveau pour les deux derniers réseaux tests avant le réseau principal. « Nous devrions éviter de nous engager dès maintenant sur des dates, car les choses pourraient mal se passer sur Goerli, et revenir en arrière poserait problème. Ajouter une nouvelle version avec la bonne époque sans autres modifications est facile. Supprimer une version et corriger des erreurs, c’est problématique. Cela prend bien plus que quelques semaines », a déclaré Potuz.
Lightclient a souligné que les équipes clientes n’auraient besoin de publier une nouvelle version qu’une semaine après la fourchette dure de Goerli, donc à moins qu’un problème soit détecté sur Goerli après le 24 janvier, il ne serait pas nécessaire de supprimer la nouvelle version. Le développeur Geth Marius van der Wijden a estimé qu’il ne voyait aucun inconvénient à fixer des dates pour Sepolia et Holesky, puisque les développeurs pouvaient toujours les modifier si un problème survenait sur Goerli.
Barnabas Busa, ingénieur DevOps à la Fondation Ethereum, a écrit dans le chat Zoom que, selon lui, il ne serait nécessaire de publier une nouvelle version pour les mises à niveau de Sepolia et Holesky qu’après confirmation du bon fonctionnement de la version sur Goerli. Un développeur Lighthouse utilisant le pseudonyme « Sean » a partagé cet avis, affirmant que les développeurs pouvaient fixer une date « provisoire » pour la fourchette dure de Sepolia, mais devraient d’abord observer comment se déroule Goerli avant le 30 janvier.
Potuz a suggéré d’ajouter une semaine supplémentaire de tests entre les activations des fourchettes dures de Goerli et de Sepolia, passant ainsi de deux à trois semaines d’analyse. Il a expliqué qu’une semaine supplémentaire permettrait aux versions clientes de « tremper » quelques jours avant que les équipes n’aient à sortir une nouvelle version pour la prochaine mise à niveau de testnet. « Deux semaines, c’est trop serré. C’est le point que je veux souligner », a ajouté Potuz, précisant que si la version cliente de Goerli était suffisamment analysée et testée, il pourrait ne pas être nécessaire de conserver un délai de trois semaines entre les activations des fourchettes dures de Sepolia et Holesky.
La position de Potuz a suscité la controverse. Ansgar Dietrichs, de la Fondation Ethereum, a déclaré que l’intervalle entre la première activation publique du testnet et l’activation sur le réseau principal constituait habituellement une « échéance » pour les développeurs, et qu’il n’était pas nécessaire de l’allonger. Toutefois, Dietrichs a également indiqué que le souhait d’étendre les intervalles entre les mises à niveau des testnets devrait faire l’objet d’une discussion plus approfondie dans le contexte des fourchettes dures, et pas uniquement pour la mise à niveau Dencun. « Si quelqu’un souhaite un processus plus long, alors nous devrions en discuter quand nous avons du temps, et non juste avant une fourchette dure », a-t-il dit.
Lightclient a approuvé l’avis de Dietrichs, estimant que si la discussion avait eu lieu plus tôt, en octobre, les développeurs auraient probablement été plus tolérants envers un allongement du calendrier des tests Dencun. « Je pense aussi que nous voulions terminer la mise à niveau l’automne dernier, donc maintenant nous faisons vraiment des efforts pour y parvenir, et je crois que notre calendrier aurait dû être plus ambitieux », a-t-il ajouté.
Adhérer à un calendrier ambitieux
Sur la base des points de vue exprimés par les développeurs durant l’appel, Parithosh Jayanthi, ingénieur DevOps à la Fondation Ethereum, a suggéré de repousser d’environ une semaine la mise à niveau de la fourchette dure de Sepolia, en fixant la date de cette activation lors de l’appel ACDE du 25 janvier, après la mise à niveau de Goerli. Marius van der Wijden s’est opposé à l’idée de dépendre entièrement des appels ACDE pour rediscuter les dates d’activation des mises à niveau des testnets. « Ce que je veux absolument éviter, c’est de devoir organiser un autre appel All Core Devs juste pour confirmer la date », a-t-il dit, ajoutant : « Je déteste avoir à refaire un appel All Core Devs juste pour dire “OK, Sepolia peut commencer”. Et là, nous devons attendre deux semaines avant de pouvoir véritablement commencer Sepolia. »
Pour apaiser les tensions, le développeur Geth Guillaume Ballet a proposé de créer deux ensembles de dates provisoires pour la fourchette dure de Sepolia : un ensemble à suivre si les résultats de la fourchette dure de Goerli sont positifs, et un autre en cas de résultats négatifs. Toutefois, tant Lightclient que Dietrichs se sont opposés à cette idée, arguant qu’il faudrait d’abord évaluer la nature des bogues et problèmes sur Goerli avant de fixer un nouveau calendrier pour Sepolia.
Au passage, un développeur anonyme utilisant le pseudonyme « Danceratopz », membre de l’équipe de test de la Fondation Ethereum, a demandé si les développeurs voulaient attendre d’avoir évalué le problème d’expiration des blobs sur le réseau test Goerli avant de procéder à la mise à niveau de Sepolia. Pour rappel, l’expiration des blobs fait référence à la suppression des données blob de l’état Ethereum après environ deux semaines.
Sean de Lighthouse et Justin Florentine de l’équipe Besu ont tous deux plaidé pour évaluer l’expiration des blobs sur l’un des trois testnets avant l’activation sur le réseau principal. Florentine a insisté sur le fait que l’attente de l’expiration des blobs sur les testnets profiterait également aux équipes de protocoles Rollup de deuxième couche et aux développeurs d’applications pour se préparer à la mise à niveau Dencun. Sean de Lighthouse a déclaré que bien que l’observation de l’expiration des blobs sur Goerli ne soit pas essentielle, cela pourrait justifier un allongement de la période de test entre Sepolia et Holesky, afin que les développeurs et les équipes de deuxième couche puissent vivre l’intégralité du cycle de vie des blobs sur Sepolia. Aucun autre développeur n’a explicitement approuvé la suggestion de Sean durant l’appel.
À la place, Lightclient a demandé aux développeurs s’ils étaient d’accord pour maintenir le calendrier proposé par Beiko : mise à niveau de Sepolia le 30 janvier, suivie une semaine plus tard par celle de Holesky le 7 février. Comme aucun désaccord supplémentaire n’a été exprimé, Lightclient a annoncé que les développeurs maintiendraient le calendrier initial. Potuz a écrit dans le chat Zoom qu’il préférait activer simultanément les deux réseaux tests Sepolia et Holesky le 7 février, plutôt que d’avancer Sepolia d’une semaine. Dans un message Discord post-appel, Lightclient a confirmé à nouveau que le calendrier des testnets pour Dencun restait temporairement inchangé.
Prague/Electra
Ensuite, les développeurs ont discuté des EIP prioritaires pour la prochaine mise à niveau après Dencun, Prague/Electra. Marius van der Wijden a déclaré que les développeurs devraient concentrer leurs efforts sur la mise à niveau de l’arbre de Merkle pour Prague/Electra, plutôt que sur d’autres EIP. Il a complété ce point par deux considérations. La première concerne l’état de préparation de l’arbre de Merkle. Comme discuté lors de ACDE #177, les développeurs prévoient d’organiser un appel ACDE spécial pour examiner en détail l’implémentation de l’arbre de Merkle et son état de préparation pour la fourchette dure.
La deuxième considération mentionnée par van der Wijden porte sur la possibilité de découpler les mises à jour de la couche d’exécution (EL) de celles de la couche de consensus (CL). Il a indiqué qu’il existait sur la CL des EIP « à haute priorité, très urgents », qui pourraient nécessiter une mise en œuvre plus rapide que celle de la mise à jour de l’arbre de Merkle sur l’EL. « Il est important que les membres de la couche de consensus discutent s’ils doivent effectuer une fourchette dure pour ces changements [urgents], s’ils peuvent le faire sans participation de l’EL, ou si l’EL doit participer, auquel cas nous devrons réaliser une fourchette dure conjointe — et dans ce cas, j’accepterais une fourchette dure plus petite », a dit van der Wijden. « Donc, l’arbre de Merkle est clairement prioritaire, et nous devrions le promouvoir en tenant compte de ces deux aspects. »
Ansgar Dietrichs, chercheur à la Fondation Ethereum, a écrit dans le chat Zoom qu’il s’opposait « fermement » à ce que la mise à niveau Prague/Electra se concentre sur l’arbre de Merkle, car la complexité des modifications de code requises risquerait de retarder la mise à niveau jusqu’en 2025. Lukasz Rozmej, développeur client Nethermind, a partagé cet avis. « Mon expérience me dit que la refonte de l’état est extrêmement difficile et prend beaucoup de temps », a-t-il ajouté. « Bien que je pense que l’arbre de Merkle est excellent et que de grands progrès soient accomplis, je crois que si nous nous concentrons uniquement dessus, la prochaine fourchette dure prendra au moins un an, voire plus. Je recommande donc de se concentrer peut-être sur des fourchettes plus petites, tout en continuant à travailler chacun sur l’arbre de Merkle, en y consacrant les ressources, le travail et les efforts intellectuels appropriés, appelez ça comme vous voulez. »
Concentration sur l’arbre de Merkle
Les développeurs divergent sur la question de savoir si Prague/Electra devrait se concentrer sur l’arbre de Merkle ou privilégier des modifications de code plus petites et plus rapides à publier. Ballet a souligné qu’à ses yeux, « il n’existe pas de petite fourchette » et que plus les développeurs attendront avant d’implémenter l’arbre de Merkle, plus la mise à jour de l’état d’Ethereum sera difficile à réaliser. Tomasz K. Stańczak, également développeur client Nethermind, a suggéré une approche ambitieuse, consistant à intégrer davantage d’EIP que ce que Prague/Electra pourrait contenir. « [Utilisons] la capacité des équipes cette année pour prouver que nous pouvons relever les défis les plus importants. Si finalement l’arbre de Merkle montre aux équipes que les difficultés s’accumulent vers mars, on pourra à nouveau remettre en question la décision et dire “bon, l’arbre de Merkle est mis de côté”. Mais nous continuerons avec un ensemble d’autres EIP tout à fait valables que nous inclurons », a déclaré Stańczak, citant notamment d’autres EIP importants susceptibles d’être inclus dans Prague/Electra en plus de l’arbre de Merkle, comme ceux liés au stake, au re-stake et à l’abstraction de comptes.
En réponse à Stańczak, Lightclient a déclaré qu’il serait difficile, une fois qu’une série d’EIP aurait été promise, de continuer à discuter de ceux qui devraient figurer dans Prague/Electra, surtout lorsque l’un d’eux (l’arbre de Merkle) représente un projet nécessitant 18 à 24 mois. Andrew Ashikhmin, développeur du client Erigon, a préconisé la publication d’EIP plus petits dans la fourchette Prague/Electra tout en développant simultanément l’arbre de Merkle pour une utilisation dans une future fourchette. Ballet a soutenu la suggestion de Stańczak de se concentrer sur l’arbre de Merkle dans Prague/Electra, tout en envisageant de le retirer de la mise à niveau si des problèmes majeurs apparaissaient lors de son implémentation, nécessitant plus de temps.
Focus sur les mises à jour de la CL
Concernant la séparation des mises à jour EL (couche d’exécution) et CL (couche de consensus), Potuz a indiqué qu’un seul EIP proposé pour Prague/Electra nécessitait exclusivement des modifications de la CL. « Le seul changement est l’abolition du comité d’index d’authentification... Et tous les autres changements, même ceux qui semblent concerner uniquement la CL comme Max EB, dépendent de modifications supplémentaires de l’EL. Je pense donc qu’une fourchette purement CL n’aura pas lieu. Du moins, je ne pense pas que cela arrivera cette année ni l’année prochaine. Nous n’avons pas assez de propositions purement CL », a-t-il dit.
Néanmoins, Ansgar Dietrichs a indiqué qu’il existait des EIP principalement centrés sur la CL, nécessitant seulement de légères modifications de l’EL, faciles à exécuter par les équipes clientes EL. Ces EIP exigeraient tout de même une coordination de fourchette dure entre EL et CL. Dietrichs a ensuite ajouté qu’à son avis, du côté CL, l’échantillonnage de disponibilité des données (DAS) constituait la modification de code la plus importante après EIP-4844. Dietrichs et Lightclient ont eu quelques désaccords sur la nécessité d’une fourchette dure pour implémenter le DAS.
Intérêt pour EOF et autres EIP
Un développeur anonyme utilisant le pseudonyme « Rodiazet », membre de l’équipe Ipsilon de la Fondation Ethereum, qui travaille sur la recherche autour de la machine virtuelle Ethereum (EVM). Pour rappel, EOF signifie EVM Object Format, une série d’améliorations de l’EVM initialement envisagées pour la mise à niveau Cancun/Deneb.
Outre l’arbre de Merkle, les développeurs ont proposé d’autres EIP à considérer, tels que EIP-5920 (opcode PAY) et EIP-2537 (précompilations pour opérations sur courbe BLS12-381). La liste complète des EIP candidats pour Prague/Electra est disponible dans le fil méta des mises à niveau sur le site Ethereum Magicians. Bien que la majorité des développeurs soient favorables à accorder une certaine priorité à l’arbre de Merkle après la mise à niveau Cancun/Deneb, il reste incertain dans quelle mesure il devrait primer sur d’autres EIP plus petits, réalisables plus rapidement et facilement en 2024. Lightclient a souligné que les développeurs n’avaient pas besoin de prendre une décision finale cette semaine sur le contenu de Prague/Electra. Il a suggéré de poursuivre la discussion sur ce sujet lors des prochains appels ACDE.
Par la suite, les développeurs ont rapidement abordé d'autres EIP du thème Prague/Electra qui n'ont pas encore été discutés durant l'appel, notamment :
-
EIP-7002 : Déclenchement depuis la couche d'exécution pour sortie
-
EIP-7549 : Déplacement de l'index du comité hors de l'attestation
-
EIP-3074 : Opcodes AUTH et AUTHCALL
-
EIP-6110 : Dépôts de validateurs sur chaîne
-
EIP-6913 : Instruction SETCODE
-
EIP-7377 : Transactions migratoires
-
EIP-4444 : Limitation des données historiques dans les clients d'exécution
-
EIP-6404 : Racine des transactions SSZ
-
EIP-6465 : Racine des extractions SSZ
-
EIP-6466 : Racine des reçus SSZ
-
EIP-7212 : Précompilation supportant la courbe secp256r1
Pour un aperçu détaillé des opinions exprimées sur ces EIP, voir l'enregistrement complet de l'appel disponible sur YouTube.
Formalisation officielle de l’EIP 7587
Enfin, Carl Beekhuizen, chercheur à la Fondation Ethereum, a relancé la discussion sur l’EIP 7587, qui vise à réserver un ensemble d’adresses précompilées pour usage par les protocoles de deuxième couche. Beekhuizen a demandé aux développeurs quelle serait la meilleure manière de formaliser cet EIP pour en faire un document informatif, servant de référence pour les futures procédures de gouvernance d’Ethereum. Ahmad Bitar, développeur chez Nethermind, a suggéré d’inclure cet EIP dans le fichier EIP-1, qui décrit les directives du processus EIP. Lightclient a proposé de poursuivre la discussion sur ce sujet sur Ethereum Magicians, et de le reprendre si nécessaire lors du prochain appel ACDE.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@galaxyhq
