Résumé de la dernière réunion des principaux développeurs d'Ethereum : progrès final de la mise à niveau de Dencun et discussion sur la portée de la mise à niveau de Pectra

Compilé par : Luccy, BlockBeats

L'appel de consensus des développeurs Ethereum Core (ACDC) est organisé régulièrement pour discuter et coordonner les ajustements de la couche de consensus Ethereum (CL). L'appel ACDC le plus récent était le 129e, au cours duquel les développeurs ont partagé les derniers progrès dans les préparatifs de la mise à niveau de Dencun et ont discuté de la portée et de l'EIP de Pectra, la prochaine mise à niveau d'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 BlockBeasts a compilé le texte original comme suit :

Le 7 mars 2024, les développeurs d'Ethereum se sont réunis sur Zoom pour participer au All Réunion n°129 du Core Developers Consensus (ACDC). L'appel ACDC est une série de réunions bihebdomadaires organisées par Danny Ryan, chercheur à la Fondation Ethereum, au cours desquelles les développeurs discutent et coordonnent les modifications apportées à la couche de consensus Ethereum (CL). Cette semaine, les développeurs ont partagé une dernière mise à jour sur les préparatifs de la mise à niveau de Dencun, qui devrait être activée sur le réseau principal le mercredi 13 mars. Ils ont également discuté de la portée de la prochaine mise à niveau d'Ethereum, Pectra, ainsi que de certains sujets de recherche, dont l'un est la standardisation des valeurs de bloc entre les clients CL.

Deneb

Ryan a rappelé à tout le monde au début de la conférence téléphonique que la mise à niveau de Dencun serait mise en ligne sur Ethereum dans moins d'une semaine. Il a également mentionné que pour de nombreux Américains, elle commencerait ce week-end, le 10 mars, avec le début. Étant donné que toutes les conférences téléphoniques et mises à niveau ACD sont planifiées sur la base du temps universel coordonné (UTC) sans respecter l'heure d'été, les développeurs et les participants aux appels en dehors des États-Unis devront ajuster leurs horaires en conséquence.

Lors de la conférence téléphonique, certains clients The L'équipe a révélé qu'elle prévoyait de publier une version mise à jour du logiciel dans les prochains jours pour coïncider avec la mise à niveau de Dencun. Les équipes Prysm, Lighthouse et Teku devraient sortir de nouvelles versions d'ici la fin de la semaine. Bien que ces versions mises à jour ne soient pas des mises à niveau obligatoires, Tim Beiko de la Fondation Ethereum a noté lors de la réunion Zoom qu'ils ne mettraient pas à jour le billet de blog résumant toutes les versions compatibles Dencun.

Chris Hager de l'équipe Flashbots a partagé une mise à jour rapide sur la préparation du logiciel MEV-Boost. Hager a confirmé que la version 1.7 de MEV-Boost, publiée la semaine dernière, est stable et peut être utilisée par les opérateurs de nœuds de validation. Le logiciel de création de Flashbots pour Deneb est toujours en développement et devrait être achevé et fusionné cette semaine, a-t-il déclaré. Concernant l’état de préparation des validateurs pour la mise à niveau, Hager s’est dit préoccupé par le fait qu’un nombre insuffisant de validateurs semblent avoir mis à jour leur logiciel MEV-Boost pour prendre en charge la mise à niveau de Dencun. Après avoir revérifié ses données, Hager a déclaré qu'environ 50 % des validateurs connectés aux relais Flashbots utilisent la dernière version de MEV-Boost, v1.7.

Beiko a en outre noté que ses sources, Metrika et Ethernets, montrent qu'environ la moitié des nœuds Ethereum sont prêts à passer à Dencun. Il a également exprimé l’espoir d’un outil de données capable de suivre l’état de préparation des nœuds de validation pour les mises à niveau, et pas seulement tous les nœuds Ethereum.

Electra

Les développeurs d'Ethereum ont discuté de quatre modifications de code liées à la mise à niveau de Pectra.

EIP 7459

Le premier est l'Ethereum Improvement Proposal (EIP) 7549, qui permet aux clients CL de regrouper plus efficacement les votes pour les blocs (également appelés attestations). Les développeurs sont d'accord avec les recommandations précédentes visant à intégrer EIP 7549 dans Pectra. Le développeur de Teku, Mikhail Kalinin, a partagé une analyse plus approfondie sur la manière dont EIP 7549 sera mis en œuvre sur Ethereum et a suggéré certains compromis ou « impacts négatifs » qui pourraient être introduits à la suite du changement de code. Ryan a suggéré que Kalinin résume les modifications proposées à la spécification CL directement sur GitHub pour des commentaires et un examen plus approfondis.

Le développeur de Prysm, Terence Tsao, a déclaré qu'il était d'accord avec l'implémentation EIP 7549 proposée par Kalinin, mais recommande qu'une documentation et des spécifications supplémentaires pour les modifications de l'API Beacon soient nécessaires avec cet EIP. "Aujourd'hui, si vous avez 10 agrégateurs dans le même emplacement, vous devez signer 10 attestations, puis avec ce changement, vous n'avez besoin d'envoyer qu'un seul message, vous devrez donc peut-être apporter des modifications à l'API Beacon", a déclaré Tsao, ajoutant Dao , "Je pense que cette partie nécessite peut-être plus de réflexion sur la façon de modifier l'intégration du validateur de l'API Beacon pour résoudre ce problème." En arrière-plan, l'API Beacon est une spécification de CL qui permet aux nœuds d'interroger le réseau et d'obtenir des informations sur l'état de le réseau.

Émission inférieure

Ensuite, le chercheur d'EF Ansgar Dietrichs a partagé une mise à jour rapide de sa proposition visant à réduire les récompenses de mise en abaissant les émissions du réseau. Il a déclaré qu'il y avait eu des « retours mitigés de la part de la communauté » depuis que la proposition a été présentée lors du dernier appel de l'ACDC. Il a réitéré que la proposition consisterait en un petit changement de code qui pourrait être inclus dans une mise à niveau d'Electra de dernière minute d'ici juin ou juillet, en supposant que le réseau principal subisse un hard fork en octobre. Cependant, Dietrichs a également déclaré que les discussions sont « en cours », ce qui signifie que l'idée doit être discutée plus en détail avant qu'une décision ne soit prise.

EIP 7547

Troisièmement, le chercheur EF Mike Neuder a proposé l'EIP 7547, contenant des listes pour une discussion plus approfondie. Il a déclaré qu'une deuxième séance en petits groupes pour discuter des "caractéristiques exactes" de la conception de l'EIP serait utile et qu'il envisageait d'en organiser une le vendredi 15 mars prochain. Il a également mentionné que l'EIP dispose d'un canal Discord dédié appelé « Liste d'inclusion » que les personnes souhaitant en savoir plus sur la proposition ou poser des questions devraient utiliser. Tsao a également déclaré que les spécifications de la proposition ont été largement étoffées depuis la première réunion en petits groupes sur la liste d'inclusion le 16 février. "Je pense que la spécification est probablement achevée à environ 75 %", a déclaré Tsao, ajoutant que d'autres composants de la spécification doivent être améliorés, tels que des modifications de l'API d'exécution et des spécifications concernant les validateurs honnêtes.

EIP 7251

Enfin, le développeur de Lighthouse, Mark Mackey, a exprimé son soutien à l'EIP 7251, qui augmente le solde effectif maximum (maxEB). "Nous l'avons presque prototype dans Lighthouse. Il y a encore du travail à faire sur les spécifications, mais cela ne semble pas vraiment beaucoup de travail, et compte tenu de la taille de l'ensemble des validateurs, c'est un peu une bombe à retardement. ", nous avons proposé de publier des suggestions de Tweaking, les changements de version sont toujours controversés, donc il n'y a aucune garantie que la communauté les acceptera, et si elle ne l'aime pas, alors la seule chose que nous pouvons vraiment faire est maxEB", a déclaré Mackey. Ryan a déclaré que la principale résistance à l'intégration de maxEB dans Electra était due à la complexité des modifications du code, comme indiqué lors des appels précédents avec l'équipe Prysm. « Potuz », un développeur anonyme de l'équipe Prysm, a déclaré lors d'une réunion Zoom que son équipe réexaminerait l'EIP et réévaluerait la complexité de la proposition. Ryan a demandé aux équipes de compte de se préparer pour le prochain appel de l'ACDC dans deux semaines afin de prendre une « décision ferme » sur les EIP 7547 et 7251.

Standardisation de l'API Key Manager

L'ingénieur des opérations de développement (DevOps) d'EF, Barnabas Busa, a expliqué que tous les clients CL semblent avoir des méthodes légèrement différentes pour générer des clés de validateur, qui sont utilisées pour faire fonctionner et révoquer les validateurs. La clé de cryptage requise. Il existe des API appelées « API Key Manager » qui aident les opérateurs de nœuds de validation à gérer les clés et à rejoindre et quitter les validateurs. Busa a expliqué que les différences subtiles entre les clients lorsqu'il s'agit de renvoyer des valeurs pour cette API rendent difficile le test des points de terminaison de l'API. Il a également mentionné que son équipe a commencé les tests de base des validateurs hybrides, ce qui signifie que les opérateurs de nœuds de validation utilisent un client différent pour leurs nœuds balises que le client de validation. Les nœuds Beacon sont des clients qui maintiennent l'état CL mais ne gèrent pas les paires de clés requises par les validateurs pour participer au consensus. Les clients validateurs sont des clients qui utilisent des paires de clés pour générer des blocs et signer des preuves sur la chaîne. Ryan a suggéré que Busa lance une documentation ou une pull request avec une proposition visant à standardiser l'API du gestionnaire de clés. Les développeurs présents à l'appel prennent également en charge des tests supplémentaires pour garantir que le validateur hybride fonctionne sur toutes les combinaisons de clients CL.

Standardisation de l'API Block Value Beacon

Un développeur Nimbus avec le nom d'écran "Dustin" a également exprimé ses inquiétudes concernant la standardisation CL des points de terminaison de l'API Beacon "productBlockV3" et "getBlockRewards". Dustin a expliqué que certains domaines de l'API Beacon ne sont pas clairement définis et « ne sont pas universellement mis en œuvre » parmi les clients. Plus précisément, lorsqu'il s'agit de points finaux qui doivent renvoyer des valeurs de bloc, le calcul doit au moins inclure la modification des soldes du validateur avant et après le bloc proposé. Cependant, la spécification ne précise pas si les clients doivent inclure des récompenses et des pénalités pour les modifications du solde d'un validateur dues aux actions d'un autre validateur. Il s'agit, par exemple, de récompenses ou de pénalités simultanées pour les fonctions du comité, d'auto-réductions du proposant ou du certificateur et des récompenses pour les dénonciateurs. Ryan convient que des instructions doivent être ajoutées à l'API Beacon. Cependant, d'autres développeurs présents à l'appel, dont Radosław Kapka et Potuz de l'équipe Prysm, étaient moins confiants. Potuz s'est dit préoccupé par le fait que le nombre de personnes utilisant ces points de terminaison est faible et capables d'utiliser leurs propres outils pour normaliser les valeurs de bloc de différents clients CL. "Je ne comprends même pas pourquoi nous accepterions de soutenir cela si les consommateurs sont restreints. J'essaierais d'étudier ces marchés et de voir si nous pouvons réellement envoyer ce travail aux personnes utilisant ces points finaux au lieu de nous-mêmes", a déclaré Potuz.

Le développeur de Nimbus, Jacek Sieka, a réfuté ce point de vue, affirmant qu'en raison de l'existence du point de terminaison "productBlockV3", les développeurs doivent résoudre les incohérences entre les clients ou déprécier le point de terminaison en faveur de "V4". De plus, Sieka a ajouté : "Je pense que ce point de terminaison n'est qu'une fonctionnalité très basique. Si nous envisageons un avenir dans lequel nous avons plusieurs sources de blocs et que vous devez les comparer, alors cela a du sens. C'est aussi simple que cela a conseillé à Dustin de créer une proposition." pour standardiser la V3 et le point de terminaison « getBlockRewards ». Une fois la proposition créée, l'équipe du compte réexaminera si elle doit continuer à les prendre en charge.

Le reste

Potuz a signalé deux projets pour des commentaires et des discussions plus approfondis des développeurs. Le premier concerne le comportement du client de la couche d'exécution (EL) des blocs tardifs qui n'est actuellement pas spécifié dans l'API du moteur qui spécifie la communication entre EL et CL. "Si cela pouvait être spécifié dans l'API du moteur, cela nous faciliterait la tâche lors de la réorganisation des blocs ultérieurs", a déclaré Potuz. Le deuxième élément signalé par Potuz concernait son analyse de la mise à niveau de la charge utile Proposer Builder Separation (ePBS), une mise à niveau qui éliminerait le besoin de relais de confiance sur Ethereum. Potuz a demandé des commentaires supplémentaires sur l'analyse et d'autres limitations de la conception ePBS.

Enfin, Pooja Ranjan du groupe Ethereum Cat Herder a annoncé la formation d'un nouveau groupe de travail appelé Women in the Ethereum Protocol (WiEP). WiEP est une nouvelle organisation de la Fondation Ethereum qui se consacre à encourager et à développer davantage de développeurs de protocoles Ethereum. Ranjan a déclaré que le groupe organiserait un webinaire d'une heure le 8 mars pour discuter avec plusieurs contributrices du protocole Ethereum.

Ryan a ensuite indiqué qu'il prendrait une pause de trois mois à partir du 1er avril. En son absence, Alex Stokes, membre de l'EF, modérera l'appel de l'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!