jakiro
Auteur: Christine Kim, Galaxy;
Le 12 septembre 2024, les développeurs du protocole d’Ethereum ont tenu la conférence téléphonique 196e des développeurs entièrement core (ACDE) par le biais de Zoom Virtual Meeting.Cette semaine, la conférence téléphonique a été organisée par Tim Beiko, responsable de l’accord à la Fondation Ethereum (EF).La conférence téléphonique de l’ACDE est une série de conférences bihebdomadaires où les développeurs discutent et coordonnent les modifications de la couche d’exécution Ethereum (EL).
Sur ACDE # 196,Les développeurs ont partagé les dernières mises à jour publiées par Pectra Devnet 3 et ont discuté de divers modifications de code PECTRA implémentées sur le réseau de développement à l’avenir.Ils ont sérieusement discuté de la division de la mise à niveau en deux parties afin qu’ils puissent publier des modifications de code sur Devnet 3 sur un calendrier plus rapide (probablement d’ici février de l’année prochaine).Le développeur a accepté de prendre une décision finale à ce sujet lors de la prochaine conférence téléphonique ACD.Enfin, un ingénieur des opérations de développeur EF nommé « PK910 » a partagé les derniers développements de son travail sur le nettoyage du référentiel Github de test de test de l’éthereum et de peaufiner sa structure pour une utilisation plus facile.
PECTRA DEVNET 3
L’ingénieur du développement et des opérations de l’EF, Parisosh Jayanthi, a introduit la sortie de PECTRA DEVNET 3.Le réseau de développement a été lancé le mercredi 11 septembre.Il comprend des correctifs pour les fusions valides dans EIP 7251 et des spécifications mises à jour pour EIP 7702.Sur la base de tests sur DevNet 3 jusqu’à présent, EIP 7251 et EIP 7702 semblent fonctionner comme prévu.Jayanthi a noté qu’il y avait des problèmes trouvés dans les clients des Pays-Bas et Ethereumjs, et les deux équipes clients travaillent pour y remédier.Jayanthi a ajouté que puisque EIP 7702 est en ligne dans Devnet 3, il est préférable de faire tester la mise en œuvre de Wallet Developer et de fournir des commentaires sur leur utilisation.Toutes les informations sur Pectra Devnet 3, y compris les robinets demandant TestNet ETH, peuvent être trouvées sur ce site Web.
Mise à jour des spécifications PECTRA
Le développeur GETH Felix Lange a proposé des modifications à l’encodage des demandes de déclenchement EL dans PECTRA.Dans un arrière-plan, PECTRA permettra aux contrats intelligents sur EL de lancer des retraits et des fusions valides sur CL.Au cours du dernier appel ACD, Lange a partagé une suggestion pour réduire la quantité de travail requise par les clients EL pour résoudre ces demandes.Depuis la conférence téléphonique de la semaine dernière, Lange a officialisé ses recommandations et le travail que l’équipe du client EL doit faire pour mettre à jour le codage des quatre EIP suivants:
-
EIP 7685, demande générale de la couche d’exécution;
-
EIP 7002, EL peut déclencher des retraits;
-
EIP 6110, dépôt de validateur d’alimentation en chaîne;
-
EIP 7251, augmentez l’équilibre efficace maximal.
Les développeurs étaient généralement d’accord avec la proposition de Lange.Cependant, les développeurs de Nimbus, dont le Web intitulé « Dustin », pensait que la proposition était « sans signification flexible » et n’était pas compatible avec les changements futurs dans le format de sérialisation EL.Il a également souligné que des spécifications supplémentaires sont nécessaires pour clarifier l’ordre des demandes de clients EL et le comportement des clients CL lorsque EL soumet des demandes non valides à CL.Lange accepte d’ajouter plus de texte à l’API du moteur pour spécifier l’ordre des demandes.Il convient également avec Dustin que le comportement des clients CL lorsque les clients CL détectent les demandes non valides des clients EL devraient être considérés plus profondément.
Le chercheur de la Fondation Ethereum, Peter Miller, a souligné que sur la base du comportement logique des clients CL sous les spécifications actuelles, les clients CL devraient rejeter des blocs d’EL qui ne sont pas triés de la bonne manière.De plus, s’il existe des demandes non valides dans la liste partagée par l’EL au CL, le CL doit simplement traiter toutes les demandes valides de la liste et ignorer les demandes non valides.Dustin est d’accord avec Miller et conseille aux développeurs de spécifier ce comportement dans la documentation appropriée.Beiko a déclaré que les développeurs devraient travailler sur la résolution de problèmes dans la proposition de Lange et le terminer avant le prochain appel ACD.
Alors,Le développeur d’Eragon, Andrew Ashikhmin, a proposé une mise à jour de EIP 7702, configurant le code du compte EOA.Il a noté que la vérification de validité spécifiée dans l’EIP n’était pas cohérente avec la vérification de validité spécifiée dans l’ancien EIP.Le développeur de Geth, Matt Garnett (alias « LightClient »), a déclaré qu’il avait une alternative pour résoudre les problèmes de cohérence et simplifier le contrôle d’efficacité de l’EIP 7702.La plupart des développeurs favorisent la finalisation de la proposition de LightClient et l’ajoutant à PECTRA DEVNET 4.
La prochaine discussion liée à PECTRA concerne les prix de la précompilation BLS sous EIP 2537.Le développeur de Geth, Jared Wasinger, a déclaré que, selon son analyse de référence, le prix de la précompilation BLS devrait être deux fois plus élevé que stipulé actuellement.Actuellement, le coût est basé sur l’exécution multi-thread, qui n’est pas une norme pour la tarification d’une autre exécution précompilée.Par conséquent, sur la base de son analyse en utilisant un seul thread, Wasinger recommande d’apporter des modifications aux tables de réduction exploitées dans EIP 2537.L’équipe des Pays-Bas a indiqué qu’elle développait un outil afin que d’autres équipes clients puissent facilement effectuer leur propre analyse d’analyse comparative des EIP également.Beiko conseille à l’équipe de réaliser ses propres repères pour la précompilation BLS et de proposer des idées sur la réparation de ces opérations au cours des deux prochaines semaines.
Supplément PECTRA EIP
Les développeurs ont ensuite commencé à discuter du sujet de l’ajout de nouveaux EIP à la mise à niveau de PECTRA.Au début de la discussion, Beiko a averti: « Nous avons déjà une grande quantité d’EIP à PECTRA. C’est de loin la plus grande fourchette en termes de nombre d’EIP. » a déclaré qu’il est évident que l’EIP 7742 (la séparation du nombre de BLOB entre EL et CL) est la liste la moins controversée des EIP qui sont toujours considérées pour l’inclusion dans la liste améliorée.
Le chercheur de l’EF, Alex Stokes, a une fois de plus proposé l’idée de diviser Pecctra en deux plus petites fourches dures. »Je pense que tout le monde convient que c’est une très grande fourchette. Donc, la chose naturelle à faire est de la diviser en deux. Habituellement, le risque de fourchettes plus petites est moindre. EIP, cela ajoute vraiment au fardeau des tests, de la sécurité et de l’examen », a déclaré Stokes.Jayanthi a également proposé l’idée lors d’une conférence téléphonique précédente, qu’il a dit qu’il soutenait toujours.«Je pense que la principale raison est qu’au moment où nous avons beaucoup de DUI, nous avons tendance à toucher de nombreuses couches de la pile, et plus nous ajoutons, il est difficile pour quiconque d’avoir une compréhension mondiale de tous les changements même sous le courant Charge. », A déclaré Jayanthi.
En ce qui concerne la façon dont le PECTRA EIP actuel peut être divisé en deux branches, Stokes recommande d’utiliser tous les EIP qui s’exécutent actuellement sur le réseau de développement pour publier la première partie de PECTRA, puis en utilisant Peerdas, EOF et quelques autres EIP supplémentaires pour publier la seconde partie de PECTRA.Les développeurs sont convaincus que ce faisant, ils pourront publier la première partie de Pectra d’ici février prochain. »Je pense que si nous ne publions encore la première mi-temps en juin, alors cette fourche serait un échec », a déclaré le chercheur EF Ansgar Dietrichs dans un chat Zoom.
Beiko privilégie l’idée de forking, mais avertit contre le retrait de tout EIP du réseau de développement, car cela peut apporter plus de travail à l’équipe client et étendre plutôt que de raccourcir le calendrier pour préparer ces modifications de code pour activer le Mainnet.Danno Ferrin, un développeur de protocole Ethereum indépendant, recommande d’améliorer EIP sur DevNet 3 dès que possible pour activer le MainNet, puis en travaillant en parallèle à partir de DevNet 4 ou 5, relocalisant Peerdas et EOF vers PECTRA EIP.En fait, dans la mise à niveau après PECTRA, Devnet 4 ou 5 deviendra DevNet 0, et les développeurs ne savent pas comment le nommer.
Lors d’une conférence téléphonique précédente, les développeurs ont convenu de nommer la mise à niveau après Pectra Fusaka, mais ils ont également convenu de maintenir la mise à niveau de la transition Verkle.En ce qui concerne cela, Ferrin conseille aux développeurs de ne pas réserver de mise à niveau à l’avance jusqu’à ce qu’ils soient sûrs que les modifications de code sont prêtes pour l’activation du MainNet.Cela a provoqué la colère du développeur de Geth Guillaume Ballet, qui a dirigé la transition Verkle et insiste sur le fait que la transition de Verkle était prête «il y a longtemps».Pour faciliter les tensions, Beiko a déclaré que l’objectif de division de Pectra dans deux est finalement d’essayer de libérer les modifications du code de Pectra sur une chronologie plus rapide, ce qui aidera à ouvrir la voie à la transition Verkle par la suite.
Cependant,Il y a un risque que la deuxième partie de la mise à niveau de PECTRA puisse devenir plus grande à mesure que davantage d’EIP soient ajoutés, il faudra donc plus de temps à publier que les listes actuelles de PECTRA EIP ne seront pas publiées simultanément.Le développeur de Nethermind, Ben Adams, a interrogé,Si la mise à niveau est divisée en deux parties, comment le processus de test PECTRA se déroulera-t-il.Étant donné que cette décision révolutionnera la portée de la prochaine mise à niveau immédiate d’Ethereum, Beiko conseille aux développeurs de passer une semaine à réfléchir à cette idée.Il a demandé aux développeurs de se préparer à une décision finale sur la question lors de l’appel consensuel de jeudi prochain à tous les développeurs de base.
Alignement de la structure de la configuration du réseau
Enfin et surtout, l’ingénieur des opérations de développement EF « PK910 » a partagé sa mise à jour de travail pour nettoyer le référentiel GitHub TestNet public TestNet Ethereum et modifier sa structure pour une utilisation plus facile.Il a demandé à l’équipe client de vérifier la configuration du nœud du MainNet et TestNet Ethereum et d’ajouter toutes les informations manquantes au référentiel correspondant.
