Ethereum dispose de deux types de comptes : les comptes détenus en externe (EOA) et les comptes contractuels (CA). Les EOA sont contrôlés par une clé privée, tandis que les autorités de certification sont contrôlées par le code de contrat intelligent qu’elles contiennent. Les OEA ont toujours été plus privilégiés que les AC, car seuls les EOA peuvent commencer l’exécution des transactions en payant du gaz. L’abstraction de compte (AA) est une proposition qui permet à un contrat d’être un compte de « premier niveau », comme un EOA, qui peut payer des frais et commencer l’exécution d’une transaction.

La motivation pour AA est d'améliorer significativement l'expérience utilisateur dans la façon dont les utilisateurs interagissent avec la blockchain Ethereum aujourd'hui dans divers scénarios tels que les portefeuilles, les mixeurs, les ÐApps et la DeFi. AA fournit une fonctionnalité de couche de base dans Ethereum pour décider quand on peut payer pour le gaz, ce qui a également des implications sur qui paie pour le gaz et comment ils le paient.

L'application Status Messenger regroupe un messager axé sur la confidentialité avec un portefeuille Ethereum et un navigateur Web3 ÐApp. Le portefeuille Status est actuellement un portefeuille EOA qui nous limite dans l'offre d'une UX riche que seul un portefeuille de contrat intelligent peut offrir, telles que la sécurité multi-signature, la récupération sociale, la limitation du taux, l'autorisation/interdiction de listes d'adresses et les méta-transactions sans gaz. Cependant, l'UX des portefeuilles de contrats intelligents est actuellement sévèrement entravée par la fluctuation des prix du gaz, ce qui n'est pas efficacement résolu par des relais tiers. AA vise à résoudre ce problème.

Dans cet article, nous motivons la nécessité de l'Abstraction de Compte dans le contexte des portefeuilles de contrats intelligents. Nous plongeons ensuite en profondeur dans les aspects clés de l'AA en décrivant les changements de protocole et l'impact sur les nœuds. Enfin, nous discutons de certaines des extensions proposées et concluons en rationalisant la feuille de route prévue pour les projets Status qui interagissent avec Ethereum et pourraient donc être impactés par l'AA.

Histoire & Motivation

L'abstraction de compte a été initialement proposée comme EIP-86en 2017 pour mettre en œuvre la « Abstraction de l'origine et de la signature de la transaction », mais les origines de l'idée motivante remontent même plus loin à début 2016, où il a été suggéré que : « Au lieu d'avoir un mécanisme en protocole où ECDSA et le schéma de nonce par défaut sont consacrés comme la seule façon « standard » de sécuriser un compte, nous faisons des premiers pas vers un modèle où à long terme tous les comptes sont des contrats, les contrats peuvent payer pour le gaz, et les utilisateurs sont libres de définir leur propre modèle de sécurité.

Les propositions initiales ont été considérées comme difficiles à mettre en œuvre en raison des nombreux changements de protocole nécessaires et des garanties de sécurité à respecter. Plus récemment, Vitalik et al. ont proposé un projet de EIP-2938qui définit une implémentation beaucoup plus simple en maintenant les changements de protocole/consensus minimaux et en imposant les garanties de sécurité requises via les règles de la mempool du nœud. Vitalik’sPrésentation du Meetup du groupe d'ingénierie EthereumetPrésentation ETHOnline(avec les articles accompagnants @SamWilsn/ryhxoGp4D">1 & @SamWilsn/S1UQDOzBv">2) par Sam Wilson & Ansgar Dietrichs (deux des autres auteurs de l'EIP) offrent de grandes introductions au sujet. Cet article met en évidence les aspects clés de toutes ces sources.

Motivation: La raison motivante derrière AA est très simple mais fondamentale: les transactions Ethereum aujourd'hui ont des effets programmables (réalisés via des appels à des contrats intelligents) mais elles ont une validité fixe en ce sens que les transactions ne sont valides que si elles ont une signature ECDSA valide avec un nonce valide et un solde de compte suffisant. AA améliore les transactions de validité fixe à une validité programmable en introduisant un nouveau type de transaction AA qui provient toujours d'une adresse spéciale pour laquelle le protocole ne nécessite pas de signature, de nonce ou de vérifications de solde. La validité de ces transactions AA est déterminée par un contrat intelligent cible qui peut faire respecter ses propres règles de validité après quoi il peut décider de payer pour de telles transactions.

Alors, pourquoi est-ce utile? Prenons l'exemple des portefeuilles Ethereum pour mettre en évidence l'avantage de AA.

Portefeuilles de contrats intelligents: La plupart des portefeuilles Ethereum aujourd'hui sont des portefeuilles EOA qui sont protégés par une clé privée générée à partir d'une phrase de récupération. (A BIP-39La phrase de récupération ou mnémonique est une liste ordonnée de 12 à 24 mots choisis au hasard parmi une liste de 2048 mots. Cela fournit l'entropie nécessaire pour obtenir une graine binaire qui est générée à l'aide de la fonction PBKDF2. La graine binaire est ensuite utilisée pour générer les paires de clés asymétriques pour le BIP-32 wallet.) L'utilisateur est censé noter la phrase de récupération quelque part en sécurité car elle pourrait être nécessaire ultérieurement pour restaurer les clés sur un autre portefeuille. Cependant, de tels portefeuilles sont vulnérables au vol de clés privées ou à la perte de phrases de récupération, ce qui entraîne la perte des fonds de l'utilisateur.

Les portefeuilles de contrats intelligents sont mis en œuvre on-chain via des contrats intelligents (comme son nom l'indique). Ces portefeuilles offrent une atténuation du risque programmable et une expérience conviviale en mettant en œuvre des fonctionnalités telles que la sécurité multi-signature, la récupération sociale ou basée sur le temps, la limitation du taux des transactions ou des montants, la liste d'adresses autorisées/interdites, les méta-transactions sans gaz et les transactions groupées.

Alors que les portefeuilles de contrats intelligents sont exposés à des risques de sécurité liés aux contrats intelligents vulnérables, ce risque peut être atténué par des tests de sécurité et des révisions effectués par le fournisseur de portefeuille. Le risque lié aux portefeuilles EOA relève entièrement de l'utilisateur du portefeuille qui est chargé de la sécurité de la phrase de démarrage sans aucun des sauvegardes programmables possibles avec des contrats intelligents.

Des exemples de portefeuilles de contrats intelligents sont Argent, Authereum, Dapper, Dharma, Gnosis Safe, MonolitheetMYKEYL'adoption de ces portefeuilles semble augmenter comme indiqué ci-dessous graph.

Argent met en œuvre une récupération sociale sans graine avec leur concept de Gardiens qui sont des personnes ou des appareils de confiance de l'utilisateur qui peuvent aider à récupérer le portefeuille de l'utilisateur. Argent vise également à permettre une sécurité bancaire (via des fonctionnalités telles que des limites de transaction quotidiennes, le verrouillage du compte et des contacts de confiance) combinée à une facilité d'utilisation similaire à Venmo (via l'utilisation de noms ENS au lieu d'adresses et le support des méta-transactions).

Gnosis Safe est un portefeuille de contrat intelligent multi-sig axé sur la gestion d'équipe des fonds qui nécessite un nombre minimum (m-sur-n) de membres de l'équipe pour approuver une transaction avant qu'elle ne puisse avoir lieu. Il permet également des signatures sans gaz via des méta-transactions.

Toutes ces capacités de portefeuille avancées nécessitent l'utilisation de contrats intelligents non triviaux. Les utilisateurs de portefeuille ont besoin d'un EOA avec du gaz pour interagir avec eux ou dépendent du fournisseur de portefeuille pour prendre en charge les méta-transactions via les relais du fournisseur ou des réseaux de relais tiers tels que Réseau de Stations-serviceAlors que le premier repose généralement sur de l'ETH acheté sur des plateformes d'échange centralisées après KYC, le second vise à réduire cette friction UX d'intégration en transférant le fardeau de l'utilisateur sur des relayeurs pour un coût compensé par le fournisseur de portefeuille sur-/hors chaîne et/ou par l'utilisateur hors chaîne.

Cependant, les architectures basées sur les relayers présentent trois principaux inconvénients : (1) Ils peuvent être considérés comme des intermédiaires centralisés avec le potentiel de censurer les transactions (2) Ils sont techniquement/économiquement inefficaces en raison des 21000 frais de base supplémentaires requis pour la transaction du relayer et de leur besoin commercial de réaliser un profit en plus des frais de gaz (3) L'utilisation de protocoles spécifiques au relayer oblige les applications à dépendre d'une infrastructure Ethereum non basée sur la couche de base avec des bases d'utilisateurs plus petites et des garanties de disponibilité incertaines.

L'abstraction de compte permettra aux portefeuilles de contrats intelligents d'accepter des méta-transactions sans gaz de l'utilisateur et de payer leur gaz sans dépendre des réseaux de relais. Cette capacité de couche de base améliorera donc considérablement l'expérience utilisateur de tels portefeuilles sans sacrifier les garanties de décentralisation d'Ethereum.

Tornado Cash: Une application motivante connexe est celle d'un mélangeur tel que tornado.cashoù@tornadoTornado améliore la confidentialité des transactions en rompant le lien on-chain entre les adresses en utilisant un contrat intelligent qui accepte les dépôts d'ETH qui peuvent ensuite être retirés par une adresse différente. L'utilisateur est censé fournir le hash d'un secret lors du dépôt et fournir plus tard une preuve zkSnark lors du retrait pour montrer la connaissance du secret sans révéler le secret ou le dépôt précédent lui-même. Cela délie le retrait du dépôt.

Mais il y a un problème de poule et d'oeuf avec le retrait. Pour exécuter une transaction de retrait à partir d'une adresse nouvellement générée, l'utilisateur doit avoir un peu d'ETH pour payer les frais de gaz. La source de cet ETH (généralement une bourse) peut compromettre la confidentialité de Tornado. L'alternative préférée est de nouveau d'utiliser un réseau de relais qui présente les inconvénients mentionnés précédemment.

L'abstraction de compte résoudra ce problème en permettant au contrat Tornado d'accepter la transaction de retrait de l'utilisateur AA, de valider le zkSnark, de déduire des frais de gaz (du montant de dépôt initial) puis de transférer le reste du montant de dépôt à l'adresse de retrait.

Abstraction de compte

L'abstraction de compte, telle que proposée dans l'EIP-2938, permet à un contrat d'être le compte de niveau supérieur qui paie les frais et lance l'exécution des transactions. Cela est réalisé en introduisant des modifications de protocole avec un nouveau type de transaction AA qui nécessite deux nouveaux opcodes : NONCE et PAYGAS, des modifications des règles de la mempool et des extensions pour prendre en charge des utilisations avancées. Les types de comptes restent au nombre de deux (EOA et compte de contrat) et toutes les modifications proposées sont rétrocompatibles avec les transactions actuelles, les contrats intelligents et le protocole.

Les applications de AA sont considérées dans deux catégories: 1) Les applications mono-locataires telles que les portefeuilles de contrats intelligents, qui créent un nouveau contrat pour chaque utilisateur 2) Les applications multi-locataires telles que tornado.cash ou Uniswap, où plusieurs utilisateurs interagissent avec le même ensemble de contrats intelligents.

Le support AA pour les applications multi-locataires nécessite plus de recherche et est proposé comme travail futur. Nous nous concentrerons donc sur le support AA pour les applications mono-locataires dans cet article.

Changements de protocole

Il existe un nouveau type de transaction introduit avec deux opcodes de support NONCE et PAYGAS. Ce sont les seuls changements de protocole.

Transaction AA : Un nouveau type de transaction AA, AA_TX_TYPE, est introduit. Sa charge utile est interprétée comme RLP([nonce, cible, données]) au lieu du type de transaction existant dont la charge utile est RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s]).

Le gas_price et le gas_limit omis dans la transaction AA sont spécifiés par le contrat AA cible pendant l'exécution. La signature ECDSA v, r, s omise dans la transaction AA est remplacée par des vérifications de contrat spécifiques sur les données. L'adresse de destination est remplacée par l'adresse du contrat cible. La valeur est omise car l'adresse d'origine de toutes les transactions AA est une adresse spéciale ENTRY_POINT (0xFFFF…FFFF) et non une EOA qui lui est associée à une valeur.

Les nonces sont traités de manière analogue aux transactions existantes en vérifiant si tx.nonce == tx.target.nonce. Si cette vérification échoue, la transaction est considérée comme invalide, sinon tx.target.nonce est incrémenté et la transaction se poursuit.

Le coût de base du gaz d'une transaction AA est proposé à 15000 au lieu des 21000 actuels (pour refléter les économies de coûts liées à l'absence de signature ECDSA intrinsèque). De plus, les transactions AA n'ont pas de limite de gaz intrinsèque. Lors du début de l'exécution, la limite de gaz est simplement définie sur le gaz restant dans le bloc.

L'opération NONCE : L'opération NONCE (0x48) pousse le nonce du destinataire, c'est-à-dire du contrat cible AA, sur la pile EVM. Les nonces sont donc exposés à l'EVM pour permettre la vérification de la signature sur tous les champs de transaction (y compris le nonce) dans le cadre de la validation dans le contrat AA.

L'opcode PAYGAS : L'opcode PAYGAS (0x49) prend deux arguments de la pile : (en haut) version_number, (deuxième en partant de haut) memory_start. Le version_number permet aux implémentations futures de modifier la sémantique de l'opcode. Actuellement, l'opcode a les sémantiques suivantes :

1. Vérifiez version_number == 0 (sinon lancez une exception)
2. Lire gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])
3. Lire gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])
4. Vérifiez le solde du contrat >= prix_gaz * limite_gaz (sinon jeter une exception)
5. Vérifiez que globals.transaction_fee_paid == False (sinon lancez une exception)
6. Vérifiez que le cadre d'exécution AA est égal au cadre de niveau supérieur, c'est-à-dire que si l'exécution EVM actuelle se termine ou fait marche arrière, l'exécution EVM de l'ensemble de la transaction est interrompue (sinon lancez une exception)
7. Réduire le solde du contrat de gas_price * gas_limit
8. Définir globals.transaction_fee_paid = Vrai
9. Définir globals.gas_price = gas_price et globals.gas_limit = gas_limit
10. Définir le remaining_gas du contexte d'exécution actuel = gas_limit - gaz déjà consommé

À la fin de l'exécution de la transaction AA, (globals.gas_limit - remaining_gas) globals.gas_price est transféré au mineur et le contrat AA rembourse remaining_gasglobals.prix_gaz.

PAYGAS agit comme un point de contrôle d'exécution de l'EVM. Tous les retraits après ce point ne seront annulés qu'ici, puis le contrat ne reçoit aucun remboursement et globals.gas_limit * globals.gas_price est transféré au mineur.

Le nouveau type de transaction et les deux nouveaux opcodes constituent les changements de niveau de protocole/consensus et leur sémantique est relativement simple à comprendre.

Règles Mempool

"Le mempoolfait référence à l'ensemble des structures de données en mémoire à l'intérieur d'un nœud Ethereum qui stocke les transactions candidates avant qu'elles ne soient extraites. Geth l'appelle le "pool de transactions"; Parity l'appelle la "file d'attente des transactions." Peu importe le nom, il s'agit d'un pool de transactions en attente en mémoire d'être incluses dans un bloc. Pensez-y comme une "zone d'attente" pour que les transactions soient acceptées dans un bloc.

Actuellement, avec des règles de validité de transaction fixes, les mineurs et les autres nœuds ont besoin d'un effort minimal pour valider les transactions dans leur mempool et ainsi éviter les attaques DoS. Par exemple, un mineur peut être certain qu'une transaction paiera effectivement les frais si elle possède une signature ECDSA valide, un nonce valide et un solde de compte suffisant. D'autres transactions dans la mempool de ce mineur peuvent invalider cette transaction en attente uniquement si elles proviennent de la même adresse et augmentent le nonce ou réduisent suffisamment le solde du compte. Ces conditions sont minimes du point de vue computationnel pour donner aux mineurs et aux nœuds une confiance suffisante dans leurs mempools respectifs pour la considération des blocs ou la retransmission.

Les transactions AA introduisent plus de complexité avec leur validité programmable. Les transactions AA ne paient pas de gaz initialement et comptent sur leurs contrats AA cibles pour payer le gaz (via PAYGAS). Conceptuellement, le traitement des transactions AA est divisé en deux phases : la phase de vérification plus courte (avant PAYGAS) et la phase d'exécution plus longue (après PAYGAS). Si la phase de vérification échoue (ou lance une exception), la transaction est invalide (tout comme une transaction non-AA avec une signature invalide aujourd'hui), n'est pas incluse dans un bloc et le mineur ne reçoit pas de frais.

Les mineurs et les nœuds ont donc besoin d'un mécanisme prévisible pour éviter la dépendance de la validité d'une transaction AA en attente vis-à-vis d'autres transactions en attente dans le mempool. Sinon, l'exécution d'une transaction pourrait invalider de nombreuses/toutes les transactions AA dans le mempool, entraînant des attaques de type DoS. Pour éviter ce scénario, deux règles proposées doivent être appliquées (par les mineurs et les nœuds mais pas dans le protocole lui-même) sur les transactions AA dans les mempools :

Restriction d'opcode

Pour empêcher la validité de la transaction AA de dépendre de tout état externe au contrat AA lui-même, les opcodes suivants sont considérés comme invalides dans la phase de vérification (c'est-à-dire avant PAYGAS) : opcodes d'environnement (BLOCKHASH, COINBASE, TIMESTAMP, NUMBER, DIFFICULTY, GASLIMIT), BALANCE (de n'importe quel compte, y compris la cible elle-même), un appel externe/création à autre chose que la cible ou une précompilation (CALL, CALLCODE, STATICCALL, CREATE, CREATE2) et l'accès à l'état externe qui lit le code (EXTCODESIZE, EXTCODEHASH, EXTCODECOPY, DELEGATECALL) sauf si l'adresse est la cible.

Les nœuds devraient supprimer les transactions AA du mempool qui ciblent les contrats AA enfreignant cette règle de restriction d'opcode. Cela garantit que les transactions AA valides dans le mempool resteront valides tant que l'état du contrat AA ne change pas.

Restriction de préfixe de code bytecode

Si les transactions non-AA peuvent affecter l'état des contrats AA, cela aura un impact sur la validité des transactions AA dans le mempool. Pour éviter cela, les transactions AA ne devraient être autorisées à cibler que les contrats qui ont un AA_PREFIX au début de leur bytecode, où AA_PREFIX met en œuvre une vérification que msg.sender est l'adresse spéciale ENTRY_POINT des transactions AA. Cela empêche efficacement les transactions non-AA d'interagir avec les contrats AA.

Les nœuds sont censés abandonner les transactions AA aux contrats AA qui n'ont pas ce AA_PREFIX à leurs points d'entrée en bytecode.

Ces deux restrictions imposées aux contrats AA garantissent ensemble que : (1) le seul état accessible à la logique de validité d'une transaction AA est l'état interne au contrat AA et (2) cet état ne peut être modifié que par d'autres transactions AA ciblant ce contrat AA spécifique.

Une transaction AA en attente vers un contrat AA ne peut donc être invalidée que par un bloc contenant une autre transaction AA ciblant le même contrat AA. Cependant, étant donné qu'il ne s'agit pas de modifications de protocole/consensus, les mineurs sont libres d'inclure des transactions dans un bloc qui enfreignent ces règles.

Extensions

Les changements de protocole ci-dessus et les règles de la mempool permettent aux contrats AA de base de mettre en œuvre de manière suffisante et sûre des applications mono-locataires telles que les portefeuilles de contrats intelligents. D'autres utilisations avancées nécessitant une relaxation des règles ci-dessus ou la mise en œuvre d'applications multi-locataires nécessitent un soutien accru de la part d'AA sous la forme d'extensions telles que :

1. l'opcode SET_INDESTRUCTIBLE, qui désactive SELFDESTRUCT et permet aux contrats AA d'appeler en toute sécurité des bibliothèques avec DELEGATECALL lors de la phase de vérification.
2. L'opcode IS_STATIC, qui renvoie vrai si le contexte actuel est statique et permet aux appelants de transaction non-AA de remplacer la restriction de préfixe de bytecode précédente et de lire en toute sécurité des valeurs à partir de contrats AA.
3. opcode RESERVE_GAS, qui établit une limite inférieure sur le gaz consommé par le contrat AA lorsqu'il est invoqué à partir d'une transaction non-AA qui cherche à écrire l'état du contrat. Cela sert à contraindre les attaquants à dépenser une quantité minimale de gaz pour dissuader les tentatives d'invalidation de toute transaction AA dans le mempool.

Il existe d'autres éléments tels que plusieurs transactions en attente, la mise en cache des résultats de la validation, des limites de gaz dynamiques pour la validation et des transactions sponsorisées qui sont nécessaires pour prendre en charge des applications multi-locataires et des preuves zk par exemple Tornado Cash. Leur discussion est hors sujet pour cet article.

Étapes suivantes

L'EIP-2938 sur l'abstraction de compte est actuellement en mode brouillon et fait l'objet de discussions dans les forums de recherche sur Ethereum. La prochaine étape pour l'EIP est d'être envisagée pour inclusion dans l'une des prochaines fourches dures. Les auteurs de l'EIP visent apparemment la fourche dure après Berlin (Berlin est provisoirement prévue pour quelque temps en début 2021) dont la chronologie n'est pas très claire pour le moment. Il est donc encore tôt dans le processus pour l'EIP-2938.

De plus, il n'est pas clair qu'il sera nécessaire d'inclure l'EIP-2938 dans la couche de base Ethereum 1 (L1). Étant donnée la flexibilité relative des solutions de couche 2 (L2) (comme décrit dans notre précédent article) La comptabilité par abstraction peut être mise en œuvre sur des L2 spécifiques sans nécessiter la mise à niveau de l'ensemble de L1. Cependant, il y a des avantages à soutenir un AA uniforme sur L1, même si certains L2 mettent en œuvre leurs propres versions AA. Par conséquent, il reste à voir où et comment l'AA est mis en œuvre.

"L'abstraction de compte est quelque peu moins importante, car elle peut être mise en œuvre sur L2 indépendamment du fait que L1 la prend en charge ou non." — Vitalik sur les choses qui continueront à être importantes au niveau de base (dans sonarticlesur la feuille de route centrée sur le rollup Ethereum).

Statut : Le portefeuille Status est actuellement un portefeuille EOA qui se différencie par le regroupement d'un messager axé sur la confidentialité et la possibilité d'intégrer des fonctionnalités telles que les paiements en chat ou une sécurité renforcée avec Carte cléLes fonctionnalités du portefeuille de smart contract telles que le multisig et la récupération sociale sont envisagées pour lesquelles le support AA EIP-2938 aidera en supprimant la dépendance aux architectures centralisées et inefficaces basées sur les relais, comme décrit précédemment.

Status évalue également les solutions L2 à la fois pour prendre en charge plusieurs chaînes dans son portefeuille et pour fournir l'évolutivité requise pour divers cas d'utilisation, comme décrit dans notre précédent article. Par exemple, Keycard explore un réseau de paiementdont les exigences de conception en matière de scalabilité au niveau des cartes de crédit et de finalité quasi-instantanée ne sont pas remplies par le réseau Ethereum aujourd'hui. De plus, il existe de nombreuses autres initiatives telles que le Programme de parrainage, Réactions SNT, Tribute-to-Talketnoms ENS, dont tous bénéficieraient d'une évolutivité L2 pour un déploiement faisable et une expérience utilisateur raisonnable. Si une solution L2 viable met en œuvre AA, alors les projets construits sur cette L2 pourront tirer parti des avantages de AA sans avoir à compter sur L1.

Résumé

Un aspect fondamental du protocole Ethereum est que seuls les comptes possédés de manière externe (EOAs) peuvent payer les frais de gaz et commencer l'exécution de transactions. Les comptes de contrat (CAs) ne peuvent pas le faire. L'Abstraction de Compte (AA) est une proposition qui vise à changer cette distinction et à permettre aux CAs spécialement construits de vérifier de manière programmatique la validité d'un nouveau type de transactions AA, de décider de payer les frais de gaz en leur nom et ainsi de commencer effectivement leur exécution sans nécessiter un EOA.

AA a des implications pour améliorer considérablement l'expérience utilisateur dans divers scénarios tels que les portefeuilles, les mixeurs, les ÐApps et la DeFi sans dépendre d'architectures centralisées et inefficaces basées sur des relais. Les scénarios de base à locataire unique, tels que les portefeuilles de contrats intelligents, peuvent être pris en charge en toute sécurité par AA avec l'introduction d'un nouveau type de transaction, de deux nouveaux opcodes et de deux règles de mempool. Les applications avancées à locataires multiples, telles que Tornado Cash, nécessitent des extensions à ces changements de protocole et aux règles des nœuds.

Dans cet article, nous avons motivé la nécessité de AA dans le contexte des portefeuilles de contrats intelligents. Nous avons mis en évidence les aspects clés de AA en décrivant les changements de protocole et l'impact sur les nœuds. Nous avons abordé certaines des extensions proposées pour des utilisations avancées et avons enfin conclu en positionnant AA dans le contexte des feuilles de route actuelles d'Ethereum et des priorités de Status.

Réduire les frictions et améliorer l'expérience utilisateur dans Web3 est une priorité absolue pour tous les projets de cet écosystème. L'Abstraction de Compte, sous une forme quelconque, pourrait certainement jouer un rôle important dans cet effort à l'avenir.

Avertissement：

1. Cet article est repris de [ statutTransmettre le titre original 'Abstraction de compte (EIP-2938): Pourquoi & Quoi', Tous les droits d'auteur appartiennent à l'auteur originalRajeev Gopalakrishna]. Si des objections sont soulevées concernant cette reproduction, veuillez contacter le Apprendre Gatel'équipe, et ils le traiteront rapidement.

2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.

3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.