Résumé de la dernière réunion des principaux développeurs d'Ethereum : activation de PeerDAS, augmentation de la limite de gaz blob

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

Note de l'éditeur : L'Ethereum All Core Developers Consensus Call (ACDC) a lieu toutes les deux semaines, principalement pour discuter et coordonner le consensus. sur Ethereum Modifications apportées à la couche de consensus (CL). Il s'agit de la 135e conférence téléphonique de l'ACDC. Cette conférence se concentre principalement sur la préparation du réseau de test des propositions d'amélioration d'Ethereum (EIP) Pectra Devnet 1, PeerDAS Devnet 1 et Simple Serialize (SSZ).

Les développeurs ont eu des discussions approfondies sur la maintenance des progiciels, le processus d'inclusion EIP et la dénomination du nouveau cycle de mise à niveau de la couche consensus Ethereum. En outre, la session a abordé les progrès de la mise en œuvre dans le cadre de la spécification Electra, l'impact des modifications du réseau PeerDAS sur la façon dont les nœuds Ethereum traitent et valident les données, ainsi que les problèmes d'ingénierie complexes liés à l'augmentation des limites de gaz blob.

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 13 juin 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°135. L'appel ACDC est une série bihebdomadaire organisée par Alex Stokes, chercheur à la Fondation Ethereum, où 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 ont discuté des préparatifs pour Pectra Devnet 1, PeerDAS Devnet 1 et un troisième réseau de test dédié pour les propositions d'amélioration Ethereum (EIP) Simple Serialize (SSZ).

Annonces

Les développeurs ont commencé la réunion avec deux annonces. Parithosh Jayanthi, ingénieur DevOps de la Fondation Ethereum, a déclaré que l'équipe ethPandaOps, un groupe d'ingénieurs travaillant dans Ethereum Foundation DevOps (EF DevOps), prendra en charge la maintenance et le développement du module Kurtosis du package Ethereum. Ce package a été utilisé par les développeurs dans le passé pour lancer des réseaux de test Ethereum et des outils associés, tels que le tableau de bord de données Grafana pour surveiller et tester diverses implémentations client. La migration de ce package de l'équipe technique Kurtosis vers l'équipe ethPandaOps peut impacter les utilisateurs car certains liens redirigeront vers des référentiels GitHub gérés par l'équipe ethPandaOps et non plus l'équipe Kurtosis. Jayanthi conseille aux utilisateurs de mettre à jour leurs liens logiciels et de garder un œil sur les nouvelles versions de l'équipe ethPandaOps.

La deuxième annonce a été faite par Tim Beiko, responsable du support du protocole à la Fondation Ethereum. Beiko a déclaré qu'il travaillait à l'introduction d'un nouveau processus pour inclure les EIP dans les mises à niveau d'Ethereum par étapes. Il a créé un projet d'EIP qui définit les étiquettes « Proposé pour inclusion », « Considéré pour inclusion » et « Programmé pour inclusion ». Il espère que les développeurs examineront le document et fourniront leurs commentaires. Il espère que le document sera terminé avant la prochaine réunion de l'ACD.

Electra

La spécification du code pour la prochaine version majeure d'Electra v1.5.0-alpha.3 est presque terminée. Les développeurs ont convenu de fusionner la pull request (PR) #3768 du référentiel GitHub de spécification de consensus dans la prochaine version. La pull request a été créée par Etan Kissling, développeur de Nimbus, qui a souligné que le champ « committee_bits » devrait être ajouté à la fin de « Attestation » plutôt qu'au milieu des données pour éviter les problèmes de sérialisation des données. En plus du PR #3768, Stokes a demandé s'il y avait d'autres problèmes ouverts qui devaient être résolus avant la publication de la prochaine version majeure de la spécification Electra. Jayanthi a mentionné dans le chat Zoom qu'il existe des problèmes en suspens avec l'intégration des validateurs déclenchés via la couche d'exécution (EL). Stokes a pris note du suivi de l'état de l'intégration du validateur déclenché par EL après la réunion.

Concernant l'avancement de la mise en œuvre de la dernière spécification Electra, la plupart des équipes clientes de la couche consensus (CL) présentes lors de la réunion ont déclaré qu'elles seraient en mesure de préparer la nouvelle version pour les tests d'ici une à deux semaines après la v1.5.0-alpha. .3 est finalisé . Les développeurs ont convenu de revoir le calendrier du prochain réseau de développement Pectra, Pectra Devnet 1, dans quelques semaines.

PeerDAS

Ensuite, les développeurs ont discuté de l'avancement de la mise en œuvre de PeerDAS. PeerDAS est une amélioration du réseau d'Ethereum qui améliorera la capacité des nœuds à traiter et à vérifier de grandes quantités de données arbitraires soumises par les utilisateurs via des transactions blob. Stokes a rappelé la décision prise lors de la dernière réunion de l'ACDC selon laquelle les développeurs développeraient PeerDAS en parallèle avec d'autres EIP Pectra, en activant un cycle d'activation distinct pour PeerDAS sur le réseau de développement.

Le développeur de Lodestar, Gajinder Singh, a déclaré que, sur la base des discussions lors d'une récente session en petits groupes sur PeerDAS, les développeurs activeront PeerDAS en plus de la mise à niveau de Deneb et sur un réseau de développement distinct des autres EIP Pectra. Le développeur de Teku, Enrico Del Fante, a déclaré qu'il serait plus facile pour les développeurs de créer PeerDAS sur les spécifications de code stable déjà établies dans la précédente mise à niveau d'Ethereum Deneb, plutôt que sur les spécifications de code Pectra en constante évolution. Jayanthi a convenu que la fusion de l'implémentation PeerDAS avec d'autres implémentations de Pectra EIP pourrait désormais entraîner des complications lors des tests, en particulier lorsque l'on tente d'identifier la source des erreurs. Il a suggéré de conserver les deux flux de travail séparés, puis de les fusionner une fois que leurs implémentations seront plus stables. Stokes a accepté, affirmant que les développeurs pourraient revoir la fusion de PeerDAS et d'autres implémentations de Pectra EIP dans environ un mois.

En ce qui concerne le lancement de PeerDAS Devnet 1, l'équipe client n'a pas d'estimation claire du moment où le testnet sera prêt pour le lancement. Les estimations individuelles lors des séances variaient environ de 2 semaines à 1 mois. Stokes a suggéré de revoir le calendrier de développement du réseau dans quelques semaines, lorsque l'équipe client aura plus de temps pour travailler sur la mise en œuvre de PeerDAS.

Beiko a ensuite souligné que même si PeerDAS est une amélioration du réseau plutôt qu'une modification du protocole principal Ethereum, il souhaite toujours que les modifications de code soient incluses dans le méta-EIP pour la mise à niveau de Pectra. Le document méta-EIP est un document public qui répertorie toutes les modifications de protocole de base incluses dans la mise à niveau d'Ethereum. Beiko a souligné que PeerDAS est la « plus grande fonctionnalité » de Pectra, et bien qu'elle ne nécessite pas d'activation par hard fork, elle devrait quand même être incluse dans la documentation pour montrer que les développeurs souhaitent sérieusement qu'elle soit prête à temps pour l'activation du réseau principal de Pectra. Aucune objection à cela.

Augmentation de la limite de gaz blob

PeerDAS modifie la façon dont les nœuds traitent et propagent les données via la couche réseau peer-to-peer Ethereum. Pour que les utilisateurs, en particulier les cumuls de couche 2, puissent bénéficier de ces changements, les développeurs doivent augmenter la limite actuelle de six blobs par bloc jusqu'à un seuil plus élevé, ce qui permettra un débit de blob (données arbitraires) plus élevé. Changer la limite de blob nécessiterait des modifications du protocole principal d'Ethereum, ce qui, comme les développeurs l'ont discuté lors d'une conférence cette semaine, pourrait impliquer un travail d'ingénierie plus complexe que la simple modification d'une valeur constante dans la pile de protocoles.

Stokes a proposé de découpler les dépendances entre la couche d'exécution (EL) et la couche de consensus (CL) lors de la modification des limites de gaz blob. Actuellement, toute modification des limites de gaz blob nécessite des modifications des protocoles EL et CL. Stokes a proposé des moyens de rompre ces dépendances, permettant aux développeurs de supprimer en toute sécurité les limites de gaz blob codées en dur d'EL et de les laisser entièrement au CL. Dankrad Feist, chercheur à la Fondation Ethereum (EF), a souligné qu'en plus du problème de dépendance entre EL et CL, l'effet d'entraînement de la modification de la limite de gaz blob sur le calcul du gaz du bloc est également important. Feist a déclaré : "La meilleure façon est de changer la façon dont le calcul est effectué. C'est probablement un bug que le calcul du prix du gaz se fasse en EL. Cela devrait être en CL, mais c'est plus difficile à changer maintenant. … Ce n'est pas facile. "

Les développeurs ont convenu de continuer à rechercher la meilleure façon d'apporter des modifications aux limites de gaz blob et aux calculs de gaz au sein des blocs. Les développeurs ont également convenu de poursuivre les discussions pour savoir si l'activation de PeerDAS à Pectra s'accompagnerait d'une augmentation de la limite de gaz blob. Les développeurs sont divisés sur la question de savoir si les changements doivent être déployés ensemble ou mis en œuvre par phases sur plusieurs hard forks.

Jayanthi a déclaré que l'intégration de ces changements était une décision "risquée" car les développeurs ne sauront pas comment PeerDAS fonctionnera tant qu'il ne sera pas activé sur le réseau principal. Barnabas Busa, ingénieur DevOps de la Fondation Ethereum (EF), a ajouté que la portée du hard fork de Pectra est déjà très vaste et ne nécessite pas de modifications de code supplémentaires. "La clé est que nous avons déjà beaucoup d'EIP et j'ai l'impression que nous continuons à en ajouter et cela ne finit jamais", a déclaré Busa. "Donc, nous devons tracer une ligne quelque part et c'est là que nous terminons. Je pense que ce sera le cas. impossible de publier PeerDAS et d'augmenter le nombre de blobs au cours de la prochaine année et demie de tests. "

Un développeur avec le pseudonyme "Francesco" a suggéré que si les changements de réseau ne s'accompagneraient pas d'une augmentation du nombre de blobs, il peut être supprimé PeerDAS pour « réduire le risque de Pectra ». Francesco a demandé : « Quel est l'avantage du PeerDAS de Pectra s'il n'augmente pas le nombre de blobs ? »

Pour illustrer davantage la difficulté de tester PeerDAS, Jayanthi a souligné que le test de l'EIP 4844 qui a introduit les blobs dans Ethereum n'a pas entièrement simulé les blobs. sur les performances et l’impact réels du réseau principal Ethereum. Jayanthi a déclaré : « Le problème est que tester le réseau est très difficile. Nous avons effectué de nombreux tests intéressants liés au 4844, mais les blobs n'ont pas fonctionné exactement de la même manière sur le réseau principal que lors des tests. Nous avons vu des nœuds plus faibles. Une question émerge. Nous constatons des problèmes de timing et des choses comme ça, c'est pourquoi même si nous pouvons simuler une situation parfaite dans le réseau de développement où PeerDAS et l'augmentation du nombre de blobs fonctionnent, cela n'a aucune implication pratique pour le réseau principal. Cela signifie que c’est la principale raison pour laquelle je pense que nous devrions procéder étape par étape au lieu de tout faire d’un coup. »

Le chercheur d'EF Ansgar Dietrichs a commenté qu'il est erroné d'associer l'augmentation du nombre de blobs à PeerDAS, car PeerDAS seul oblige déjà les développeurs à choisir une valeur pour le nombre de blobs. Bien que les développeurs puissent choisir le même numéro que sur le réseau principal Ethereum, une décision doit être prise quant au numéro que PeerDAS doit utiliser. La seule raison pour laquelle nous avons choisi le même numéro est que les développeurs ont augmenté la complexité de PeerDAS pour lui permettre de revenir au mécanisme de propagation des blob dans la spécification Deneb actuelle en cas d'erreur. Dietrichs a ajouté que les préoccupations concernant la complexité des tests renforcent encore son point de vue selon lequel Pectra devrait être activé via deux hard forks plutôt qu'un, mais cela ne signifie pas qu'il pense que PeerDAS devrait être découplé des changements du nombre de blob.

MISE À JOUR SSZ

Kissling a partagé une mise à jour des progrès sur trois EIP liés à SSZ. Il a noté que la mise en œuvre de ces EIP est déjà en cours sur plusieurs clients, notamment Teku, Grandine et Lighthouse. Les développeurs peuvent commencer à discuter du calendrier de développement du réseau pour ces EIP SSZ et éventuellement les inclure dans la portée de la mise à niveau de Pectra lors de la prochaine réunion de l'ACDC, a-t-il déclaré.

F-Star Naming

Il y a un article sur Ethereum Magicians discutant du nom de la prochaine mise à niveau Ethereum Consensus Layer (CL) après Electra. Les développeurs ont décidé d'un nom pour la mise à niveau de la couche exécutive (EL) après Prague : Osaka. Les noms des mises à niveau CL candidates sont : Fulu, Felis, Formosa et Funi. Ces noms suivent tous la convention de dénomination des étoiles majeures commençant par « F » et conviennent à la sixième mise à niveau de Beacon Chain à l’échelle du réseau. Stokes a demandé aux développeurs de l'appel de se prononcer sur le sujet sur le fil des magiciens.

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!