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

Écrit par : Christine Kim

Compilé par : Luccy, BlockBeats

Note de l'éditeur : L'appel de consensus des développeurs Ethereum All Core (ACDC) a lieu toutes les deux semaines pour discuter et coordonner la mise en œuvre de la couche de consensus Ethereum (CL ) Changement. Il s'agit de la 134e conférence téléphonique de l'ACDC. Lors de cette conférence, les développeurs ont discuté 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 améliorer considérablement la capacité du réseau Ethereum à prendre en charge les cumuls et leurs exigences en matière de disponibilité des données. Au cours de la réunion, une proposition a été faite pour diviser Pectra en deux hard forks pour la mise à niveau, et les questions de temps d'activation et d'interdépendance des différents EIP ont été discutées.

La vice-présidente de la recherche de Galaxy Digital, Christine Kim, a enregistré en détail les points clés de cette réunion, et BlockBeasts a compilé le texte original comme suit :

Le 30 mai 2024, les développeurs d'Ethereum se sont réunis sur Zoom pour participer au consensus de tous les principaux développeurs. (ACDC) appel à la réunion n°134. L'appel ACDC est une série de réunions bihebdomadaires organisé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 Ethereum (CL, également connue sous le nom de Beacon Chain). Cette semaine, les développeurs discutent de leurs expériences et des problèmes en suspens depuis 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.

Devnet 0 Review

À la lumière du lancement de Pectra sur Devnet 0, l'équipe client a accepté de conserver le comportement de validation affecté par EIP 7549 inchangé pendant l'activation du hard fork. Lors d'une précédente réunion de l'ACDC, les développeurs ont envisagé diverses options pour garantir que l'impact de l'EIP 7549 n'entraînerait pas un grand nombre de vérifications invalides lors du fork. Pour éviter de compliquer davantage les mises à niveau, l'équipe client a décidé d'activer l'EIP 7549 à la même époque que les autres EIP Pectra, sans modifier le comportement de validation avant et après le fork.

Concernant l'EIP 7251, les développeurs ne savent toujours pas si les fusions d'ETH mis en jeu doivent pouvoir être déclenchées à partir de la couche d'exécution (EL). Ce serait une fonctionnalité idéale pour les pools de jalonnement comme Lido afin que la fusion des participations ne nécessite pas de dépendre des opérateurs de nœuds mais puisse plutôt être réalisée via des contrats intelligents. Stokes a recommandé de vérifier les progrès des clients mettant en œuvre les fusions de jalonnement des validateurs dans quelques semaines avant de décider s'il doit s'agir d'opérations EL ou CL.

Les développeurs ont ensuite discuté de certaines questions restées sans réponse concernant la confirmation finale des dépôts des validateurs sous EIP 6110. Le développeur de Teku, Mikhail Kalinin, a résumé les orientations pour résoudre ces problèmes dans un commentaire sur GitHub avant la conférence. Le développeur de Lighthouse, « Sean », a soulevé une question sur la gestion des versions de la requête « GetPayloadBodies » dans l'API du moteur. Stokes a recommandé aux développeurs de publier leurs commentaires dans une pull request créée pour le problème sur GitHub.

Modifications de l'EIP 7549

Le développeur de Nimbus, Etan Kissling, a suggéré un petit changement dans l'implémentation de l'EIP 7549. "Il s'agit de la stabilité de l'index généralisé. Lorsque nous ajoutons un nouveau champ au milieu du conteneur, les champs suivants se verront attribuer un nouvel index, ce qui brisera la preuve basée sur EIP 4788 au niveau d'exécution (EL), et quelques trompeurs. … Par conséquent, je recommande de déplacer le nouveau champ vers la fin pour éviter les deux problèmes", a expliqué Kissling. Il n’y a eu aucune objection à ce changement. Stokes recommande aux développeurs de consulter la pull request de Kissling sur GitHub.

Un autre changement proposé à l'EIP 7549 lors de la réunion consistait à concevoir les requêtes et autres requêtes déclenchées par EL en tant que modules complémentaires au bloc EL. Concernant ce changement, Kalinin a déclaré : "À mon avis, c'est une très bonne solution de conception, elle simplifie EL... et c'est fondamentalement une alternative aux requêtes généralisées dans le bloc de couche d'exécution. Il est recommandé que ce sujet soit." discuté à nouveau lors de la prochaine réunion du CL afin que les développeurs aient plus de temps pour examiner la proposition sur GitHub.

Discussion sur Pectra Scope

Il existe certains EIP axés sur la couche de consensus (CL) qui ne sont pas encore 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'ajouter EIP 7688 et PeerDAS à Pectra. EIP 7688 adopte une partie de la structure de données SSZ « StableContainer » pour garantir la compatibilité ascendante des modifications d'attestation d'EIP 7549. En guise d'introduction, SSZ est une structure de données utilisée dans CL, et les développeurs souhaitent également l'utiliser dans la couche d'exécution (EL). Pour plus d’informations sur la transition SSZ, consultez le procès-verbal de la réunion précédente. PeerDAS est une implémentation d'échantillonnage de disponibilité des données sur Ethereum qui devrait améliorer considérablement la capacité du réseau à prendre en charge les cumuls et ses exigences en matière de disponibilité des données. En pratique, PeerDAS devrait augmenter le nombre de transactions blob que les validateurs peuvent attacher à un bloc de 3 à 64 ou plus par bloc.

Barnabas Busa, ingénieur des opérations de développement à la Fondation Ethereum, a déclaré que les développeurs avaient lancé une première itération de PeerDAS sur un réseau de développement. "Je pense que beaucoup de clients ont découvert beaucoup de problèmes, et lorsque nous faisons des progrès substantiels, nous pouvons toujours relancer un nouveau réseau de développement", a déclaré Busa. Stokes a demandé aux développeurs s'ils seraient prêts à ajouter PeerDAS à Pectra sans provoquer de retards de mise à niveau.

Un développeur surnommé "Nishant" a relancé la suggestion de séparer l'activation de PeerDAS de l'activation d'autres EIP dans Pectra. Bien que cela soit réalisable, un autre développeur surnommé « atd » a souligné que si les développeurs envisagent d'activer ces mises à niveau les unes après les autres dans un court laps de temps, les utilisateurs doivent toujours mettre à niveau leur logiciel en même temps. atd a déclaré : « Je pense que c'est un peu fou de faire un fork deux mois après une autre mise à niveau. Si nous devons coordonner tout le monde pour mettre à niveau le client, nous ne voulons pas que tout le monde mette à niveau le client deux mois plus tard. , même pas un seul cycle de publication ne suffit. »

atd a ajouté qu'à son avis, PeerDAS est le changement de code le plus « intéressant » de l'EIP inclus et discuté dans Pectra. Stokes a déclaré qu'il espérait inclure PeerDAS dans Pectra même si cela entraîne des retards de mise à niveau. Le développeur client Grandine, Saulius Grigaitis, a proposé de supprimer EIP 7549 et EIP 7688 de Pectra au profit de PeerDAS. Cela a suscité une discussion sur les détails de mise en œuvre de l’EIP 7688. Les développeurs n'ont pas pu se mettre d'accord sur les modifications du code et la proposition sera réexaminée lors de la prochaine réunion de l'ACDC.

Sur le thème de PeerDAS, les développeurs continuent de réfléchir à l'idée de diviser Pectra en deux hard forks. Parithosh Jayanthi, ingénieur en options de développement de la Fondation Ethereum, a averti que si les développeurs divisaient Pectra en deux mises à niveau, ils devaient faire attention à ne pas ajouter d'autres EIP dans la future partie 2 de Pectra. Jayanthi a déclaré : « Une chose que je tiens à mentionner est que si nous envisageons de nous diviser en deux forks, nous devons faire très attention à ne pas ajouter de nouveaux EIP dans le prochain fork. Je ne sais pas si nous pourrons le faire. À ce point. Si nous avions pu nous engager dans quelque chose il y a un an ou un an et demi, parce que nous proposons toujours de nouvelles idées et que les priorités changent, etc. "

Continuez à discuter de deux idées de mise à niveau, le développement de Lighthouse. L'auteur "Sean" a déclaré qu'il ne prévoyait pas de nombreuses interdépendances entre PeerDAS et la liste actuelle de Pectra EIP. Par conséquent, les deux peuvent être réalisés séparément et ensuite facilement fusionnés lorsque le développeur devient plus confiant dans leur mise en œuvre. Atd a accepté, arguant qu'il n'y aurait pas beaucoup de risque à 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 Pectra EIP et PeerDAS, mais en concevant les modifications du code de manière à ce que PeerDAS soit activé une époque plus tard que Pectra EIP sur les réseaux de développement et de test. Il a noté que c'est déjà ainsi que les tests de Pectra EIP et PeerDAS sont effectués sur Devnet 0. "Il n'y a vraiment rien à changer", a déclaré Busa, ajoutant que si PeerDAS n'est pas prêt alors que les autres EIP Pectra le sont, les développeurs peuvent supprimer ce changement de code de la mise à niveau. Cela soulève plusieurs questions sur la manière dont les différentes époques d'activation de PeerDAS affectent le travail des équipes clientes. En fin de compte, les développeurs ont accepté de continuer à développer PeerDAS et Pectra EIP, mais uniquement à la condition que PeerDAS soit activé à différentes époques sur le réseau de développement et sur le réseau de test.

Comme mentionné ci-dessus, les développeurs ont convenu de laisser la discussion sur la question de savoir si l'EIP 7688 sera inclus dans Pectra jusqu'au prochain appel ACDC.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!