Résumé de la dernière réunion des principaux développeurs d'Ethereum : préparation à la mise en œuvre de l'EIP 3074, feuille de route Rollup

Titre original : "Ethereum All Core Developers Execution Call #186 Writeup"

Auteur original : Christine Kim

Compilation originale : Frost, BlockBeats

NDLR :

L'appel de consensus des développeurs Ethereum (ACDE) a lieu toutes les deux semaines pour discuter et coordonner les modifications apportées à la couche d'exécution Ethereum (EL). Lors de la 186e conférence téléphonique de l'ACDE, les développeurs ont discuté des préparatifs pour la mise en œuvre de Pectra Devnet 0 et EIP 3074. Ils ont détaillé les progrès de diverses équipes clients dans la préparation de Pectra Devnet 0 et ont discuté des modifications proposées à la spécification EIP 3074 et de l'avancement des tests associés.

De plus, cet article aborde également d'autres sujets importants, tels qu'une discussion sur d'autres modifications de code pouvant être incluses dans la mise à niveau de Pectra et une discussion sur la manière dont les modifications apportées au processus Ethereum EIP sont affectées par le processus L2/RIP. . 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 25 avril 2024, les développeurs d'Ethereum se sont réunis sur Zoom pour participer au All Core Developers. Exécution ( ACDE ) convocation # 186 réunions. La conférence téléphonique ACDE est une série de réunions bihebdomadaires organisées par Tim Beiko, responsable du support de protocole à la Fondation Ethereum, au cours de laquelle les développeurs discutent et coordonnent les modifications apportées à la couche d'exécution Ethereum (EL). Cette semaine, les développeurs ont discuté des préparatifs pour la mise en œuvre de Pectra Devnet 0 et EIP 3074. Ils ont également discuté des autres EIP qui devraient être envisagés pour être inclus dans les mises à niveau de Pectra, ainsi que de réflexions plus larges sur les changements de gouvernance compte tenu de la « feuille de route centrée sur le rollup » d’Ethereum.

Derniers progrès de Pectra Devnet 0

Beiko a demandé à l'équipe du compte de partager les derniers progrès de Pectra Devnet 0 lors de la conférence téléphonique. Marek Moraczyński de l'équipe Nethermind a déclaré que Nethermind avait mis en œuvre tous les EIP Pectra et les testait. Justin Florentine de l'équipe Besu a déclaré que Besu mettait en œuvre le Pectra EIP et travaillait avec eux pour préparer le déploiement de Devnet 0. Andrew Ashikhmin de l'équipe d'Erigon a déclaré : « Je ne suis pas sûr qu'Erigon soit prêt pour le nombre d'EIP pour la suite complète de Devnet 0, en partie parce que les spécifications de ces EIP sont encore en train de changer et que le client d'Erigon est en transition vers le nouveau. version majeure Erigon 3. Cela prend des ressources et du temps de l'équipe alors qu'Erigon 3 et Pectra EIP sont finalisés et intégrés ensemble dans le client Erigon. Le « Lightclient » de l’équipe Geth a déclaré que Geth était « dans quelques jours » avant d’être prêt pour Devnet 0. Gajinder Singh de l'équipe Ethereum JS a déclaré qu'Ethereum JS serait également « prêt » pour Devnet 0.

EIP -7685

Lightclient fusionne EIP 7685, ce qui crée un cadre commun pour stocker les requêtes déclenchées par EL vers la couche de consensus (CL) et son impact sur EIP 6110 et 7002. Beiko a déclaré que les développeurs devraient inclure cet EIP dans leurs versions Devnet 0 et continuer à améliorer l'EIP Pectra.

En termes de tests, Mario Vega de l'équipe de test EF a déclaré que les tests des EIP 6110 et 2537 sont terminés et que les tests des EIP 7002 et EIP 2935 seront terminés cette semaine ou la semaine prochaine. Les tests d'EIP 3074 ne sont pas encore prêts pour Devnet 0. Le chercheur d'EF Antonio Sanso a déclaré que la spécification EIP 2537 a été mise à jour et que de nouveaux vecteurs de test ont été ajoutés au référentiel GitHub, et il recommande à tout le monde de la consulter sur GitHub. Le chercheur d'EF, Hsiao Wei Wang, a signalé une erreur dans le vecteur de test de la spécification CL. L'erreur a été rapidement corrigée et une nouvelle version a été publiée.

Mises à jour de l'EIP -3074

L'appel de l'ACDE de cette semaine pour la spécification EIP 3074 propose plusieurs modifications. Ahmad Mazen Bitar a suggéré de modifier le comportement d'EIP 3074 pour autoriser DELEGATECALL avant AUTH CALL, ce qui élargirait les cas d'utilisation d'EIP. Derek Jiang, fondateur et PDG du système d'exploitation de portefeuille blockchain ZeroDev, a suggéré de créer un « noncemanager » pour faciliter la révocation globale des messages AUTH et d'autres changements si nécessaire. Certains développeurs participant à l'appel ont estimé que les modifications apportées à l'EIP 3074 devraient être retardées car elles rendraient sa mise en œuvre beaucoup plus difficile.

Beiko recommande aux développeurs de discuter des modifications proposées à l'EIP 3074 lors de sessions en petits groupes distinctes. Il a noté que afin d'avoir suffisamment de temps pour mettre en œuvre l'EIP 3074 à Pectra, les développeurs devraient essayer de finaliser ses spécifications "dans un mois ou deux". Lightclient s'engage à organiser une session en petits groupes EIP 3074. Pour Devnet 0, Beiko a confirmé que les équipes client devraient implémenter EIP 3074 sans aucun changement, même si les développeurs peuvent décider que les futurs devnets implémentent EIP différemment ou le suppriment complètement des mises à niveau.

En plus des détails de mise en œuvre d'EIP 3074, les développeurs ont également discuté sérieusement de la question de savoir si EIP dispose d'un soutien communautaire suffisant. Un développeur dont le pseudonyme est "Siri" a exprimé son inquiétude lors de l'appel selon lequel "EIP 3074 est mauvais en principe et ralentira notre capacité à réaliser une abstraction complète des comptes". Beiko a répondu que, sur la base des discussions sur les appels Ethereum Magician et ACD, l'équipe de compte semble soutenir l'EIP 3074 par rapport à d'autres propositions liées à l'abstraction de compte (AA). Beiko a déclaré : « Cela semble être la proposition la plus consensuelle à court terme, et nous pouvons réellement améliorer le statut de l'EOA lors du prochain fork. À cet égard, Siri estime que l'équipe client ne devrait pas prendre cette décision de manière isolée. « Nous devrions écouter les autres parties prenantes », a déclaré Siri, ajoutant : « Nous ne voulons pas nous lancer dans la création de hard forks controversés… Je pense qu'il serait bon de comprendre ce que disent les autres parties prenantes et comment ils perçoivent cela. . Proposition. "

Beiko et Siri ont également discuté de la manière de construire un consensus plus large pour l'EIP au-delà de l'appel de l'ACD. Chiang a suggéré d'organiser d'abord une réunion en petits groupes de l'EIP 3074 pour discuter en profondeur des spécifications techniques de l'EIP, puis de décider s'il doit rester dans la mise à niveau de Pectra. Le chercheur d'EF Ansgar Dietrichs a déclaré : « Nous devons comprendre qu'à moins que nous ne fassions suffisamment de progrès, l'EIP 3074 sera retiré.

Le co-fondateur d'Ethereum, Vitalik Buterin, a ajouté : « La fonctionnalité du compte utilisateur est sur le point de changer dans les prochaines années. Comptes externes (EOA). EIP liés à l'abstraction du compte d'activation, tels que EIP 3074, etc.

Autres propositions Pectra

Les développeurs continuent de discuter des autres modifications de code qui devraient être envisagées pour être incluses dans la mise à niveau de Pectra. Le développeur de Geth, Marius van der Wijden, a déclaré que cela devrait dépendre de la question de savoir si des EIP plus complexes comme EOF parviennent à Pectra. "Si nous devions inclure EOF, cela entraînerait une saturation du fork. Si nous n'incluions pas EOF, nous pourrions peut-être en inclure davantage", a déclaré van der Wijden.

Siri a exprimé son inquiétude quant à l'inclusion de l'EIP 3074 dans Pectra sans examen de sécurité. Beiko a suggéré de suspendre cette discussion jusqu'à ce que les spécifications de l'EIP 3074 soient finalisées.

Bitar a déclaré qu'il aimerait voir EIP 7212 ajouté à Pectra. EIP 7212 créera une nouvelle précompilation qui effectue la vérification de la signature dans les courbes elliptiques secp256 r1. Cela peut être utilisé avec des périphériques matériels prenant en charge la biométrie des utilisateurs. Bitar a déclaré que la prise en charge de la biométrie pour signer les transactions Ethereum constituerait une amélioration majeure de l'expérience utilisateur. Ashihemin a déclaré qu'il soutenait également la proposition. Dietrichs a souligné qu'il s'agit de la seule solution approuvée pour la mise en œuvre par les rollups de couche 2 via le processus « Rollup Improvement Proposal » (RIP).

D'autres développeurs, dont Dietrichs, van der Wijden et Moraczyński, ont exprimé leur soutien à l'EIP 7623, qui augmenterait le coût des données d'appel et limiterait ainsi la taille maximale des blocs. Beiko recommande de marquer EIP 7623 et EIP 7212 comme « à considérer » ou CFI dans Pectra, et de revoir la bande passante de l'équipe client pour prendre en charge ces deux propositions d'amélioration après le lancement de Devnet 0.

Concernant le bundle EIP lié à la mise à jour de la méthode de sérialisation d'EL vers SSZ, van der Wijden a exprimé sa préoccupation quant au fait qu'ils seraient trop difficiles à transporter à Pectra. Son collègue de l'équipe Geth, Guillaume Ballet, partage ce constat. Buterin est intervenu, affirmant qu'au moins une méthode de sérialisation pour mettre à jour les reçus de transaction aurait une « valeur significative » au-delà d'Ethereum lui-même, car elle élimine les frais supplémentaires d'audit de sécurité des cumuls de couche 2 construits sur Ethereum. ». Le principal bailleur de fonds de l'EIP lié à SSZ, Etan Kissling de l'équipe Nimbus, n'était pas présent à l'appel, mais il a écrit une explication détaillée sur GitHub expliquant pourquoi ces modifications de code sont importantes et devraient être envisagées pour être incluses dans Pectra.

Les développeurs ont également revisité EOF. Danno Ferrin, un développeur indépendant du protocole Ethereum, a déclaré que l'équipe EOF effectuait des tests de spécification EL sur les modifications de code. EVMOne et Reth sont deux équipes clientes EL qui auraient terminé la mise en œuvre d'EOF. Ferrin a déclaré que l'équipe Geth avait fait « de bons progrès » dans la mise en œuvre. Ferrin a ajouté que Ballet travaille avec "Daniel" de l'équipe Solidity pour répondre aux préoccupations concernant la compatibilité EOF et Verkle.

Ballet a souligné que sur la base de ses conversations avec d'autres développeurs tels que Daniel et Dietrichs, il serait difficile de restreindre la portée d'EOF sans aller à l'encontre de son objectif et créer davantage d'opportunités pour les développeurs d'implémenter un autre ensemble de modifications de code de type EOF dans le futur.

Un développeur qui s'appelle "Charles C" a suggéré de rechercher un moyen d'implémenter facilement EOF de manière itérative via un mécanisme Side Car (tel que celui utilisé pour les transactions Blob) plutôt qu'entre petites ou grandes mises à niveau EOF. Faites votre sélection . Dietrichs a demandé lors du chat si les équipes de comptes seraient plus intéressées par Pectra si sa complexité EOF était réduite. L'équipe Ipsilon a noté que les modifications de code qui causaient la plus grande complexité dans EOF (telles que « TX create ») ont été résolues et que la suppression des demandes spécifiques pour des fonctions telles que « EOF create » ne réduira pas de manière significative la complexité globale d'EOF. Pour le contexte, Ipsilon est le nom de l’équipe R&D EVM financée par EF. Beiko recommande aux développeurs de continuer à discuter des implémentations d'EOF lors des sessions en petits groupes récurrentes d'EOF.

ACD/EIP et L2/RIP

Comme le dernier sujet abordé dans ACDE #186, les développeurs ont discuté des modifications apportées au processus Ethereum EIP pour prendre en compte le nouveau processus RIP. Dietrichs a noté que cela faisait six mois que les développeurs avaient commencé une série de réunions sur les processus de coordination Rollup, RollCall et RIP. Il existe actuellement des questions ouvertes sur la façon dont ces processus auront et devraient avoir un impact sur le processus Ethereum EIP. Dietrichs a déclaré qu'une question de recherche en cours en L2 est de savoir si l'équivalence à long terme avec la machine virtuelle Ethereum (EVM) est souhaitable pour Rollup. Il a également ajouté qu’une question ouverte est de savoir dans quelle mesure les changements mis en œuvre sur L2 auront finalement un impact sur les décisions de protocole au niveau de la couche 1 d’Ethereum.

Le développeur de Geth, Péter Szilágyi, a déclaré que certaines fonctionnalités disponibles sur L2 peuvent ne pas être adaptées pour être fournies sur L1, et dans certains cas, même en suivant les fonctionnalités disponibles sur L2, il peut y avoir des différences entre L2, ce qui peut prêter à confusion pour Développeurs du protocole Ethereum. Le chercheur d'EF Carl Beekhuizen a souligné que les processus RollCalls et RIP n'exigent pas que les développeurs du protocole Ethereum publient des fonctionnalités sur L2, mais améliorent plutôt la communication entre les Rollups et les développeurs Ethereum afin d'éviter des situations confuses comme celle décrite par Szilágyi. Van der Wijden s'est dit préoccupé par le fait que les développeurs de protocoles passent du temps à soutenir les changements mis en œuvre sur L2 qui deviendront finalement obsolètes ou inutiles à mesure que L2 lui-même s'arrêtera ou cessera d'être utilisé.

Concernant ces préoccupations, Dietrichs a déclaré : « Je pense que les gens ont toujours pensé que la couche 2 pouvait expérimenter et devenir plus folle. Je pense que ce que nous voyons dans la pratique, c'est que la plupart d'entre eux décident de ne pas le faire, même ou du moins, cela a probablement commencé. en faisant cela, puis au fil du temps, la plupart des gens ont arrêté de le faire, alors maintenant ils suivent principalement la spécification de la première couche, je pense au moins étant donné la feuille de route centrée sur le Rollup, ou c'est ce que nous en pensons tous. La meilleure façon. pour que l'écosystème évolue, nous devons au moins des conseils et une communication clairs de la part de la couche 2, comme la meilleure voie à suivre ici. "

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!