Chaque compte Ethereum met en œuvre cinq fonctionnalités :
Une EOA les met en œuvre d'une manière codée en dur :
L'abstraction de compte consiste à ajouter une logique programmatique à ces cinq fonctionnalités :
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.
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 :
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 :
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.
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 ?
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.
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.
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 :
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.
Chaque compte Ethereum met en œuvre cinq fonctionnalités :
Une EOA les met en œuvre d'une manière codée en dur :
L'abstraction de compte consiste à ajouter une logique programmatique à ces cinq fonctionnalités :
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.
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 :
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 :
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.
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 ?
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.
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.
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 :
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.