Dernier procès-verbal de la réunion Ethereum ACDC : progrès d'Electra Devnet 0 et autres problèmes techniques

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

Auteur original : Christine Kim

Compilation originale : Luccy, BlockBeats

Note de l'éditeur :

Ethereum All Core Developers Consensus Call (ACDC) ) se tient toutes les deux semaines pour discuter et coordonner les modifications apportées à la couche de consensus Ethereum (CL). Il s'agit de la 132e conférence téléphonique de l'ACDC. Lors de la réunion, les développeurs ont partagé les dernières informations sur le premier réseau de test des développeurs Pectra (Pectra Devnet 0), discuté des questions en suspens liées à la spécification et souligné la relation avec les projets de recherche du réseau. liés à l’échantillonnage de la disponibilité des données. Les questions couvertes comprennent les questions ouvertes d'Electra, les questions ouvertes liées à Electra et les questions ouvertes de recherche.

En ce qui concerne les problèmes ouverts d'Electra, les développeurs se concentrent sur l'impact des EIP 7251 et EIP 7549, ainsi que sur les propositions visant à ajouter un nouvel EIP qui créera des requêtes EL universelles. Pour les problèmes en suspens liés à Electra, la discussion a inclus des modifications apportées au type d'index du comité de validation, des modifications au traitement des données de dépôt du validateur, et plus encore. 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 BlockBeasts a compilé le texte original comme suit :

Le 21 mars 2024, les développeurs d'Ethereum se sont réunis sur Zoom pour participer au All Core Developers. Consensus (ACDC) appelle à des réunions n° 132. La conférence téléphonique ACDC est une série bihebdomadaire, organisée par Alex Stokes, chercheur à la Fondation Ethereum, au cours de laquelle les développeurs discutent et coordonnent les modifications apportées à la couche de consensus (CL) Ethereum. Cette semaine, les développeurs ont partagé les dernières informations sur leurs préparatifs pour le premier Pectra Developer Test Network, également connu sous le nom de Pectra Devnet 0. Ils ont discuté des questions en suspens concernant la spécification Pectra Devnet 0 et ont brièvement souligné deux projets de recherche inachevés liés à la publication réseau et à l'échantillonnage de la disponibilité des données.

Electra Open Issue

Les développeurs d'Ethereum Foundation ont publié les spécifications CL initiales et les vecteurs de test pour Pectra Devnet 0. Cependant, il existe plusieurs problèmes en suspens concernant ces spécifications qui pourraient ou non être résolus à temps pour le premier lancement de Devnet. Stokes a souligné que l'un des problèmes est lié à l'EIP 7251 (augmentation de MAX_EFFECTIVE_BALANCE). Les développeurs semblent avoir tendance à incorporer l'ETH mis en jeu par le validateur en tant qu'action déclenchable au niveau de la couche d'exécution (EL). Cependant, pour l'instant, la fusion est définie comme une opération CL dans la spécification Electra initiale. "C'est une bonne chose car la plupart de la logique de traitement requise pour la chaîne de balises est la même quelle que soit la source", a déclaré Stokes.

Un autre problème ouvert discuté par les développeurs lors de l'appel lié à l'EIP 7549 (Moving Committee Indexing Beyond Proof). EIP modifie la façon dont les preuves du validateur sont regroupées et les blocs sont formatés. Lorsque Pectra sera activé, il sera résumé que les preuves préalables à la mise à niveau ne sont plus compatibles avec les nouvelles preuves soumises en chaîne. Stokes a souligné deux solutions possibles à un problème GitHub avant l'appel. Il a écrit :

· Le client diffusait les deux formats lors de la dernière ère Deneb, en prenant soin de ne pas produire de messages biaisés.

· Étendez les blocs avec des champs supplémentaires pour les preuves pré-Electra et autorisez le style Deneb uniquement pendant la première époque d'Electra.

Deneb est le nom de mise à niveau combiné du dernier hard fork activé sur Ethereum. Electra est le nom de la mise à niveau CL pour le prochain hard fork immédiat sur Ethereum.

Les développeurs ont discuté des deux options lors de la conférence téléphonique. En fin de compte, ils ont décidé de ne pas modifier la spécification Electra pour l'instant, mais de voir comment ces preuves manquantes impactent la sécurité du réseau sur le devnet.

Le troisième problème ouvert discuté par les développeurs lors de la conférence téléphonique liée à Electra est l'ajout d'un nouvel EIP dans la mise à niveau qui créera des requêtes EL universelles. L'EIP proposé par le développeur Geth "Lightclient" simplifiera le processus d'envoi de messages de mise à jour d'EL à CL. En raison de la montée en puissance des solutions de jalonnement basées sur des contrats intelligents, il y a eu un afflux d'EIP activés sur Ethereum, avec des propositions pour que Pectra déclenche diverses opérations de validation directement depuis EL au lieu de CL. La proposition Lightclient crée un cadre commun pour propager des « demandes déclenchées par contrat » d'EL à CL. Étant donné que cet EIP va changer la façon dont Pectra est conçu, en particulier la mise en œuvre d'EIP 6110 et d'EIP 7002, Lightclient a souligné qu'il espère que l'équipe client fournira des commentaires sur sa proposition dès que possible. Les développeurs ont convenu d'essayer de finaliser l'EIP de Lightclient d'ici la fin de la semaine afin que sa spécification puisse être construite et partagée d'ici le lundi 22 avril.

Les développeurs ont ensuite discuté de deux autres problèmes ouverts liés à EIP 7549 et EIP 7251 soulevés par le développeur de Teku, Mikhail Kalinin. Le premier concerne les modifications du type d'index du comité de validation, tandis que le second propose des modifications dans le traitement des données de dépôt des validateurs. Stokes a encouragé les développeurs à examiner les deux propositions plus en détail en vue de discussions plus approfondies dans les semaines à venir.

Enfin, le dernier problème ouvert lié à la spécification Electra discuté par les développeurs est l'augmentation du nombre de blob. Parithosh Jayanthi, ingénieur des opérations des développeurs de la Fondation Ethereum, a déclaré qu'il espérait mener une analyse de l'activité des blob après la mise à niveau de Dencun et, sur la base de cette analyse, recommander une augmentation unique du nombre de blob à inclure dans la mise à niveau d'Electra. Ansgar Dietrichs, chercheur à la Fondation Ethereum, a souligné qu'il avait également proposé d'activer une augmentation progressive du nombre de blobs, ce qui devrait être envisagé parallèlement à la proposition de Jayanthi d'incorporer Electra.

Problèmes ouverts de recherche

Lors de la conférence téléphonique ACD de cette semaine, les développeurs ont brièvement discuté de deux projets de recherche. Le premier est un nouvel article de recherche rédigé par Anders Elowsson, chercheur à la Fondation Ethereum, qui propose un nouveau modèle pour réfléchir et mettre en œuvre des changements dans la politique d’émission d’Ethereum. L’article complet peut être lu ici. Stokes a encouragé les développeurs lors de l'appel à examiner le message.

Le deuxième projet de recherche proposé par le développeur de Lighthouse, Adrian Manning, concerne la preuve des sous-réseaux. Comme Manning l'a dit sur GitHub, « Ce PR introduit le concept de « partitionnement de réseau », qui n'est qu'un concept abstrait qui marque l'ID du nœud sous la forme d'un nombre (partitionnement de réseau). Nous pouvons ensuite utiliser ce partage de réseau (numéro) pour attribuer des sujets. auquel les nœuds doivent s'abonner à long terme. Manning recherche des commentaires définitifs sur sa proposition afin que son équipe puisse commencer à travailler sur PeerDAS, une solution d'échantillonnage de disponibilité des données pour Ethereum. Pour plus d'informations sur l'échantillonnage de la disponibilité des données, lisez ceci

.

Le développeur de Nethermind, Lukasz Rozmej, a demandé si l'inclusion de l'EIP 7547 (liste d'inclusion) avait été approuvée dans la mise à niveau d'Electra. Le développeur a réitéré que l'inclusion de l'EIP 7547 n'avait pas été approuvée », a déclaré le développeur du client Ethereum CL, qui a soulevé des questions sur le fork d'Ethereum. règles de sélection à la lumière des recherches PeerDAS en cours. Grigaitis a demandé aux développeurs de contribuer avec leurs idées au groupe de travail PeerDAS.

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!