Conférence Ethereum ACDC #132 Minutes : Electra Devnet 0 prêt avec d’autres sujets techniques

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

Article original de Christine Kim

Compilation originale : Luccy, BlockBeats

Note de l’éditeur :

Ethereum tous les principaux appels de Consensus des développeurs (ACDC) ont lieu toutes les deux semaines pour discuter et coordonner les modifications apportées à la couche Ethereum Consensus (CL). Il s’agit de la 132e conférence téléphonique de l’ACDC, au cours de laquelle les développeurs ont partagé des mises à jour sur le premier Testnet Pectra Devnet (Pectra Devnet 0), discuté des questions ouvertes concernant la spécification et mis en évidence les projets de recherche liés à la publication réseau et à l’échantillonnage de la disponibilité des données. Il s’agit notamment des questions ouvertes sur Electra, des questions sans réponse liées à Electra et des questions ouvertes sur la recherche.

En ce qui concerne les questions ouvertes d’Electra, les développeurs se sont concentrés sur l’impact des EIP 7251 et EIP 7549, ainsi que sur les suggestions d’ajout d’une nouvelle EIP qui créerait une demande EL générique. Pour les questions en suspens liées à Electra, les discussions portent sur les changements apportés aux types d’index du conseil des validateurs, le traitement des données des dépôts des validateurs, etc. Christine Kim, VP de la recherche chez Galaxy Digital, a donné une note détaillée sur les points forts de la réunion, que BlockBeasts a compilée comme suit :

Le 21 mars 2024, les développeurs Ethereum se sont réunis à Zoom pour la session #132 de l’appel All Core Developers Consensus (ACDC). La conférence téléphonique de l’ACDC est une série de réunions bihebdomadaires organisées par Alex Stokes, membre de la Fondation Ethereum, au cours desquelles les développeurs discutent et coordonnent les modifications apportées à la couche Ethereum Consensus (CL). Cette semaine, les développeurs ont partagé une mise à jour sur leurs préparatifs pour le premier Testnet des développeurs Pectra, également connu sous le nom de Pectra Devnet 0. Ils ont discuté de questions ouvertes sur la spécification Pectra Devnet 0 et ont brièvement mis en évidence deux projets de recherche inachevés liés à la publication en réseau et à l’échantillonnage de la disponibilité des données.

Questions ouvertes sur Electra

Les développeurs de la Fondation Ethereum ont publié la spécification CL initiale et les vecteurs de test pour Pectra Devnet 0. Cependant, il existe plusieurs questions ouvertes sur ces spécifications qui peuvent ou non être résolues à temps pour le premier lancement du réseau de développement. Stokes a souligné que l’un des problèmes est lié à EIP 7251 (augmentation de MAX_EFFECTIVE_BALANCE). Les développeurs semblent se tourner vers validateurs stake ETH merge en tant qu’action déclenchable de la couche d’exécution (EL). Cependant, dans l’état actuel des choses, la fusion est définie comme une opération CL dans la spécification initiale d’Electra. « C’est une bonne chose parce que la beacon chain nécessite la même logique de traitement la plus longue, quelle que soit la source », a déclaré Stokes.

Une autre question ouverte dont les développeurs ont discuté lors de l’appel était liée à EIP 7549 (Moving Commission Indexes Outside of Proof). Les EIP modifient la façon dont les preuves de validation sont agrégées et les blocs sont formatés. Lorsque Pectra est activé, les preuves de pré-mise à niveau seront cumulées pour ne pas être compatibles plus long avec les nouvelles preuves soumises off-chain. Stokes a mis en évidence deux solutions possibles dans un problème GitHub leading jusqu’à l’appel. Voici ce qu’il écrit :

· Le client diffuse les deux formats dans 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 n’autorisez le style Deneb que pendant la première époque d’Electra.

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

Les développeurs ont discuté des deux options lors d’une conférence téléphonique. Finalement, ils ont décidé de ne pas changer la spécification Electra pour le moment, mais de voir comment ces preuves perdues affectent la sécurité du réseau sur devnet.

La troisième question en suspens discutée par les développeurs lors de la conférence téléphonique liée à Electra était l’ajout d’une nouvelle EIP à la mise à niveau qui créerait une demande EL générique. L’EIP proposé par le développeur Geth « Lightclient » simplifiera le processus d’envoi des messages de mise à jour d’EL vers CL. En raison de l’hausse des solutions de stake basées sur smart contracts, il y a eu un afflux massif d’EIP activés sur Ethereum et diverses opérations de validation pour que la proposition de Pectra se déclenche directement à partir d’EL au lieu de CL. La proposition de Lightclient crée un cadre commun pour la propagation des « requêtes déclenchées par contrat » de l’EL vers l’EL. Étant donné que l’EIP changera la façon dont Pectra est conçu, en particulier la mise en œuvre de l’EIP 6110 et de l’EIP 7002, Lightclient souligne qu’il s’attend à ce que l’équipe du client fournisse 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 pour construire et partager ses spécifications d’ici le lundi 22 avril.

Les développeurs ont ensuite discuté de deux autres questions en suspens liées à l’EIP 7549 et à l’EIP 7251 soulevées par le développeur Teku Mikhail Kalinin. Le premier concerne les changements apportés aux types d’index du conseil des validateurs, tandis que le second propose des changements dans le traitement des données des dépôts des validateurs. M. Stokes a encouragé les promoteurs à examiner les deux propositions plus en détail pour une discussion plus approfondie dans les semaines à venir.

Enfin, le dernier problème en suspens lié à la spécification Electra discutée par les développeurs est l’augmentation du nombre de blobs. Parithosh Jayanthi, ingénieur des opérations de développement à la Fondation Ethereum, a déclaré qu’il souhaitait analyser l’activité des blob de Dencun après la mise à niveau et recommander une augmentation ponctuelle du nombre de blob à inclure dans la mise à niveau d’Electra. Le chercheur de la Fondation Ethereum, Ansgar Dietrichs, a souligné qu’il avait également suggéré d’activer une augmentation progressive du nombre de blobs, ce qui devrait être considéré en parallèle avec la proposition de Jayanthi d’inclure Electra.

Rechercher des questions ouvertes

Au cours de l’appel ACD de cette semaine, les développeurs ont brièvement discuté de deux projets de recherche. Le premier est un nouvel article de recherche d’Anders Elowsson, chercheur à la Fondation Ethereum, qui propose un nouveau modèle de réflexion et de mise en œuvre des changements de politique Ethereum émission. L’article complet peut être lu ici. Stokes a encouragé les développeurs à examiner la publication lors de l’appel.

Le deuxième projet de recherche proposé par Adrian Manning, développeur de Lighthouse, concerne les sous-réseaux de preuve. Comme le dit Manning sur GitHub, « Ce PR introduit le concept de « partitionnement de réseau », qui n’est qu’un concept abstrait qui marque l’ID de nœud comme un nombre (partitionnement de réseau). Nous pouvons ensuite utiliser ce partitionnement réseau (nombre) pour allouer des rubriques auxquelles les nœuds doivent s’abonner pendant un long temps. Manning cherche à obtenir un avis final sur sa proposition afin que son équipe puisse commencer à travailler sur la solution d’échantillonnage de la disponibilité des données d’Ethereum, PeerDAS. Pour plus d’informations sur l’échantillonnage de la disponibilité des données, lisez ce rapport de Galaxy Research.

Le développeur de Nethermind, Lukasz Rozmej, a demandé si l’EIP 7547 (liste d’inclusion) avait été approuvé pour inclusion dans la mise à niveau d’Electra. Les développeurs réitèrent que l’inclusion de l’EIP 7547 n’a pas encore été approuvée.

Saulius Grigaitis, un développeur qui construit le client CL d’Ethereum appelé « Grandine », a remis en question les règles de choix de fork d’Ethereum compte tenu des recherches en cours sur PeerDAS. Grigaitis demande aux développeurs d’inclure des idées dans le groupe de travail PeerDAS.