L'essence de l'abstraction de compte est un compte de contrat. Dans Ethereum, il existe deux types de comptes :
Un exemple simple est que l'adresse du contrat est l'adresse où le contrat est déployé. Tout contrat dans Ethereum qui peut être appelé a une adresse de contrat, comme l'adresse du contrat USDT. Un compte EOA est le compte ETH bien connu, comme le compte affiché dans le portefeuille Metamask.
0xdac17f958d2ee523a2206206994597c13d831ec7est l'adresse du contrat pour les jetons USDT. Les adresses de contrat ne peuvent pas être créées directement de l'extérieur; elles sont créées et gérées par des EOAs. L'EOA qui a créé l'adresse du contrat USDT est 0x36928500Bc1dCd7af6a2B4008875CC336b927D57.
Par conséquent, nous comprenons qu'un compte AA est un type spécial de compte de contrat (CA) sur Ethereum. Les comptes AA doivent encore être créés par les EOAs et sont contrôlés par des EOAs externes car le seul moyen d'interagir avec la chaîne Ethereum est par le biais des EOAs. Par conséquent, AA sert de mise en œuvre standardisée et modulaire des portefeuilles CA, qui continue d'évoluer avec le temps.
Nous venons d'expliquer la relation entre AA et CA. Avant la proposition de la norme ERC-4337, il y avait déjà un nombre significatif de portefeuilles CA disponibles. Ci-dessous, nous fournissons des informations sur trois portefeuilles CA populaires et leur fonctionnement :
Pendant les premiers stades du développement d'Ethereum, plusieurs portefeuilles de contrats ont émergé. Le plus connu est le portefeuille Parity, développé par l'équipe de Gavin Wood, les fondateurs de PolkaDot. Parity est implémenté en Rust et sert d'alternative au nœud Geth, développé en Golang. Le portefeuille Parity est un portefeuille de contrat multi-signature qui permet à plusieurs comptes détenus à l'extérieur (EOA) de contrôler et de gérer un compte de contrat (CA). Cependant, en 2017, un pirate a exploité une faille dans le portefeuille Parity et a volé plus de 150 000 ETH. Cet incident a entraîné une perte de confiance dans les portefeuilles de contrats.
Par conséquent, les portefeuilles AA nécessitent une pratique extensive et une standardisation pour éviter que des incidents similaires ne se produisent.
Le portefeuille multi-signature Gnosis est actuellement le portefeuille multi-sig le plus courant et est utilisé par la plupart des institutions et des développeurs. Un nombre important d'équipes stockent leurs fonds de développement dans le portefeuille multi-signature de Gnosis pour empêcher les membres de l'équipe d'agir de manière malveillante. Des équipes notables utilisant Gnosis Safe incluentYearn,Aave, etBalancer. La sécurité de Gnosis Safe est extrêmement élevée, mais son utilisation est relativement coûteuse, ce qui est un problème courant avec les portefeuilles CA.
Unipass Wallet combine la technologie MPC et les portefeuilles de contrat CA, permettant aux utilisateurs d'utiliser la connexion sociale sans auto-conservation d'un portefeuille EOA. Il convient de noter que le portefeuille Parity et Gnosis Safe nécessitent toujours que les utilisateurs conservent eux-mêmes leurs clés privées. Le flux général de Unipass est :
Il est important de noter que la solution AA originale de Unipass ne respecte pas entièrement la norme ERC-4337. Le contrôle du portefeuille est toujours délégué à un EOA contrôlé par le MPC de Unipass.
L'essence de l'AA est un compte CA standardisé et modulaire. ERC-4337 se manifeste principalement par les innovations suivantes :
Le diagramme ci-dessus décrit approximativement le processus de transaction standard sous ERC-4337 :
Nous pouvons résumer les principales différences entre AA et CA traditionnelle comme suit :
Avant de comprendre pleinement AA, beaucoup de gens confondent souvent les concepts de AA et de MPC car ils soutiennent tous deux des fonctionnalités telles que la récupération sociale et les plugins sans navigateur. Les différences essentielles entre AA et MPC sont les suivantes :
Ensuite, permettez-moi de vous présenter MPC et ses fonctionnalités uniques.
Les solutions MPC sont largement utilisées dans les connexions sociales actuelles, et de nombreux projets ont lancé des portefeuilles MPC pour fournir une expérience de portefeuille sans chaîne, éliminant ainsi le besoin pour les utilisateurs d'installer des portefeuilles de plugins ou de gérer des clés privées. Dans l'industrie, ces types de portefeuilles gérés sont collectivement appelés Wallet-as-a-Service (WaaS). Les projets matures incluent :
Face à un nombre croissant de services WaaS, il est prévisible qu'il y aura plus de produits offrant WaaS à l'avenir. Cependant, les bourses centralisées ont un volume absolu d'utilisateurs et une vaste expérience commerciale dans ce domaine, il est donc possible que toutes les bourses centralisées fournissent des services connexes à l'avenir.
Le principal inconvénient des comptes détenus traditionnels (EOA) est que les utilisateurs sont responsables de stocker leurs propres clés privées. Cette auto-garde présente les problèmes suivants :
AA (Account Abstraction) est conçu pour permettre aux utilisateurs de configurer des comptes de récupération sociale. Ils peuvent utiliser une ou plusieurs EOA externes pour reprendre le contrôle de leur AA. Le flux commun pour le redressement social est le suivant :
Grâce à ce processus d'appel, même si l'utilisateur perd le contrôle de l'EOA gouvernant l'AA, il peut toujours basculer vers un nouveau EOA. Contrairement à la connexion sociale MPC (Calcul multi-partite), cette récupération sociale est entièrement décentralisée et ne présente pas de point de défaillance unique.
La délégation de gaz est essentielle à l'adoption massive de la blockchain. Pour les nouveaux utilisateurs entrant dans le Web3, le plus grand point douloureux est de préfinancer les frais de gaz. En utilisant le Paymaster de AA pour déléguer le gaz, les nouveaux utilisateurs peuvent être subventionnés, réduisant ainsi la barrière à l'entrée des applications Web3.
Un autre problème central affectant l'adoption massive de Web3 est la compatibilité inter-chaînes. Paymaster, grâce à l'intégration de protocoles inter-chaînes comme Layer0/Warmhole, permet aux utilisateurs de déposer sur la Chaîne A (par exemple, Ethereum) et d'utiliser sans problème des applications sur une autre Chaîne B (par exemple, Matic ou BSC), faisant ainsi disparaître les frontières entre les chaînes et aidant les nouveaux Dapps à gagner des utilisateurs d'autres chaînes.
Bien que nous ayons discuté des avantages de AA, la norme ERC-4337 évolue encore rapidement pour remédier à ses inconvénients actuels :
Contrairement à EOA, une fois qu'un EOA est créé, il peut être utilisé sur n'importe quelle chaîne compatible avec l'EVM, car la même paire de clés publique-privée peut être utilisée pour interagir sur différentes chaînes. Cependant, en raison de la nature de AA en tant que Compte de Contrat (CA), un nouveau contrat AA doit être déployé séparément sur chaque chaîne ou Layer2. Le coût élevé du déploiement des contrats AA pourrait dissuader les utilisateurs d'adopter des AA.
De plus, si les utilisateurs déploient de manière incorrecte, par exemple en utilisant différents Factories pour déployer des comptes de contrat AA, ils peuvent se retrouver avec des adresses AA différentes sur différentes chaînes, ce qui peut causer une confusion et une difficulté significatives dans l'utilisation et la compréhension. Bien que les Factories de portefeuilles AA actuelles aient réussi à générer la même adresse AA sur différentes chaînes, les utilisateurs doivent toujours faire preuve de prudence en vérifiant les protocoles qu'ils utilisent pour s'assurer que leurs adresses AA restent cohérentes sur différentes chaînes, évitant ainsi tout problème ou confusion futurs.
Comme mentionné, les comptes AA exigent que les utilisateurs déploient les contrats AA générés par Wallet Factory sur différentes chaînes et Layer2 séparément. Même avec les sidechains actuels, les chaînes compatibles EVM et les frais de gaz plus bas de Layer2, c'est encore une dépense importante. Avec les frais de gaz actuels et le prix de l'ETH à 1800 $, le déploiement d'un compte AA sur le mainnet ETH coûterait environ 20 à 40 dollars, tandis que sur les chaînes compatibles EVM ou Layer2, cela varierait de 0,5 à 5 dollars. Pour la plupart des utilisateurs, il est difficile d'accepter le coût de déploiement avant même d'utiliser l'application. En supposant que ce coût soit subventionné par un Bundler ou un Paymaster, le coût de la subvention est encore trop élevé et nécessite un incitatif fort.
En fonction de la mise en œuvre de AA et du nombre de transactions regroupées dans une seule transaction de Bundler (plus il y a de transactions, plus le coût en gaz par UserOP est faible), la consommation de gaz des transactions standard ERC-4337 actuelles peut être plusieurs fois plus élevée que celle des comptes EOA réguliers. En effet, une transaction initiée par un compte AA nécessite souvent l'appel de 3 contrats ou plus et implique des calculs complexes tels que la vérification de signature BLS on-chain. La norme ERC-4337 actuelle est également en cours d'optimisation à cet égard, avec la feuille de route suivante :
Nous venons de mentionner le coût relativement élevé de l'utilisation de la norme ERC-4337. Quels sont les coûts spécifiques ? Tout d'abord, permettez-nous de présenter un concept, qui est la formule de calcul des frais de gaz :
frais = gaz × prix
Alors, quels sont les coûts de déploiement et d'utilisation de l'ERC-4337 ? L'équipe StackUp a fourni des estimations précises dans leur blog.
https://www.stackup.sh/blog/how-much-more-expensive-is-erc-4337
Table 1. Gaz pour les transactions ERC-4337
Le tableau ci-dessus montre:
Table 2. Estimations des frais de gaz pour les transactions ERC-4337
Cette table fournit des estimations de coûts pour diverses opérations sur le compte AA ERC-4337 en utilisant les prix actuels du gaz. Nous pouvons observer ce qui suit :
En résumé, en raison du coût élevé de la création de comptes AA ERC-4337 sur le mainnet, une adoption généralisée est susceptible de se produire d'abord sur les chaînes Layer2 et compatibles EVM.
Un autre obstacle au développement de AA est la compatibilité de l'infrastructure avec les contrats AA. La plupart des Dapps en dehors de la chaîne AA native ne prennent en charge que les comptes EOA. Le support pour AA nécessite que les Dapps utilisent le SDK de AA pour les transactions et modifient les paramètres de requête pour les informations utilisateur.
De plus, les navigateurs de chaînes de blocs tels que Etherscan sont principalement conçus pour les EOAs. Pour améliorer la commodité de la consultation des comptes AA, ces navigateurs peuvent nécessiter une série d'optimisations de l'interface utilisateur et de l'expérience utilisateur.
Sauf Ethereum, la plupart des nouvelles blockchains publiques ont déjà mis en place des comptes AA natifs.
Les AA natifs sont mis en œuvre au niveau du consensus de la chaîne, ce qui signifie qu'ils ne nécessitent pas de développeurs communautaires pour le déploiement. Il s'agit généralement de contrats internes ou système développés et maintenus par les développeurs de la blockchain.
Coûts de déploiement inférieurs et frais de gaz supplémentaires
Les contrats internes ont souvent des autorisations et des priorités plus élevées, et leurs calculs de gaz sont différents de ceux des contrats externes. Par conséquent, les AA natifs ont des coûts de déploiement plus bas et n'ajoutent généralement pas de surcharge de gaz significative.
La mise à niveau des AA natifs nécessite que les développeurs de la chaîne publique soient responsables, nécessitant souvent des forks souples ou durs. Cela les rend moins flexibles que l'ERC-4337 modulaire, limitant le rythme de l'itération et de la publication de nouvelles fonctionnalités.
Les chaînes avec des AA natifs étudient activement l'extensibilité et la modularité de l'ERC-4337, permettant ainsi de construire plus de fonctionnalités sur les AA natifs.
Near implémente des AAs natifs au niveau du consensus avec des comptes stockés directement dans la blockchain. Il prend en charge plusieurs clés d'accès et la récupération sociale (e-mail, numéro de téléphone). L'image suivante illustre les différences entre un compte ETH et un compte Near.
En raison du modèle de propriété des ressources dans Aptos et Sui, à la fois Aptos et Sui ont mis en œuvre un AA natif au niveau du consensus. En prenant Aptos comme exemple, un compte Aptos est un ensemble de ressources sur la blockchain, donc lors de la création d'un compte Aptos, il est nécessaire de prépayer des Aptos pour compléter l'initialisation du compte. Les comptes Aptos/Sui prennent également en charge le changement de la clé d'authentification, mais l'adresse du compte reste la même, parmi d'autres fonctionnalités AA.
Contrairement à Near/Aptos/Sui/Starknet, ZKsync prend en charge à la couche de consensus à la fois EOA et AA. Par conséquent, ZKsync peut initier des transactions à la fois avec EOA et AA, ce qui lui permet d'être utilisé avec des portefeuilles populaires comme Metamask et Argent. La conception AA de ZKSync est basée sur ERC-4337, ce qui le rend compatible avec les portefeuilles et Dapps prenant en charge l'EIP-4337. Actuellement, le coût en gaz supplémentaire pour les transactions AA dans ZKsync est d'environ execution_gas + 20000, soit environ 0.01USD au moment de la rédaction. Il s'agit d'un coût modeste par rapport aux transactions AA ERC-4337 non natives.
Starknet prend en charge nativement AA et ne prend pas en charge les transactions initiées par EOA. Les comptes AA dans Starknet sont conçus sur la base de ERC-4337. Actuellement, les contrats AA dans Starknet sont fournis par OpenZeppelin et développés en utilisant Cairo.
Les comptes AA natifs dans ICP sont appelés Identité Internet (II pour faire court). La mise en œuvre de II est différente de ERC-4337. II utilise WebAuthn, couramment utilisé dans les frameworks Web2, permettant aux utilisateurs de contrôler leurs comptes en utilisant les puces de sécurité intégrées à leurs smartphones. Les utilisateurs peuvent librement ajouter et supprimer des appareils. En essence, II transforme les appareils smartphones de l'utilisateur en portefeuilles matériels.
Le Bundler remplace le Mempool node précédent dans l'écosystème AA. Les UserOps ne sont plus envoyés aux Validators mais aux Bundlers pour l'emballage et le traitement on-chain. Les bundlers principaux sont les suivants:
Le bundler de Stackup est implémenté en Go lang et vise à s'intégrer parfaitement à Go Ethereum (geth). C'est le premier bundler de norme de production de cette liste qui est entièrement conforme à l'ERC-4337. Stackup est activement maintenu et dispose d'une documentation complète, ce qui en fait le bundler le plus populaire actuellement. Stackup fournit des services de bundler, éliminant ainsi le besoin pour les équipes de mettre en place leur propre service de bundler.
Le bundler d’Infinitism est développé en TypeScript et a été développé par l’auteur original de l’ERC-4337. Infinitism développe également des contrats ERC-4337, ce qui rend son bundler hautement compatible avec ERC-4337. Cependant, une vérification supplémentaire est nécessaire pour les performances et la stabilité car il est développé en TypeScript.
Skandha est un bundler basé sur TypeScript développé par Etherspot. Etherspot est actif dans l'implémentation du mempool du bundler. Skandha a réussi tous les tests en avril 2023.
Voltaire est un protocole de bundler développé par l'équipe de Candide pour prendre en charge leur propre portefeuille Candide. Voltaire est une implémentation basée sur Python de l'ERC-4337. Voltaire fournit actuellement un bon support pour le portefeuille open-source de Candide.
Rundler est un protocole Bundler développé par Alchemy, le plus grand fournisseur de services de noeuds pour Ethereum. Actuellement, Rundler n'est pas open source, mais en raison de la grande base d'utilisateurs d'Alchemy, il pourrait bénéficier d'un important soutien de trafic.
Bundler est actuellement dans une phase de développement et d'itération rapides.
Le point douloureux actuel que le bundler doit aborder est la cohérence et les problèmes de communication de la mempool du bundler. En supposant qu'il existe plusieurs protocoles de bundler sur le marché et qu'il y a un manque de communication entre eux, cela peut entraîner un grave problème d'attaques DDoS sur le bundler. Si un utilisateur envoie simultanément des transactions à plusieurs bundlers sans communication entre eux, ces bundlers emballeront et enverront simultanément des UserOps au validateur. Cependant, seul le UserOp du premier bundler sera exécuté, et les transactions des bundlers restants seront rejetées en raison du même nonce. Dans ce cas, si le paymaster de l'utilisateur a un solde insuffisant, les bundlers paieront des frais de gaz invalides pour ces UserOps. Ainsi, actuellement, la communication entre les bundlers est un problème qui doit être résolu afin de prévenir les attaques de spam UserOp sur les bundlers.
Les emballeurs actuels sont très centralisés. Si les emballeurs mettent certains utilisateurs sur liste noire, cela entraînerait l'impossibilité d'exécuter leurs transactions. Cela va à l'encontre de la nature décentralisée et sans permission de la blockchain.
Le Paymaster est une partie importante de AA, car il peut subventionner les frais de gaz des utilisateurs et réduire considérablement la barrière à l'entrée pour Web3. Voici quelques implémentations populaires du paymaster:
stackups paymaster
Le paymaster de Stackups fait partie de l'écosystème Stackups AA. Stackups a mis en place un tableau de bord du paymaster où les DApps ou autres fournisseurs de services peuvent configurer leurs propres comptes de subventionnement.https://app.stackup.sh/sign-inpour parrainer les transactions des utilisateurs.
Tableau de bord Biconomy
Le tableau de bord Biconomy permet aux organisations et aux développeurs d'utiliser les composants AA dans leurs projets. Les propriétaires de projets peuvent configurer leurs projets pour payer les frais de gaz des utilisateurs via des paymasters et ajouter des conditions de parrainage de gaz. En enregistrant votre paymaster pour toute chaîne prise en charge, les DApps peuvent grandement simplifier l'expérience Web3 pour les utilisateurs.
Les comptes EOA traditionnels ont souvent du mal à atteindre simultanément la décentralisation, la convivialité et la sécurité.
Dans le cadre traditionnel de l'EOA, les utilisateurs ont souvent besoin d'acquérir des jetons de blockchain comme l'ETH à travers des monnaies fiduciaires pour utiliser des applications Web3. Cela implique généralement d'utiliser des échanges centralisés (CEX) pour déposer des devises fiduciaires, les échanger contre le jeton requis, et finalement le transférer vers un compte EOA nouvellement créé. Ce processus nécessite une compréhension significative de Web3 et est fastidieux dans de nombreuses régions. En introduisant des paymasters dans AA, les coûts initiaux d'intégration pour les utilisateurs peuvent être délégués aux propriétaires de projets de DApps. Le transfert des frais de gaz a des implications significatives pour l'adoption massive de Web3.
Actuellement, l'ERC-4337 en est à ses débuts et de nombreux outils sont en cours de développement sur cette base. Du côté du payeur, l'UserOp de l'utilisateur peut être vérifié pour éviter les problèmes, tels que des approbations excessives ou des transferts de fonds non autorisés. L'audit de sécurité du payeur peut être effectué en utilisant des méthodes bien établies dans le secteur financier web2 pour examiner les transactions problématiques et garantir la sécurité des fonds des utilisateurs.
Une autre innovation en cours de développement est l'isolement sécuritaire des comptes, tels que la séparation du compte de fonds du compte de jeu, etc. Lorsque les utilisateurs utilisent des fonctions DeFi familières et de transfert, le compte de fonds avec un audit de sécurité plus strict est utilisé. Lorsque les utilisateurs essaient GameFi ou DeFi peu familiers, le compte de jeu est utilisé. De cette manière, sans augmenter les clés privées que les utilisateurs doivent gérer, la conception d'isolement sécuritaire des comptes assure la sécurité des fonds des utilisateurs au niveau sous-jacent.
Actuellement, de nombreux appareils tels que les smartphones et les ordinateurs portables disposent de puces sécurisées intégrées, telles que la puce de sécurité Apple T2 utilisée dans Mac et iPhone. Par conséquent, fondamentalement, chaque appareil avec une puce Tee est un portefeuille matériel fiable. Cependant, ces puces sécurisées ne prennent actuellement pas en charge les algorithmes de signature de chaîne de blocs courants tels que ECDSA.
La sécurité actuelle des clés privées EOA dans les plugins / portefeuilles mobiles est directement stockée en texte clair sur l'appareil. Si l'appareil est compromis, les actifs de l'utilisateur peuvent être rapidement perdus. Par conséquent, les portefeuilles d'extension de navigateur comme Metamask ont une haute convivialité mais une faible sécurité.
Portefeuilles matériels
Les portefeuilles matériels garantissent que les clés privées ne quittent jamais l'appareil et ne peuvent pas être directement accessibles par des tiers. Cependant, la plupart des utilisateurs ne peuvent pas transporter leurs portefeuilles matériels avec eux en permanence, ce qui se traduit par une sécurité élevée mais une faible utilisabilité.
En utilisant le portefeuille AA et la méthode innovante de vérification on-chain, les transactions peuvent être directement signées par la puce sécurisée de l’appareil, garantissant ainsi que la clé privée de l’utilisateur ne quitte jamais l’appareil. Cela offre une plus grande sécurité par rapport aux comptes EOA traditionnels. À l’heure actuelle, Internet Identity de l’Internet Computer et un projet appelé Porton Wallet dans le cadre de l’ETHBogota Hackathon ont mis en œuvre une solution qui utilise la signature par puce sécurisée et la clé de session, permettant aux utilisateurs d’utiliser pleinement la sécurité de leurs appareils tels que les smartphones ou les ordinateurs, équivalente à un portefeuille matériel.
Grâce à la conception hautement modulaire de l'ERC-4337, grâce à son expansion et à son itération, les comptes AA bénéficieront d'une sécurité considérablement améliorée.
Actuellement, un autre obstacle à l’adoption massive du Web3 est la fragmentation des écosystèmes blockchain entre différentes chaînes.
À titre d'exemple simple, considérons un utilisateur sur Ethereum (ETH) qui souhaite découvrir une application sur Binance Smart Chain (BSC). Que devrait faire cet utilisateur ? Tout d'abord, l'utilisateur doit échanger ses ETH contre les USDT/USDC correspondants, puis utiliser un pont inter-chaînes pour transférer ces jetons d'ETH à BSC. Ensuite, l'utilisateur doit acheter des BNB sur une bourse centralisée (CEX) et les transférer à BSC. Seulement alors l'utilisateur pourra commencer à découvrir diverses applications DeFi sur BSC. Tout ce processus est chronophage, peu sécurisé et nécessite une courbe d'apprentissage raide, en particulier pour les nouveaux utilisateurs qui pourraient ne pas être familiers avec les ponts inter-chaînes.
À travers les protocoles inter-chaînes couramment utilisés, tels que Layer0 + AA, le processus d'utilisation de DApp sur différentes chaînes peut être grandement simplifié. Le maître de paiement peut intégrer pleinement les protocoles inter-chaînes pour réaliser le concept de "payer une seule fois, payer partout". Par exemple, si un utilisateur recharge des USDC sur le maître de paiement d'ETH, tant que le compte AA de l'utilisateur sur différentes chaînes est le même et est lié au même maître de paiement, le maître de paiement peut gérer la comptabilité au nom de l'utilisateur. L'utilisateur n'a pas besoin de transférer manuellement des actifs vers une chaîne/Layer2 compatible avec EVM avec la même adresse de compte.
Le plus grand avantage de l'introduction du paymaster est qu'il établit de manière programmatique des conditions pour subventionner les utilisateurs de Dapp.
Dans le passé, il y a eu des cas où des projets de l'écosystème Web3 ont subventionné le gaz pour attirer des clients. Cependant, subventionner les comptes EOA sans définir de manière programmée des conditions a souvent conduit à une mauvaise utilisation des fonds de subvention par des robots et des fraudeurs, tels que le transfert direct des fonds de subvention, sans attirer de véritables clients.
Actuellement, les tableaux de bord du paymaster incluent généralement la fonctionnalité de subventionner les frais de gaz pour les Dapps. Les développeurs de projets peuvent facilement définir les conditions de subvention dans le tableau de bord, de sorte que seules les transactions répondant à des conditions spécifiques sont éligibles à la subvention. En contrôlant les conditions de transaction dans les subventions via le paymaster, les Dapps peuvent attirer plus d'utilisateurs authentiques tout en maîtrisant les coûts.
Sous EOA, en raison de la domination de Metamask, les Dapps actuels sont principalement accessibles via des interfaces web, ce qui se traduit par une plus grande part de marché pour les portefeuilles de plugins web. Cependant, l'adoption massive du web3 repose sur la participation des utilisateurs mobiles, ce qui rend le développement et l'adaptation de AA plus Mobile Native.
Avec la popularité croissante de Dark Forest, la tendance des jeux entièrement sur la chaîne émerge tranquillement. Cependant, l’expérience utilisateur de l’utilisation des EOA (comptes externes) dans les jeux est très médiocre. Imaginez que vous deviez utiliser un portefeuille pour autoriser ou signer des transactions chaque fois que vous effectuez une action dans un jeu. Cette interruption constante empêche les joueurs de se concentrer pleinement sur le jeu lui-même. Pour résoudre ce problème, les comptes d’arcade, qui sont des versions spécialisées des AA ordinaires, ont été développés spécifiquement pour les jeux entièrement sur la chaîne. Ces comptes autorisent des opérations de jeu spécifiques, ce qui permet aux joueurs de participer à des jeux complets sur la chaîne sans avoir besoin d’autorisations répétitives et de signatures de transactions. En conséquence, l’expérience de jeu est grandement améliorée. L’essor des jeux entièrement on-chain à l’avenir est susceptible de favoriser l’adoption généralisée des comptes AA.
Récemment, le concept de transactions basées sur l'intention a gagné en popularité avec l'essor d'Unibot, et Uniswap a également lancé le projet Uniswap X pour promouvoir la mise en œuvre de transactions basées sur l'intention. L'exemple suivant peut expliquer ce que sont les transactions basées sur l'intention :
Si quelqu'un est prêt à exécuter l'intention, la contrepartie initie une autre intention de transférer 1000 USDT à Alice et de recevoir 1 ETH.
La transaction est réussie.
Les transactions basées sur l'intention offrent les avantages suivants :
Actuellement, CowSwap a mis en œuvre des transactions basées sur l'intention basée sur EOA. Cependant, les transactions basées sur l'intention basée sur EOA nécessitent toujours que les utilisateurs autorisent (ERC-20, Approve) avant d'initier la transaction. Cependant, sous la nouvelle architecture de compte de AA, les utilisateurs peuvent envoyer Approve et Intention ensemble au regroupeur. Le regroupeur de AA peut accéder simultanément au sondage des intentions, faire correspondre les intentions et fournir une expérience de trading plus pratique.
L'essence de l'abstraction de compte est un compte de contrat. Dans Ethereum, il existe deux types de comptes :
Un exemple simple est que l'adresse du contrat est l'adresse où le contrat est déployé. Tout contrat dans Ethereum qui peut être appelé a une adresse de contrat, comme l'adresse du contrat USDT. Un compte EOA est le compte ETH bien connu, comme le compte affiché dans le portefeuille Metamask.
0xdac17f958d2ee523a2206206994597c13d831ec7est l'adresse du contrat pour les jetons USDT. Les adresses de contrat ne peuvent pas être créées directement de l'extérieur; elles sont créées et gérées par des EOAs. L'EOA qui a créé l'adresse du contrat USDT est 0x36928500Bc1dCd7af6a2B4008875CC336b927D57.
Par conséquent, nous comprenons qu'un compte AA est un type spécial de compte de contrat (CA) sur Ethereum. Les comptes AA doivent encore être créés par les EOAs et sont contrôlés par des EOAs externes car le seul moyen d'interagir avec la chaîne Ethereum est par le biais des EOAs. Par conséquent, AA sert de mise en œuvre standardisée et modulaire des portefeuilles CA, qui continue d'évoluer avec le temps.
Nous venons d'expliquer la relation entre AA et CA. Avant la proposition de la norme ERC-4337, il y avait déjà un nombre significatif de portefeuilles CA disponibles. Ci-dessous, nous fournissons des informations sur trois portefeuilles CA populaires et leur fonctionnement :
Pendant les premiers stades du développement d'Ethereum, plusieurs portefeuilles de contrats ont émergé. Le plus connu est le portefeuille Parity, développé par l'équipe de Gavin Wood, les fondateurs de PolkaDot. Parity est implémenté en Rust et sert d'alternative au nœud Geth, développé en Golang. Le portefeuille Parity est un portefeuille de contrat multi-signature qui permet à plusieurs comptes détenus à l'extérieur (EOA) de contrôler et de gérer un compte de contrat (CA). Cependant, en 2017, un pirate a exploité une faille dans le portefeuille Parity et a volé plus de 150 000 ETH. Cet incident a entraîné une perte de confiance dans les portefeuilles de contrats.
Par conséquent, les portefeuilles AA nécessitent une pratique extensive et une standardisation pour éviter que des incidents similaires ne se produisent.
Le portefeuille multi-signature Gnosis est actuellement le portefeuille multi-sig le plus courant et est utilisé par la plupart des institutions et des développeurs. Un nombre important d'équipes stockent leurs fonds de développement dans le portefeuille multi-signature de Gnosis pour empêcher les membres de l'équipe d'agir de manière malveillante. Des équipes notables utilisant Gnosis Safe incluentYearn,Aave, etBalancer. La sécurité de Gnosis Safe est extrêmement élevée, mais son utilisation est relativement coûteuse, ce qui est un problème courant avec les portefeuilles CA.
Unipass Wallet combine la technologie MPC et les portefeuilles de contrat CA, permettant aux utilisateurs d'utiliser la connexion sociale sans auto-conservation d'un portefeuille EOA. Il convient de noter que le portefeuille Parity et Gnosis Safe nécessitent toujours que les utilisateurs conservent eux-mêmes leurs clés privées. Le flux général de Unipass est :
Il est important de noter que la solution AA originale de Unipass ne respecte pas entièrement la norme ERC-4337. Le contrôle du portefeuille est toujours délégué à un EOA contrôlé par le MPC de Unipass.
L'essence de l'AA est un compte CA standardisé et modulaire. ERC-4337 se manifeste principalement par les innovations suivantes :
Le diagramme ci-dessus décrit approximativement le processus de transaction standard sous ERC-4337 :
Nous pouvons résumer les principales différences entre AA et CA traditionnelle comme suit :
Avant de comprendre pleinement AA, beaucoup de gens confondent souvent les concepts de AA et de MPC car ils soutiennent tous deux des fonctionnalités telles que la récupération sociale et les plugins sans navigateur. Les différences essentielles entre AA et MPC sont les suivantes :
Ensuite, permettez-moi de vous présenter MPC et ses fonctionnalités uniques.
Les solutions MPC sont largement utilisées dans les connexions sociales actuelles, et de nombreux projets ont lancé des portefeuilles MPC pour fournir une expérience de portefeuille sans chaîne, éliminant ainsi le besoin pour les utilisateurs d'installer des portefeuilles de plugins ou de gérer des clés privées. Dans l'industrie, ces types de portefeuilles gérés sont collectivement appelés Wallet-as-a-Service (WaaS). Les projets matures incluent :
Face à un nombre croissant de services WaaS, il est prévisible qu'il y aura plus de produits offrant WaaS à l'avenir. Cependant, les bourses centralisées ont un volume absolu d'utilisateurs et une vaste expérience commerciale dans ce domaine, il est donc possible que toutes les bourses centralisées fournissent des services connexes à l'avenir.
Le principal inconvénient des comptes détenus traditionnels (EOA) est que les utilisateurs sont responsables de stocker leurs propres clés privées. Cette auto-garde présente les problèmes suivants :
AA (Account Abstraction) est conçu pour permettre aux utilisateurs de configurer des comptes de récupération sociale. Ils peuvent utiliser une ou plusieurs EOA externes pour reprendre le contrôle de leur AA. Le flux commun pour le redressement social est le suivant :
Grâce à ce processus d'appel, même si l'utilisateur perd le contrôle de l'EOA gouvernant l'AA, il peut toujours basculer vers un nouveau EOA. Contrairement à la connexion sociale MPC (Calcul multi-partite), cette récupération sociale est entièrement décentralisée et ne présente pas de point de défaillance unique.
La délégation de gaz est essentielle à l'adoption massive de la blockchain. Pour les nouveaux utilisateurs entrant dans le Web3, le plus grand point douloureux est de préfinancer les frais de gaz. En utilisant le Paymaster de AA pour déléguer le gaz, les nouveaux utilisateurs peuvent être subventionnés, réduisant ainsi la barrière à l'entrée des applications Web3.
Un autre problème central affectant l'adoption massive de Web3 est la compatibilité inter-chaînes. Paymaster, grâce à l'intégration de protocoles inter-chaînes comme Layer0/Warmhole, permet aux utilisateurs de déposer sur la Chaîne A (par exemple, Ethereum) et d'utiliser sans problème des applications sur une autre Chaîne B (par exemple, Matic ou BSC), faisant ainsi disparaître les frontières entre les chaînes et aidant les nouveaux Dapps à gagner des utilisateurs d'autres chaînes.
Bien que nous ayons discuté des avantages de AA, la norme ERC-4337 évolue encore rapidement pour remédier à ses inconvénients actuels :
Contrairement à EOA, une fois qu'un EOA est créé, il peut être utilisé sur n'importe quelle chaîne compatible avec l'EVM, car la même paire de clés publique-privée peut être utilisée pour interagir sur différentes chaînes. Cependant, en raison de la nature de AA en tant que Compte de Contrat (CA), un nouveau contrat AA doit être déployé séparément sur chaque chaîne ou Layer2. Le coût élevé du déploiement des contrats AA pourrait dissuader les utilisateurs d'adopter des AA.
De plus, si les utilisateurs déploient de manière incorrecte, par exemple en utilisant différents Factories pour déployer des comptes de contrat AA, ils peuvent se retrouver avec des adresses AA différentes sur différentes chaînes, ce qui peut causer une confusion et une difficulté significatives dans l'utilisation et la compréhension. Bien que les Factories de portefeuilles AA actuelles aient réussi à générer la même adresse AA sur différentes chaînes, les utilisateurs doivent toujours faire preuve de prudence en vérifiant les protocoles qu'ils utilisent pour s'assurer que leurs adresses AA restent cohérentes sur différentes chaînes, évitant ainsi tout problème ou confusion futurs.
Comme mentionné, les comptes AA exigent que les utilisateurs déploient les contrats AA générés par Wallet Factory sur différentes chaînes et Layer2 séparément. Même avec les sidechains actuels, les chaînes compatibles EVM et les frais de gaz plus bas de Layer2, c'est encore une dépense importante. Avec les frais de gaz actuels et le prix de l'ETH à 1800 $, le déploiement d'un compte AA sur le mainnet ETH coûterait environ 20 à 40 dollars, tandis que sur les chaînes compatibles EVM ou Layer2, cela varierait de 0,5 à 5 dollars. Pour la plupart des utilisateurs, il est difficile d'accepter le coût de déploiement avant même d'utiliser l'application. En supposant que ce coût soit subventionné par un Bundler ou un Paymaster, le coût de la subvention est encore trop élevé et nécessite un incitatif fort.
En fonction de la mise en œuvre de AA et du nombre de transactions regroupées dans une seule transaction de Bundler (plus il y a de transactions, plus le coût en gaz par UserOP est faible), la consommation de gaz des transactions standard ERC-4337 actuelles peut être plusieurs fois plus élevée que celle des comptes EOA réguliers. En effet, une transaction initiée par un compte AA nécessite souvent l'appel de 3 contrats ou plus et implique des calculs complexes tels que la vérification de signature BLS on-chain. La norme ERC-4337 actuelle est également en cours d'optimisation à cet égard, avec la feuille de route suivante :
Nous venons de mentionner le coût relativement élevé de l'utilisation de la norme ERC-4337. Quels sont les coûts spécifiques ? Tout d'abord, permettez-nous de présenter un concept, qui est la formule de calcul des frais de gaz :
frais = gaz × prix
Alors, quels sont les coûts de déploiement et d'utilisation de l'ERC-4337 ? L'équipe StackUp a fourni des estimations précises dans leur blog.
https://www.stackup.sh/blog/how-much-more-expensive-is-erc-4337
Table 1. Gaz pour les transactions ERC-4337
Le tableau ci-dessus montre:
Table 2. Estimations des frais de gaz pour les transactions ERC-4337
Cette table fournit des estimations de coûts pour diverses opérations sur le compte AA ERC-4337 en utilisant les prix actuels du gaz. Nous pouvons observer ce qui suit :
En résumé, en raison du coût élevé de la création de comptes AA ERC-4337 sur le mainnet, une adoption généralisée est susceptible de se produire d'abord sur les chaînes Layer2 et compatibles EVM.
Un autre obstacle au développement de AA est la compatibilité de l'infrastructure avec les contrats AA. La plupart des Dapps en dehors de la chaîne AA native ne prennent en charge que les comptes EOA. Le support pour AA nécessite que les Dapps utilisent le SDK de AA pour les transactions et modifient les paramètres de requête pour les informations utilisateur.
De plus, les navigateurs de chaînes de blocs tels que Etherscan sont principalement conçus pour les EOAs. Pour améliorer la commodité de la consultation des comptes AA, ces navigateurs peuvent nécessiter une série d'optimisations de l'interface utilisateur et de l'expérience utilisateur.
Sauf Ethereum, la plupart des nouvelles blockchains publiques ont déjà mis en place des comptes AA natifs.
Les AA natifs sont mis en œuvre au niveau du consensus de la chaîne, ce qui signifie qu'ils ne nécessitent pas de développeurs communautaires pour le déploiement. Il s'agit généralement de contrats internes ou système développés et maintenus par les développeurs de la blockchain.
Coûts de déploiement inférieurs et frais de gaz supplémentaires
Les contrats internes ont souvent des autorisations et des priorités plus élevées, et leurs calculs de gaz sont différents de ceux des contrats externes. Par conséquent, les AA natifs ont des coûts de déploiement plus bas et n'ajoutent généralement pas de surcharge de gaz significative.
La mise à niveau des AA natifs nécessite que les développeurs de la chaîne publique soient responsables, nécessitant souvent des forks souples ou durs. Cela les rend moins flexibles que l'ERC-4337 modulaire, limitant le rythme de l'itération et de la publication de nouvelles fonctionnalités.
Les chaînes avec des AA natifs étudient activement l'extensibilité et la modularité de l'ERC-4337, permettant ainsi de construire plus de fonctionnalités sur les AA natifs.
Near implémente des AAs natifs au niveau du consensus avec des comptes stockés directement dans la blockchain. Il prend en charge plusieurs clés d'accès et la récupération sociale (e-mail, numéro de téléphone). L'image suivante illustre les différences entre un compte ETH et un compte Near.
En raison du modèle de propriété des ressources dans Aptos et Sui, à la fois Aptos et Sui ont mis en œuvre un AA natif au niveau du consensus. En prenant Aptos comme exemple, un compte Aptos est un ensemble de ressources sur la blockchain, donc lors de la création d'un compte Aptos, il est nécessaire de prépayer des Aptos pour compléter l'initialisation du compte. Les comptes Aptos/Sui prennent également en charge le changement de la clé d'authentification, mais l'adresse du compte reste la même, parmi d'autres fonctionnalités AA.
Contrairement à Near/Aptos/Sui/Starknet, ZKsync prend en charge à la couche de consensus à la fois EOA et AA. Par conséquent, ZKsync peut initier des transactions à la fois avec EOA et AA, ce qui lui permet d'être utilisé avec des portefeuilles populaires comme Metamask et Argent. La conception AA de ZKSync est basée sur ERC-4337, ce qui le rend compatible avec les portefeuilles et Dapps prenant en charge l'EIP-4337. Actuellement, le coût en gaz supplémentaire pour les transactions AA dans ZKsync est d'environ execution_gas + 20000, soit environ 0.01USD au moment de la rédaction. Il s'agit d'un coût modeste par rapport aux transactions AA ERC-4337 non natives.
Starknet prend en charge nativement AA et ne prend pas en charge les transactions initiées par EOA. Les comptes AA dans Starknet sont conçus sur la base de ERC-4337. Actuellement, les contrats AA dans Starknet sont fournis par OpenZeppelin et développés en utilisant Cairo.
Les comptes AA natifs dans ICP sont appelés Identité Internet (II pour faire court). La mise en œuvre de II est différente de ERC-4337. II utilise WebAuthn, couramment utilisé dans les frameworks Web2, permettant aux utilisateurs de contrôler leurs comptes en utilisant les puces de sécurité intégrées à leurs smartphones. Les utilisateurs peuvent librement ajouter et supprimer des appareils. En essence, II transforme les appareils smartphones de l'utilisateur en portefeuilles matériels.
Le Bundler remplace le Mempool node précédent dans l'écosystème AA. Les UserOps ne sont plus envoyés aux Validators mais aux Bundlers pour l'emballage et le traitement on-chain. Les bundlers principaux sont les suivants:
Le bundler de Stackup est implémenté en Go lang et vise à s'intégrer parfaitement à Go Ethereum (geth). C'est le premier bundler de norme de production de cette liste qui est entièrement conforme à l'ERC-4337. Stackup est activement maintenu et dispose d'une documentation complète, ce qui en fait le bundler le plus populaire actuellement. Stackup fournit des services de bundler, éliminant ainsi le besoin pour les équipes de mettre en place leur propre service de bundler.
Le bundler d’Infinitism est développé en TypeScript et a été développé par l’auteur original de l’ERC-4337. Infinitism développe également des contrats ERC-4337, ce qui rend son bundler hautement compatible avec ERC-4337. Cependant, une vérification supplémentaire est nécessaire pour les performances et la stabilité car il est développé en TypeScript.
Skandha est un bundler basé sur TypeScript développé par Etherspot. Etherspot est actif dans l'implémentation du mempool du bundler. Skandha a réussi tous les tests en avril 2023.
Voltaire est un protocole de bundler développé par l'équipe de Candide pour prendre en charge leur propre portefeuille Candide. Voltaire est une implémentation basée sur Python de l'ERC-4337. Voltaire fournit actuellement un bon support pour le portefeuille open-source de Candide.
Rundler est un protocole Bundler développé par Alchemy, le plus grand fournisseur de services de noeuds pour Ethereum. Actuellement, Rundler n'est pas open source, mais en raison de la grande base d'utilisateurs d'Alchemy, il pourrait bénéficier d'un important soutien de trafic.
Bundler est actuellement dans une phase de développement et d'itération rapides.
Le point douloureux actuel que le bundler doit aborder est la cohérence et les problèmes de communication de la mempool du bundler. En supposant qu'il existe plusieurs protocoles de bundler sur le marché et qu'il y a un manque de communication entre eux, cela peut entraîner un grave problème d'attaques DDoS sur le bundler. Si un utilisateur envoie simultanément des transactions à plusieurs bundlers sans communication entre eux, ces bundlers emballeront et enverront simultanément des UserOps au validateur. Cependant, seul le UserOp du premier bundler sera exécuté, et les transactions des bundlers restants seront rejetées en raison du même nonce. Dans ce cas, si le paymaster de l'utilisateur a un solde insuffisant, les bundlers paieront des frais de gaz invalides pour ces UserOps. Ainsi, actuellement, la communication entre les bundlers est un problème qui doit être résolu afin de prévenir les attaques de spam UserOp sur les bundlers.
Les emballeurs actuels sont très centralisés. Si les emballeurs mettent certains utilisateurs sur liste noire, cela entraînerait l'impossibilité d'exécuter leurs transactions. Cela va à l'encontre de la nature décentralisée et sans permission de la blockchain.
Le Paymaster est une partie importante de AA, car il peut subventionner les frais de gaz des utilisateurs et réduire considérablement la barrière à l'entrée pour Web3. Voici quelques implémentations populaires du paymaster:
stackups paymaster
Le paymaster de Stackups fait partie de l'écosystème Stackups AA. Stackups a mis en place un tableau de bord du paymaster où les DApps ou autres fournisseurs de services peuvent configurer leurs propres comptes de subventionnement.https://app.stackup.sh/sign-inpour parrainer les transactions des utilisateurs.
Tableau de bord Biconomy
Le tableau de bord Biconomy permet aux organisations et aux développeurs d'utiliser les composants AA dans leurs projets. Les propriétaires de projets peuvent configurer leurs projets pour payer les frais de gaz des utilisateurs via des paymasters et ajouter des conditions de parrainage de gaz. En enregistrant votre paymaster pour toute chaîne prise en charge, les DApps peuvent grandement simplifier l'expérience Web3 pour les utilisateurs.
Les comptes EOA traditionnels ont souvent du mal à atteindre simultanément la décentralisation, la convivialité et la sécurité.
Dans le cadre traditionnel de l'EOA, les utilisateurs ont souvent besoin d'acquérir des jetons de blockchain comme l'ETH à travers des monnaies fiduciaires pour utiliser des applications Web3. Cela implique généralement d'utiliser des échanges centralisés (CEX) pour déposer des devises fiduciaires, les échanger contre le jeton requis, et finalement le transférer vers un compte EOA nouvellement créé. Ce processus nécessite une compréhension significative de Web3 et est fastidieux dans de nombreuses régions. En introduisant des paymasters dans AA, les coûts initiaux d'intégration pour les utilisateurs peuvent être délégués aux propriétaires de projets de DApps. Le transfert des frais de gaz a des implications significatives pour l'adoption massive de Web3.
Actuellement, l'ERC-4337 en est à ses débuts et de nombreux outils sont en cours de développement sur cette base. Du côté du payeur, l'UserOp de l'utilisateur peut être vérifié pour éviter les problèmes, tels que des approbations excessives ou des transferts de fonds non autorisés. L'audit de sécurité du payeur peut être effectué en utilisant des méthodes bien établies dans le secteur financier web2 pour examiner les transactions problématiques et garantir la sécurité des fonds des utilisateurs.
Une autre innovation en cours de développement est l'isolement sécuritaire des comptes, tels que la séparation du compte de fonds du compte de jeu, etc. Lorsque les utilisateurs utilisent des fonctions DeFi familières et de transfert, le compte de fonds avec un audit de sécurité plus strict est utilisé. Lorsque les utilisateurs essaient GameFi ou DeFi peu familiers, le compte de jeu est utilisé. De cette manière, sans augmenter les clés privées que les utilisateurs doivent gérer, la conception d'isolement sécuritaire des comptes assure la sécurité des fonds des utilisateurs au niveau sous-jacent.
Actuellement, de nombreux appareils tels que les smartphones et les ordinateurs portables disposent de puces sécurisées intégrées, telles que la puce de sécurité Apple T2 utilisée dans Mac et iPhone. Par conséquent, fondamentalement, chaque appareil avec une puce Tee est un portefeuille matériel fiable. Cependant, ces puces sécurisées ne prennent actuellement pas en charge les algorithmes de signature de chaîne de blocs courants tels que ECDSA.
La sécurité actuelle des clés privées EOA dans les plugins / portefeuilles mobiles est directement stockée en texte clair sur l'appareil. Si l'appareil est compromis, les actifs de l'utilisateur peuvent être rapidement perdus. Par conséquent, les portefeuilles d'extension de navigateur comme Metamask ont une haute convivialité mais une faible sécurité.
Portefeuilles matériels
Les portefeuilles matériels garantissent que les clés privées ne quittent jamais l'appareil et ne peuvent pas être directement accessibles par des tiers. Cependant, la plupart des utilisateurs ne peuvent pas transporter leurs portefeuilles matériels avec eux en permanence, ce qui se traduit par une sécurité élevée mais une faible utilisabilité.
En utilisant le portefeuille AA et la méthode innovante de vérification on-chain, les transactions peuvent être directement signées par la puce sécurisée de l’appareil, garantissant ainsi que la clé privée de l’utilisateur ne quitte jamais l’appareil. Cela offre une plus grande sécurité par rapport aux comptes EOA traditionnels. À l’heure actuelle, Internet Identity de l’Internet Computer et un projet appelé Porton Wallet dans le cadre de l’ETHBogota Hackathon ont mis en œuvre une solution qui utilise la signature par puce sécurisée et la clé de session, permettant aux utilisateurs d’utiliser pleinement la sécurité de leurs appareils tels que les smartphones ou les ordinateurs, équivalente à un portefeuille matériel.
Grâce à la conception hautement modulaire de l'ERC-4337, grâce à son expansion et à son itération, les comptes AA bénéficieront d'une sécurité considérablement améliorée.
Actuellement, un autre obstacle à l’adoption massive du Web3 est la fragmentation des écosystèmes blockchain entre différentes chaînes.
À titre d'exemple simple, considérons un utilisateur sur Ethereum (ETH) qui souhaite découvrir une application sur Binance Smart Chain (BSC). Que devrait faire cet utilisateur ? Tout d'abord, l'utilisateur doit échanger ses ETH contre les USDT/USDC correspondants, puis utiliser un pont inter-chaînes pour transférer ces jetons d'ETH à BSC. Ensuite, l'utilisateur doit acheter des BNB sur une bourse centralisée (CEX) et les transférer à BSC. Seulement alors l'utilisateur pourra commencer à découvrir diverses applications DeFi sur BSC. Tout ce processus est chronophage, peu sécurisé et nécessite une courbe d'apprentissage raide, en particulier pour les nouveaux utilisateurs qui pourraient ne pas être familiers avec les ponts inter-chaînes.
À travers les protocoles inter-chaînes couramment utilisés, tels que Layer0 + AA, le processus d'utilisation de DApp sur différentes chaînes peut être grandement simplifié. Le maître de paiement peut intégrer pleinement les protocoles inter-chaînes pour réaliser le concept de "payer une seule fois, payer partout". Par exemple, si un utilisateur recharge des USDC sur le maître de paiement d'ETH, tant que le compte AA de l'utilisateur sur différentes chaînes est le même et est lié au même maître de paiement, le maître de paiement peut gérer la comptabilité au nom de l'utilisateur. L'utilisateur n'a pas besoin de transférer manuellement des actifs vers une chaîne/Layer2 compatible avec EVM avec la même adresse de compte.
Le plus grand avantage de l'introduction du paymaster est qu'il établit de manière programmatique des conditions pour subventionner les utilisateurs de Dapp.
Dans le passé, il y a eu des cas où des projets de l'écosystème Web3 ont subventionné le gaz pour attirer des clients. Cependant, subventionner les comptes EOA sans définir de manière programmée des conditions a souvent conduit à une mauvaise utilisation des fonds de subvention par des robots et des fraudeurs, tels que le transfert direct des fonds de subvention, sans attirer de véritables clients.
Actuellement, les tableaux de bord du paymaster incluent généralement la fonctionnalité de subventionner les frais de gaz pour les Dapps. Les développeurs de projets peuvent facilement définir les conditions de subvention dans le tableau de bord, de sorte que seules les transactions répondant à des conditions spécifiques sont éligibles à la subvention. En contrôlant les conditions de transaction dans les subventions via le paymaster, les Dapps peuvent attirer plus d'utilisateurs authentiques tout en maîtrisant les coûts.
Sous EOA, en raison de la domination de Metamask, les Dapps actuels sont principalement accessibles via des interfaces web, ce qui se traduit par une plus grande part de marché pour les portefeuilles de plugins web. Cependant, l'adoption massive du web3 repose sur la participation des utilisateurs mobiles, ce qui rend le développement et l'adaptation de AA plus Mobile Native.
Avec la popularité croissante de Dark Forest, la tendance des jeux entièrement sur la chaîne émerge tranquillement. Cependant, l’expérience utilisateur de l’utilisation des EOA (comptes externes) dans les jeux est très médiocre. Imaginez que vous deviez utiliser un portefeuille pour autoriser ou signer des transactions chaque fois que vous effectuez une action dans un jeu. Cette interruption constante empêche les joueurs de se concentrer pleinement sur le jeu lui-même. Pour résoudre ce problème, les comptes d’arcade, qui sont des versions spécialisées des AA ordinaires, ont été développés spécifiquement pour les jeux entièrement sur la chaîne. Ces comptes autorisent des opérations de jeu spécifiques, ce qui permet aux joueurs de participer à des jeux complets sur la chaîne sans avoir besoin d’autorisations répétitives et de signatures de transactions. En conséquence, l’expérience de jeu est grandement améliorée. L’essor des jeux entièrement on-chain à l’avenir est susceptible de favoriser l’adoption généralisée des comptes AA.
Récemment, le concept de transactions basées sur l'intention a gagné en popularité avec l'essor d'Unibot, et Uniswap a également lancé le projet Uniswap X pour promouvoir la mise en œuvre de transactions basées sur l'intention. L'exemple suivant peut expliquer ce que sont les transactions basées sur l'intention :
Si quelqu'un est prêt à exécuter l'intention, la contrepartie initie une autre intention de transférer 1000 USDT à Alice et de recevoir 1 ETH.
La transaction est réussie.
Les transactions basées sur l'intention offrent les avantages suivants :
Actuellement, CowSwap a mis en œuvre des transactions basées sur l'intention basée sur EOA. Cependant, les transactions basées sur l'intention basée sur EOA nécessitent toujours que les utilisateurs autorisent (ERC-20, Approve) avant d'initier la transaction. Cependant, sous la nouvelle architecture de compte de AA, les utilisateurs peuvent envoyer Approve et Intention ensemble au regroupeur. Le regroupeur de AA peut accéder simultanément au sondage des intentions, faire correspondre les intentions et fournir une expérience de trading plus pratique.