L’inventaire EIP à l’origine de l’abstraction du compte

Par Vasa, co-fondateur d’OpenSea Pro ; Traduction : Golden Finance Xiaozou

Dans cet article, nous allons jeter un coup d’œil rapide aux différents EIP qui nous ont amenés aux abstractions de compte d’aujourd’hui.

! [IBi1wWpT0680RWZaqv5DB56VCs7bGvDrkaHl3Wky.png] (https://img.jinse.cn/7122936_watermarknone.png « 7122936 »)

**1. Pourquoi avons-nous besoin de l’abstraction de compte (AA) ? **

Les gens aiment poser des questions telles que : « Comment pouvons-nous amener le prochain milliard d’utilisateurs au Web3 ? » « Il y a de nombreux obstacles à surmonter, mais le plus important d’entre eux est l’expérience utilisateur.

Le diagramme suivant est une expérience utilisateur typique pour un nouvel utilisateur. Notez également que si vous perdez votre phrase de récupération, il n’y a aucun moyen de récupérer vos propres fonds. C’est un énorme obstacle pour les nouveaux utilisateurs.

! [vvFxw94g95EIvo2NuFwxQX9g5mTtJo2EvxwLJO2y.png] (https://img.jinse.cn/7122937_watermarknone.png « 7122937 »)

Voici ce que nous pouvons faire pour améliorer l’expérience utilisateur. Nous pouvons :

• Créez des portefeuilles sans phrases mnémotechniques.

• Utilisez un portefeuille qui ne nécessite pas de stocker de l’ETH et de payer des frais de gaz avec de l’ETH.

• Utilisez Social Recovery pour récupérer votre portefeuille.

• Opérations en masse en une seule transaction.

! [dE8KCPMN0cVxJwYU2lm5yt5B9g3GLhSxilFQWvfW.png] (https://img.jinse.cn/7122938_watermarknone.png « 7122938 »)

2、Type de résumé de compte

Il existe deux types de comptes : les comptes externes (EOA) et les comptes contractuels. EOA est contrôlé par la clé privée et le compte de contrat est contrôlé par le code de contrat.

! [64lX5U5G6sNJZBjPvNiC827QJil9Zi8BpTNMeQ8Y.png] (https://img.jinse.cn/7122939_watermarknone.png « 7122939 »)

Les EOA peuvent initier des transactions vers d’autres EOA ou comptes de contrat, qui peuvent ensuite exécuter leur code. Les comptes de contrat peuvent également envoyer des transactions à d’autres comptes de contrat, qui peuvent exécuter leur propre code.

3. Les débuts d’Ethereum : exécution et vérification des transactions**

Lorsqu’une transaction est envoyée au réseau, elle passe par deux étapes : la vérification et l’exécution. Alors que l’exécution de la logique de transaction peut être arbitraire, la partie validation est fixe.

La partie vérification est effectuée par un seul algorithme fixe que l’EOA doit utiliser, c’est-à-dire la vérification de la signature ECDSA. Mais pourquoi utilisons-nous une méthode fixe pour vérifier la validité des transactions ? Que se passera-t-il si la vérification de la signature ECDSA n’est plus fiable à l’avenir en raison de l’informatique quantique ?

Si nous laissons la partie validation ouverte, alors vous pouvez créer une transaction avec un algorithme de validation très complexe, alors le mineur/validateur devra dépenser beaucoup de ressources pour vérifier si la transaction peut être incluse dans le bloc.

Maintenant, notez que les mineurs ne sont payés que pour l’exécution et l’inclusion de transactions, pas pour la vérification. Ainsi, si, après avoir dépensé beaucoup de ressources, les mineurs constatent qu’ils ne peuvent pas ajouter de transactions, ils gaspillent des ressources et ne sont rien payés pour cela. Par conséquent, cela peut être utilisé pour mener des attaques DDoS sur le réseau. C’est pourquoi Ethereum a commencé avec un algorithme de vérification fixe.

4. Les débuts d’Ethereum : le problème de l’adoption du multisig**

Un portefeuille multisig est un contrat avec un grand nombre de propriétaires avec des seuils. Si vous souhaitez envoyer une transaction, vous devez obtenir les signatures de tous les propriétaires avant de pouvoir envoyer la transaction.

Cela prend en charge des fonctionnalités telles que la récupération sociale, où vous pouvez avoir de nombreux amis pour vous aider à récupérer votre portefeuille si vous perdez vos clés privées. Dès les premiers jours d’Ethereum, la valeur que les portefeuilles multisig peuvent apporter est évidente. Par conséquent, l’équipe de développement d’Ethereum à l’époque souhaitait que les utilisateurs d’Ethereum utilisent des portefeuilles multisig. Cependant, cela ne s’est pas produit.

Étant donné que l’équipe de développement d’Ethereum envisageait que les utilisateurs utilisent des portefeuilles multisig, elle n’a pas ajouté de journal automatique pour les transferts d’ETH, car elle s’attendait à ce que le portefeuille multisig enregistre chaque transfert d’ETH. À l’époque, les plateformes d’échange devaient analyser les transactions de transfert d’ETH, et non les enregistrer.

Lorsque quelqu’un essaie d’utiliser un portefeuille multisig avec des journaux de transfert d’ETH, l’échange est méconnaissable car l’échange n’analyse pas les journaux. Par conséquent, cette petite hypothèse rend finalement l’adoption des portefeuilles multisig plus difficile.

EIP 86 et 1014 : Première étape de l’abstraction de compte**

L’EIP-86 vise à introduire le concept de portefeuille de contrats intelligents appelé « contrats de transfert ». Ces contrats sont conçus pour ne recevoir que des transactions provenant d’adresses de « point d’entrée », qui doivent respecter un format spécifique.

Maintenant, pour créer un portefeuille de contrats intelligents, vous devez avoir des ETH au préalable pour payer les frais de gaz. Vous pouvez aller sur CEX et obtenir de l’ETH, mais comme votre portefeuille de contrats intelligents n’a pas encore été créé, vous ne pouvez pas encore envoyer d’ETH au portefeuille.

Si nous pouvons d’une manière ou d’une autre connaître exactement l’adresse du contrat avant que le contrat intelligent ne soit créé, nous pouvons envoyer de l’ETH à cette adresse, puis créer un portefeuille de contrat intelligent en utilisant l’ETH sur l’adresse.

C’est ce que l’EIP-1014 introduit. Il introduit CREATE2 opcodes qui vous permettent de déterminer l’adresse du contrat avant de créer un contrat intelligent. C’est le premier pas vers l’abstraction des comptes.

L’EIP-86 original nécessitait des modifications importantes du protocole, car les modifications apportées au protocole nécessitaient une collaboration entre les équipes de développement de nœuds et nécessitaient un examen approfondi, de sorte qu’il n’a jamais été mis en œuvre. EIP-1014 a été implémenté dans le hard fork de Constantinople.

Développement communautaire : Gnosis Safe, Argent Wallet, Réseau de stations-service**

En discutant de l’étude de l’EIP, la communauté a déjà entrepris de développer ses propres solutions.

Le plus notable d’entre eux a été la sortie de Gnosis Safe en 2018. Safe est un portefeuille de contrats intelligents qui permet aux utilisateurs de créer des portefeuilles multisig et permet également aux utilisateurs de regrouper plusieurs opérations en une seule transaction. Il permet également aux utilisateurs de payer les frais de gaz en utilisant des jetons ERC20.

Une autre note notable est la sortie du portefeuille Argent en 2019. Argent Smart Wallet permet aux utilisateurs de créer des portefeuilles multisig et de payer les frais de gaz en utilisant des jetons ERC20. Il permet également aux utilisateurs d’utiliser la récupération sociale pour récupérer leurs portefeuilles.

Le réseau de stations-service (GSN), lancé en 2019, est un réseau décentralisé qui permet aux utilisateurs de payer les frais de gaz en utilisant des jetons ERC20. GSN peut être utilisé avec n’importe quel portefeuille de contrats intelligents.

EIP 2938 – Un pas de géant

À partir de 2018, l’équipe Ethereum s’est penchée sur la migration vers le PoS (proof-of-stake), ce qui a conduit par inadvertance à moins mettre l’accent sur l’évaluation et la mise en œuvre de l’EIP par les équipes de recherche et les équipes de développement de nœuds.

Ce changement a ouvert la voie à l’EIP-2938 en 2020, deux ans après la mise en œuvre de l’EIP-1014.

L’idée centrale derrière la proposition est l’introduction de portefeuilles de contrats intelligents, qui sont conçus pour recevoir spécifiquement des types spécifiques de transactions, qui peuvent être programmés pour déterminer le plafond de gaz des transactions et développer des méthodes de vérification arbitraires.

La proposition introduit deux nouveaux opcodes pour gérer les transactions, et comme nous l’avons souligné précédemment, l’inclusion de ces mises à jour de base est un processus complexe.

En outre, des questions restent ouvertes sur la manière dont la protection contre le rejeu est mise en œuvre et sur la manière dont les nœuds peuvent vérifier la validité de ces nouveaux types de transactions. Bien que la proposition n’ait pas attiré beaucoup d’attention, elle a ouvert la voie à la proposition suivante (EIP-3074).

EIP-3074 – Solution très polyvalente**

La proposition introduit deux nouveaux opcodes : AUTH et AUTHCALL. La différence avec cette proposition est qu’elle permet aux comptes externes de déléguer le contrôle des contrats. Ces opcodes sont spécifiés pour les contrats « invoker », qui ont le potentiel d’améliorer considérablement la fonctionnalité de n’importe quel EOA.

Le contrat initie une structure de transaction totalement arbitraire, ce qui facilite la mise en œuvre de solutions telles que les achats multi-signatures, les achats par lots et l’aide, la récupération des clés et les dépôts CeFi plus conviviaux. En raison de sa nature ouverte, la proposition est apparue comme une solution très polyvalente capable de répondre à un large éventail de cas d’utilisation.

D’autre part, la position neutre de la proposition pose également des problèmes de sécurité. Une discussion plus approfondie suggère une approche AUTHCALL plus opiniâtre pour atténuer les risques associés. Cette discussion a conduit les chercheurs à arriver à une solution plus optimisée, ce qui a donné naissance à l’EIP-4337.

EIP-4337 – Abstraction du compte Ethereum sans modification du protocole de la couche de consensus**

! [HQ5SxXOpxJLs0tzXo1IgTdGxAe5XHPNAIJiDKUMM.png] (https://img.jinse.cn/7122940_watermarknone.png « 7122940 »)

EIP-4337 propose un mécanisme permettant d’introduire l’abstraction de compte dans Ethereum sans modifier le protocole de la couche de consensus. Dans le cadre de cet EIP, les utilisateurs interagissent différemment avec le réseau Ethereum ; Au lieu d’envoyer des transactions, l’utilisateur envoie l’objet UserOperation à un pool de mémoire distinct. L’expéditeur est le contrat de compte qui initie l’action de l’utilisateur. Le bundler collecte ces opérations et les empaquette dans une transaction qui déclenche un appel handleOps sur le contrat EntryPoint spécifié pour effectuer l’opération empaquetée. Paymaster est l’entité qui parraine la transaction, et ses détails sont inclus dans UserOperation pour le traitement des frais.

L’agrégateur vérifie les signatures agrégées, ce qui améliore la sécurité et l’efficacité. Le bundler ou la liste blanche de clients prend en charge les points d’entrée et les contrats d’agrégation, contrôle les interactions et assure la bonne exécution des actions des utilisateurs sur le réseau Ethereum, conformément aux objectifs de l’abstraction du compte sans modifier la couche de consensus.

Les portefeuilles de contrats intelligents déployés dans le cadre de ce processus gèrent de manière autonome les valeurs aléatoires et la vérification des signatures, offrant ainsi une grande flexibilité. Cette conception permet de créer des portefeuilles de contrats intelligents capables de gérer les transactions multisig et packagées, la récupération sociale et même de payer des frais à l’aide de jetons ERC20.

Une certaine forme d’abstraction de compte comme celle proposée dans l’EIP-4337 pourrait être mise en œuvre dans l’avenir à moyen terme d’Ethereum, apparaissant initialement dans de nouvelles solutions L2 et entrant éventuellement dans Ethereum L1, élargissant ainsi la portée de l’interaction des utilisateurs avec Ethereum.

10、L2 - Nouvelle frontière

Les mises à jour du protocole de base constituent un obstacle important lors de l’introduction d’une EIP liée à l’abstraction de compte. Les développeurs principaux ont été occupés par la feuille de route de l’ETH 2.0, qui est une priorité absolue depuis longtemps.

Mais qu’en est-il de la L2 ? Contrairement à Ethereum L1, qui comporte une dette technique, les chaînes L2 récentes ont une architecture qui intègre les abstractions de compte dès le départ.

Par exemple, StarkNet est un cumul ZK qui crée une abstraction de compte unique. En outre, Argent, connu pour son portefeuille de contrats intelligents L1, a lancé ArgentX sur StarkNet, intégrant une implémentation d’abstraction de compte personnalisée qui a été fortement influencée par EIP-4337. Ces initiatives soulignent l’importance et l’applicabilité de l’abstraction de compte sur la blockchain Ethereum.