Qu'il s'agisse d'un marché haussier ou d'un marché baissier, l'écosystème Ethereum se construit et s'auto-optimise constamment. Parmi eux, Account Abstraction (AA) a fait des progrès importants ces dernières années et a pénétré dans toutes les parties de l'écosystème Ethereum, y compris les applications, l'infrastructure, les utilisateurs et les développeurs. Nous pouvons prévoir que l'adoption à grande échelle des AA abaissera le seuil d'utilisation de la blockchain dans son ensemble et introduira l'expérience utilisateur du web2 dans l'industrie du web3.
Pour saisir l'opportunité du marché AA potentiellement de plusieurs milliards de dollars, BlockPI prévoit d'intégrer AA dans ses services d'infrastructure. Grâce à l'intégration et à l'innovation dans le domaine AA, BlockPI s'engage à fournir aux utilisateurs AA un moyen plus pratique et efficace d'interagir avec les comptes de portefeuille de contrats blockchain, et espère devenir un leader dans ce secteur.
Dans cet article, l'équipe BlockPI approfondira sa compréhension des AA et partagera ses réflexions du point de vue d'un fournisseur de services d'infrastructure.
EOA et portefeuille de contrats
Le concept d'AA découle des limites des comptes EOA. Un compte EOA (compte externe) est un compte utilisateur dans Ethereum, représenté par une clé publique (adresse de la blockchain) et accessible via une clé privée. C'est un composant majeur de l'écosystème Ethereum, permettant aux utilisateurs de transférer de l'argent sur la blockchain ou d'interagir avec des contrats intelligents. Cependant, pour de nombreuses personnes, l'utilisation d'un EOA peut être une tâche difficile en soi. De plus, le compte EOA actuel présente encore quelques désagréments d'utilisation, ce qui nuit à l'expérience utilisateur.
Le premier est la question des frais d'essence. Chaque transaction coûtera à l'utilisateur une quantité considérable d'ETH en tant que frais de gaz (prenez l'exemple du prix du gaz de 25 Gwei, les frais de gaz pour un simple transfert ETH sont d'environ 0,5 dollar américain, et il sera plus cher pour l'interaction contractuelle ou lorsque le prix du gaz est plus élevé) . Cela rend les petites transactions très coûteuses, en particulier pendant les périodes de forte congestion du réseau. De plus, seul l'ETH peut être utilisé pour payer le gaz, ce qui signifie que les utilisateurs doivent détenir l'ETH dans leur portefeuille, ce qui constitue une barrière élevée à l'entrée pour de nombreux utilisateurs.
Deuxièmement, pour certaines opérations complexes que les utilisateurs souhaitent réaliser, EOA doit s'appuyer sur d'autres contrats intelligents. Par exemple, si un utilisateur souhaite définir un transfert périodique chronométré, l'utilisateur doit transférer ETH vers un contrat intelligent avec cette fonction pour réaliser cette opération.
Le troisième problème avec EOA est l'algorithme de chiffrement de signature fixe. Le réseau Ethereum utilise un algorithme de signature numérique appelé secp256k1 pour garantir l'authenticité et la sécurité des transactions. Cet algorithme est codé en dur dans le système et les utilisateurs ne peuvent pas choisir d'utiliser d'autres algorithmes de chiffrement.
En plus des trois problèmes ci-dessus, la relation de liaison entre la clé publique et la clé privée d'EOA est également un problème. La clé privée est le seul moyen pour les utilisateurs d'accéder à EOA, si la clé privée est perdue, elle ne sera pas récupérée. Cela signifie également que tous les actifs de l'EOA qui lui sont associés seront irrécupérables.
Dans le même temps, EOA a également des limites lors de l'exécution de certaines tâches linéaires. Par exemple, si un utilisateur souhaite approuver (approuver), échanger (échanger) et désapprouver des jetons (jeton non approuvé) en une seule opération, trois transactions distinctes doivent être effectuées, ce qui est inefficace et prend du temps.
La bonne nouvelle est que les portefeuilles contractuels peuvent résoudre tous les problèmes ci-dessus. Un portefeuille de contrat est essentiellement un type spécifique de compte de contrat intelligent qui implémente AA, qui peut être utilisé comme portefeuille d'utilisateur sur Ethereum. Et il peut fournir aux utilisateurs un moyen plus flexible et personnalisé de gérer les fonds. Tant que c'est la logique qui peut être réalisée par le contrat intelligent Ethereum, le portefeuille de contrats peut réaliser et fournir les fonctions correspondantes.
Plus précisément, plusieurs opérations de portefeuille de contrats peuvent être regroupées dans une transaction en chaîne, et ces opérations peuvent partager le coût du gaz de cette transaction. Si le tiers est prêt à payer les frais de gaz, il n'est pas nécessaire de payer le gaz pour les utilisateurs utilisant le portefeuille contractuel. Les portefeuilles contractuels peuvent également effectuer plusieurs tâches linéaires à la fois. En outre, le portefeuille contractuel prend également en charge l'algorithme de cryptage des signatures personnalisées et définit la fonction de récupération du portefeuille, etc.
Alors que la discussion sur les avantages des portefeuilles contractuels se poursuit, la communauté Ethereum a en fait mené des recherches à long terme sur les portefeuilles contractuels. Bien que de nombreux EIP aient exploré les problèmes liés à l'abstraction des comptes, à partir de 2021, aucune norme unifiée n'a été établie. Vous trouverez ci-dessous plusieurs EIP représentatifs.
EIP-86
Initialement proposé en 2017 par Vitalik Buterin. Ce schéma implémente une série de modifications dans le but commun de "résumer" la vérification de signature et la vérification nonce, permettant ainsi aux utilisateurs de créer des "contrats de compte" qui peuvent effectuer une vérification arbitraire de signature/nonce.
EIP-2938
Présenté en 2020. Le titre de cet EIP est Account Abstraction. Le concept d'AA est bien décrit dans cet EIP. Il introduit un nouveau type de transaction, la transaction AA. La transaction est initiée par l'adresse du point d'entrée (adresse EntryPoint) et appelle le portefeuille de contrats AA. EIP-2938 fournit une spécification unifiée et introduit officiellement l'abstraction du compte AA dans le consensus Ethereum. Plus précisément, il introduit deux nouveaux opcodes, trois variables globales et une structure de charge utile différente du consensus Ethereum.
EIP-3074
Présenté en 2020. Cet EIP introduit deux instructions EVM, AUTH et AUTHCALL. AUTH définit les variables d'environnement en fonction de l'autorité de signature ECDSA. AUTHCALL envoie l'appel en tant que compte autorisé. Cela permet aux contrats intelligents d'envoyer des transactions au nom d'EOA. Mais ce n'est toujours pas une solution parfaite pour les AA. Dans le processus de transaction d'autorisation, EIP-3074 a certaines restrictions sur la transmission de la valeur d'origine. Et si l'utilisateur perd l'accès à l'EOA, il n'y a toujours aucun moyen de récupérer ses actifs. Si la clé privée est divulguée, l'utilisateur doit transférer tous les actifs vers le nouveau compte.
Aucune des propositions ci-dessus n'a été officiellement intégrée au protocole Ethereum en raison de la nécessité de modifications au niveau du consensus ou parce que les propositions n'étaient pas suffisamment complètes. Par conséquent, la communauté Ethereum a continué à explorer comment introduire AA dans le protocole Ethereum sans changer le consensus, et a finalement proposé EIP4337.
ERC - 4337
L'EIP-4337 a été initialement proposé en septembre 2021 et autorisé sous le nom d'ERC-4337 en mars 2023. Ses auteurs incluent Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh, Shahaf Nacson et Tjaden Hess.
EIP-4337 est une proposition perturbatrice qui introduirait AA sans changer le protocole Ethereum de base. EIP-4337 est finalement devenu la norme ERC-4337, que les constructeurs peuvent utiliser pour mettre en œuvre leurs propres portefeuilles de contrats intelligents. Dans le même temps, la norme introduit également une infrastructure supplémentaire, notamment des "Bundlers" et "UserOperation mempool". De cette façon, il réplique en fait un mempool Ethereum avec des fonctions similaires sur la couche supérieure du système blockchain. Ce que l'utilisateur soumet n'est plus une transaction unique, mais une UserOperation. Ces UserOperations peuvent être regroupées en une seule transaction et envoyées à Ethereum.
Ce qui suit est une explication technique détaillée de ERC-4337 dans Ethereum [documentation officielle], avec quelques commentaires utiles.
Rôles clés de l'ERC-4337 et leurs définitions
UserOperation : décrit la structure d'une transaction envoyée au nom d'un utilisateur. Pour éviter toute confusion, il n'est pas nommé "transaction" et il sera envoyé au Bundler pour être emballé avec d'autres UserOperations en tant que Bundle. Le Bundle est ensuite envoyé en chaîne en une seule transaction.
Sender : le compte de contrat qui envoie UserOperation. Le contrat de portefeuille doit suivre la norme ERC-4337 pour configurer l'interface IAccount.
EntryPoint - le contrat singleton global qui exécute le bundle UserOperations. Bundlers/Clients whitelist pris en charge EntryPoints. Le contrat est audité et approuvé pour le déploiement par l'équipe Infinitism, et est responsable de la gestion de toutes les opérations utilisateur et de la connexion des contrats avec d'autres rôles, y compris Wallet Factory, Aggregator et Paymaster. Le contrat est tous à la même adresse sur la chaîne compatible EVM.
Bundler : le nœud qui regroupe plusieurs UserOperations à partir du mempool et crée la transaction EntryPoint.handleOps() (le nœud producteur de bloc actuel). Le service Bundler peut s'exécuter indépendamment des nœuds de la blockchain et envoyer des UserOperations packagées via RPC.
Agrégateur : un contrat auxiliaire auquel les comptes font confiance pour vérifier les signatures agrégées. Bundlers/Clients liste blanche des agrégateurs de signatures pris en charge. Les agrégateurs doivent configurer l'interface IAggregator conformément à la norme ERC-4337.
Paymaster : un contrat intelligent qui peut payer l'essence en votre nom. S'il dépose suffisamment d'ETH dans le contrat EntryPoint, il peut payer à l'expéditeur le contrat intelligent pour les frais de gaz de UserOperation, mettant ainsi en œuvre efficacement l'abstraction de gaz. Paymaster doit suivre la norme ERC-4337 pour configurer l'interface Paymaster. Paymaster peut conclure un accord avec l'expéditeur. Par exemple, Sender paie USDC à Paymaster, et Paymaster utilise ETH pour payer le Gas des UserOperations qu'il envoie. En fait, Paymaster peut choisir de prendre en charge n'importe quel
Jeton
, y compris ERC-20
Jeton
même d'autres chaînes
Jeton
。
Wallet Factory — un contrat intelligent qui peut créer des portefeuilles de contrats pour les utilisateurs de l'ERC-4337. Le déploiement de Wallet Factory est sans licence. En tant que contrat intelligent en chaîne, son code est ouvert au public et tout le monde peut le consulter. Une usine de portefeuille largement utilisée doit être entièrement auditée par des professionnels.
Le schéma ci-dessous explique comment le contrat EntryPoint interagit avec les autres acteurs.
Les bundlers appellent la fonction handleOps du contrat EntryPoint, qui accepte une UserOperation en entrée.
handleOps vérifiera UserOperation sur la chaîne, vérifiera s'il est signé par l'adresse de portefeuille de contrat intelligent spécifiée et confirmera si le portefeuille a suffisamment de gaz pour compenser Bundler.
Si la vérification est réussie, handleOps exécutera la fonction de portefeuille de contrat intelligent en fonction de la fonction et des paramètres d'entrée définis dans les calldata de UserOperation.
D'autre part, lorsque Bundler utilise EOA pour déclencher la fonction handleOps, des frais de gaz seront facturés. Le portefeuille de contrats intelligents peut payer les frais de Bundlers Gas à partir de son propre solde de compte ou demander au contrat Paymaster de les payer. UserOperations ne peut pas réussir l'étape de vérification hors chaîne sans suffisamment de gaz, c'est-à-dire qu'il échoue avant d'exécuter la transaction sur la chaîne. Même s'il y a suffisamment de gaz, UserOperations peut toujours échouer en raison d'erreurs d'exécution et d'autres raisons lors de l'exécution. Pour une UserOperation, que l'exécution du contrat soit réussie ou non, le contrat EntryPoint paiera les frais de gaz au Bundler qui déclenche la fonction handleOps.
Après l'entrée en vigueur de l'ERC-4337, les utilisateurs peuvent désormais initier des transactions blockchain de deux manières. L'une est la méthode traditionnelle, c'est-à-dire que l'EOA initie directement la transaction. L'autre consiste à utiliser la norme ERC-4337 pour lancer UserOperation via Bundler, puis Bundler la regroupera avec d'autres UserOperations et l'enverra à la chaîne de réseau. L'organigramme ci-dessous illustre la différence entre une transaction d'envoi EOA normale et un envoi de portefeuille de contrat ERC-4337 UserOperation.
La route a été goudronnée, mais il n'y a pas encore beaucoup de piétons
ERC-4337 fournit un cadre puissant permettant aux utilisateurs et aux développeurs d'utiliser et de créer des AA sur Ethereum. Bien que ce cadre soit une avancée importante, il reste encore des défis et des incertitudes qui doivent être abordés et résolus.
L'adoption des AA en est encore à ses balbutiements. Selon le panel d'analyse Dune ERC-4337 [ERC-4337 Account Abstraction], seules plus de 65 000 UserOperations ont été exécutées sur la chaîne, dont 90 % provenaient de Polygon. Par conséquent, le nombre d'opérations utilisateur actuellement effectuées est encore très faible, dont la plupart sont des tests de développeur, et seule une petite partie provient d'utilisateurs réels. Nous notons que les produits qui ont intégré AA sont encore à leurs débuts. À l'heure actuelle, nous pouvons observer que les Bundlers dans leur ensemble sont toujours en état de perte, et la perte actuelle est d'environ plus de 700 MATIC. Cela est principalement dû au fait que certains bundlers sur Polygon ont mal estimé le gaz requis, ce qui fait que le gaz renvoyé par EntryPoint est inférieur au gaz consommé par le bundle soumis. Ce problème doit être résolu au niveau du client Bundler.
Au-delà de cela, il y a quelques problèmes qui doivent être résolus. L'un de ces problèmes est la façon dont les bundlers gèrent les échecs de transaction.
Après avoir regroupé plusieurs UserOperations, les bundlers simuleront d'abord la transaction, détecteront s'il y aura un échec d'exécution du contrat et calculeront si les frais de gaz retournés par l'expéditeur ou le payeur sont supérieurs aux frais de gaz payés.
S'il est rentable, Bundler soumet ce lot d'opérations utilisateur au nœud de bloc en tant que transaction. Cependant, il est toujours possible que la transaction échoue, ce qui fait que le Bundler paie les frais de gaz mais ne reçoit pas le remboursement de gaz du point d'entrée. Par exemple, un utilisateur peut envoyer des actions à différents Bundlers. S'il y a de la place pour le profit et que la simulation est réussie, les Bundlers l'engagent dans la chaîne. Dans ce cas, si une UserOperation est soumise au nœud de bloc par différents Bundlers en même temps, une seule transaction réussira, ce qui signifie qu'un seul Bundler recevra les frais de gaz retournés par l'EntryPoint, et tous les autres Bundlers échoueront en raison à enchaîner et à perdre du gaz. Bien que l'on puisse affirmer que ce comportement doit être considéré comme une attaque malveillante et affirmer que Bundler peut interdire l'adresse de l'expéditeur et rejeter toutes les demandes futures de cette adresse, ce n'est pas une solution raisonnable car les utilisateurs peuvent prendre cette action involontairement. Ce problème doit être correctement traité dans le code, peut-être via un réseau mempool public en cours de développement. En outre, les bundlers peuvent subir des pertes dues à des fluctuations soudaines du gaz, même si la transaction est soumise avec succès et que les résultats de la simulation montrent qu'il y a place pour le profit.
Un autre problème est la valeur extractible maximale (MEV) qui peut être obtenue à partir de l'AA. Dans le contexte d'Ethereum, MEV fait généralement référence à la valeur que les mineurs ou d'autres processeurs de transactions extraient en manipulant l'ordre des transactions dans un bloc ou en insérant leurs propres transactions dans un bloc. On peut remarquer que la logique de MEV peut également être appliquée à AA. En effet, dans AA, les bundlers peuvent commander librement UserOps, ce qui leur donne la possibilité d'acquérir MEV. Cependant, si Bundler peut extraire MEV dépend si suffisamment d'opérations utilisateur peuvent être regroupées. Maintenant, l'ensemble du marché AA en est encore à ses balbutiements, donc Bundler MEV peut également être considéré à ses balbutiements. On peut voir que le MEV d'AA peut se développer dans deux directions : l'une est similaire au réseau principal Ethereum, avec la participation de participants tels que Flashbots, Ultra Sound et BloXroute ; l'autre direction est de former un consensus Bundler pour mettre en œuvre un tri équitable. Ce dernier éliminerait complètement la possibilité d'extraire des MEV en AA.
développement futur
pool de mémoire public
Bien que l'écosystème AA soit déjà opérationnel, il reste encore beaucoup de travail de développement à faire. En regardant l'ensemble de l'écosystème AA, la plus grande pièce manquante à l'heure actuelle est le mempool public. L'équipe Etherspot, développeurs du client Skandha Bundler, développe actuellement un réseau p2p avec un mempool public. Un réseau p2p de mempools publics devrait être lancé en août de cette année.
Algorithme de bundle
En cours de route, la Fondation Ethereum a financé plusieurs équipes de développement AA exceptionnelles. Jusqu'à présent, plusieurs clients Bundler ont été développés et sont actuellement disponibles. Parmi eux, certains sont très matures. Ce sont Candide (Voltaire Bundler écrit en Python), Pimlico (Alto Bundler écrit en Type), Etherspot (Skandha Bundler écrit en Type), Stackup (Stackup-Bundler écrit en Go), etc.
Voici la question de la stratégie d'emballage. Actuellement, en raison du petit nombre d'opérations utilisateur, les bundlers peuvent adopter une logique de conditionnement simple, telle que des intervalles de temps fixes ou un certain nombre d'opérations utilisateur dans chaque bundle. Cependant, à mesure que le nombre d'UserOperations augmente, en particulier après l'introduction du mempool public, la stratégie de sélection et de conditionnement des UserOperations devient plus complexe. La raison est simple : dans l'écosystème AA, il n'existe pas de mécanisme similaire au protocole de consensus blockchain, et le groupe Bundler est devenu une forêt noire, chaque Bundler hiérarchise les tâches en fonction de ses propres intérêts et se fait concurrence. Contrairement aux mempools publics, les mempools privés peuvent apparaître plus tôt. Parce que lorsque le package UserOperations à partir du mempool public n'est pas rentable, il est toujours possible de packager UserOperations dans le mempool privé. Dans ce cas, le Bundler est plus compétitif que les autres Bundlers lors de l'emballage.
De plus, avec la vulgarisation progressive du mempool public, les UserOperations qu'il contient ont diverses caractéristiques, telles que différentes attentes de profit de gaz et la complexité d'exécution en chaîne. Les bundlers effectueront des simulations hors chaîne pour évaluer la rentabilité de diverses combinaisons d'UserOperations afin d'établir leurs stratégies de regroupement respectives. Emballer plus d'opérations utilisateur a le potentiel de générer des profits plus élevés, mais cela augmente également le risque d'échecs de validation. Même si la vérification est réussie, le risque d'échec d'exécution sur la chaîne existe toujours. En revanche, UserOperations avec moins d'emballage est le contraire.
Les bundlers doivent définir leurs propres paramètres de gaz de transaction, ce qui affectera la priorité des producteurs de blocs pour exécuter cette transaction. Dans différentes conditions de prix estimés du gaz et de volatilité du gaz, les bundlers peuvent avoir des stratégies de conditionnement différentes. Dans le même temps, il est également nécessaire de prendre en compte le coût des ressources informatiques matérielles locales et des ressources de nœud de chaîne de blocs pour ces calculs de vérification et de politique. En outre, les bundlers doivent également garantir une bonne expérience utilisateur pour les utilisateurs et veiller à ce que les utilisateurs ne soient pas confrontés à des retards excessifs après avoir soumis des opérations utilisateur.
Bien que les solutions à ces défis ne soient pas encore claires, nous pouvons dire avec confiance que le développement de l'industrie AA et les efforts conjoints des développeurs finiront par résoudre ces problèmes. En tant que constructeur d'infrastructures, BlockPI espère jouer le rôle de solutionneur de problèmes dans le développement de l'industrie AA, que ce soit en tant que développeur ou pour fournir une infrastructure compatible AA pour d'autres développeurs.
*L'infrastructure doit s'adapter à l'AA
AA résume les différents rôles impliqués dans les transactions en chaîne, y compris l'expéditeur, les bundlers, les payeurs de gaz, les portefeuilles contractuels et les signataires, afin que les utilisateurs aient un degré de liberté plus élevé lors de l'utilisation de la blockchain. Dans le même temps, les fournisseurs d'infrastructures peuvent déployer ces services de manière indépendante en fonction de leur propre jugement sur le marché.
Afin de s'adapter à l'adoption à grande échelle de l'AA, les fournisseurs d'infrastructure doivent d'abord fournir au moins deux services de base : le service Bundler et le service Paymaster.
Dans le service Bundler, le fournisseur d'infrastructure peut avoir besoin de développer un mempool privé avec les bundlers pour offrir une bonne expérience utilisateur. Plus précisément, les fournisseurs d'infrastructure doivent intégrer divers clients Bundler pour assurer la stabilité des services Bundler. Ces clients Bundler fournissent actuellement aux utilisateurs plusieurs méthodes JSON RPC standard fournies par le groupe de développement principal ERC-4337. Il est prévisible que davantage de méthodes RPC seront disponibles pour les utilisateurs à l'avenir. Les fournisseurs de services d'infrastructure doivent mettre à jour la prise en charge de ces méthodes en temps opportun au cours de ce processus.
En outre, il est important d'optimiser entre l'API Bundler et le RPC client du nœud d'origine. Le client de nœud actuel n'est pas optimisé pour AA. Certaines méthodes de l'API Bundler nécessitent un index par rapport aux données fournies pour l'AA. Par exemple, lorsque le client actuel recherche UserOperation par hachage, il doit analyser les journaux de contrat EntryPoint dans tous les blocs. S'il n'y a pas d'index de données, la consommation de ressources matérielles de cette requête unique sera assez énorme, et le temps de retour de la requête deviendra également très long.
De plus, afin de fournir aux utilisateurs une expérience utilisateur sans gaz et des services diversifiés, les fournisseurs d'infrastructure doivent coopérer avec différents fournisseurs de services Paymaster pour intégrer différents services Paymaster. Dans le même temps, selon la demande du marché, les fournisseurs d'infrastructures peuvent également concevoir des solutions intégrées plus pratiques basées sur les services Paymaster existants. D'autres services, tels que les signatures agrégées, les fabriques de portefeuilles, etc., sont également des orientations potentielles pour le développement futur et l'intégration de l'infrastructure.
En bref, afin de s'adapter à l'application à grande échelle de l'AA, les fournisseurs d'infrastructure doivent continuellement améliorer et étendre leurs services. Cela comprend l'optimisation des services Bundler, la coopération avec différents fournisseurs de services Paymaster, l'intégration de diverses interfaces API et le développement d'autres services potentiels. Alors que l'industrie AA continue de se développer, ces efforts contribueront à fournir une expérience blockchain plus efficace, sécurisée et pratique.
Actuellement, BlockPI travaille dur pour atteindre les objectifs ci-dessus. De plus, nous avons communiqué avec presque tous les clients Bundler et les fournisseurs de services Paymaster de la communauté, et intégrerons AA dans le réseau BlockPI en tant que tâche de développement principale. Dans le même temps, nous avons également mené une communication approfondie avec les développeurs de portefeuilles AA pour comprendre les besoins des utilisateurs. Nous invitons sincèrement tous les bundlers, paymasters et portefeuilles à communiquer et à coopérer avec nous.
L'objectif de BlockPI est de construire et de développer l'écosystème AA avec la communauté, et de faire tout son possible pour promouvoir le progrès et la prospérité de l'écosystème AA. Nous espérons que grâce à la coopération avec la communauté, nous contribuerons à l'ensemble de l'industrie AA en tant que leader de l'industrie et soutiendrons son processus de développement ultérieur, afin que les utilisateurs de Web2 puissent découvrir la technologie blockchain sans barrières.
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Comment l'infrastructure prend-elle en charge des milliards d'utilisateurs via l'abstraction de compte ?
Qu'il s'agisse d'un marché haussier ou d'un marché baissier, l'écosystème Ethereum se construit et s'auto-optimise constamment. Parmi eux, Account Abstraction (AA) a fait des progrès importants ces dernières années et a pénétré dans toutes les parties de l'écosystème Ethereum, y compris les applications, l'infrastructure, les utilisateurs et les développeurs. Nous pouvons prévoir que l'adoption à grande échelle des AA abaissera le seuil d'utilisation de la blockchain dans son ensemble et introduira l'expérience utilisateur du web2 dans l'industrie du web3.
Pour saisir l'opportunité du marché AA potentiellement de plusieurs milliards de dollars, BlockPI prévoit d'intégrer AA dans ses services d'infrastructure. Grâce à l'intégration et à l'innovation dans le domaine AA, BlockPI s'engage à fournir aux utilisateurs AA un moyen plus pratique et efficace d'interagir avec les comptes de portefeuille de contrats blockchain, et espère devenir un leader dans ce secteur.
Dans cet article, l'équipe BlockPI approfondira sa compréhension des AA et partagera ses réflexions du point de vue d'un fournisseur de services d'infrastructure.
EOA et portefeuille de contrats
Le concept d'AA découle des limites des comptes EOA. Un compte EOA (compte externe) est un compte utilisateur dans Ethereum, représenté par une clé publique (adresse de la blockchain) et accessible via une clé privée. C'est un composant majeur de l'écosystème Ethereum, permettant aux utilisateurs de transférer de l'argent sur la blockchain ou d'interagir avec des contrats intelligents. Cependant, pour de nombreuses personnes, l'utilisation d'un EOA peut être une tâche difficile en soi. De plus, le compte EOA actuel présente encore quelques désagréments d'utilisation, ce qui nuit à l'expérience utilisateur.
Le premier est la question des frais d'essence. Chaque transaction coûtera à l'utilisateur une quantité considérable d'ETH en tant que frais de gaz (prenez l'exemple du prix du gaz de 25 Gwei, les frais de gaz pour un simple transfert ETH sont d'environ 0,5 dollar américain, et il sera plus cher pour l'interaction contractuelle ou lorsque le prix du gaz est plus élevé) . Cela rend les petites transactions très coûteuses, en particulier pendant les périodes de forte congestion du réseau. De plus, seul l'ETH peut être utilisé pour payer le gaz, ce qui signifie que les utilisateurs doivent détenir l'ETH dans leur portefeuille, ce qui constitue une barrière élevée à l'entrée pour de nombreux utilisateurs.
Deuxièmement, pour certaines opérations complexes que les utilisateurs souhaitent réaliser, EOA doit s'appuyer sur d'autres contrats intelligents. Par exemple, si un utilisateur souhaite définir un transfert périodique chronométré, l'utilisateur doit transférer ETH vers un contrat intelligent avec cette fonction pour réaliser cette opération.
Le troisième problème avec EOA est l'algorithme de chiffrement de signature fixe. Le réseau Ethereum utilise un algorithme de signature numérique appelé secp256k1 pour garantir l'authenticité et la sécurité des transactions. Cet algorithme est codé en dur dans le système et les utilisateurs ne peuvent pas choisir d'utiliser d'autres algorithmes de chiffrement.
En plus des trois problèmes ci-dessus, la relation de liaison entre la clé publique et la clé privée d'EOA est également un problème. La clé privée est le seul moyen pour les utilisateurs d'accéder à EOA, si la clé privée est perdue, elle ne sera pas récupérée. Cela signifie également que tous les actifs de l'EOA qui lui sont associés seront irrécupérables.
Dans le même temps, EOA a également des limites lors de l'exécution de certaines tâches linéaires. Par exemple, si un utilisateur souhaite approuver (approuver), échanger (échanger) et désapprouver des jetons (jeton non approuvé) en une seule opération, trois transactions distinctes doivent être effectuées, ce qui est inefficace et prend du temps.
La bonne nouvelle est que les portefeuilles contractuels peuvent résoudre tous les problèmes ci-dessus. Un portefeuille de contrat est essentiellement un type spécifique de compte de contrat intelligent qui implémente AA, qui peut être utilisé comme portefeuille d'utilisateur sur Ethereum. Et il peut fournir aux utilisateurs un moyen plus flexible et personnalisé de gérer les fonds. Tant que c'est la logique qui peut être réalisée par le contrat intelligent Ethereum, le portefeuille de contrats peut réaliser et fournir les fonctions correspondantes.
Plus précisément, plusieurs opérations de portefeuille de contrats peuvent être regroupées dans une transaction en chaîne, et ces opérations peuvent partager le coût du gaz de cette transaction. Si le tiers est prêt à payer les frais de gaz, il n'est pas nécessaire de payer le gaz pour les utilisateurs utilisant le portefeuille contractuel. Les portefeuilles contractuels peuvent également effectuer plusieurs tâches linéaires à la fois. En outre, le portefeuille contractuel prend également en charge l'algorithme de cryptage des signatures personnalisées et définit la fonction de récupération du portefeuille, etc.
Alors que la discussion sur les avantages des portefeuilles contractuels se poursuit, la communauté Ethereum a en fait mené des recherches à long terme sur les portefeuilles contractuels. Bien que de nombreux EIP aient exploré les problèmes liés à l'abstraction des comptes, à partir de 2021, aucune norme unifiée n'a été établie. Vous trouverez ci-dessous plusieurs EIP représentatifs.
EIP-86
Initialement proposé en 2017 par Vitalik Buterin. Ce schéma implémente une série de modifications dans le but commun de "résumer" la vérification de signature et la vérification nonce, permettant ainsi aux utilisateurs de créer des "contrats de compte" qui peuvent effectuer une vérification arbitraire de signature/nonce.
EIP-2938
Présenté en 2020. Le titre de cet EIP est Account Abstraction. Le concept d'AA est bien décrit dans cet EIP. Il introduit un nouveau type de transaction, la transaction AA. La transaction est initiée par l'adresse du point d'entrée (adresse EntryPoint) et appelle le portefeuille de contrats AA. EIP-2938 fournit une spécification unifiée et introduit officiellement l'abstraction du compte AA dans le consensus Ethereum. Plus précisément, il introduit deux nouveaux opcodes, trois variables globales et une structure de charge utile différente du consensus Ethereum.
EIP-3074
Présenté en 2020. Cet EIP introduit deux instructions EVM, AUTH et AUTHCALL. AUTH définit les variables d'environnement en fonction de l'autorité de signature ECDSA. AUTHCALL envoie l'appel en tant que compte autorisé. Cela permet aux contrats intelligents d'envoyer des transactions au nom d'EOA. Mais ce n'est toujours pas une solution parfaite pour les AA. Dans le processus de transaction d'autorisation, EIP-3074 a certaines restrictions sur la transmission de la valeur d'origine. Et si l'utilisateur perd l'accès à l'EOA, il n'y a toujours aucun moyen de récupérer ses actifs. Si la clé privée est divulguée, l'utilisateur doit transférer tous les actifs vers le nouveau compte.
Aucune des propositions ci-dessus n'a été officiellement intégrée au protocole Ethereum en raison de la nécessité de modifications au niveau du consensus ou parce que les propositions n'étaient pas suffisamment complètes. Par conséquent, la communauté Ethereum a continué à explorer comment introduire AA dans le protocole Ethereum sans changer le consensus, et a finalement proposé EIP4337.
ERC - 4337
L'EIP-4337 a été initialement proposé en septembre 2021 et autorisé sous le nom d'ERC-4337 en mars 2023. Ses auteurs incluent Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh, Shahaf Nacson et Tjaden Hess.
EIP-4337 est une proposition perturbatrice qui introduirait AA sans changer le protocole Ethereum de base. EIP-4337 est finalement devenu la norme ERC-4337, que les constructeurs peuvent utiliser pour mettre en œuvre leurs propres portefeuilles de contrats intelligents. Dans le même temps, la norme introduit également une infrastructure supplémentaire, notamment des "Bundlers" et "UserOperation mempool". De cette façon, il réplique en fait un mempool Ethereum avec des fonctions similaires sur la couche supérieure du système blockchain. Ce que l'utilisateur soumet n'est plus une transaction unique, mais une UserOperation. Ces UserOperations peuvent être regroupées en une seule transaction et envoyées à Ethereum.
Ce qui suit est une explication technique détaillée de ERC-4337 dans Ethereum [documentation officielle], avec quelques commentaires utiles.
Rôles clés de l'ERC-4337 et leurs définitions
UserOperation : décrit la structure d'une transaction envoyée au nom d'un utilisateur. Pour éviter toute confusion, il n'est pas nommé "transaction" et il sera envoyé au Bundler pour être emballé avec d'autres UserOperations en tant que Bundle. Le Bundle est ensuite envoyé en chaîne en une seule transaction.
Sender : le compte de contrat qui envoie UserOperation. Le contrat de portefeuille doit suivre la norme ERC-4337 pour configurer l'interface IAccount.
EntryPoint - le contrat singleton global qui exécute le bundle UserOperations. Bundlers/Clients whitelist pris en charge EntryPoints. Le contrat est audité et approuvé pour le déploiement par l'équipe Infinitism, et est responsable de la gestion de toutes les opérations utilisateur et de la connexion des contrats avec d'autres rôles, y compris Wallet Factory, Aggregator et Paymaster. Le contrat est tous à la même adresse sur la chaîne compatible EVM.
Bundler : le nœud qui regroupe plusieurs UserOperations à partir du mempool et crée la transaction EntryPoint.handleOps() (le nœud producteur de bloc actuel). Le service Bundler peut s'exécuter indépendamment des nœuds de la blockchain et envoyer des UserOperations packagées via RPC.
Agrégateur : un contrat auxiliaire auquel les comptes font confiance pour vérifier les signatures agrégées. Bundlers/Clients liste blanche des agrégateurs de signatures pris en charge. Les agrégateurs doivent configurer l'interface IAggregator conformément à la norme ERC-4337.
Paymaster : un contrat intelligent qui peut payer l'essence en votre nom. S'il dépose suffisamment d'ETH dans le contrat EntryPoint, il peut payer à l'expéditeur le contrat intelligent pour les frais de gaz de UserOperation, mettant ainsi en œuvre efficacement l'abstraction de gaz. Paymaster doit suivre la norme ERC-4337 pour configurer l'interface Paymaster. Paymaster peut conclure un accord avec l'expéditeur. Par exemple, Sender paie USDC à Paymaster, et Paymaster utilise ETH pour payer le Gas des UserOperations qu'il envoie. En fait, Paymaster peut choisir de prendre en charge n'importe quel
Jeton
, y compris ERC-20
Jeton
même d'autres chaînes
Jeton
。
Le schéma ci-dessous explique comment le contrat EntryPoint interagit avec les autres acteurs.
Les bundlers appellent la fonction handleOps du contrat EntryPoint, qui accepte une UserOperation en entrée.
handleOps vérifiera UserOperation sur la chaîne, vérifiera s'il est signé par l'adresse de portefeuille de contrat intelligent spécifiée et confirmera si le portefeuille a suffisamment de gaz pour compenser Bundler.
Si la vérification est réussie, handleOps exécutera la fonction de portefeuille de contrat intelligent en fonction de la fonction et des paramètres d'entrée définis dans les calldata de UserOperation.
D'autre part, lorsque Bundler utilise EOA pour déclencher la fonction handleOps, des frais de gaz seront facturés. Le portefeuille de contrats intelligents peut payer les frais de Bundlers Gas à partir de son propre solde de compte ou demander au contrat Paymaster de les payer. UserOperations ne peut pas réussir l'étape de vérification hors chaîne sans suffisamment de gaz, c'est-à-dire qu'il échoue avant d'exécuter la transaction sur la chaîne. Même s'il y a suffisamment de gaz, UserOperations peut toujours échouer en raison d'erreurs d'exécution et d'autres raisons lors de l'exécution. Pour une UserOperation, que l'exécution du contrat soit réussie ou non, le contrat EntryPoint paiera les frais de gaz au Bundler qui déclenche la fonction handleOps.
Après l'entrée en vigueur de l'ERC-4337, les utilisateurs peuvent désormais initier des transactions blockchain de deux manières. L'une est la méthode traditionnelle, c'est-à-dire que l'EOA initie directement la transaction. L'autre consiste à utiliser la norme ERC-4337 pour lancer UserOperation via Bundler, puis Bundler la regroupera avec d'autres UserOperations et l'enverra à la chaîne de réseau. L'organigramme ci-dessous illustre la différence entre une transaction d'envoi EOA normale et un envoi de portefeuille de contrat ERC-4337 UserOperation.
La route a été goudronnée, mais il n'y a pas encore beaucoup de piétons
ERC-4337 fournit un cadre puissant permettant aux utilisateurs et aux développeurs d'utiliser et de créer des AA sur Ethereum. Bien que ce cadre soit une avancée importante, il reste encore des défis et des incertitudes qui doivent être abordés et résolus.
L'adoption des AA en est encore à ses balbutiements. Selon le panel d'analyse Dune ERC-4337 [ERC-4337 Account Abstraction], seules plus de 65 000 UserOperations ont été exécutées sur la chaîne, dont 90 % provenaient de Polygon. Par conséquent, le nombre d'opérations utilisateur actuellement effectuées est encore très faible, dont la plupart sont des tests de développeur, et seule une petite partie provient d'utilisateurs réels. Nous notons que les produits qui ont intégré AA sont encore à leurs débuts. À l'heure actuelle, nous pouvons observer que les Bundlers dans leur ensemble sont toujours en état de perte, et la perte actuelle est d'environ plus de 700 MATIC. Cela est principalement dû au fait que certains bundlers sur Polygon ont mal estimé le gaz requis, ce qui fait que le gaz renvoyé par EntryPoint est inférieur au gaz consommé par le bundle soumis. Ce problème doit être résolu au niveau du client Bundler.
Au-delà de cela, il y a quelques problèmes qui doivent être résolus. L'un de ces problèmes est la façon dont les bundlers gèrent les échecs de transaction.
Après avoir regroupé plusieurs UserOperations, les bundlers simuleront d'abord la transaction, détecteront s'il y aura un échec d'exécution du contrat et calculeront si les frais de gaz retournés par l'expéditeur ou le payeur sont supérieurs aux frais de gaz payés.
S'il est rentable, Bundler soumet ce lot d'opérations utilisateur au nœud de bloc en tant que transaction. Cependant, il est toujours possible que la transaction échoue, ce qui fait que le Bundler paie les frais de gaz mais ne reçoit pas le remboursement de gaz du point d'entrée. Par exemple, un utilisateur peut envoyer des actions à différents Bundlers. S'il y a de la place pour le profit et que la simulation est réussie, les Bundlers l'engagent dans la chaîne. Dans ce cas, si une UserOperation est soumise au nœud de bloc par différents Bundlers en même temps, une seule transaction réussira, ce qui signifie qu'un seul Bundler recevra les frais de gaz retournés par l'EntryPoint, et tous les autres Bundlers échoueront en raison à enchaîner et à perdre du gaz. Bien que l'on puisse affirmer que ce comportement doit être considéré comme une attaque malveillante et affirmer que Bundler peut interdire l'adresse de l'expéditeur et rejeter toutes les demandes futures de cette adresse, ce n'est pas une solution raisonnable car les utilisateurs peuvent prendre cette action involontairement. Ce problème doit être correctement traité dans le code, peut-être via un réseau mempool public en cours de développement. En outre, les bundlers peuvent subir des pertes dues à des fluctuations soudaines du gaz, même si la transaction est soumise avec succès et que les résultats de la simulation montrent qu'il y a place pour le profit.
Un autre problème est la valeur extractible maximale (MEV) qui peut être obtenue à partir de l'AA. Dans le contexte d'Ethereum, MEV fait généralement référence à la valeur que les mineurs ou d'autres processeurs de transactions extraient en manipulant l'ordre des transactions dans un bloc ou en insérant leurs propres transactions dans un bloc. On peut remarquer que la logique de MEV peut également être appliquée à AA. En effet, dans AA, les bundlers peuvent commander librement UserOps, ce qui leur donne la possibilité d'acquérir MEV. Cependant, si Bundler peut extraire MEV dépend si suffisamment d'opérations utilisateur peuvent être regroupées. Maintenant, l'ensemble du marché AA en est encore à ses balbutiements, donc Bundler MEV peut également être considéré à ses balbutiements. On peut voir que le MEV d'AA peut se développer dans deux directions : l'une est similaire au réseau principal Ethereum, avec la participation de participants tels que Flashbots, Ultra Sound et BloXroute ; l'autre direction est de former un consensus Bundler pour mettre en œuvre un tri équitable. Ce dernier éliminerait complètement la possibilité d'extraire des MEV en AA.
développement futur
pool de mémoire public
Bien que l'écosystème AA soit déjà opérationnel, il reste encore beaucoup de travail de développement à faire. En regardant l'ensemble de l'écosystème AA, la plus grande pièce manquante à l'heure actuelle est le mempool public. L'équipe Etherspot, développeurs du client Skandha Bundler, développe actuellement un réseau p2p avec un mempool public. Un réseau p2p de mempools publics devrait être lancé en août de cette année.
Algorithme de bundle
En cours de route, la Fondation Ethereum a financé plusieurs équipes de développement AA exceptionnelles. Jusqu'à présent, plusieurs clients Bundler ont été développés et sont actuellement disponibles. Parmi eux, certains sont très matures. Ce sont Candide (Voltaire Bundler écrit en Python), Pimlico (Alto Bundler écrit en Type), Etherspot (Skandha Bundler écrit en Type), Stackup (Stackup-Bundler écrit en Go), etc.
Voici la question de la stratégie d'emballage. Actuellement, en raison du petit nombre d'opérations utilisateur, les bundlers peuvent adopter une logique de conditionnement simple, telle que des intervalles de temps fixes ou un certain nombre d'opérations utilisateur dans chaque bundle. Cependant, à mesure que le nombre d'UserOperations augmente, en particulier après l'introduction du mempool public, la stratégie de sélection et de conditionnement des UserOperations devient plus complexe. La raison est simple : dans l'écosystème AA, il n'existe pas de mécanisme similaire au protocole de consensus blockchain, et le groupe Bundler est devenu une forêt noire, chaque Bundler hiérarchise les tâches en fonction de ses propres intérêts et se fait concurrence. Contrairement aux mempools publics, les mempools privés peuvent apparaître plus tôt. Parce que lorsque le package UserOperations à partir du mempool public n'est pas rentable, il est toujours possible de packager UserOperations dans le mempool privé. Dans ce cas, le Bundler est plus compétitif que les autres Bundlers lors de l'emballage.
De plus, avec la vulgarisation progressive du mempool public, les UserOperations qu'il contient ont diverses caractéristiques, telles que différentes attentes de profit de gaz et la complexité d'exécution en chaîne. Les bundlers effectueront des simulations hors chaîne pour évaluer la rentabilité de diverses combinaisons d'UserOperations afin d'établir leurs stratégies de regroupement respectives. Emballer plus d'opérations utilisateur a le potentiel de générer des profits plus élevés, mais cela augmente également le risque d'échecs de validation. Même si la vérification est réussie, le risque d'échec d'exécution sur la chaîne existe toujours. En revanche, UserOperations avec moins d'emballage est le contraire.
Les bundlers doivent définir leurs propres paramètres de gaz de transaction, ce qui affectera la priorité des producteurs de blocs pour exécuter cette transaction. Dans différentes conditions de prix estimés du gaz et de volatilité du gaz, les bundlers peuvent avoir des stratégies de conditionnement différentes. Dans le même temps, il est également nécessaire de prendre en compte le coût des ressources informatiques matérielles locales et des ressources de nœud de chaîne de blocs pour ces calculs de vérification et de politique. En outre, les bundlers doivent également garantir une bonne expérience utilisateur pour les utilisateurs et veiller à ce que les utilisateurs ne soient pas confrontés à des retards excessifs après avoir soumis des opérations utilisateur.
Bien que les solutions à ces défis ne soient pas encore claires, nous pouvons dire avec confiance que le développement de l'industrie AA et les efforts conjoints des développeurs finiront par résoudre ces problèmes. En tant que constructeur d'infrastructures, BlockPI espère jouer le rôle de solutionneur de problèmes dans le développement de l'industrie AA, que ce soit en tant que développeur ou pour fournir une infrastructure compatible AA pour d'autres développeurs.
*L'infrastructure doit s'adapter à l'AA
AA résume les différents rôles impliqués dans les transactions en chaîne, y compris l'expéditeur, les bundlers, les payeurs de gaz, les portefeuilles contractuels et les signataires, afin que les utilisateurs aient un degré de liberté plus élevé lors de l'utilisation de la blockchain. Dans le même temps, les fournisseurs d'infrastructures peuvent déployer ces services de manière indépendante en fonction de leur propre jugement sur le marché.
Afin de s'adapter à l'adoption à grande échelle de l'AA, les fournisseurs d'infrastructure doivent d'abord fournir au moins deux services de base : le service Bundler et le service Paymaster.
Dans le service Bundler, le fournisseur d'infrastructure peut avoir besoin de développer un mempool privé avec les bundlers pour offrir une bonne expérience utilisateur. Plus précisément, les fournisseurs d'infrastructure doivent intégrer divers clients Bundler pour assurer la stabilité des services Bundler. Ces clients Bundler fournissent actuellement aux utilisateurs plusieurs méthodes JSON RPC standard fournies par le groupe de développement principal ERC-4337. Il est prévisible que davantage de méthodes RPC seront disponibles pour les utilisateurs à l'avenir. Les fournisseurs de services d'infrastructure doivent mettre à jour la prise en charge de ces méthodes en temps opportun au cours de ce processus.
En outre, il est important d'optimiser entre l'API Bundler et le RPC client du nœud d'origine. Le client de nœud actuel n'est pas optimisé pour AA. Certaines méthodes de l'API Bundler nécessitent un index par rapport aux données fournies pour l'AA. Par exemple, lorsque le client actuel recherche UserOperation par hachage, il doit analyser les journaux de contrat EntryPoint dans tous les blocs. S'il n'y a pas d'index de données, la consommation de ressources matérielles de cette requête unique sera assez énorme, et le temps de retour de la requête deviendra également très long.
De plus, afin de fournir aux utilisateurs une expérience utilisateur sans gaz et des services diversifiés, les fournisseurs d'infrastructure doivent coopérer avec différents fournisseurs de services Paymaster pour intégrer différents services Paymaster. Dans le même temps, selon la demande du marché, les fournisseurs d'infrastructures peuvent également concevoir des solutions intégrées plus pratiques basées sur les services Paymaster existants. D'autres services, tels que les signatures agrégées, les fabriques de portefeuilles, etc., sont également des orientations potentielles pour le développement futur et l'intégration de l'infrastructure.
En bref, afin de s'adapter à l'application à grande échelle de l'AA, les fournisseurs d'infrastructure doivent continuellement améliorer et étendre leurs services. Cela comprend l'optimisation des services Bundler, la coopération avec différents fournisseurs de services Paymaster, l'intégration de diverses interfaces API et le développement d'autres services potentiels. Alors que l'industrie AA continue de se développer, ces efforts contribueront à fournir une expérience blockchain plus efficace, sécurisée et pratique.
Actuellement, BlockPI travaille dur pour atteindre les objectifs ci-dessus. De plus, nous avons communiqué avec presque tous les clients Bundler et les fournisseurs de services Paymaster de la communauté, et intégrerons AA dans le réseau BlockPI en tant que tâche de développement principale. Dans le même temps, nous avons également mené une communication approfondie avec les développeurs de portefeuilles AA pour comprendre les besoins des utilisateurs. Nous invitons sincèrement tous les bundlers, paymasters et portefeuilles à communiquer et à coopérer avec nous.
L'objectif de BlockPI est de construire et de développer l'écosystème AA avec la communauté, et de faire tout son possible pour promouvoir le progrès et la prospérité de l'écosystème AA. Nous espérons que grâce à la coopération avec la communauté, nous contribuerons à l'ensemble de l'industrie AA en tant que leader de l'industrie et soutiendrons son processus de développement ultérieur, afin que les utilisateurs de Web2 puissent découvrir la technologie blockchain sans barrières.