Le système de gouvernance d'Ethereum est le modèle VVRC, toute proposition doit d'abord être conforme aux valeurs d'Ethereum (Value).
Rédaction : shew
Aperçu
Dans la mise à niveau de Pectra, la question des disputes de gouvernance les plus complexes est apparue. Lorsque l'EIP3074 a été intégré dans la mise à niveau de Pectra, cela a provoqué d'énormes controverses, notamment de la part de l'équipe d'ERC4337.
EIP3074 est dans une impasse, le processus de gouvernance ne peut pas se poursuivre. Jusqu'à ce que Vitalik propose EIP7702, mettant fin aux questions de l'équipe ERC4337 concernant EIP3074.
GCC Research a constaté que la gouvernance des EIP3074 et des ERC7702 dans la mise à niveau de Pectra est rarement discutée dans le monde chinois. Mais cette question de gouvernance reflète également le problème plus profond de la gouvernance d’Ethereum, c’est-à-dire qui peut contrôler le contenu spécifique du code en partant du principe que le code est la loi. Les questions de gouvernance de EIP3074 et de ERC7702 peuvent nous donner une bonne perspective sur le processus de gouvernance réel au sein d’Ethereum.
La conclusion finale de cet article est une paraphrase d’un article d’opinion publié par ZeroDev, qui affirme que le système de gouvernance d’Ethereum est un modèle VVRC, et que l’inclusion de toute proposition doit d’abord s’aligner sur les valeurs d’Ethereum (Value), puis la proposition doit refléter la vision conçue par Vitalik (Vision), la proposition finale doit être reflétée dans la feuille de route (Roadmap), puis discutée par les développeurs principaux et intégrée au client (Client) mise en œuvre.
Dans un précédent article, GCC Research a présenté que l'EIP2537 a simplement rencontré des problèmes de mise en œuvre au niveau du client, ce qui a entraîné un retard dans son inclusion dans le hard fork, tandis que l'EIP3074 n'a finalement pas été inclus dans le hard fork en raison de problèmes de vision et de feuille de route. Les développeurs principaux d'Ethereum ont directement choisi l'EIP7702 rédigé par Vitalik comme proposition finale d'abstraction de compte.
Aperçu du contenu de la proposition
Avant de présenter les processus de gouvernance spécifiques, nous devons d'abord donner une brève introduction au contenu spécifique concernant EIP3074, EIP7702 et ERC4337.
EIP3074 s’agit d’une proposition de couche d’exécution dont l’exécution nécessite une mise à niveau logicielle de nœud. L’objectif principal de EIP3074 est de permettre le parrainage du gaz et le commerce en vrac. Ce que l’on appelle le parrainage de gaz signifie que les utilisateurs peuvent payer des frais de gaz avec n’importe quel jeton, ou que les utilisateurs peuvent payer des frais de gaz hors ligne. Cependant, il convient de noter que EIP3074 ne permet pas aux utilisateurs d’utiliser un algorithme de signature autre que secp256k1, par rapport à d’autres propositions d’abstraction de compte qui permettent de modifier l’algorithme de vérification de signature. En d’autres termes, EIP3074 n’est pas une proposition qui satisfait toutes les abstractions de compte. C’est aussi un point pour lequel EIP3074 a été critiqué.
Pour atteindre l'objectif souhaité, l'EIP3074 introduit deux codes d'opération, à savoir AUTH et AUTHCALL. Le code d'opération AUTH peut, par la vérification de la signature, configurer le champ authorized dans le contexte EVM actuel à l'adresse du signataire lorsque la vérification de la signature réussit. Une fois le champ authorized configuré dans le contexte, AUTHCALL peut utiliser l'adresse authorized comme msg.sender pour initier une transaction. D'une certaine manière, les utilisateurs peuvent déléguer leur compte à un contrat intelligent pour une transaction via une signature. On appelle généralement ce contrat intelligent délégué par l'utilisateur un contrat invoker.
Quel est le contenu spécifique de la signature de l'utilisateur ? L'utilisateur doit signer le contenu suivant :
L'adresse invoker mentionnée dans le contenu ci-dessus fait référence à l'adresse du contrat invoker que l'utilisateur souhaite déléguer. L'EVM vérifiera si le contenu de la signature de l'utilisateur correspond au contrat qui vérifie réellement la signature, afin d'éviter que le contenu de la signature AUTH de l'utilisateur soit utilisé par d'autres contrats.
Un nonce, quant à lui, est un identifiant qui empêche la relecture des transactions. Cependant, il convient de noter que l’opcode AUTH vérifiera si le nonce dans la signature est cohérent avec le nonce de l’EOA actuellement signé, et théoriquement tant que l’utilisateur n’utilise pas le compte EOA pour initier une transaction afin d’augmenter la valeur du nonce, alors la signature AUTH émise par l’utilisateur peut toujours être utilisée par le contrat de l’appelant. Il s’agit d’une énorme faille de sécurité qui signifie que les utilisateurs qui utilisent EIP3074 doivent faire confiance au fournisseur de services de relais qui obtient la signature. Si le fournisseur de services de relais qui obtient la signature de l’utilisateur est malveillant, il peut rejouer la signature d’authentification de l’utilisateur à un moment donné pour voler les ressources de l’utilisateur.
Un autre problème de sécurité est le champ de validation. Le champ de validation est utilisé pour garantir certaines opérations, et les utilisateurs peuvent affiner le contrôle de leurs autorisations de signature dans la validation, par exemple en écrivant du contenu dans la validation pour empêcher que leur contenu de signature ne soit utilisé pour les transferts d’ETH. Dans le document EIP3074, le proposant donne une série d’exemples d’utilisation du champ commit. Mais le problème est que le rôle du commit dépend entièrement de la définition du contrat intelligent, et qu’il s’agit essentiellement d’un contenu facultatif. Différents contrats intelligents peuvent analyser le contenu de la validation de manière totalement incohérente, et certains contrats peuvent même ne pas lire du tout le contenu de la validation. Si vous souhaitez utiliser EIP3074 en toute sécurité, il vous suffit d’examiner vous-même le contrat intelligent.
Enfin, jetons un coup d’œil à l’impact d’un EIP3074 sur le mempool de transactions Ethereum actuel. Avec l’introduction de EIP3074, un pirate peut utiliser un grand nombre de comptes pour initier des transactions, puis utiliser EIP3074 transactions pour drainer l’ETH de ces comptes en une seule fois lorsque la transaction est sur le point d’être emballée, ce qui entraînera l’échec de toutes les transactions précédemment initiées. Ce type d’attaque peut avoir un impact considérable sur les nœuds de la couche d’exécution et est essentiellement une attaque par déni de service. Il convient toutefois de noter que le EIP7702 utilisé pour remplacer EIP3074 présente également ce problème, mais EIP7702 introduit quelques limitations pour éviter ce problème, dont nous parlerons plus tard.
En plus des problèmes liés à l'EIP3074 mentionnés ci-dessus, l'auteur de l'ERC4337, Yova, a présenté davantage d'objections dans son article "Implications of EIP-3074 inclusion". En termes simples, ces objections comprennent principalement :
Risque de centralisation. En raison de la nature particulière des signatures d’authentification, les utilisateurs doivent faire entièrement confiance au fournisseur de relais et à l’infrastructure sous-jacente de EIP3074. Dans le même temps, l’infrastructure actuelle construite par des protocoles d’abstraction de compte tels que ERC4337 est totalement incompatible avec EIP3074
Sécurité des utilisateurs. Comme mentionné ci-dessus, l'EIP3074 ne dispose pas d'une méthode de contrôle des permissions uniformément conçue, et la conception du nonce de signature présente également des risques de sécurité, ce qui pourrait entraîner l'apparition de problèmes de sécurité graves.
Fonctionnalité d'abstraction de compte incomplète. Comparé à d'autres propositions d'abstraction de compte, l'EIP3074 est incomplet et ne peut pas réaliser des fonctionnalités telles que le changement de l'algorithme de signature utilisateur.
Il y a des problèmes d'expérience utilisateur. Lorsque l'utilisateur doit déléguer son compte à un contrat intelligent, il doit effectuer une signature AUTH, puis publier l'appel contenant la signature AUTH sur la chaîne. L'utilisateur doit effectuer deux signatures.
EIP7702 s’agit d’une proposition de Vitalik pour remplacer EIP3074. Au lieu d’introduire un nouvel opcode EVM, la proposition introduit un nouveau type de transaction, appelé SET_CODE_TX_TYPE. Une fois qu’un utilisateur initie un EIP7702 type de transaction, il peut ajouter la fonctionnalité du contrat intelligent à son EOA tout en conservant les fonctionnalités de base du EOA. Pour faire simple, les utilisateurs peuvent soit continuer à initier des transactions à l’aide de portefeuilles tels que MetaMask, soit appeler des adresses EOA sous la forme de contrats intelligents.
Nous introduisons les fonctionnalités de l'EIP7702 avec un exemple simple de transaction en lot. Les utilisateurs peuvent utiliser l'EIP7702 pour déléguer leur adresse EOA à un contrat intelligent capable d'exécuter des appels en lot, puis les utilisateurs peuvent directement appeler leur adresse EOA pour initier des transactions en lot sous la forme d'un contrat intelligent.
En termes de mise en œuvre technique, par rapport aux transactions traditionnelles, EIP7702 introduit une liste d’autorisation_list de types de transactions, qui est [[chain_id, address, nonce, y_parity, r, s], ...]. où adresse est l’adresse du contrat intelligent que l’utilisateur souhaite déléguer et nonce est la valeur actuelle du nonce de l’utilisateur. Les y_parity, r et s restants sont le résultat de la signature de l’utilisateur. Dans le processus d’exécution spécifique, nous allons d’abord parcourir chaque élément dans authorization_list pour le traitement, et la méthode de traitement consiste à restaurer l’adresse EOA via des paramètres de signature tels que y_parity, puis à pointer l’adresse EOA vers le contrat intelligent avec l’adresse d’adresse. Après cela, l’adresse EOA peut accepter l’appel pour jouer la fonction du contrat.
Les avantages de EIP7702 sont évidents, et l’avantage principal de EIP7702 est essentiellement de permettre à EOA d’avoir les fonctionnalités d’un contrat intelligent. Cela est cohérent avec les règles de base de l’abstraction de compte telles que ERC4337, ce qui signifie que EIP7702 pouvez tirer parti de toute l’infrastructure existante dans le domaine d’abstraction de compte courant pour explorer et réutiliser l’infrastructure existante, par exemple EIP7702 pouvez utiliser directement ERC4337 infrastructure. EntryPoint v0.8 avec prise en charge des appels EIP7702 est désormais disponible en ERC4337. Du point de vue de la réutilisation de l’infrastructure existante, EIP7702 a le même degré de caractère ludique que ERC4337.
Bien sûr, l'EIP7702 n'a en réalité pas complètement corrigé les problèmes soulevés dans l'EIP3074. La plupart des problèmes présents dans l'EIP3074 subsistent encore. L'EIP7702 exige que les contrats de compte aient une mise en œuvre sécurisée, tandis que le protocole lui-même ne garantit aucune sécurité. Dans les premières propositions de l'EIP7702, certains développeurs ont suggéré de standardiser le nonce de signature pour éviter d'éventuelles attaques par rejeu, mais l'EIP7702 n'a finalement pas accepté ces suggestions. Donc, si un utilisateur souhaite utiliser l'EIP7702 de manière sécurisée, il doit examiner lui-même la sécurité du contrat.
Dans le même temps, EIP7702 crée également une série de problèmes pour la couche exécutive. Ci-dessus, nous avons décrit un moyen possible d’exploiter EIP3074 pour effectuer des attaques par déni de service sur les pools de mémoire de la couche d’exécution. Cette méthode est également efficace dans EIP7702. Par conséquent, EIP7702 recommande que toutes les adresses EOA qui utilisent EIP7702 n’aient qu’une seule transaction en attente dans le mempool afin d’éviter les attaques par déni de service à grande échelle.
En résumé, le principal problème de l'EIP3074 est qu'il n'a pas mis en œuvre la fonctionnalité complète d'abstraction de compte, alors que l'EIP7702 a réalisé cette fonctionnalité complète. La définition de ce que comprend "l'abstraction complète de compte" est précisément celle de l'auteur de l'ERC4337. À ce stade, le lecteur devrait comprendre pourquoi l'EIP3074 a été contesté par l'équipe de l'ERC4337 et finalement remplacé par l'EIP7702. Nous présenterons dans la suite l'ensemble du processus de gouvernance et de discussion.
Le processus de gouvernance des EIP3074 et EIP7702
EIP3074 a été mentionné très tôt lors des réunions des développeurs principaux d'Ethereum. Lors de la réunion #109 du 2 avril 2021, les développeurs principaux d'Ethereum ont eu une discussion simple sur EIP3074. Le résultat de la discussion était très simple:
Alexey a soulevé que le contenu de la signature de l'EIP3074 présente des risques de sécurité, pouvant causer des pertes de sécurité graves pour les utilisateurs. Il recommande de normaliser davantage le contenu spécifique de la signature AUTH de l'EIP3074, cette proposition a reçu le soutien de Martin.
James a proposé que l'EIP3074 pourrait introduire des vulnérabilités potentielles au niveau d'exécution, comme des attaques DoS, et a suggéré que l'EIP3074 fournisse une analyse de menace écrite.
Alexey et Martin se plaignent que la qualité de la documentation EIP3074 est moyenne, et qu'ils ont passé beaucoup de temps à lire et à comprendre.
Martin pense que le cœur de l'EIP3074 réside dans la collaboration et la mise en œuvre avec les applications, en particulier avec les développeurs de portefeuilles. L'auteur de l'EIP3074 a déclaré avoir eu une série d'échanges avec les développeurs d'applications.
Il est intéressant de noter que Vitalik a déclaré lors de cette conférence qu'il est nécessaire qu'Ethereum dispose d'une solution technique permettant de générer plusieurs appels à partir d'une seule transaction conçue pour les EOA. Bien que l'EIP3074 présente des problèmes de sécurité potentiels, l'EIP3074 propose une solution technique possible, et les développeurs doivent avancer sur la base de l'EIP3074.
Il est évident qu'en raison des problèmes de sécurité liés à EIP3074, cette réunion n'a pas inclus EIP3074 dans la mise à niveau de Londres.
Lors de la réunion #115 du 11 juin 2021, les développeurs de l'EIP3074 ont soumis un rapport sur l'audit de sécurité, la réunion a principalement discuté des problèmes de sécurité de l'EIP3074. Une conclusion simple est que le contrat invoker de l'EIP3074 est très important dans le système, donc la question de savoir s'il est nécessaire de gérer le contrat invoker est posée. Les développeurs de l'EIP3074 souhaitent procéder à une preuve formelle du contrat invoker pour accroître la sécurité.
Bien sûr, il y a aussi une partie de la discussion sur certains contrats utilisant msg.sender == tx.origin pour déterminer si l’adresse d’appel est EOA, et lorsque EIP3074 sera introduite, ces jugements seront invalidés, mais la conclusion est que l’échec de cette partie du jugement ne causera pas de graves problèmes de sécurité. En résumé, la réunion s’est concentrée sur les EIP3074 présentateurs présentant les résultats de l’audit de sécurité 3074 aux développeurs principaux. La conclusion finale de la réunion a été que 3074 doit encore examiner la question du contrat d’invocation et qu’il est recommandé de ne pas se joindre au hard fork de Londres.
Lors de la réunion #116 du 25 juin 2021, Yova, l'un des auteurs principaux d'ERC4337, a soumis des documents intitulés A case for a simpler alternative to EIP 3074, qui indiquent qu'EIP3074 présente de nombreux problèmes de sécurité. Il est suggéré de modifier certains de ses contenus, par exemple en limitant le contenu du champ commit dans la signature, exigeant que le champ commit soit sous la forme {nonce,to,gas,calldata,value,chainid}. Après avoir utilisé ce mode de signature, EIP3074 ne peut être utilisé que pour exécuter certaines transactions spécifiques afin de garantir la sécurité des transactions.
Lors de cette réunion, l'auteur de l'EIP3074 a répondu aux documents soumis par Yova :
J'espère inclure l'adresse du contrat invoker dans la norme EIP, puis que les développeurs principaux d'Ethereum écrivent un contrat invoker sécurisé pour éviter les problèmes de sécurité.
Concernant le contenu du commit dans la signature, les développeurs de l'EIP3074 estiment que cela relève entièrement des utilisateurs et des logiciels de portefeuille, et qu'il n'est pas nécessaire de le normaliser dans l'EIP.
Vitalik a présenté les trois points suivants lors de cette conférence :
EIP3074 utilise toujours le schéma de signature traditionnel secp256k1, ce qui ne permet pas d'implémenter des caractéristiques anti-quantique.
EIP3074 n'a pas de compatibilité future, utiliser EIP3074 ne permet pas à un EOA d'évoluer en compte de contrat intelligent.
La durée de vie de l'EIP3074 est limitée. 3074 introduit deux codes d'assemblage préliminaire, AUTH et AUTHCALL, mais selon la feuille de route de l'abstraction de compte, tous les portefeuilles sur Ethereum pourraient à l'avenir être des portefeuilles de contrats intelligents, les codes d'assemblage préliminaire de l'EIP3074 seront abandonnés à l'avenir.
Lors de la réunion #131 du 4 février 2022, les développeurs ont discuté des types d'EIP qui devraient être inclus dans la mise à niveau ShangHai. L'EIP3074 a été inclus dans le champ de discussion, mais les développeurs ont simplement synchronisé les dynamiques de développement de l'EIP3074. Il est à noter qu'avant le début de la réunion, Nethermind a rédigé un article intitulé "Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337", dans lequel aucune objection à l'EIP3074 n'a été mentionnée.
Lors de la réunion #167 du 3 août 2023, les développeurs principaux ont mentionné EIP3074 tout en discutant d’un autre EIP5806. EIP5806 s’agit d’un contrat qui permet à EOA d’appeler des contrats externes à l’aide d’appels deleGate.io pendant les transactions. Le système est quelque peu similaire à celui de EIP7702. Cependant, la sécurité de cette solution a également été remise en question par les développeurs principaux, Ansgar notant que dans le passé, EIP3074 n’a pas pu être incluse dans le hard fork en raison d’éventuels problèmes de sécurité, EIP5806'est une approche plus agressive.
Lors de la réunion #182 du 29 février 2024, les développeurs ont discuté en détail de la question de savoir si l'EIP3074 devrait être inclus dans la mise à niveau Pectra. Vitalik a proposé que tout standard d'abstraction de compte doit avoir les trois fonctionnalités suivantes :
Rotation des clés
Clé obsolète
Compatible avec les signatures post-quantum
Les commentaires de Vitalik sur EIP5806 sont peut-être une meilleure option que EIP3074. Andrew pense que EIP3074 est plus polyvalent que EIP5806 et recommande d’utiliser EIP3074. Vitalik rétorque à Andrew, arguant que tous les portefeuilles à l’avenir pourraient être des portefeuilles de contrats intelligents, et que si cela se produit, l’opcode pré-assemblé introduit par EIP3074 sera invalidé. Yoav, l’auteur du ERC4337, a fait une longue présentation lors de la conférence, qui a couvert les sujets suivants :
EIP3074 peut entraîner des attaques DoS sur la mémoire tampon d'Ethereum, tandis qu'ERC4337 a effectué de nombreuses recherches à ce sujet et a proposé certaines règles pour éviter ces attaques.
EIP3074 nécessite que l'utilisateur signe deux fois lors de l'initiation de transactions en lot, ce qui n'est pas raisonnable.
L'EIP3074 exige l'utilisation de relais centralisés
Yova est plus enclin à utiliser EIP5806 comme solution d'abstraction de compte.
Lors de la réunion #183 du 14 mars 2024, les développeurs principaux ont invité Dan Finlay de MetaMask à discuter de ce que le portefeuille pense de EIP3074. Dan est en faveur de EIP3074, notant que MetaMask prendra également en charge les tests de EIP3074. MetaMask estime que EIP3074 peut permettre à EOA de profiter de toutes les fonctionnalités d’abstraction de compte. En termes de sécurité, EIP3074 fournit une solution pour les fournisseurs de services de portefeuille, c’est-à-dire la séparation des clés chaudes et froides. Le fournisseur de services de portefeuille peut détenir la signature EIP3074 d’EOA pour initier une transaction, et les utilisateurs peuvent utiliser la clé privée à chaud dans les transactions normales, mais la clé privée froide peut être conservée dans le portefeuille matériel de l’utilisateur, et lorsqu’une urgence est détectée, l’utilisateur peut utiliser la clé privée froide dans le portefeuille à froid pour initier une transaction afin de révoquer la signature du EIP3074. Cette solution de séparation des clés privées à chaud et à froid offre de la flexibilité aux fournisseurs de portefeuilles.
Vitalik souligne qu’au sein de la EIP3074, les concepteurs de portefeuilles doivent concevoir une logique d’autorisation stricte pour éviter l’utilisation abusive des signatures EIP3074 des utilisateurs. Il est intéressant de noter qu’en discutant de la capacité de MetaMask à ajouter des fonctionnalités EIP3074, Vitalik a souligné que L2 pourrait être utilisé comme solution de transition, c’est-à-dire que tout nouveau changement de couche d’exécution devrait être mis en œuvre d’abord dans L2, car L2 a un financement limité et peut causer de graves pertes même si quelque chose ne va pas.
Dror Tiros a souligné lors de la discussion que la meilleure façon de garantir la sécurité de l'EIP3074 est que l'équipe officielle d'Ethereum fournisse directement le contrat invoker. Cependant, Dan Finlay s'oppose à cette idée, affirmant que le contrat invoker devrait être entièrement décidé par les utilisateurs, et que le marché finira par choisir le contrat invoker le plus sûr.
Ansgar insiste toujours sur le fait qu’EIP3074 une signature ne devrait correspondre qu’à une seule transaction, et que les fournisseurs de services de portefeuille ne devraient pas réutiliser les signatures des utilisateurs pour initier des transactions, mais Dan Finlay s’y est également opposé. Dan Finlay pense que EIP3074 doit être signé par un portefeuille froid, puis que le fournisseur de services de portefeuille peut réutiliser la signature pour initier des transactions directement pour l’utilisateur, et si l’utilisateur doit resigner à chaque fois, la clé privée froide peut être utilisée plusieurs fois. Ceci est incompatible avec l’idée de séparer les clés privées chaudes et froides.
Lors de cette réunion, les développeurs principaux ont discuté d'un autre sujet important : les listes d'inclusion. Les listes d'inclusion sont un moyen d'augmenter les propriétés d'anti-censure d'Ethereum. En termes simples, les listes d'inclusion permettent à certaines transactions d'être promises pour être directement incluses dans le prochain bloc. Mais les développeurs principaux ont souligné que l'EIP3074 est en contradiction avec les listes d'inclusion.
Lors de la réunion #185 du 11 avril 2024, la plupart des implémentations clients internes ont convenu d'inclure l'EIP3074 dans le hard fork Pectra, mais Geth a exprimé son opposition, car l'EIP3074 pourrait entraîner des problèmes avec les arbres Verkle. Danno a également exprimé son opposition, car l'EIP3074 pourrait entraîner des situations de réutilisation de signatures. Yoav a également exprimé son opposition, proposant un scénario d'attaque utilisant l'EIP3074 et les transactions Blob sur le pool de mémoire. En résumé, un attaquant pourrait initier un grand nombre de transactions Blob, toutes contenant de grandes quantités de données, puis utiliser l'EIP3074 pour invalider toutes ces transactions Blob.
En résumé, lors de cette réunion, tous les développeurs de clients ont convenu que l'EIP3074 serait inclus dans la mise à niveau finale.
Lors de la réunion #187 du 9 mai 2024, les développeurs principaux ont discuté pour la première fois de la question du remplacement de EIP3074 EIP7702. Le EIP7702 a été fait dans les 90 premières minutes de la réunion des développeurs principaux de Vitalik. Au cours de la conférence, les développeurs principaux ont reconnu que EIP7702 était un meilleur standard que EIP3074. Il n’y a pas eu d’opposition à EIP7702 lors de cette réunion, mais certains chercheurs ont estimé qu’EIP7702 avait également des attributs irrévocables similaires à EIP3074, ce qui pourrait entraîner des problèmes de sécurité financière.
Lors de la réunion #188 du 23 mai 2024, le développement de base a discuté de la possibilité de remplacer EIP3074 par EIP7702. La conclusion finale de la réunion a été de remplacer EIP3074 par EIP7702 en tant que norme d’abstraction de compte dans le hard fork de Pectra. Vitalik souligne que EIP7702 a également une certaine irrévocabilité compatible avec EIP3074, des attributs qui ont été beaucoup discutés dans la discussion sur EIP3074. Il est intéressant de noter qu’il y avait un grand nombre de délégués ERC4337 à la réunion.
En fait, la discussion sur le remplacement de l'EIP3074 par l'EIP7702 avait déjà été largement débattue avant la 188e réunion des développeurs principaux, et le résultat de la discussion à l'époque était que le 3074 serait remplacé, donc il n'y a pas eu beaucoup de controverses lors de la réunion des développeurs principaux.
Feuille de route et décisions
L'infrastructure de base d'abstraction de compte Zerodev a publié un article intéressant après avoir appris que l'EIP3074 serait remplacé, intitulé Reflections on Ethereum Governance Following the 3074 Saga. La conclusion de cet article est que l'EIP7702 est une bonne proposition qui peut bénéficier à tous les utilisateurs. Cependant, le processus de gouvernance par lequel l'EIP7702 remplace l'EIP3074 n'est pas optimal, pour des raisons incluant :
EIP3074 a traversé un long processus de discussion, comme nous l'avons déjà mentionné dans le texte précédent, EIP3074 a été discuté à plusieurs reprises lors des réunions des développeurs principaux.
Après que l'EIP3074 a été décidé d'être inclus dans la mise à niveau Pectra, il a reçu une forte opposition de la communauté ERC4337. Bien sûr, dans le texte ci-dessus, nous avons déjà souligné que le principal développeur d'ERC4337, yova, a exprimé à plusieurs reprises son opposition à l'EIP3074 lors des réunions des développeurs principaux.
Zerodev pense que le meilleur chemin de gouvernance devrait être que la communauté ERC4337 participe largement et exprime son avis au cours du long processus de discussion des développeurs principaux sur l'EIP3074.
Les développeurs d'EIP3074 estiment qu'ERC4337 devrait être responsable des échecs de gouvernance. En effet, EIP3074 a participé activement à la gouvernance au cours des dernières années et a échangé à plusieurs reprises avec le développeur principal d'ERC4337, yova.
La communauté ERC4337, quant à elle, estime que EIP3074 est la première responsable des défaillances de la gouvernance. ERC4337 membres de la communauté pensent que Yova, en tant que développeur principal du ERC4337, a exprimé son opposition à EIP3074 lors de plusieurs réunions de développeurs principaux, mais le développeur principal ne semble pas écouter. La plupart des membres de la communauté dans le ERC4337 ne prêtent pas attention à la dynamique de gouvernance de EIP3074, et la plupart des membres s’accordent à dire que EIP3074 est une norme dépassée. La communauté ERC4337 a également estimé que les développeurs principaux ne communiquaient pas activement avec la communauté ERC4337.
EIP3074 et ERC4337 croient tous deux avoir réalisé un bon travail de gouvernance, tandis que l'autre partie devrait porter la principale responsabilité de l'échec de la gouvernance. Il est évident qu'il existe une raison plus profonde qui joue un rôle dans ce processus de gouvernance.
En termes simples, cette raison plus profonde est en réalité la feuille de route d'Ethereum. La feuille de route d'Ethereum a plus de pouvoir que les réunions des développeurs principaux. La feuille de route de l'abstraction des comptes est centrée sur l'ERC4337. L'EIP7702 est entièrement compatible avec la norme ERC4337, mais l'EIP3074 n'est pas pleinement compatible avec la norme ERC4337. Donc, du point de vue de la feuille de route d'Ethereum, il est certain que l'EIP3074 sera remplacé.
Bien sûr, la feuille de route d'Ethereum est avant tout une démonstration de la vision future d'Ethereum par Vitalik. En cas de débat sérieux dans le processus de gouvernance d'Ethereum, Vitalik, en tant que défendeur de la feuille de route, a le dernier mot. C'est d'ailleurs la décision de Vitalik qui a conduit au remplacement de l'EIP3074.
Le modèle de gouvernance d'Ethereum est le modèle values ⇒ vision ⇒ roadmaps ⇒ clients, ou simplement le modèle VVRC. Le processus de gouvernance est le suivant :
valeurs des valeurs, en particulier les valeurs de la communauté, les valeurs de la communauté Ethereum incluent la décentralisation, la résistance à la censure, etc.
vision, en réalité, c'est la réflexion personnelle de Vitalik sur l'avenir d'Ethereum.
roadmaps, les chercheurs fournissent quelques considérations techniques sur la base de la vision pour donner une feuille de route d'implémentation relativement complète.
clients Mise en œuvre du client, les développeurs principaux du client utilisent des outils comme les réunions des développeurs principaux pour discuter de la feuille de route et mettre en œuvre les exigences de la feuille de route.
Le processus décrit ci-dessus est le véritable processus de gouvernance d'Ethereum. Nous pouvons voir que la vision personnelle de Vitalik se situe dans la partie inférieure du modèle de gouvernance d'Ethereum, donc une fois qu'il y a de sérieuses divergences dans l'implémentation du client, l'opinion personnelle de Vitalik sera la décision finale.
Références
Introduction à ZeroDev
null
Introduction à ZeroDev
null
Notes sur la feuille de route de l'abstraction de compte - HackMD
Notes sur la feuille de route de l'abstraction de compte *Remerciements spéciaux à Vitalik et à l'équipe AA pour leurs commentaires
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Guerre de gouvernance : EIP3074, ERC4337 et EIP7702｜Recherche GCC
Rédaction : shew
Aperçu
Dans la mise à niveau de Pectra, la question des disputes de gouvernance les plus complexes est apparue. Lorsque l'EIP3074 a été intégré dans la mise à niveau de Pectra, cela a provoqué d'énormes controverses, notamment de la part de l'équipe d'ERC4337.
EIP3074 est dans une impasse, le processus de gouvernance ne peut pas se poursuivre. Jusqu'à ce que Vitalik propose EIP7702, mettant fin aux questions de l'équipe ERC4337 concernant EIP3074.
GCC Research a constaté que la gouvernance des EIP3074 et des ERC7702 dans la mise à niveau de Pectra est rarement discutée dans le monde chinois. Mais cette question de gouvernance reflète également le problème plus profond de la gouvernance d’Ethereum, c’est-à-dire qui peut contrôler le contenu spécifique du code en partant du principe que le code est la loi. Les questions de gouvernance de EIP3074 et de ERC7702 peuvent nous donner une bonne perspective sur le processus de gouvernance réel au sein d’Ethereum.
La conclusion finale de cet article est une paraphrase d’un article d’opinion publié par ZeroDev, qui affirme que le système de gouvernance d’Ethereum est un modèle VVRC, et que l’inclusion de toute proposition doit d’abord s’aligner sur les valeurs d’Ethereum (Value), puis la proposition doit refléter la vision conçue par Vitalik (Vision), la proposition finale doit être reflétée dans la feuille de route (Roadmap), puis discutée par les développeurs principaux et intégrée au client (Client) mise en œuvre.
Dans un précédent article, GCC Research a présenté que l'EIP2537 a simplement rencontré des problèmes de mise en œuvre au niveau du client, ce qui a entraîné un retard dans son inclusion dans le hard fork, tandis que l'EIP3074 n'a finalement pas été inclus dans le hard fork en raison de problèmes de vision et de feuille de route. Les développeurs principaux d'Ethereum ont directement choisi l'EIP7702 rédigé par Vitalik comme proposition finale d'abstraction de compte.
Aperçu du contenu de la proposition
Avant de présenter les processus de gouvernance spécifiques, nous devons d'abord donner une brève introduction au contenu spécifique concernant EIP3074, EIP7702 et ERC4337.
EIP3074 s’agit d’une proposition de couche d’exécution dont l’exécution nécessite une mise à niveau logicielle de nœud. L’objectif principal de EIP3074 est de permettre le parrainage du gaz et le commerce en vrac. Ce que l’on appelle le parrainage de gaz signifie que les utilisateurs peuvent payer des frais de gaz avec n’importe quel jeton, ou que les utilisateurs peuvent payer des frais de gaz hors ligne. Cependant, il convient de noter que EIP3074 ne permet pas aux utilisateurs d’utiliser un algorithme de signature autre que secp256k1, par rapport à d’autres propositions d’abstraction de compte qui permettent de modifier l’algorithme de vérification de signature. En d’autres termes, EIP3074 n’est pas une proposition qui satisfait toutes les abstractions de compte. C’est aussi un point pour lequel EIP3074 a été critiqué.
Pour atteindre l'objectif souhaité, l'EIP3074 introduit deux codes d'opération, à savoir AUTH et AUTHCALL. Le code d'opération AUTH peut, par la vérification de la signature, configurer le champ authorized dans le contexte EVM actuel à l'adresse du signataire lorsque la vérification de la signature réussit. Une fois le champ authorized configuré dans le contexte, AUTHCALL peut utiliser l'adresse authorized comme msg.sender pour initier une transaction. D'une certaine manière, les utilisateurs peuvent déléguer leur compte à un contrat intelligent pour une transaction via une signature. On appelle généralement ce contrat intelligent délégué par l'utilisateur un contrat invoker.
Quel est le contenu spécifique de la signature de l'utilisateur ? L'utilisateur doit signer le contenu suivant :
L'adresse invoker mentionnée dans le contenu ci-dessus fait référence à l'adresse du contrat invoker que l'utilisateur souhaite déléguer. L'EVM vérifiera si le contenu de la signature de l'utilisateur correspond au contrat qui vérifie réellement la signature, afin d'éviter que le contenu de la signature AUTH de l'utilisateur soit utilisé par d'autres contrats.
Un nonce, quant à lui, est un identifiant qui empêche la relecture des transactions. Cependant, il convient de noter que l’opcode AUTH vérifiera si le nonce dans la signature est cohérent avec le nonce de l’EOA actuellement signé, et théoriquement tant que l’utilisateur n’utilise pas le compte EOA pour initier une transaction afin d’augmenter la valeur du nonce, alors la signature AUTH émise par l’utilisateur peut toujours être utilisée par le contrat de l’appelant. Il s’agit d’une énorme faille de sécurité qui signifie que les utilisateurs qui utilisent EIP3074 doivent faire confiance au fournisseur de services de relais qui obtient la signature. Si le fournisseur de services de relais qui obtient la signature de l’utilisateur est malveillant, il peut rejouer la signature d’authentification de l’utilisateur à un moment donné pour voler les ressources de l’utilisateur.
Un autre problème de sécurité est le champ de validation. Le champ de validation est utilisé pour garantir certaines opérations, et les utilisateurs peuvent affiner le contrôle de leurs autorisations de signature dans la validation, par exemple en écrivant du contenu dans la validation pour empêcher que leur contenu de signature ne soit utilisé pour les transferts d’ETH. Dans le document EIP3074, le proposant donne une série d’exemples d’utilisation du champ commit. Mais le problème est que le rôle du commit dépend entièrement de la définition du contrat intelligent, et qu’il s’agit essentiellement d’un contenu facultatif. Différents contrats intelligents peuvent analyser le contenu de la validation de manière totalement incohérente, et certains contrats peuvent même ne pas lire du tout le contenu de la validation. Si vous souhaitez utiliser EIP3074 en toute sécurité, il vous suffit d’examiner vous-même le contrat intelligent.
Enfin, jetons un coup d’œil à l’impact d’un EIP3074 sur le mempool de transactions Ethereum actuel. Avec l’introduction de EIP3074, un pirate peut utiliser un grand nombre de comptes pour initier des transactions, puis utiliser EIP3074 transactions pour drainer l’ETH de ces comptes en une seule fois lorsque la transaction est sur le point d’être emballée, ce qui entraînera l’échec de toutes les transactions précédemment initiées. Ce type d’attaque peut avoir un impact considérable sur les nœuds de la couche d’exécution et est essentiellement une attaque par déni de service. Il convient toutefois de noter que le EIP7702 utilisé pour remplacer EIP3074 présente également ce problème, mais EIP7702 introduit quelques limitations pour éviter ce problème, dont nous parlerons plus tard.
En plus des problèmes liés à l'EIP3074 mentionnés ci-dessus, l'auteur de l'ERC4337, Yova, a présenté davantage d'objections dans son article "Implications of EIP-3074 inclusion". En termes simples, ces objections comprennent principalement :
EIP7702 s’agit d’une proposition de Vitalik pour remplacer EIP3074. Au lieu d’introduire un nouvel opcode EVM, la proposition introduit un nouveau type de transaction, appelé SET_CODE_TX_TYPE. Une fois qu’un utilisateur initie un EIP7702 type de transaction, il peut ajouter la fonctionnalité du contrat intelligent à son EOA tout en conservant les fonctionnalités de base du EOA. Pour faire simple, les utilisateurs peuvent soit continuer à initier des transactions à l’aide de portefeuilles tels que MetaMask, soit appeler des adresses EOA sous la forme de contrats intelligents.
Nous introduisons les fonctionnalités de l'EIP7702 avec un exemple simple de transaction en lot. Les utilisateurs peuvent utiliser l'EIP7702 pour déléguer leur adresse EOA à un contrat intelligent capable d'exécuter des appels en lot, puis les utilisateurs peuvent directement appeler leur adresse EOA pour initier des transactions en lot sous la forme d'un contrat intelligent.
En termes de mise en œuvre technique, par rapport aux transactions traditionnelles, EIP7702 introduit une liste d’autorisation_list de types de transactions, qui est [[chain_id, address, nonce, y_parity, r, s], ...]. où adresse est l’adresse du contrat intelligent que l’utilisateur souhaite déléguer et nonce est la valeur actuelle du nonce de l’utilisateur. Les y_parity, r et s restants sont le résultat de la signature de l’utilisateur. Dans le processus d’exécution spécifique, nous allons d’abord parcourir chaque élément dans authorization_list pour le traitement, et la méthode de traitement consiste à restaurer l’adresse EOA via des paramètres de signature tels que y_parity, puis à pointer l’adresse EOA vers le contrat intelligent avec l’adresse d’adresse. Après cela, l’adresse EOA peut accepter l’appel pour jouer la fonction du contrat.
Les avantages de EIP7702 sont évidents, et l’avantage principal de EIP7702 est essentiellement de permettre à EOA d’avoir les fonctionnalités d’un contrat intelligent. Cela est cohérent avec les règles de base de l’abstraction de compte telles que ERC4337, ce qui signifie que EIP7702 pouvez tirer parti de toute l’infrastructure existante dans le domaine d’abstraction de compte courant pour explorer et réutiliser l’infrastructure existante, par exemple EIP7702 pouvez utiliser directement ERC4337 infrastructure. EntryPoint v0.8 avec prise en charge des appels EIP7702 est désormais disponible en ERC4337. Du point de vue de la réutilisation de l’infrastructure existante, EIP7702 a le même degré de caractère ludique que ERC4337.
Bien sûr, l'EIP7702 n'a en réalité pas complètement corrigé les problèmes soulevés dans l'EIP3074. La plupart des problèmes présents dans l'EIP3074 subsistent encore. L'EIP7702 exige que les contrats de compte aient une mise en œuvre sécurisée, tandis que le protocole lui-même ne garantit aucune sécurité. Dans les premières propositions de l'EIP7702, certains développeurs ont suggéré de standardiser le nonce de signature pour éviter d'éventuelles attaques par rejeu, mais l'EIP7702 n'a finalement pas accepté ces suggestions. Donc, si un utilisateur souhaite utiliser l'EIP7702 de manière sécurisée, il doit examiner lui-même la sécurité du contrat.
Dans le même temps, EIP7702 crée également une série de problèmes pour la couche exécutive. Ci-dessus, nous avons décrit un moyen possible d’exploiter EIP3074 pour effectuer des attaques par déni de service sur les pools de mémoire de la couche d’exécution. Cette méthode est également efficace dans EIP7702. Par conséquent, EIP7702 recommande que toutes les adresses EOA qui utilisent EIP7702 n’aient qu’une seule transaction en attente dans le mempool afin d’éviter les attaques par déni de service à grande échelle.
En résumé, le principal problème de l'EIP3074 est qu'il n'a pas mis en œuvre la fonctionnalité complète d'abstraction de compte, alors que l'EIP7702 a réalisé cette fonctionnalité complète. La définition de ce que comprend "l'abstraction complète de compte" est précisément celle de l'auteur de l'ERC4337. À ce stade, le lecteur devrait comprendre pourquoi l'EIP3074 a été contesté par l'équipe de l'ERC4337 et finalement remplacé par l'EIP7702. Nous présenterons dans la suite l'ensemble du processus de gouvernance et de discussion.
Le processus de gouvernance des EIP3074 et EIP7702
EIP3074 a été mentionné très tôt lors des réunions des développeurs principaux d'Ethereum. Lors de la réunion #109 du 2 avril 2021, les développeurs principaux d'Ethereum ont eu une discussion simple sur EIP3074. Le résultat de la discussion était très simple:
Il est intéressant de noter que Vitalik a déclaré lors de cette conférence qu'il est nécessaire qu'Ethereum dispose d'une solution technique permettant de générer plusieurs appels à partir d'une seule transaction conçue pour les EOA. Bien que l'EIP3074 présente des problèmes de sécurité potentiels, l'EIP3074 propose une solution technique possible, et les développeurs doivent avancer sur la base de l'EIP3074.
Il est évident qu'en raison des problèmes de sécurité liés à EIP3074, cette réunion n'a pas inclus EIP3074 dans la mise à niveau de Londres.
Lors de la réunion #115 du 11 juin 2021, les développeurs de l'EIP3074 ont soumis un rapport sur l'audit de sécurité, la réunion a principalement discuté des problèmes de sécurité de l'EIP3074. Une conclusion simple est que le contrat invoker de l'EIP3074 est très important dans le système, donc la question de savoir s'il est nécessaire de gérer le contrat invoker est posée. Les développeurs de l'EIP3074 souhaitent procéder à une preuve formelle du contrat invoker pour accroître la sécurité.
Bien sûr, il y a aussi une partie de la discussion sur certains contrats utilisant msg.sender == tx.origin pour déterminer si l’adresse d’appel est EOA, et lorsque EIP3074 sera introduite, ces jugements seront invalidés, mais la conclusion est que l’échec de cette partie du jugement ne causera pas de graves problèmes de sécurité. En résumé, la réunion s’est concentrée sur les EIP3074 présentateurs présentant les résultats de l’audit de sécurité 3074 aux développeurs principaux. La conclusion finale de la réunion a été que 3074 doit encore examiner la question du contrat d’invocation et qu’il est recommandé de ne pas se joindre au hard fork de Londres.
Lors de la réunion #116 du 25 juin 2021, Yova, l'un des auteurs principaux d'ERC4337, a soumis des documents intitulés A case for a simpler alternative to EIP 3074, qui indiquent qu'EIP3074 présente de nombreux problèmes de sécurité. Il est suggéré de modifier certains de ses contenus, par exemple en limitant le contenu du champ commit dans la signature, exigeant que le champ commit soit sous la forme {nonce,to,gas,calldata,value,chainid}. Après avoir utilisé ce mode de signature, EIP3074 ne peut être utilisé que pour exécuter certaines transactions spécifiques afin de garantir la sécurité des transactions.
Lors de cette réunion, l'auteur de l'EIP3074 a répondu aux documents soumis par Yova :
Vitalik a présenté les trois points suivants lors de cette conférence :
Lors de la réunion #131 du 4 février 2022, les développeurs ont discuté des types d'EIP qui devraient être inclus dans la mise à niveau ShangHai. L'EIP3074 a été inclus dans le champ de discussion, mais les développeurs ont simplement synchronisé les dynamiques de développement de l'EIP3074. Il est à noter qu'avant le début de la réunion, Nethermind a rédigé un article intitulé "Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337", dans lequel aucune objection à l'EIP3074 n'a été mentionnée.
Lors de la réunion #167 du 3 août 2023, les développeurs principaux ont mentionné EIP3074 tout en discutant d’un autre EIP5806. EIP5806 s’agit d’un contrat qui permet à EOA d’appeler des contrats externes à l’aide d’appels deleGate.io pendant les transactions. Le système est quelque peu similaire à celui de EIP7702. Cependant, la sécurité de cette solution a également été remise en question par les développeurs principaux, Ansgar notant que dans le passé, EIP3074 n’a pas pu être incluse dans le hard fork en raison d’éventuels problèmes de sécurité, EIP5806'est une approche plus agressive.
Lors de la réunion #182 du 29 février 2024, les développeurs ont discuté en détail de la question de savoir si l'EIP3074 devrait être inclus dans la mise à niveau Pectra. Vitalik a proposé que tout standard d'abstraction de compte doit avoir les trois fonctionnalités suivantes :
Les commentaires de Vitalik sur EIP5806 sont peut-être une meilleure option que EIP3074. Andrew pense que EIP3074 est plus polyvalent que EIP5806 et recommande d’utiliser EIP3074. Vitalik rétorque à Andrew, arguant que tous les portefeuilles à l’avenir pourraient être des portefeuilles de contrats intelligents, et que si cela se produit, l’opcode pré-assemblé introduit par EIP3074 sera invalidé. Yoav, l’auteur du ERC4337, a fait une longue présentation lors de la conférence, qui a couvert les sujets suivants :
Yova est plus enclin à utiliser EIP5806 comme solution d'abstraction de compte.
Lors de la réunion #183 du 14 mars 2024, les développeurs principaux ont invité Dan Finlay de MetaMask à discuter de ce que le portefeuille pense de EIP3074. Dan est en faveur de EIP3074, notant que MetaMask prendra également en charge les tests de EIP3074. MetaMask estime que EIP3074 peut permettre à EOA de profiter de toutes les fonctionnalités d’abstraction de compte. En termes de sécurité, EIP3074 fournit une solution pour les fournisseurs de services de portefeuille, c’est-à-dire la séparation des clés chaudes et froides. Le fournisseur de services de portefeuille peut détenir la signature EIP3074 d’EOA pour initier une transaction, et les utilisateurs peuvent utiliser la clé privée à chaud dans les transactions normales, mais la clé privée froide peut être conservée dans le portefeuille matériel de l’utilisateur, et lorsqu’une urgence est détectée, l’utilisateur peut utiliser la clé privée froide dans le portefeuille à froid pour initier une transaction afin de révoquer la signature du EIP3074. Cette solution de séparation des clés privées à chaud et à froid offre de la flexibilité aux fournisseurs de portefeuilles.
Vitalik souligne qu’au sein de la EIP3074, les concepteurs de portefeuilles doivent concevoir une logique d’autorisation stricte pour éviter l’utilisation abusive des signatures EIP3074 des utilisateurs. Il est intéressant de noter qu’en discutant de la capacité de MetaMask à ajouter des fonctionnalités EIP3074, Vitalik a souligné que L2 pourrait être utilisé comme solution de transition, c’est-à-dire que tout nouveau changement de couche d’exécution devrait être mis en œuvre d’abord dans L2, car L2 a un financement limité et peut causer de graves pertes même si quelque chose ne va pas.
Dror Tiros a souligné lors de la discussion que la meilleure façon de garantir la sécurité de l'EIP3074 est que l'équipe officielle d'Ethereum fournisse directement le contrat invoker. Cependant, Dan Finlay s'oppose à cette idée, affirmant que le contrat invoker devrait être entièrement décidé par les utilisateurs, et que le marché finira par choisir le contrat invoker le plus sûr.
Ansgar insiste toujours sur le fait qu’EIP3074 une signature ne devrait correspondre qu’à une seule transaction, et que les fournisseurs de services de portefeuille ne devraient pas réutiliser les signatures des utilisateurs pour initier des transactions, mais Dan Finlay s’y est également opposé. Dan Finlay pense que EIP3074 doit être signé par un portefeuille froid, puis que le fournisseur de services de portefeuille peut réutiliser la signature pour initier des transactions directement pour l’utilisateur, et si l’utilisateur doit resigner à chaque fois, la clé privée froide peut être utilisée plusieurs fois. Ceci est incompatible avec l’idée de séparer les clés privées chaudes et froides.
Lors de cette réunion, les développeurs principaux ont discuté d'un autre sujet important : les listes d'inclusion. Les listes d'inclusion sont un moyen d'augmenter les propriétés d'anti-censure d'Ethereum. En termes simples, les listes d'inclusion permettent à certaines transactions d'être promises pour être directement incluses dans le prochain bloc. Mais les développeurs principaux ont souligné que l'EIP3074 est en contradiction avec les listes d'inclusion.
Lors de la réunion #185 du 11 avril 2024, la plupart des implémentations clients internes ont convenu d'inclure l'EIP3074 dans le hard fork Pectra, mais Geth a exprimé son opposition, car l'EIP3074 pourrait entraîner des problèmes avec les arbres Verkle. Danno a également exprimé son opposition, car l'EIP3074 pourrait entraîner des situations de réutilisation de signatures. Yoav a également exprimé son opposition, proposant un scénario d'attaque utilisant l'EIP3074 et les transactions Blob sur le pool de mémoire. En résumé, un attaquant pourrait initier un grand nombre de transactions Blob, toutes contenant de grandes quantités de données, puis utiliser l'EIP3074 pour invalider toutes ces transactions Blob.
En résumé, lors de cette réunion, tous les développeurs de clients ont convenu que l'EIP3074 serait inclus dans la mise à niveau finale.
Lors de la réunion #187 du 9 mai 2024, les développeurs principaux ont discuté pour la première fois de la question du remplacement de EIP3074 EIP7702. Le EIP7702 a été fait dans les 90 premières minutes de la réunion des développeurs principaux de Vitalik. Au cours de la conférence, les développeurs principaux ont reconnu que EIP7702 était un meilleur standard que EIP3074. Il n’y a pas eu d’opposition à EIP7702 lors de cette réunion, mais certains chercheurs ont estimé qu’EIP7702 avait également des attributs irrévocables similaires à EIP3074, ce qui pourrait entraîner des problèmes de sécurité financière.
Lors de la réunion #188 du 23 mai 2024, le développement de base a discuté de la possibilité de remplacer EIP3074 par EIP7702. La conclusion finale de la réunion a été de remplacer EIP3074 par EIP7702 en tant que norme d’abstraction de compte dans le hard fork de Pectra. Vitalik souligne que EIP7702 a également une certaine irrévocabilité compatible avec EIP3074, des attributs qui ont été beaucoup discutés dans la discussion sur EIP3074. Il est intéressant de noter qu’il y avait un grand nombre de délégués ERC4337 à la réunion.
En fait, la discussion sur le remplacement de l'EIP3074 par l'EIP7702 avait déjà été largement débattue avant la 188e réunion des développeurs principaux, et le résultat de la discussion à l'époque était que le 3074 serait remplacé, donc il n'y a pas eu beaucoup de controverses lors de la réunion des développeurs principaux.
Feuille de route et décisions
L'infrastructure de base d'abstraction de compte Zerodev a publié un article intéressant après avoir appris que l'EIP3074 serait remplacé, intitulé Reflections on Ethereum Governance Following the 3074 Saga. La conclusion de cet article est que l'EIP7702 est une bonne proposition qui peut bénéficier à tous les utilisateurs. Cependant, le processus de gouvernance par lequel l'EIP7702 remplace l'EIP3074 n'est pas optimal, pour des raisons incluant :
Zerodev pense que le meilleur chemin de gouvernance devrait être que la communauté ERC4337 participe largement et exprime son avis au cours du long processus de discussion des développeurs principaux sur l'EIP3074.
Les développeurs d'EIP3074 estiment qu'ERC4337 devrait être responsable des échecs de gouvernance. En effet, EIP3074 a participé activement à la gouvernance au cours des dernières années et a échangé à plusieurs reprises avec le développeur principal d'ERC4337, yova.
La communauté ERC4337, quant à elle, estime que EIP3074 est la première responsable des défaillances de la gouvernance. ERC4337 membres de la communauté pensent que Yova, en tant que développeur principal du ERC4337, a exprimé son opposition à EIP3074 lors de plusieurs réunions de développeurs principaux, mais le développeur principal ne semble pas écouter. La plupart des membres de la communauté dans le ERC4337 ne prêtent pas attention à la dynamique de gouvernance de EIP3074, et la plupart des membres s’accordent à dire que EIP3074 est une norme dépassée. La communauté ERC4337 a également estimé que les développeurs principaux ne communiquaient pas activement avec la communauté ERC4337.
EIP3074 et ERC4337 croient tous deux avoir réalisé un bon travail de gouvernance, tandis que l'autre partie devrait porter la principale responsabilité de l'échec de la gouvernance. Il est évident qu'il existe une raison plus profonde qui joue un rôle dans ce processus de gouvernance.
En termes simples, cette raison plus profonde est en réalité la feuille de route d'Ethereum. La feuille de route d'Ethereum a plus de pouvoir que les réunions des développeurs principaux. La feuille de route de l'abstraction des comptes est centrée sur l'ERC4337. L'EIP7702 est entièrement compatible avec la norme ERC4337, mais l'EIP3074 n'est pas pleinement compatible avec la norme ERC4337. Donc, du point de vue de la feuille de route d'Ethereum, il est certain que l'EIP3074 sera remplacé.
Bien sûr, la feuille de route d'Ethereum est avant tout une démonstration de la vision future d'Ethereum par Vitalik. En cas de débat sérieux dans le processus de gouvernance d'Ethereum, Vitalik, en tant que défendeur de la feuille de route, a le dernier mot. C'est d'ailleurs la décision de Vitalik qui a conduit au remplacement de l'EIP3074.
Le modèle de gouvernance d'Ethereum est le modèle values ⇒ vision ⇒ roadmaps ⇒ clients, ou simplement le modèle VVRC. Le processus de gouvernance est le suivant :
Le processus décrit ci-dessus est le véritable processus de gouvernance d'Ethereum. Nous pouvons voir que la vision personnelle de Vitalik se situe dans la partie inférieure du modèle de gouvernance d'Ethereum, donc une fois qu'il y a de sérieuses divergences dans l'implémentation du client, l'opinion personnelle de Vitalik sera la décision finale.
Notes sur la feuille de route de l'abstraction de compte - HackMD