Auteur : Christine Kim, Galaxy Compilateur : Wu Baht, Golden Finance ;
Le 12 septembre 2024, les développeurs du protocole Ethereum se sont rencontrés virtuellement via Zoom pour la 196e conférence téléphonique All-Core Developer Execution (ACDE). Cette semaine, l'appel a été organisé par Tim Beiko, responsable du support protocolaire à la Fondation Ethereum (EF). La conférence téléphonique ACDE est une série de conférences bihebdomadaires au cours de laquelle les développeurs discutent et coordonnent les modifications apportées à la couche d'exécution Ethereum (EL).
Lors de l'ACDE #196, les développeurs ont partagé les dernières mises à jour de la version Pectra Devnet 3 et ont discuté de diverses modifications du code Pectra à mettre en œuvre sur le futur réseau de développement. Ils ont des discussions sérieuses sur la division de la mise à niveau en deux parties afin de pouvoir publier les modifications de code sur Devnet 3 plus rapidement, probablement d'ici février de l'année prochaine. Les développeurs ont convenu de prendre une décision finale à ce sujet lors du prochain appel ACD. Enfin, un ingénieur des opérations de développement EF appelé « pk910 » a partagé une mise à jour sur son travail de nettoyage du référentiel GitHub du réseau de test public Ethereum et de sa restructuration pour le rendre plus facile à utiliser.
Pectra Devnet 3
Parithosh Jayanthi, ingénieur EF DevOps, explique la sortie de Pectra Devnet 3. Le réseau de développement est lancé le mercredi 11 septembre. Il inclut des correctifs pour la fusion des validateurs dans EIP 7251 et des spécifications mises à jour pour EIP 7702. D'après les tests réalisés jusqu'à présent sur Devnet 3, EIP 7251 et EIP 7702 semblent fonctionner comme prévu. Jayanthi a noté que certains problèmes ont été découverts dans les clients Nethermind et EthereumJS et que les deux équipes client travaillent dur pour les résoudre. Jayanthi a ajouté que depuis la mise en ligne de l'EIP 7702 sur Devnet 3, ce serait une bonne idée de laisser les développeurs de portefeuilles tester la mise en œuvre et de fournir des commentaires sur leur utilisation. Toutes les informations sur Pectra Devnet 3, y compris les robinets permettant de demander testnet ETH, peuvent être trouvées sur ce site Web.
Mise à jour des spécifications Pectra
Le développeur de Geth, Felix Lange, a proposé des modifications au codage des requêtes de déclenchement EL dans Pectra. En arrière-plan, Pectra permettra aux contrats intelligents sur EL d'initier des retraits de validateurs et des fusions sur CL. Lors du dernier appel ACD, Lange a partagé une recommandation visant à réduire la quantité de travail requise par les clients EL pour analyser ces demandes. Depuis l'appel de la semaine dernière, Lange a formalisé ses recommandations et le travail que l'équipe client EL doit effectuer pour mettre à jour le codage des quatre EIP suivants :
EIP 7685, demande de couche d'exécution générique ;
EIP 7002, EL peut déclencher des retraits ;
EIP 6110, dépôt du validateur d'approvisionnement en chaîne ;
EIP 7251, augmente le solde effectif maximum.
Les développeurs sont généralement d'accord avec la proposition de Lange. Cependant, un développeur de Nimbus appelé « Dustin » estime que la proposition est « inutilement flexible » et n'est pas compatible avec les futures modifications du format de sérialisation EL. Il a également souligné que des spécifications supplémentaires sont nécessaires pour réglementer clairement l'ordre des demandes des clients EL et le comportement des clients CL lorsque EL soumet des demandes invalides à CL. Lange a accepté d'ajouter plus de texte à l'API du moteur pour spécifier l'ordre des requêtes. Il est également d'accord avec Dustin sur le fait qu'une considération plus approfondie devrait être accordée au comportement du client CL lorsque le client CL détecte une demande invalide d'un client EL.
Peter Miller, chercheur à la Fondation Ethereum, a souligné que, sur la base du comportement logique des clients CL selon la spécification actuelle, les clients CL devraient rejeter les blocs d'EL qui ne sont pas ordonnés correctement. De plus, s'il y a des requêtes invalides dans la liste partagée par l'EL avec la CL, la CL doit simplement traiter toutes les requêtes valides dans la liste et ignorer les requêtes invalides. Dustin est d'accord avec Miller et recommande aux développeurs de spécifier ce comportement dans la documentation appropriée. Beiko a déclaré que les développeurs devraient travailler à résoudre les problèmes de la proposition de Lange et la terminer avant le prochain appel ACD.
Par la suite, le développeur d'Erigon, Andrew Ashikhmin, a proposé une mise à jour d'EIP 7702, configurant les codes de compte EOA. Il a noté que les contrôles de validité spécifiés dans l'EIP n'étaient pas cohérents avec ceux spécifiés dans l'ancien EIP. Le développeur de Geth, Matt Garnett (alias "Lightclient"), affirme qu'il dispose d'une alternative pour résoudre les problèmes de cohérence et simplifier les contrôles de validité d'EIP 7702. Les développeurs sont pour la plupart favorables à la finalisation de la proposition Lightclient et à son ajout à Pectra Devnet 4.
La prochaine discussion liée à Pectra concerne la tarification de la précompilation BLS selon EIP 2537. Jared Wasinger, développeur de Geth, a déclaré que, sur la base de son analyse de référence, la précompilation BLS devrait coûter deux fois plus cher qu'actuellement. Actuellement, le coût est basé sur une exécution multithread, ce qui n'est pas la norme selon laquelle les autres exécutions précompilées sont tarifées. Par conséquent, sur la base de son analyse utilisant une exécution monothread, Wasinger a recommandé des modifications au tableau de remise pour les opérations dans EIP 2537. L'équipe Nethermind indique qu'elle développe un outil afin que d'autres équipes clientes puissent facilement effectuer leur propre analyse de référence d'EIP. Beiko a suggéré que l'équipe effectue ses propres tests de performance sur la précompilation BLS et propose des idées sur la retarification de ces opérations dans les deux prochaines semaines.
Supplément Pectra EIP
Les développeurs ont ensuite commencé à discuter de l'ajout de nouveaux EIP pour les mises à niveau de Pectra. Au début de la discussion, Beiko a prévenu : « Nous avons déjà un grand nombre d'EIP à Pectra. Il s'agit déjà du plus grand fork à ce jour en termes de volume d'EIP, selon les avis partagés par les développeurs avant l'appel, Beiko. a déclaré : De toute évidence, l'EIP 7742 (séparation du nombre de blobs entre EL et CL) est le moins controversé de la liste des EIP encore envisagés pour être inclus dans la mise à niveau.
Le chercheur d'EF, Alex Stokes, a une fois de plus lancé l'idée de diviser Pectra en deux hard forks plus petits. "Je pense que tout le monde est d'accord sur le fait qu'il s'agit d'un très grand fork. La chose naturelle à faire est donc de le diviser en deux. Généralement, les plus petits forks sont moins risqués. En particulier, Pectra a maintenant beaucoup d'EIP multicouches, qui vraiment augmente la charge de test, de sécurité et d’examen », a déclaré Stokes. Jayanthi, qui a également soulevé l'idée lors d'un précédent appel, a déclaré qu'il soutenait toujours l'idée. "Je pense que la raison principale est qu'à l'heure actuelle, nous avons beaucoup d'EIP et que nous avons tendance à toucher plusieurs couches de la pile, et plus nous en ajoutons, il est difficile pour une seule personne d'avoir une vue d'ensemble de tous les changements. , même sous la charge actuelle", a déclaré Jayanthi.
Concernant la façon dont l'EIP Pectra actuel peut être divisé en deux branches, Stokes a suggéré d'utiliser tous les EIP actuellement exécutés sur le réseau de développement pour publier la première partie de Pectra, puis d'utiliser PeerDAS, EOF et quelques autres EIP supplémentaires pour publier la deuxième partie de Pectra. Pectre. Les développeurs sont convaincus qu'en faisant cela, ils pourront publier la première partie de Pectra d'ici février de l'année prochaine. "Je pense que ce fork serait un échec si nous ne publiions le premier semestre qu'en juin", a déclaré Ansgar Dietrichs, chercheur chez EF, lors d'une discussion sur Zoom.
Beiko est favorable à l'idée d'un fork, mais met en garde contre la suppression de tout EIP du devnet, car cela pourrait créer plus de travail pour les équipes clients et prolonger, plutôt que raccourcir, le délai de préparation de ces modifications de code pour l'activation du réseau principal. Le développeur indépendant du protocole Ethereum, Danno Ferrin, a recommandé de terminer l'EIP sur Devnet 3 dès que possible pour activer le réseau principal, puis de travailler en parallèle en commençant par Devnet 4 ou 5 pour déplacer PeerDAS et EOF vers l'EIP Pectra. En fait, dans une mise à niveau après Pectra, Devnet 4 ou 5 deviendra Devnet 0, et les développeurs ne savent pas comment le nommer.
Lors d'un appel précédent, les développeurs ont convenu de donner à la mise à niveau le nom de Pectra Fusaka, mais ils ont également convenu de réserver la mise à niveau pour la transition Verkle. À ce sujet, Ferrin a conseillé aux développeurs de ne pas précommander les mises à niveau tant qu'ils ne sont pas sûrs que les modifications du code sont prêtes pour l'activation du réseau principal. Cela a suscité la colère du développeur de Geth, Guillaume Ballet, qui a dirigé les efforts de transition vers Verkle et a insisté sur le fait que la transition Verkle était prête "il y a longtemps". Pour apaiser les tensions, Beiko a déclaré que le but de la division de Pectra en deux était finalement d'essayer de publier les modifications du code de Pectra dans un délai plus rapide, ce qui aiderait à ouvrir la voie à la transition de Verkle par la suite.
Cependant, il existe un risque que la deuxième partie de la mise à niveau de Pectra devienne plus importante à mesure que davantage d'EIP sont ajoutés, et prenne donc plus de temps à être publiée que la liste actuelle des EIP de Pectra n'est publiée en même temps. Ben Adams, développeur de Nethermind, s'est demandé comment le processus de test de Pectra fonctionnerait si la mise à niveau était divisée en deux parties. Étant donné que cette décision modifiera complètement la portée de la prochaine mise à niveau immédiate d’Ethereum, Beiko a recommandé aux développeurs de prendre une semaine pour réfléchir à cette idée. Il a demandé aux développeurs de se préparer à prendre une décision finale sur la question lors de l'appel de consensus des développeurs de jeudi prochain.
Alignement de la structure de configuration du réseau
Enfin, l'ingénieur EF DevOps "pk910" a partagé une mise à jour sur son travail visant à nettoyer le référentiel GitHub du réseau de test public Ethereum et à le restructurer pour une utilisation plus facile. Il a demandé à l'équipe de compte de vérifier la configuration des nœuds du réseau principal Ethereum et du testnet et d'ajouter toute information manquante aux référentiels correspondants.
