Résumé de la dernière réunion des développeurs principaux d'Ethereum : Pectra pourrait être divisé en deux hard forks

Auteur: Christine Kim

Compilation: Luccy, BlockBeats

Note de l’éditeur: La réunion téléphonique de consensus des développeurs principaux d’Ethereum (ACDC) a lieu toutes les deux semaines et vise principalement à discuter et coordonner les modifications apportées à la couche de consensus d’Ethereum (CL). Cette 134e réunion téléphonique d’ACDC a permis aux développeurs de discuter des détails de mise en œuvre et des défis techniques de plusieurs EIP clés, notamment EIP 7549, EIP 7251, EIP 6110, EIP 7688, etc.

De plus, les développeurs ont également discuté en profondeur de la mise en œuvre de PeerDAS, une technologie d’échantillonnage de la disponibilité des données qui devrait considérablement améliorer la capacité du réseau Ethereum à prendre en charge les Rollups et leurs besoins en termes de disponibilité des données. Des suggestions ont été faites lors de la réunion pour diviser Pectra en deux forks durs pour une mise à niveau, et des discussions ont eu lieu sur les temps d’activation et les dépendances mutuelles des différents EIP.

Christine Kim, vice-présidente de la recherche chez Galaxy Digital, a fait un compte rendu détaillé des points saillants de cette réunion. BlockBeasts a traduit le texte original comme suit :

Le 30 mai 2024, les développeurs d’Ethereum se sont réunis sur Zoom pour assister à la réunion de consensus All Core Developers (ACDC) n°134. Les réunions téléphoniques ACDC sont une série de réunions bihebdomadaires animées par Alex Stokes, chercheur à la Fondation Ethereum, au cours desquelles les développeurs discutent et coordonnent les modifications apportées à la couche de consensus d’Ethereum (CL, également appelée beacon chain). Cette semaine, les développeurs ont discuté de l’expérience et des problèmes non résolus après le lancement de Pectra Devnet 0. Ils ont également débattu de la faisabilité d’étendre la portée de la mise à niveau de Pectra pour inclure les modifications du code des conteneurs peerDAS et SSZ.

Rétrospective Devnet 0

Selon le lancement de Pectra sur Devnet 0, l’équipe du client a accepté de maintenir le comportement de validation de l’EIP 7549 pendant la période d’activation du hard fork. Lors d’une réunion ACDC précédente, les développeurs ont envisagé plusieurs solutions pour garantir que l’impact de l’EIP 7549 pendant la période de fork n’entraîne pas une grande quantité de validations invalides. Afin d’éviter de rendre la mise à niveau plus complexe, l’équipe du client a décidé d’activer l’EIP 7549 dans la même époque que les autres EIP de Pectra et de ne pas modifier le comportement de validation avant et après le fork.

Concernant l’EIP 7251, les développeurs ne sont toujours pas certains s’ils devraient autoriser la fusion du staking ETH depuis la couche d’exécution (EL). Cela serait une fonctionnalité idéale pour des pools de staking tels que Lido, car cela éviterait de dépendre des opérateurs de nœuds pour la fusion du staking, mais plutôt la réaliser via des smart contracts. Stokes suggère de vérifier les progrès de l’implémentation client de la fusion du staking des validateurs dans quelques semaines, puis de décider s’il devrait s’agir d’une opération EL ou CL.

Les développeurs ont ensuite discuté de certaines questions non résolues concernant la confirmation finale des dépôts des validateurs en vertu de l’EIP 6110. Le développeur de Teku, Mikhail Kalinine, a résumé la voie à suivre pour résoudre ces problèmes dans un commentaire GitHub avant la réunion. Le développeur de Lighthouse « Sean » a soulevé une question sur la gestion des versions de la demande « GetPayloadBodies » dans l’API Engine. Stokes conseille aux développeurs de commenter la demande de tirage créée sur GitHub pour la bougie à longue mèche sur ce problème.

Changements EIP 7549

Le développeur de Nimbus, Etan Kissling, a suggéré une petite modification de la mise en œuvre de l’EIP 7549. “Il s’agit d’un problème de stabilité des index généralisés. Lorsque nous ajoutons un nouveau champ au milieu du conteneur, les champs suivants se verront attribuer un nouvel index, ce qui rompt la preuve basée sur l’EIP 4788 dans la couche d’exécution (EL) et est quelque peu trompeur… C’est pourquoi je suggère de déplacer le nouveau champ à la fin pour éviter ces deux problèmes.” Kissling a expliqué. Personne n’a exprimé d’opposition à cette modification. Stokes a suggéré aux développeurs de consulter la pull request de Kissling sur GitHub.

Un autre changement apporté à EIP 7549 a été apporté lors de la conférence, concevant des demandes et d’autres demandes déclenchées par EL en tant que modules complémentaires au bloc EL. Commentant ce changement, Kalinin a déclaré : « À mon avis, il s’agit d’une très bonne solution de conception qui simplifie l’EL… Et c’est essentiellement une alternative à la généralisation des requêtes dans Bloc au niveau de la couche d’exécution. » Stokes a suggéré que ce sujet soit réexaminé lors de la prochaine réunion CL pour donner aux développeurs plus de longs temps pour examiner la proposition sur GitHub.

Discussion sur la gamme Pectra

Certains EIP axés sur la couche Consensus (CL) n’ont pas été officiellement inclus ou exclus de la mise à niveau de Pectra. Lors de la réunion de cette semaine, les développeurs ont discuté de l’opportunité d’inclure EIP 7688 et PeerDAS dans Pectra. EIP 7688 utilise une partie « StableContainer » de la structure de données SSZ pour s’assurer que EIP 7549 est compatible avec les modifications apportées aux preuves. Pour la petite histoire, SSZ est une structure de données utilisée dans CL que les développeurs souhaitent également utiliser dans la couche d’exécution (EL). Pour plus d’informations longues sur la transition SSZ, veuillez consulter le procès-verbal de la réunion précédente. PeerDAS est une mise en œuvre de l’échantillonnage de la disponibilité des données sur Ethereum et devrait améliorer considérablement la capacité du réseau à support rollups et ses besoins en matière de disponibilité des données. En pratique, PeerDAS s’attend à ce que les validateurs augmentent le nombre de transactions d’objets blob pouvant être attachées à des blocs de 3 par bloc à 64 ou plus de longs.

Barnabas Busa, ingénieur de développement opérationnel de la Fondation Ethereum, a déclaré que les développeurs avaient lancé une version itérative précoce de PeerDAS sur un réseau de développement. “Je pense que de nombreux clients ont découvert de nombreux problèmes, et nous pouvons relancer un nouveau réseau de développement à tout moment lorsque nous aurons fait des progrès substantiels”, a déclaré Busa. Stokes a demandé aux développeurs s’ils étaient prêts à ajouter PeerDAS à Pectra, même si cela pourrait entraîner un retard dans la mise à niveau.

Un développeur nommé “Nishant” a proposé à nouveau de séparer l’activation de PeerDAS de l’activation des autres EIP de Pectra. Bien que cela soit faisable, un autre développeur nommé “atd” a souligné que si les développeurs prévoient d’activer ces mises à niveau les unes après les autres dans un court laps de temps, les utilisateurs devront quand même mettre à niveau leur logiciel en même temps. Atd a déclaré : “Je pense que bifurquer deux mois après une autre mise à niveau est un peu fou. Si nous devons coordonner la mise à niveau de tous les utilisateurs du client, nous ne voulons pas les faire mettre à niveau tous en même temps deux mois plus tard. Dans ce cas, même un cycle de publication ne suffirait pas.”

atd a ajouté qu’à son avis, PeerDAS est le changement de code le plus « intéressant » parmi les EIP inclus et discutés dans Pectra. Stokes a déclaré qu’il souhaitait inclure PeerDAS dans Pectra, même si cela entraînait une latence de mise à niveau. Le développeur client de Grandine, Saulius Grigaitis, a proposé de supprimer EIP 7549 et EIP 7688 de Pectra en faveur de PeerDAS. Cela a déclenché une discussion sur les détails de la mise en œuvre de l’EIP 7688. Les développeurs n’ont pas réussi à s’entendre sur les changements de code et réexamineront la proposition lors de la prochaine réunion de l’ACDC.

En ce qui concerne PeerDAS, les développeurs continuent de réfléchir à l’idée de scinder Pectra en deux hard forks. Parithosh Jayanthi, ingénieur en options des développeurs à la Fondation Ethereum, avertit que si les développeurs divisent Pectra en deux mises à niveau, ils doivent faire attention à ne pas ajouter plus de longues EIP dans la future partie 2 de Pectra. « Une chose que je veux mentionner est que si nous pensons à nous diviser en deux forks, nous devons faire très attention à ne pas ajouter les nouveaux EIP les plus longs au prochain fork », a déclaré Jayanthi. Je ne sais pas si nous y parviendrons. Si nous pouvons nous engager dans quelque chose il y a un an ou un an et demi parce que nous avons toujours de nouvelles idées, les priorités changent, et ainsi de suite.

Poursuivant avec l’idée de deux mises à niveau, le développeur de Lighthouse « sean » a déclaré qu’il ne prévoyait pas d’interdépendances nostalgiques entre PeerDAS et la liste actuelle des EIP Pectra. Par conséquent, les deux peuvent être réalisés séparément et facilement fusionnés plus tard lorsque les développeurs sont plus confiants dans leur mise en œuvre. Atd est d’accord avec ce point de vue et estime qu’il n’y a pas beaucoup de risques à fusionner Pectra EIP, PeerDAS et EIP 7688 après les avoir développés et testés séparément.

Busa recommande de continuer à tester l’EIP Pectra et PeerDAS, mais de concevoir le changement de code de manière à ce que PeerDAS s’active une époque plus tard que l’EIP Pectra sur le réseau de développement et le réseau de test. Il souligne que c’est déjà le moyen de tester Pectra EIP et PeerDAS sur Devnet 0. « Il n’y a vraiment rien à changer », a déclaré Busa, ajoutant que les développeurs peuvent supprimer le changement de code de la mise à niveau si PeerDAS n’est pas prêt au moment où les autres EIP Pectra sont prêts. Cela soulève plusieurs questions sur la façon dont les différentes époques d’activation de PeerDAS affectent le travail de l’équipe client. Finalement, les développeurs ont accepté de continuer à développer les EIP PeerDAS et Pectra, à condition que PeerDAS soit activé à différentes époques sur le réseau de développement et le réseau de test.

Comme mentionné précédemment, les développeurs ont convenu de reporter la discussion sur l’inclusion de l’EIP 7688 dans Pectra lors de la prochaine réunion téléphonique ACDC.