Résumé de la dernière réunion des principaux développeurs d'Ethereum : lancement de la mise à niveau de Pectra, discussion sur les progrès de la mise en œuvre de PeerDAS

Titre original : "Ethereum All Core Developers Consensus Call #138 Writeup"

NDLR :

Ether L'appel de consensus de tous les principaux développeurs (ACDC) a lieu toutes les deux semaines pour discuter et coordonner les modifications apportées à la couche de consensus Ethereum (CL). Il s'agit de la 138e conférence téléphonique de l'ACDC. Cette conférence couvre le lancement de Pectra Devnet 1, les modifications apportées au corps du bloc de balise et à la structure de l'API du moteur, ainsi que l'inclusion des propositions d'amélioration Ethereum (EIP) du conteneur stable dans Pectra, à savoir EIP 7688 et EIP 7495. et mises à jour PeerDAS et autres sujets. Au cours de la réunion, les développeurs ont examiné l'état de préparation des mises à niveau de Pectra et ont discuté de certaines questions et propositions ouvertes concernant la mise en œuvre de PeerDAS. En outre, le développeur de Nimbus, Etan Kissling, a également partagé les progrès des travaux de mise en œuvre des EIP 7688 et EIP 7495, soulignant l'importance de ces propositions pour mettre à niveau la méthode de sérialisation des données Ethereum. Christine Kim, vice-présidente de la recherche chez Galaxy Digital, a enregistré en détail les points clés de cette réunion, et BlockBeats a compilé le texte original comme suit :

Le 25 juillet 2024, les développeurs d'Ethereum ont tenu le 138e Consensus des développeurs All-Core (ACDC). ) via Zoom )Réunion. La conférence ACDC est une série de réunions bihebdomadaires 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. La session de cette semaine a été animée par Alex Stokes, chercheur à la Fondation Ethereum (EF). Les développeurs ont discuté des points suivants : ·Lancement de Pectra Devnet 1
·Modifications apportées au corps du bloc de balise et à la structure de l'API du moteur·Incorporation des propositions d'amélioration d'Ethereum (EIP) de conteneur stable dans Pectra, connues sous le nom d'EIP 7688 et EIP 7495 · Mises à jour de PeerDAS et de son calendrier de mise en œuvre sur le réseau principal
Pectra Devnet 1 Pectra Devnet 1 a été mis en ligne le mardi 23 juillet. Cependant, le réseau n'est pas stable. Parithosh Jayanthi, ingénieur DevOps à la Fondation Ethereum, a déclaré que le client d'Erigon avait rencontré des problèmes peu de temps après le lancement du devnet. Ensuite, une transaction EIP 7702 diffusée sur le devnet a provoqué la division du réseau en trois états. Les développeurs déboguent le client et résolvent les problèmes de division de chaîne.
Présentation d'ExecutionPayloadEnvelope
Le développeur de Prysm, Potuz, a proposé des améliorations majeures à la structure de charge d'exécution du bloc de chaîne de balise, ainsi que des ajustements correspondants à l'API du moteur. Cette proposition vise à simplifier le processus de stockage et de traitement des données de transition d'état par les clients Consensus Layer (CL). Avec la mise en œuvre de la mise à niveau de Pectra, les clients CL doivent accéder à des parties spécifiques de la charge d'exécution pour effectuer correctement les transitions d'état. Cependant, la conception existante amène ces clients à ignorer certaines informations non essentielles lors de la charge d'exécution.
Les mises à niveau de Pectra nécessiteront que les clients CL demandent les données de transition d'état nécessaires à la couche d'exécution (EL) ou stockent localement les parties critiques des blocs. Afin d'améliorer l'efficacité du client CL après la mise à niveau de Pectra, Potuz a suggéré d'introduire une nouvelle structure appelée « bind_execution_payload_envelope » pour stocker de manière centralisée les informations clés requises pour les transitions d'état d'exécution. De telles améliorations augmenteront considérablement la vitesse et l'efficacité des clients CL dans le calcul des transitions d'état. Il a également souligné que ces ajustements garantiront la compatibilité avec les futures mises à niveau du réseau telles que le format Simple Serialization (SSZ).

Mark Mackey, le développeur du projet Lighthouse, a averti que si ces changements ne sont pas mis en œuvre, les performances du client CL sur le testnet Pectra pourraient être affectées. Mikhail Kalinin, développeur du projet Teku, s'est montré prudent, se demandant si des changements de protocole étaient vraiment nécessaires pour répondre à la complexité de la mise en œuvre des EIP à Pectra. Potuz insiste sur le fait qu'il existe des problèmes fondamentaux dans la conception du protocole existant et qu'ils doivent être corrigés. Il a souligné : « La conception actuelle est conceptuellement erronée. Elle mélange des données essentielles aux transitions d'état CL avec des données totalement indépendantes au même niveau et dans le même message. Par conséquent, je pense que la conception actuelle est erronée. Nous travaillons dur. pour corriger cette erreur."

Stokes encourage les développeurs à continuer de discuter de cette proposition sur GitHub.

Mise à jour de l'API du moteur pour Devnet 2

En rapport avec la discussion ci-dessus, le développeur de Geth "Lightclient" a proposé une autre modification de l'API du moteur. Ce changement vise à faciliter la conversion de blocs pour les clients EL. Les clients EL déterminent la version du bloc en interprétant les champs nuls et nuls du bloc. Cependant, en raison de l'EIP 7685 de Prague, sans planification de fork, les clients EL ne pourront pas différencier les versions de bloc en fonction de ces champs. Pour éviter la surcharge liée au référencement d'un calendrier de mises à niveau passées, Lightclient propose d'unifier toutes les requêtes en un seul type dans l'API du moteur, que EL peut transmettre à CL pour interprétation.

Lightclient souligne que l'interprétation des morceaux diffère entre EL et CL, et que dans ce cas, CL est mieux adapté pour représenter les données de la requête. "Lorsque nous traitons des blocs eux-mêmes, il n'y a aucune notion de" Ceci est un bloc Bellatrix ", comme sur CL. Je pense que vous avez fait du bon travail en distinguant les différents types de blocs fourchus. Mais dans On EL, Je pense que c'est ainsi que presque tous les clients sont implémentés, nous avons un bloc qui représente tous les types de blocs et nous utilisons la présence, disons, d'une valeur nulle pour déterminer si ce [fork] est actif."

Développeur Nimbus "Dustin " s'est opposé à cette proposition, affirmant que la proposition de Lightclient ne répondait pas pleinement à la complexité de l'interprétation des blocs sur EL et CL. "Cela déplace simplement la complexité et la confusion de l'EL vers le CL, et les deux endroits sont viables. Le déplacer vers le CL ne résout pas le problème. … Cela déplace simplement le problème", a déclaré Dustin.

Stokes affirme que CL est mieux adapté pour gérer l'interprétation des requêtes et recommande aux développeurs d'examiner de plus près les modifications de l'API du moteur proposées par Potuz et Lightclient sur GitHub.

EIP 7688 et 7495 à Pectra

Le développeur de Nimbus Etan Kissling a fait pression pour une mise à jour de la méthode de sérialisation Ethereum vers SSZ. Pour les besoins de Pectra, il a identifié deux EIP intermédiaires, 7688 et 7495, pour introduire des structures de données sur lesquelles les développeurs de contrats intelligents peuvent s'appuyer pour être compatibles avec les futurs changements liés au SSZ. Kissling a noté qu'il bénéficie déjà du soutien de pools de jalonnement liquide comme Rocketpool, ainsi que d'autres équipes clientes comme Teku et Lodestar.

Stokes avertit l'équipe client CL de ne pas ajouter de nouveaux EIP dans Pectra. "Pectra est déjà très gros, surtout si nous nous retrouvons avec PeerDAS dans le fork. À un moment donné, nous devons être très réalistes quant à la taille du fork et aux risques qu'il pose. Encore une fois, je suis d'accord avec Etan. Il y a des raisons à cela. fonctionnalité est précieuse dans le vide, mais je pense que c'est l'un des plus gros hard forks que nous ayons jamais fait, ou le plus gros, et cela ne devrait pas être pris à la légère", a-t-il déclaré.

Les développeurs ont exprimé certaines inquiétudes quant au moment où ces EIP peuvent réellement être ajoutés au devnet Pectra, car les devnet Pectra n'ont pas encore intégré de nombreux EIP tels que PeerDAS et EOF. À cet égard, Jayanthi recommande d'abord de décider clairement si les développeurs doivent inclure ces EIP dans les mises à niveau. Jayanthi a également averti qu'il existe un goulot d'étranglement lors du test conjoint de CL et EL EIP sur un devnet. Il a écrit dans un chat Zoom : "Expédier 10 EIP directs ensemble rendrait très compliqué la création et les tests de combinaisons. Et nous n'avons pas seulement des EIP directs

Mackey a partagé cela comme l'essaye l'équipe de développeurs d'applications EigenLayer." pour comprendre ce qui devrait être activé dans Pectra, et le manque persistant de clarté sur ces deux EIP est un obstacle à leurs efforts. Le développeur de Lighthouse, Sean Anderson, recommande d'obtenir davantage de commentaires des développeurs d'applications sur Ethereum sur ces EIP afin de déterminer leur importance pour l'application.

Stokes suggère de revenir sur cette discussion à une date ultérieure afin que les développeurs puissent se concentrer sur la résolution des problèmes de Pectra Devnet 1.

Mise à jour PeerDAS

Les développeurs ont eu une discussion approfondie sur les derniers progrès de PeerDAS. Anderson rapporte que l'équipe client Consensus Layer (CL) résout activement les problèmes découverts lors du cycle précédent du devnet de PeerDAS et assure la stabilité de la mise en œuvre avant de lancer un nouveau devnet. Gajinder Singh, développeur de Lodestar et EthereumJS, a déclaré que, sur la base des commentaires d'une récente réunion des implémenteurs de PeerDAS, la communauté est intéressée par l'intégration de PeerDAS dans le prochain devnet Pectra.

Stokes a proposé que, sur la base de discussions avec l'équipe de recherche de la Fondation Ethereum (EF) et d'autres développeurs, la fonction d'échantillonnage devra peut-être être omise lors de l'activation initiale de PeerDAS sur le réseau principal afin de réduire la complexité de la mise en œuvre. Il a expliqué que la mise en œuvre complète de PeerDAS implique trois fonctions clés : la distribution, l'échantillonnage et la reconstruction. "Actuellement, la spécification PeerDAS dans Pectra couvre ces trois tâches. Mon intuition me dit que la fonction d'échantillonnage est probablement le point le plus complexe de l'implémentation. Si l'échantillonnage pose un défi insurmontable, nous pourrions envisager de l'implémenter dans Pectra. Augmenter le nombre de blobs tout en réduisant ou en ajustant la portée de PeerDAS", a expliqué Stokes.

Stokes a promis qu'il élaborerait une proposition formelle sur l'idée et l'explorerait davantage avec la communauté des développeurs. Singh soutient cela. Stokes a également recommandé que PeerDAS soit officiellement inclus dans la mise à niveau de Pectra. En réponse, Jayanthi a demandé si cela signifiait redéfinir la spécification PeerDAS basée sur la spécification Pectra, notant que la fusion des réseaux de développement PeerDAS et Pectra pourrait compliquer les efforts de débogage car les deux sont instables. Il a suggéré que l'indépendance des deux flux de travail soit maintenue jusqu'à ce que la spécification soit stable. Le développeur de Teku, Enrico Del Fante, est d'accord avec Jayanthi.

Stokes a noté que de nombreux développeurs concentrés sur la mise en œuvre de PeerDAS n'ont pas pu assister à la réunion. Il a proposé de continuer à discuter des étapes futures de PeerDAS lors de la prochaine réunion des responsables de la mise en œuvre de PeerDAS.

Ajout de BeaconBlocksByRange V3

Le développeur du projet Lighthouse "Dappion" a proposé un plan d'amélioration pour aider les clients à se synchroniser plus efficacement avec la chaîne principale en cas de scission de chaîne à long terme. Il a souligné que le protocole RPC existant [BeaconBlocksByRange V2] présente certaines limites : "Lorsque vous devez synchroniser un bloc à longue fourche et que vous ne savez pas quelle branche est la chaîne principale, selon le protocole actuel, il vous suffit de soumettre un plage d'emplacements, le nœud renverra le bloc qu'il pense être correct. Bien que vous puissiez interroger ces informations via des messages d'état, ce processus est asynchrone et peut causer certains problèmes. Bien qu'il n'y ait actuellement aucune situation sérieuse sur le réseau principal, mais si un. un incident similaire se produira à l'avenir, ce sera un problème qui devra être résolu. "

Dapplion a en outre expliqué que la solution qu'il a proposée est relativement simple et pourrait même être incluse dans la prochaine mise à niveau de Pectra. Bien que ces améliorations ne soient pas imminentes, Stokes a encouragé les développeurs présents à examiner attentivement la proposition et à partager leurs réflexions et suggestions sur GitHub.

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!