Dans la mise à niveau de Pectra, un problème de gouvernance très complexe est apparu. Lorsque l'EIP3074 a été intégré dans la mise à niveau de Pectra, cela a provoqué d'énormes débats, en particulier de la part de l'équipe d'ERC4337.
EIP3074 est dans une impasse, le processus de gouvernance ne peut pas continuer. Jusqu'à ce que Vitalik propose EIP7702 qui met fin aux doutes de l'équipe ERC4337 sur EIP3074.
GCC Research a découvert qu'il y a peu de discussions sur les questions de gouvernance concernant EIP3074 et ERC7702 dans le cadre de la mise à niveau de Pectra dans le monde chinois. Cependant, cette question de gouvernance reflète également un problème profond de la gouvernance d'Ethereum, à savoir qui peut contrôler le contenu spécifique du code dans le cadre du principe "le code est la loi". Les questions de gouvernance d'EIP3074 et ERC7702 peuvent nous offrir une excellente perspective pour observer les véritables processus de gouvernance au sein d'Ethereum.
La conclusion finale de cet article est tirée d'un commentaire publié par ZeroDev, qui indique que le système de gouvernance d'Ethereum est un modèle VVRC. Toute proposition doit d'abord être conforme aux valeurs d'Ethereum (Value), puis la proposition doit refléter la vision conçue par Vitalik (Vision), et enfin, la proposition doit être intégrée à la feuille de route (Roadmap). Après discussion par les développeurs principaux, elle sera intégrée à l'implémentation du client (Client).
GCC Research a présenté dans son précédent article que l'EIP2537 a rencontré des problèmes d'implémentation au niveau du client, ce qui a finalement conduit à un retard dans son inclusion dans le hard fork, tandis que l'EIP3074 n'a 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.
Résumé du contenu de la proposition
Avant de présenter les processus de gouvernance spécifiques, nous devons d'abord donner un aperçu des contenus spécifiques liés à EIP3074, EIP7702 et ERC4337.
EIP3074 est une proposition de couche d'exécution qui nécessite une mise à niveau du logiciel des nœuds pour être mise en œuvre. L'objectif principal d'EIP3074 est de permettre le sponsoring de gas et la fonctionnalité de transactions groupées. Ce que l'on appelle le sponsoring de gas signifie que les utilisateurs peuvent payer les frais de gas avec n'importe quel token, ou que les utilisateurs peuvent payer les frais de gas hors ligne. Cependant, il est important de noter qu'en comparaison avec d'autres propositions d'abstraction de compte qui permettent de modifier l'algorithme de vérification de signature, EIP3074 ne permet pas aux utilisateurs d'utiliser d'autres algorithmes de signature que secp256k1. En d'autres termes, EIP3074 n'est pas une proposition qui répond à toutes les fonctionnalités d'abstraction de compte. C'est aussi un point qui a valu à EIP3074 de nombreuses critiques.
Pour atteindre les objectifs visés, EIP3074 introduit deux codes d'opération, à savoir AUTH et AUTHCALL. Le code d'opération AUTH peut valider une signature, et une fois la validation de la signature effectuée, ce code d'opération configurera l'adresse authorized dans le contexte EVM actuel en tant qu'adresse du signataire. Une fois l'adresse authorized configurée dans le contexte, AUTHCALL peut utiliser cette adresse comme msg.sender pour initier une transaction. D'une certaine manière, l'utilisateur peut déléguer son compte à un contrat intelligent pour une transaction en signant. Nous appelons généralement ce contrat intelligent délégué par l'utilisateur un contrat invoker.
Quelle est la 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 est cohérent avec le contrat qui valide réellement la signature, afin d'éviter que le contenu de la signature AUTH de l'utilisateur soit utilisé par d'autres contrats.
Le nonce est un identifiant qui empêche la répétition des transactions. Cependant, il est important de noter que l'opcode AUTH vérifiera si le nonce de la signature correspond à celui de l'EOA actuel. En théorie, tant que l'utilisateur n'utilise pas le compte EOA pour initier une transaction augmentant la valeur du nonce, la signature AUTH émise par l'utilisateur peut être utilisée indéfiniment par le contrat invoker. C'est une énorme faille de sécurité, ce qui signifie que les utilisateurs utilisant 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 pourrait à un moment donné reproduire la signature AUTH de l'utilisateur pour voler les actifs de l'utilisateur.
Un autre problème de sécurité concerne le champ commit. Le champ commit est utilisé pour garantir certaines opérations, permettant à l'utilisateur de contrôler finement ses droits de signature à l'intérieur du commit, par exemple en écrivant certaines informations pour éviter que son contenu de signature soit utilisé pour un transfert ETH. Dans le document EIP3074, le proposeur a fourni une série d'exemples exploitant le champ commit. Cependant, le problème est que la fonction du commit dépend entièrement de la définition du contrat intelligent, ce qui est en fait un contenu optionnel. Différents contrats intelligents peuvent interpréter le contenu du commit de manière totalement incohérente, et il est même possible que certains contrats ne lisent pas du tout le contenu du commit. Si un utilisateur souhaite utiliser EIP3074 de manière sécurisée, il doit examiner simplement le contrat intelligent lui-même.
Enfin, nous présentons l'impact de l'EIP3074 sur le pool de mémoire des transactions Ethereum actuel. Après l'introduction de l'EIP3074, une méthode d'attaque sur le pool de mémoire pourrait émerger, où des hackers pourraient utiliser un grand nombre de comptes pour initier des transactions, puis, lorsque les transactions sont sur le point d'être emballées, utiliser l'EIP3074 pour vider rapidement l'ETH de ces comptes. Cela entraînerait l'échec de toutes les transactions précédemment initiées. Cette méthode d'attaque aurait un impact considérable sur les nœuds de couche d'exécution, c'est essentiellement une attaque de type DoS. Cependant, il est important de noter que l'EIP7702, qui remplace l'EIP3074, présente également ce problème, mais l'EIP7702 a introduit certaines restrictions pour éviter que ce problème ne se produise, que nous discuterons plus loin.
En plus des problèmes liés à l'EIP3074 mentionnés ci-dessus, l'auteur de l'ERC4337, Yova, a présenté d'autres objections dans son article "Implications of EIP-3074 inclusion". En termes simples, ces objections comprennent principalement :
Risque de centralisation. En raison des propriétés particulières de la signature AUTH, les utilisateurs doivent faire entièrement confiance aux fournisseurs de services de relais EIP3074 et à l'infrastructure sous-jacente. De plus, l'infrastructure construite par des protocoles d'abstraction de compte tels qu'ERC4337 est complètement incompatible avec EIP3074.
La sécurité des utilisateurs. Comme mentionné ci-dessus, l'EIP3074 n'a pas de méthode de contrôle d'accès unifiée, et la conception de 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. Par rapport à d'autres propositions d'abstraction de compte, l'EIP3074 est incomplète 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 les utilisateurs doivent déléguer leur compte à un contrat intelligent, ils doivent effectuer une signature AUTH, puis publier l'appel contenant la signature AUTH sur la chaîne. Les utilisateurs doivent 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 à travers un exemple simple de transaction en masse. Les utilisateurs peuvent utiliser l'EIP7702 pour déléguer leur adresse EOA à un contrat intelligent capable d'exécuter des appels en masse, puis les utilisateurs peuvent directement appeler leur adresse EOA pour initier des transactions en masse 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 l'EIP7702 sont très évidents, dont le principal est que l'EIP7702 permet essentiellement à un EOA de posséder des fonctions de contrat intelligent. Cela est conforme aux règles fondamentales de l'abstraction de compte, comme le stipule l'ERC4337, ce qui signifie que l'EIP7702 peut tirer parti de toutes les explorations actuelles dans le domaine de l'abstraction de compte et réutiliser les infrastructures existantes, par exemple, l'EIP7702 peut directement utiliser l'infrastructure de l'ERC4337. Actuellement, l'ERC4337 a déjà lancé un EntryPoint v0.8 qui prend en charge les appels de l'EIP7702. Du point de vue de la réutilisation de l'infrastructure existante, l'EIP7702 et l'ERC4337 ont un degré de décentralisation équivalent.
Bien sûr, l'EIP7702 n'a en fait pas complètement résolu les problèmes soulevés dans l'EIP3074. La plupart des problèmes présents dans l'EIP3074 persistent. 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é. Au début de l'EIP7702, certains développeurs avaient proposé de normaliser le nonce de signature pour éviter d'éventuelles attaques par rejeu, mais l'EIP7702 n'a finalement pas accepté ces suggestions. Donc, si les utilisateurs souhaitent utiliser l'EIP7702 en toute sécurité, ils doivent examiner eux-mêmes la sécurité des contrats.
En même temps, l'EIP7702 posera également une série de problèmes pour la couche d'exécution. Dans le texte précédent, nous avons présenté une méthode possible d'attaque par déni de service (DoS) sur le pool de mémoire de la couche d'exécution en utilisant l'EIP3074. Cette méthode est également valable pour l'EIP7702. Ainsi, l'EIP7702 recommande que toutes les adresses EOA utilisant l'EIP7702 ne puissent avoir qu'une seule transaction en attente dans le pool de mémoire, afin d'éviter l'apparition d'attaques DoS à grande échelle.
En résumé, le principal problème de l'EIP3074 est qu'il n'a pas mis en œuvre une fonctionnalité complète d'abstraction de compte, tandis que l'EIP7702 a réalisé cette fonctionnalité complète. La définition de ce que comprend "l'abstraction complète de compte" a été fournie par 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 le processus complet de gouvernance et de discussion dans les sections suivantes.
Le processus de gouvernance d'EIP3074 et d'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 EIP3074 présente des risques de sécurité, ce qui pourrait entraîner des pertes de sécurité graves pour les utilisateurs. Il a recommandé de normaliser davantage le contenu spécifique de la signature AUTH dans l'EIP3074, proposition qui a été soutenue par Martin.
James a soulevé que l'EIP3074 pourrait présenter des vulnérabilités potentielles au niveau d'exécution, telles que des attaques DoS, et a recommandé que l'EIP3074 fournisse une analyse écrite des menaces.
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 est la collaboration et la réalisation avec les applications, en particulier 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 affirmé lors de cette conférence qu'Ethereum a besoin d'une solution technique pour 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é possibles, l'EIP3074 fournit une solution technique potentielle sur laquelle les développeurs doivent avancer.
Il est clair qu'en raison des problèmes de sécurité liés à l'EIP3074, cette réunion n'a pas inclus l'EIP3074 dans la mise à niveau de Londres.
Lors de la réunion #115 du 11 juin 2021, les développeurs d'EIP3074 ont soumis un rapport sur l'audit de sécurité, et la réunion a principalement discuté des problèmes de sécurité d'EIP3074. Une conclusion simple est que le contrat invoker d'EIP3074 est très important dans le système, donc la question de savoir s'il faut gérer le contrat invoker est posée. Les développeurs d'EIP3074 souhaitent effectuer une preuve formelle du contrat invoker afin d'augmenter la sécurité.
Bien sûr, il y a aussi une partie de la discussion sur le fait que certains contrats utilisent msg.sender == tx.origin pour déterminer si l'adresse d'appel est un EOA. Lorsque l'EIP3074 sera introduit, ces vérifications deviendront obsolètes, mais la conclusion est que l'expiration de ces vérifications ne posera pas de problèmes de sécurité graves. En résumé, cette réunion était principalement une présentation des résultats de l'audit de sécurité du 3074 par le proposeur de l'EIP3074 aux développeurs principaux. La conclusion finale de la réunion est que le 3074 doit encore tenir compte des problèmes de contrat invoker, et il est recommandé de ne pas l'inclure dans le 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 pour "A case for a simpler alternative to EIP 3074", soulignant qu'EIP3074 présente de nombreux problèmes de sécurité. Il a été suggéré de modifier certains éléments, comme la restriction du contenu du champ commit dans la signature, en exigeant que le champ commit soit sous la forme {nonce,to,gas,calldata,value,chainid}. Après avoir utilisé ce modèle de signature, EIP3074 ne peut être utilisé que pour exécuter certaines transactions spécifiques afin de garantir la sécurité des transactions.
L'auteur de l'EIP3074 a répondu aux documents soumis par Yova lors de cette réunion :
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 c'est entièrement une question d'utilisateur et de logiciel 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 réunion :
EIP3074 utilise toujours le schéma de signature traditionnel secp256k1 qui ne peut pas réaliser des caractéristiques de résistance quantique.
EIP3074 n'a pas de compatibilité future, utiliser EIP3074 ne permet pas à un EOA d'évoluer en un compte de contrat intelligent.
Le cycle de vie de l'EIP3074 est limité. L'EIP3074 a introduit deux pré-assemblages, 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, et les pré-assemblages de l'EIP3074 seront abandonnés dans le futur.
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é l'article Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337, dans lequel il n'y avait pas d'opinions opposées à l'EIP3074.
Lors de la réunion #167 du 3 août 2023, les développeurs principaux ont mentionné l'EIP3074 en discutant d'un autre EIP5806. L'EIP5806 est une méthode qui permet aux EOA d'appeler des contrats externes en utilisant deleGate.io call pendant le processus de transaction. Ce schéma est en quelque sorte similaire à l'EIP7702. Cependant, les développeurs principaux ont également exprimé des doutes sur la sécurité de cette proposition, Ansgar a souligné que l'EIP3074 n'a jamais pu être inclus dans un hard fork en raison de problèmes de sécurité potentiels, alors que l'EIP5806 est une proposition 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 de Pectra. Vitalik a proposé que tout standard d'abstraction de compte doive avoir les trois fonctionnalités suivantes :
Rotation de clés
Abandon de clé
Signature résistante aux attaques quantiques compatible
Vitalik a souligné que l'EIP5806 pourrait être un meilleur choix que l'EIP3074. Andrew pense que l'EIP3074 est plus général que l'EIP5806 et suggère d'utiliser l'EIP3074. Vitalik a contredit Andrew, affirmant que dans le futur, tous les portefeuilles pourraient être des portefeuilles de contrats intelligents, et une fois cela réalisé, les opcodes précompilés introduits par l'EIP3074 deviendront obsolètes. Yoav, en tant qu'auteur de l'ERC4337, a fait une intervention assez longue lors de cette réunion, dont le contenu principal comprend :
EIP3074 pourrait entraîner des attaques DoS sur le mempool d'Ethereum, tandis que l'ERC4337 a mené de nombreuses recherches à ce sujet et a proposé certaines règles pour éviter les attaques.
EIP3074 nécessite que l'utilisateur signe deux fois lors de l'initiation de transactions en lot, ce qui n'est pas raisonnable.
EIP3074 exige l'utilisation de relais centralisés
Yova préfère 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 a souligné que dans l'EIP3074, les concepteurs de portefeuilles doivent élaborer une logique d'autorisation stricte pour éviter que la signature EIP3074 des utilisateurs ne soit abusée. Il est intéressant de noter que lors de la discussion sur l'ajout du support de la fonctionnalité EIP3074 dans MetaMask, Vitalik a suggéré d'utiliser L2 comme solution de transition, c'est-à-dire que toute modification de la couche d'exécution nouvelle devrait d'abord être mise en pratique dans L2, car le volume de fonds dans L2 est limité, et même en cas de problème grave, cela entraînerait de lourdes pertes.
Dror Tiros a souligné lors de la discussion que le meilleur moyen d'assurer la sécurité de l'EIP3074 est que la plateforme Ethereum fournisse directement le contrat invoker. Cependant, Dan Finlay s'oppose à l'idée que le contrat soit donné par la plateforme officielle, Dan estime que le contrat invoker devrait être entièrement décidé par les utilisateurs, le marché finira par choisir le contrat invoker le plus sûr.
Ansgar continue de soutenir que l'EIP3074 devrait avoir une seule signature correspondant à une 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 a également exprimé des objections. Dan Finlay estime que l'EIP3074 devrait être signé par un portefeuille froid, puis les fournisseurs de services de portefeuille pourraient réutiliser cette signature pour initier directement des transactions pour les utilisateurs. Si l'on exigeait à chaque fois que l'utilisateur signe à nouveau, cela pourrait entraîner une utilisation répétée de la clé privée froide. Cela va à l'encontre de l'idée de séparation des clés froides et chaudes.
Lors de cette réunion, les développeurs principaux ont discuté d'un autre sujet important : la liste d'inclusion. La liste d'inclusion est un moyen d'augmenter les propriétés de résistance à la censure d'Ethereum. En termes simples, la liste d'inclusion permet à certaines transactions d'être engagées pour être directement incluses dans le prochain bloc. Cependant, les développeurs principaux ont souligné que l'EIP3074 est en conflit avec la liste d'inclusion.
Lors de la réunion #185 du 11 avril 2024, la plupart des implémentations clients internes ont convenu d'intégrer l'EIP3074 dans le hard fork Pectra, mais Geth s'est opposé, arguant que l'EIP3074 pourrait poser des problèmes concernant les arbres Verkle. Danno reste en désaccord, car l'EIP3074 pourrait entraîner des cas de réutilisation de signatures. Yoav s'est également opposé et a proposé un scénario d'attaque sur le pool de mémoire utilisant l'EIP3074 et les transactions Blob. En termes simples, un attaquant pourrait initier un grand nombre de transactions Blob, qui contiennent toutes une grande quantité de données, puis utiliser l'EIP3074 pour rendre toutes ces transactions Blob invalides.
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 n° 187 du 9 mai 2024, les développeurs principaux ont discuté pour la première fois de la question de l'EIP7702 remplaçant l'EIP3074. L'EIP7702 a été finalisé 90 minutes avant le début de la réunion des développeurs principaux par Vitalik. Au cours de la réunion, les développeurs principaux ont reconnu que l'EIP7702 était une norme supérieure à l'EIP3074. Aucun avis opposé à l'EIP7702 n'a été exprimé lors de cette réunion, bien que certains chercheurs aient estimé que l'EIP7702 présentait également des caractéristiques irrévocables similaires à celles de l'EIP3074, ce qui pourrait entraîner des problèmes de sécurité des fonds.
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 abordée avant les 188 réunions des développeurs principaux, et le résultat de cette discussion était que le 3074 serait remplacé, donc il n'y avait pas beaucoup de controverse lors de la réunion des développeurs principaux.
Feuille de route et décision
L'infrastructure de base fondamentale de l'abstraction des comptes, Zerodev, a publié un article intéressant après avoir appris que l'EIP3074 allait être remplacé. Cet article s'intitule "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 de remplacement de l'EIP3074 par l'EIP7702 n'est pas optimal, pour plusieurs raisons :
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.
EIP3074 a reçu une forte opposition de la part de la communauté ERC4337 après avoir été intégré à la mise à niveau Pectra. Bien sûr, comme mentionné ci-dessus, nous avons déjà souligné que le développeur principal d'ERC4337, yova, a exprimé à plusieurs reprises son opposition à 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 ses opinions 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 estime que EIP3074 devrait porter la principale responsabilité en cas d'échec de la gouvernance. Les membres de la communauté ERC4337 considèrent que Yova, en tant que développeur principal d'ERC4337, a exprimé ses objections à EIP3074 lors de plusieurs réunions des développeurs principaux, mais il semble que les développeurs principaux n'ont pas pris en compte ces avis. La plupart des membres de la communauté ERC4337 ne se sont pas intéressés à la dynamique de gouvernance de EIP3074 et beaucoup pensent que EIP3074 est une norme morte. La communauté ERC4337 estime également que les développeurs principaux n'ont pas communiqué activement avec la communauté ERC4337.
EIP3074 et ERC4337 estiment tous deux avoir effectué un bon travail de gouvernance, tandis que l'autre partie devrait être principalement responsable 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, la 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 de compte 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 une présentation de la vision future d'Ethereum par Vitalik personnellement. Si des controverses majeures surviennent au cours du processus de gouvernance d'Ethereum, Vitalik, en tant que définisseur de la feuille de route, détient le pouvoir de décision final. Et c'est justement 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 modèle VVRC en abrégé. Son processus de gouvernance est le suivant :
valeurs, 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 des considérations techniques basées sur la vision pour donner une feuille de route de mise en œuvre plus complète.
clients Implémentation du client, les développeurs principaux du client utilisent des outils tels que les réunions des développeurs principaux pour discuter de la feuille de route et réaliser les besoins contenus dans 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 graves désaccords dans la mise en œuvre du client, l'opinion personnelle de Vitalik sera le jugement final.
Références
Introduction à ZeroDev
null
Introduction à ZeroDev
null
Remarques sur la feuille de route de l'abstraction de compte - HackMD
Remarques sur la feuille de route de l'abstraction de compte *Remerciements spéciaux à Vitalik et à l'équipe AA pour leurs retours
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 d'Ethereum : EIP3074, ERC4337 et EIP7702
Auteur : shew
Aperçu
Dans la mise à niveau de Pectra, un problème de gouvernance très complexe est apparu. Lorsque l'EIP3074 a été intégré dans la mise à niveau de Pectra, cela a provoqué d'énormes débats, en particulier de la part de l'équipe d'ERC4337.
EIP3074 est dans une impasse, le processus de gouvernance ne peut pas continuer. Jusqu'à ce que Vitalik propose EIP7702 qui met fin aux doutes de l'équipe ERC4337 sur EIP3074.
GCC Research a découvert qu'il y a peu de discussions sur les questions de gouvernance concernant EIP3074 et ERC7702 dans le cadre de la mise à niveau de Pectra dans le monde chinois. Cependant, cette question de gouvernance reflète également un problème profond de la gouvernance d'Ethereum, à savoir qui peut contrôler le contenu spécifique du code dans le cadre du principe "le code est la loi". Les questions de gouvernance d'EIP3074 et ERC7702 peuvent nous offrir une excellente perspective pour observer les véritables processus de gouvernance au sein d'Ethereum.
La conclusion finale de cet article est tirée d'un commentaire publié par ZeroDev, qui indique que le système de gouvernance d'Ethereum est un modèle VVRC. Toute proposition doit d'abord être conforme aux valeurs d'Ethereum (Value), puis la proposition doit refléter la vision conçue par Vitalik (Vision), et enfin, la proposition doit être intégrée à la feuille de route (Roadmap). Après discussion par les développeurs principaux, elle sera intégrée à l'implémentation du client (Client).
GCC Research a présenté dans son précédent article que l'EIP2537 a rencontré des problèmes d'implémentation au niveau du client, ce qui a finalement conduit à un retard dans son inclusion dans le hard fork, tandis que l'EIP3074 n'a 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.
Résumé du contenu de la proposition
Avant de présenter les processus de gouvernance spécifiques, nous devons d'abord donner un aperçu des contenus spécifiques liés à EIP3074, EIP7702 et ERC4337.
EIP3074 est une proposition de couche d'exécution qui nécessite une mise à niveau du logiciel des nœuds pour être mise en œuvre. L'objectif principal d'EIP3074 est de permettre le sponsoring de gas et la fonctionnalité de transactions groupées. Ce que l'on appelle le sponsoring de gas signifie que les utilisateurs peuvent payer les frais de gas avec n'importe quel token, ou que les utilisateurs peuvent payer les frais de gas hors ligne. Cependant, il est important de noter qu'en comparaison avec d'autres propositions d'abstraction de compte qui permettent de modifier l'algorithme de vérification de signature, EIP3074 ne permet pas aux utilisateurs d'utiliser d'autres algorithmes de signature que secp256k1. En d'autres termes, EIP3074 n'est pas une proposition qui répond à toutes les fonctionnalités d'abstraction de compte. C'est aussi un point qui a valu à EIP3074 de nombreuses critiques.
Pour atteindre les objectifs visés, EIP3074 introduit deux codes d'opération, à savoir AUTH et AUTHCALL. Le code d'opération AUTH peut valider une signature, et une fois la validation de la signature effectuée, ce code d'opération configurera l'adresse authorized dans le contexte EVM actuel en tant qu'adresse du signataire. Une fois l'adresse authorized configurée dans le contexte, AUTHCALL peut utiliser cette adresse comme msg.sender pour initier une transaction. D'une certaine manière, l'utilisateur peut déléguer son compte à un contrat intelligent pour une transaction en signant. Nous appelons généralement ce contrat intelligent délégué par l'utilisateur un contrat invoker.
Quelle est la 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 est cohérent avec le contrat qui valide réellement la signature, afin d'éviter que le contenu de la signature AUTH de l'utilisateur soit utilisé par d'autres contrats.
Le nonce est un identifiant qui empêche la répétition des transactions. Cependant, il est important de noter que l'opcode AUTH vérifiera si le nonce de la signature correspond à celui de l'EOA actuel. En théorie, tant que l'utilisateur n'utilise pas le compte EOA pour initier une transaction augmentant la valeur du nonce, la signature AUTH émise par l'utilisateur peut être utilisée indéfiniment par le contrat invoker. C'est une énorme faille de sécurité, ce qui signifie que les utilisateurs utilisant 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 pourrait à un moment donné reproduire la signature AUTH de l'utilisateur pour voler les actifs de l'utilisateur.
Un autre problème de sécurité concerne le champ commit. Le champ commit est utilisé pour garantir certaines opérations, permettant à l'utilisateur de contrôler finement ses droits de signature à l'intérieur du commit, par exemple en écrivant certaines informations pour éviter que son contenu de signature soit utilisé pour un transfert ETH. Dans le document EIP3074, le proposeur a fourni une série d'exemples exploitant le champ commit. Cependant, le problème est que la fonction du commit dépend entièrement de la définition du contrat intelligent, ce qui est en fait un contenu optionnel. Différents contrats intelligents peuvent interpréter le contenu du commit de manière totalement incohérente, et il est même possible que certains contrats ne lisent pas du tout le contenu du commit. Si un utilisateur souhaite utiliser EIP3074 de manière sécurisée, il doit examiner simplement le contrat intelligent lui-même.
Enfin, nous présentons l'impact de l'EIP3074 sur le pool de mémoire des transactions Ethereum actuel. Après l'introduction de l'EIP3074, une méthode d'attaque sur le pool de mémoire pourrait émerger, où des hackers pourraient utiliser un grand nombre de comptes pour initier des transactions, puis, lorsque les transactions sont sur le point d'être emballées, utiliser l'EIP3074 pour vider rapidement l'ETH de ces comptes. Cela entraînerait l'échec de toutes les transactions précédemment initiées. Cette méthode d'attaque aurait un impact considérable sur les nœuds de couche d'exécution, c'est essentiellement une attaque de type DoS. Cependant, il est important de noter que l'EIP7702, qui remplace l'EIP3074, présente également ce problème, mais l'EIP7702 a introduit certaines restrictions pour éviter que ce problème ne se produise, que nous discuterons plus loin.
En plus des problèmes liés à l'EIP3074 mentionnés ci-dessus, l'auteur de l'ERC4337, Yova, a présenté d'autres 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 à travers un exemple simple de transaction en masse. Les utilisateurs peuvent utiliser l'EIP7702 pour déléguer leur adresse EOA à un contrat intelligent capable d'exécuter des appels en masse, puis les utilisateurs peuvent directement appeler leur adresse EOA pour initier des transactions en masse 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 l'EIP7702 sont très évidents, dont le principal est que l'EIP7702 permet essentiellement à un EOA de posséder des fonctions de contrat intelligent. Cela est conforme aux règles fondamentales de l'abstraction de compte, comme le stipule l'ERC4337, ce qui signifie que l'EIP7702 peut tirer parti de toutes les explorations actuelles dans le domaine de l'abstraction de compte et réutiliser les infrastructures existantes, par exemple, l'EIP7702 peut directement utiliser l'infrastructure de l'ERC4337. Actuellement, l'ERC4337 a déjà lancé un EntryPoint v0.8 qui prend en charge les appels de l'EIP7702. Du point de vue de la réutilisation de l'infrastructure existante, l'EIP7702 et l'ERC4337 ont un degré de décentralisation équivalent.
Bien sûr, l'EIP7702 n'a en fait pas complètement résolu les problèmes soulevés dans l'EIP3074. La plupart des problèmes présents dans l'EIP3074 persistent. 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é. Au début de l'EIP7702, certains développeurs avaient proposé de normaliser le nonce de signature pour éviter d'éventuelles attaques par rejeu, mais l'EIP7702 n'a finalement pas accepté ces suggestions. Donc, si les utilisateurs souhaitent utiliser l'EIP7702 en toute sécurité, ils doivent examiner eux-mêmes la sécurité des contrats.
En même temps, l'EIP7702 posera également une série de problèmes pour la couche d'exécution. Dans le texte précédent, nous avons présenté une méthode possible d'attaque par déni de service (DoS) sur le pool de mémoire de la couche d'exécution en utilisant l'EIP3074. Cette méthode est également valable pour l'EIP7702. Ainsi, l'EIP7702 recommande que toutes les adresses EOA utilisant l'EIP7702 ne puissent avoir qu'une seule transaction en attente dans le pool de mémoire, afin d'éviter l'apparition d'attaques DoS à grande échelle.
En résumé, le principal problème de l'EIP3074 est qu'il n'a pas mis en œuvre une fonctionnalité complète d'abstraction de compte, tandis que l'EIP7702 a réalisé cette fonctionnalité complète. La définition de ce que comprend "l'abstraction complète de compte" a été fournie par 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 le processus complet de gouvernance et de discussion dans les sections suivantes.
Le processus de gouvernance d'EIP3074 et d'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 affirmé lors de cette conférence qu'Ethereum a besoin d'une solution technique pour 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é possibles, l'EIP3074 fournit une solution technique potentielle sur laquelle les développeurs doivent avancer.
Il est clair qu'en raison des problèmes de sécurité liés à l'EIP3074, cette réunion n'a pas inclus l'EIP3074 dans la mise à niveau de Londres.
Lors de la réunion #115 du 11 juin 2021, les développeurs d'EIP3074 ont soumis un rapport sur l'audit de sécurité, et la réunion a principalement discuté des problèmes de sécurité d'EIP3074. Une conclusion simple est que le contrat invoker d'EIP3074 est très important dans le système, donc la question de savoir s'il faut gérer le contrat invoker est posée. Les développeurs d'EIP3074 souhaitent effectuer une preuve formelle du contrat invoker afin d'augmenter la sécurité.
Bien sûr, il y a aussi une partie de la discussion sur le fait que certains contrats utilisent msg.sender == tx.origin pour déterminer si l'adresse d'appel est un EOA. Lorsque l'EIP3074 sera introduit, ces vérifications deviendront obsolètes, mais la conclusion est que l'expiration de ces vérifications ne posera pas de problèmes de sécurité graves. En résumé, cette réunion était principalement une présentation des résultats de l'audit de sécurité du 3074 par le proposeur de l'EIP3074 aux développeurs principaux. La conclusion finale de la réunion est que le 3074 doit encore tenir compte des problèmes de contrat invoker, et il est recommandé de ne pas l'inclure dans le 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 pour "A case for a simpler alternative to EIP 3074", soulignant qu'EIP3074 présente de nombreux problèmes de sécurité. Il a été suggéré de modifier certains éléments, comme la restriction du contenu du champ commit dans la signature, en exigeant que le champ commit soit sous la forme {nonce,to,gas,calldata,value,chainid}. Après avoir utilisé ce modèle de signature, EIP3074 ne peut être utilisé que pour exécuter certaines transactions spécifiques afin de garantir la sécurité des transactions.
L'auteur de l'EIP3074 a répondu aux documents soumis par Yova lors de cette réunion :
Vitalik a présenté les trois points suivants lors de cette réunion :
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é l'article Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337, dans lequel il n'y avait pas d'opinions opposées à l'EIP3074.
Lors de la réunion #167 du 3 août 2023, les développeurs principaux ont mentionné l'EIP3074 en discutant d'un autre EIP5806. L'EIP5806 est une méthode qui permet aux EOA d'appeler des contrats externes en utilisant deleGate.io call pendant le processus de transaction. Ce schéma est en quelque sorte similaire à l'EIP7702. Cependant, les développeurs principaux ont également exprimé des doutes sur la sécurité de cette proposition, Ansgar a souligné que l'EIP3074 n'a jamais pu être inclus dans un hard fork en raison de problèmes de sécurité potentiels, alors que l'EIP5806 est une proposition 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 de Pectra. Vitalik a proposé que tout standard d'abstraction de compte doive avoir les trois fonctionnalités suivantes :
Vitalik a souligné que l'EIP5806 pourrait être un meilleur choix que l'EIP3074. Andrew pense que l'EIP3074 est plus général que l'EIP5806 et suggère d'utiliser l'EIP3074. Vitalik a contredit Andrew, affirmant que dans le futur, tous les portefeuilles pourraient être des portefeuilles de contrats intelligents, et une fois cela réalisé, les opcodes précompilés introduits par l'EIP3074 deviendront obsolètes. Yoav, en tant qu'auteur de l'ERC4337, a fait une intervention assez longue lors de cette réunion, dont le contenu principal comprend :
Yova préfère 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 a souligné que dans l'EIP3074, les concepteurs de portefeuilles doivent élaborer une logique d'autorisation stricte pour éviter que la signature EIP3074 des utilisateurs ne soit abusée. Il est intéressant de noter que lors de la discussion sur l'ajout du support de la fonctionnalité EIP3074 dans MetaMask, Vitalik a suggéré d'utiliser L2 comme solution de transition, c'est-à-dire que toute modification de la couche d'exécution nouvelle devrait d'abord être mise en pratique dans L2, car le volume de fonds dans L2 est limité, et même en cas de problème grave, cela entraînerait de lourdes pertes.
Dror Tiros a souligné lors de la discussion que le meilleur moyen d'assurer la sécurité de l'EIP3074 est que la plateforme Ethereum fournisse directement le contrat invoker. Cependant, Dan Finlay s'oppose à l'idée que le contrat soit donné par la plateforme officielle, Dan estime que le contrat invoker devrait être entièrement décidé par les utilisateurs, le marché finira par choisir le contrat invoker le plus sûr.
Ansgar continue de soutenir que l'EIP3074 devrait avoir une seule signature correspondant à une 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 a également exprimé des objections. Dan Finlay estime que l'EIP3074 devrait être signé par un portefeuille froid, puis les fournisseurs de services de portefeuille pourraient réutiliser cette signature pour initier directement des transactions pour les utilisateurs. Si l'on exigeait à chaque fois que l'utilisateur signe à nouveau, cela pourrait entraîner une utilisation répétée de la clé privée froide. Cela va à l'encontre de l'idée de séparation des clés froides et chaudes.
Lors de cette réunion, les développeurs principaux ont discuté d'un autre sujet important : la liste d'inclusion. La liste d'inclusion est un moyen d'augmenter les propriétés de résistance à la censure d'Ethereum. En termes simples, la liste d'inclusion permet à certaines transactions d'être engagées pour être directement incluses dans le prochain bloc. Cependant, les développeurs principaux ont souligné que l'EIP3074 est en conflit avec la liste d'inclusion.
Lors de la réunion #185 du 11 avril 2024, la plupart des implémentations clients internes ont convenu d'intégrer l'EIP3074 dans le hard fork Pectra, mais Geth s'est opposé, arguant que l'EIP3074 pourrait poser des problèmes concernant les arbres Verkle. Danno reste en désaccord, car l'EIP3074 pourrait entraîner des cas de réutilisation de signatures. Yoav s'est également opposé et a proposé un scénario d'attaque sur le pool de mémoire utilisant l'EIP3074 et les transactions Blob. En termes simples, un attaquant pourrait initier un grand nombre de transactions Blob, qui contiennent toutes une grande quantité de données, puis utiliser l'EIP3074 pour rendre toutes ces transactions Blob invalides.
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 n° 187 du 9 mai 2024, les développeurs principaux ont discuté pour la première fois de la question de l'EIP7702 remplaçant l'EIP3074. L'EIP7702 a été finalisé 90 minutes avant le début de la réunion des développeurs principaux par Vitalik. Au cours de la réunion, les développeurs principaux ont reconnu que l'EIP7702 était une norme supérieure à l'EIP3074. Aucun avis opposé à l'EIP7702 n'a été exprimé lors de cette réunion, bien que certains chercheurs aient estimé que l'EIP7702 présentait également des caractéristiques irrévocables similaires à celles de l'EIP3074, ce qui pourrait entraîner des problèmes de sécurité des fonds.
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 abordée avant les 188 réunions des développeurs principaux, et le résultat de cette discussion était que le 3074 serait remplacé, donc il n'y avait pas beaucoup de controverse lors de la réunion des développeurs principaux.
Feuille de route et décision
L'infrastructure de base fondamentale de l'abstraction des comptes, Zerodev, a publié un article intéressant après avoir appris que l'EIP3074 allait être remplacé. Cet article s'intitule "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 de remplacement de l'EIP3074 par l'EIP7702 n'est pas optimal, pour plusieurs raisons :
Zerodev pense que le meilleur chemin de gouvernance devrait être que la communauté ERC4337 participe largement et exprime ses opinions 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 estime que EIP3074 devrait porter la principale responsabilité en cas d'échec de la gouvernance. Les membres de la communauté ERC4337 considèrent que Yova, en tant que développeur principal d'ERC4337, a exprimé ses objections à EIP3074 lors de plusieurs réunions des développeurs principaux, mais il semble que les développeurs principaux n'ont pas pris en compte ces avis. La plupart des membres de la communauté ERC4337 ne se sont pas intéressés à la dynamique de gouvernance de EIP3074 et beaucoup pensent que EIP3074 est une norme morte. La communauté ERC4337 estime également que les développeurs principaux n'ont pas communiqué activement avec la communauté ERC4337.
EIP3074 et ERC4337 estiment tous deux avoir effectué un bon travail de gouvernance, tandis que l'autre partie devrait être principalement responsable 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, la 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 de compte 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 une présentation de la vision future d'Ethereum par Vitalik personnellement. Si des controverses majeures surviennent au cours du processus de gouvernance d'Ethereum, Vitalik, en tant que définisseur de la feuille de route, détient le pouvoir de décision final. Et c'est justement 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 modèle VVRC en abrégé. Son 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 graves désaccords dans la mise en œuvre du client, l'opinion personnelle de Vitalik sera le jugement final.