ERC-4337 vs EIP-3074 : Fausse dichotomie

Qu'est-ce que l'abstraction de compte ?

Chaque compte Ethereum met en œuvre cinq fonctionnalités :

• Authentification
• Autorisation
• Protection contre la rediffusion
• Paiement du gaz
• Exécution

Une EOA les met en œuvre d'une manière codée en dur :

• L'authentification et l'autorisation sont regroupées : une clé ECDSA immuable prouve l'identité et confère une autorité totale.
• La protection contre les rediffusions est un simple nonce - un compteur qui augmente de façon monotone.
• Le paiement du gaz est effectué directement à partir du solde d'ETH de l'EOA.
• Exécution - un seul appel vers une seule destination.

L'abstraction de compte consiste à ajouter une logique programmatique à ces cinq fonctionnalités :

• Authentification - toute forme de preuve de l'identité d'une personne.
• Autorisation - toute politique d'accès.
• Protection contre les rediffusions - l'ordre des transactions est découplé de la protection contre les rediffusions.
• Paiement du gaz - paiement du gaz découplé du compte lui-même.
• Exécution - toute logique d'exécution.

Exemples de cas d'utilisation de l'abstraction des comptes

• Différents systèmes de signature
  • secp256r1 (secure enclave, passkeys)
  • Schnorr
  • BLS
  • Post-quantique
  • Les preuves ZK (par exemple zkemail)
• Rotation des touches
  • Remplacer les clés compromises
  • L'interrupteur de l'homme mort pour l'héritage (la clé devient active si le compte est inactif pendant un an)
• Différentes politiques d'accès
  • Multisig
  • Accès basé sur les rôles
  • clés de session spécifiques à la dapp
  • Récupération sociale
• Différents systèmes de protection contre la relecture
  • Transactions parallèles de différentes entités
  • Transactions futures pré-signées à envoyer par des tiers
  • Canal administratif
• Extraction de gaz
  • Parrainage du gaz par des tiers
  • Paiement avec des actifs autres que l'ETH
  • Vie privée : demandes anonymes de largage ou retrait des rollups ou mixers ZK
• Abstraction d'exécution
  • Mise en lot de plusieurs appels vers plusieurs destinations (par ex. approuver+transferFrom)
  • Atomicité
  • Améliorations de l'interface utilisateur spécifiques aux dapps

ERC-4337 vs EIP-3074 : Fausse dichotomie

L'EIP-3074 vise à abstraire l'exécution en surchargeant l'EOA avec une logique d'exécution arbitraire par le biais d'invocateurs. Il possède une propriété unique, celle d'étendre les capacités d'un EOA sans avoir à migrer les actifs vers un nouveau compte. Il n'est pas nécessaire d'aborder des questions telles que l'accès décentralisé, car l'exécution n'a pas d'incidence sur ce point. Les quatre autres fonctionnalités existent, mais elles ne relèvent pas du champ d'application de l'EIP-3074.

L'ERC-4337 vise à abstraire l'ensemble du compte - les cinq fonctionnalités. C'est un problème plus difficile à résoudre si l'on veut préserver la décentralisation et la résistance à la censure. L'objectif de l'ERC-4337 est d'atténuer les vecteurs d'attaque DoS et griefing en faisant abstraction des quatre premières fonctionnalités sans recourir à une infrastructure centralisée. En tant qu'ERC, il ne peut pas étendre les capacités d'un EOA et nécessite une migration vers un compte intelligent.

Le chevauchement entre les deux méthodes est minime : seule l'abstraction de l'exécution.

En outre, chaque méthode vise à résoudre des problèmes que l'autre ne résout pas : EIP-3074 vise à servir les EOA existants et à garder les choses aussi simples que possible. L'ERC-4337 vise à fournir une abstraction complète des comptes sans sacrifier les propriétés essentielles d'Ethereum, telles que la décentralisation.

Si l'on insiste pour comparer l'ERC-4337 à une proposition antérieure, la proposition la plus proche est l'EIP-2938, et non l'EIP-3074. L'EIP-2938 a constitué une percée dans l'abstraction des comptes, la première proposition à prendre en compte la difficulté de l'atténuation des dénis de service dans un pool de mémoire AA. L'ERC-4337 résout certains problèmes que l'EIP-2938 n'a pas résolus, mais une comparaison complète n'entre pas dans le cadre de ce document.

Que peuvent résoudre à la fois l'ERC-4337 et l'EIP-3074 ?

Tous deux résolvent le problème de l'abstraction d'exécution et permettent donc de répondre à la dernière catégorie des cas d'utilisation ci-dessus :

• Appels groupés vers plusieurs destinations
• Atomicité
• Améliorations de l'interface utilisateur spécifiques aux dapps

Que peut faire l'EIP-3074 que l'ERC-4337 ne peut pas faire ?

• Ajouter des fonctionnalités d'exécution complexes aux EOA existants.
  • L'ERC-4337 ne peut pas ajouter de fonctionnalité aux EOA parce qu'il s'agit d'un ERC.
• Simplicité et meilleure efficacité du gaz lorsque seule l'abstraction d'exécution est nécessaire.
  • L'abstraction complète du compte ajoute une complexité qui n'est pas nécessaire pour l'abstraction de l'exécution.

Que peut faire l'ERC-4337 que l'EIP-3074 ne peut pas faire ?

• Soutenez toute chaîne EVM dès le premier jour. Pas de changement dans le consensus.
  • La norme EIP-3074 devrait être adoptée par chaque chaîne par le biais d'une modification consensuelle.
• L'innovation sans permission
  • Les portefeuilles n'autoriseront que les invokers EIP-3074 figurant sur la liste blanche. Les comptes ERC-4337 peuvent être créés et utilisés par n'importe qui.
• Abstraction totale du compte - tous les cas d'utilisation ci-dessus, sans sacrifier la décentralisation :
  • Différents systèmes de signature.
    • L'EIP-3074 utilise l'ECDSA. L'EIP mentionne une voie future pour passer à un schéma différent, mais tant que l'EOA lui-même honore la clé ECDSA, un invocateur ne peut pas l'empêcher d'être utilisé directement.
  • Rotation clé.
    • Avec l'EIP-3074, l'EOA dispose toujours d'une clé irrévocable.
  • Différentes politiques d'accès
    • La clé ECDSA peut contourner l'invocateur et effectuer n'importe quelle opération sur le compte. Pas de contrôle d'accès granulaire.
  • Différents systèmes de protection contre la relecture
    • Le compte est toujours un EOA et utilise un nonce unidimensionnel.
  • Extraction de gaz
    • Le compte paie son propre gaz, avec l'ETH.
    • Un système d'abstraction de gaz pourrait être construit sur la base de l'EIP-3074, en utilisant un relais pour envoyer des méta-transactions au nom du compte. Cependant, la protection de ces relais contre les dénis de service et le griefing est un défi, c'est pourquoi ils deviendront probablement soumis à autorisation. La complexité de l'ERC-4337 est due en grande partie au fait que ces relais (bundlers) n'ont pas d'autorisation.

EIP-3074 + EIP-5003 peuvent-ils faire ce que fait ERC-4337 ?

L'EIP-5003 complète l'EIP-3074 en permettant à l'EOA de révoquer sa clé ECDSA et de devenir un contrat intelligent. En tant que contrat, il peut abstraire le reste des fonctionnalités du compte, par exemple remplacer l'ECDSA par une signature différente, faire tourner les clés, appliquer des politiques d'accès, etc. En ce sens, il est quelque peu équivalent aux propositions telles que EIP-6913 et EIP-7377, mais il est supérieur à EIP-7377 car, en tant qu'opcode, il peut utiliser un système d'abstraction de gaz pour la migration elle-même.

Une fois que l'EOA est converti en contrat intelligent, il ne peut plus effectuer de transactions directement et doit être accessible par l'intermédiaire d'un autre EOA. C'est là le défi que l'ERC-4337 est censé relever. L'utilisateur dispose de deux moyens pour effectuer des transactions avec le compte après la migration :

1. Maintenez un autre EOA approvisionné pour effectuer des transactions sur le compte, et signez chaque transaction deux fois. Cela annule la valeur de l'abstraction des comptes et entraîne une mauvaise interface utilisateur.
2. Utilisez un relais qui maintient un EOA financé, met les transactions en chaîne et se fait rembourser par le compte. Il est plus difficile qu'il n'y paraît de protéger un tel relais contre les attaques par déni de service et le "griefing", c'est pourquoi certains projets utilisent un relais soumis à autorisation. Il en résulte une perte de décentralisation et une résistance à la censure.

La façon de décentraliser l'accès aux comptes après la migration est d'appliquer certaines restrictions jusqu'à ce que le compte paie le gaz. Cette approche a été adoptée par les programmes EIP-2938 et ERC-4337. Le site <a href="https://notes.ethereum.org/@yoav/unified-erc-4337-mempool"> ERC-4337 mempool offre un moyen décentralisé d'effectuer des transactions avec le compte.

TL;DR : Non, cela ne fait que souligner la nécessité de l'ERC-4337.

Mise en garde : la migration des EOA est considérée comme nuisible

Il est tentant pour les utilisateurs actuels de l'EOA de migrer vers un compte intelligent au lieu de transférer des actifs. Cependant, elle s'accompagne de certaines vulnérabilités, dont certaines ne peuvent être atténuées.

Que se passe-t-il si la clé EOA est compromise après avoir été révoquée ?

1. La clé reste valable pour les autres chaînes (y compris les chaînes futures qui n'existent même pas au moment de la migration). Il peut être utilisé pour revendiquer le même compte sur d'autres chaînes et transférer tous les actifs envoyés sur le compte sur ces chaînes.
2. Les systèmes hors chaîne, tels que le processus de connexion des frontends dapp, vérifient les signatures. Beaucoup d'entre eux prennent en charge l'EIP-1271 pour les signatures de contrats intelligents, mais ne l'essaient que si ecrecover échoue. La clé pourrait être utilisée pour compromettre le compte sur ces systèmes.
3. Il peut être utilisé sur la chaîne (sur la chaîne où il a été révoqué) pour signer des autorisations de permis. Si le compte contient des jetons ERC-20 qui prennent en charge le permis, ces jetons peuvent être volés à l'aide de la clé révoquée.
4. Les ponts inter-chaînes vérifient souvent la signature lors du retrait. Si le compte envoie des fonds à une autre chaîne par le biais d'un tel pont, la clé révoquée peut être utilisée pour retirer les fonds de l'autre côté.

L'utilisateur pourrait brûler la clé privée après la migration en espérant qu'il n'en reste aucune copie, mais il ne pourrait pas non plus revendiquer la même adresse sur d'autres chaînes.

La migration ne doit donc être utilisée qu'en dernier recours, lorsqu'il y a de bonnes raisons de conserver l'ancienne adresse. Par défaut, il est préférable de déployer les nouveaux comptes avec CREATE2 plutôt que de les migrer à partir d'une EOA, afin qu'ils ne soient pas liés à une clé EOA sur d'autres chaînes.

La communauté a tendance à surestimer l'importance de la migration des EOA parce que la plupart des utilisateurs actuels ont des EOA. Le prochain milliard d'utilisateurs pourrait commencer avec un compte intelligent et ne pas avoir à migrer à partir d'un EOA. Nous, les utilisateurs actuels de l'EOA, n'en représentons qu'une infime partie. La migration peut être importante pendant un certain temps, pour que les utilisateurs actuels puissent migrer. Il deviendra un flux rarement utilisé lorsque l'abstraction des comptes sera la norme.

Existe-t-il une synergie entre l'ERC-4337 et l'EIP-3074 ?

Oui, ils pourraient être <a href="https://notes.ethereum.org/@yoav/eip-3074-erc-4337-synergy"> combinés de manière intéressante. Si une chaîne adopte l'EIP-3074, les projets qui utilisent l'ERC-4337 pourraient l'utiliser à leur avantage.

RIP-7560 : Une voie prometteuse pour l'avenir de l'abstraction des comptes

L'EIP-3074 et l'ERC-4337 sont des étapes qui permettent d'obtenir certains des avantages de l'abstraction complète des comptes natifs. La première vise à obtenir tous les avantages de l'abstraction d'exécution et la seconde vise à obtenir tous les avantages de l'abstraction de compte sur toutes les chaînes EVM, mais d'une manière non native qui est moins efficace.

Une chaîne qui souhaite que ses utilisateurs bénéficient d'une abstraction native complète des comptes pourrait adopter RIP-7560. Il utilise la même architecture de compte et de pool de mémoire que l'ERC-4337, mais fonctionne de manière native au niveau du protocole.

Il n'est pas nécessaire d'adopter RIP-7560 dès le premier jour, et les comptes existants pourront migrer vers ce système sur les chaînes qui choisissent de l'adopter à tout moment dans le futur :

• Les comptes ERC-4337 pourront migrer vers le RIP-7560 sans modifier leur architecture, en changeant leur implémentation pour faire confiance à l'adresse spéciale EntryPoint définie dans le RIP-7560. Un compte peut être compatible à la fois avec l'ERC-4337 et le RIP-7560 avec peu d'efforts, de sorte qu'aucune migration n'est nécessaire.
• L'EOA pourrait être en mesure de migrer directement vers RIP-7560 sans passer par ERC-4337 ou EIP-3074. RIP-7560 prend déjà en charge l'abstraction de gaz pour les EOA. Un futur RIP pourrait permettre à l'EOA de fixer son code, soit en utilisant un opcode comme SETCODE (EIP-6913) ou AUTHUSURP (EIP-5003), soit en ajoutant un sous-type TransactionType4 similaire à l'EIP-7377. Cet opcode/sous-type peut être utilisé par un contrat de migration appelé dans une transaction de type 4 (RIP-7560). Cependant, la migration des EOA est <a href="https://notes.ethereum.org/@yoav/erc-4337-vs-eip-3074-false-dichotomy#Caveat:-EOA-migration-considérée-nuisible"> découragée.

RIP-7560 a besoin de votre avis

Nous recueillons des commentaires sur le RIP-7560 avant de proposer de l'inscrire dans la loi. Si vous êtes intéressé par l'abstraction native des comptes, veuillez consulter le PR ou rejoindre la discussion.

Clause de non-responsabilité：

1. Cet article est reproduit de [<a href="https://notes.ethereum.org/@ yoav/erc-4337-vs-eip-3074-false-dichotomy"" > @yoav]. Tous les droits d'auteur appartiennent à l'auteur original[@yoav]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.