Auteur : Albert He, Scientifique en chef de BlockPI
Compilation originale : MarsBit, MK
Qu'il s'agisse d'un marché haussier ou d'un marché baissier, l'écosystème Ethereum s'est continuellement construit et s'est auto-optimisé. Parmi eux, l'abstraction de compte (AA) est devenue une avancée très importante ces dernières années et a pénétré dans divers composants de l'écosystème Ethereum, y compris les applications, l'infrastructure, les utilisateurs et les développeurs.
Nous pouvons prévoir que l'adoption généralisée de l'AA peut réduire les barrières à l'entrée pour les cas d'utilisation de la blockchain, apportant ainsi l'expérience utilisateur Web2 à l'industrie Web3.
Pour saisir la possibilité de former un marché de plusieurs milliards d'AA, BlockPI prévoit de consacrer des ressources à l'intégration de l'AA dans ses services d'infrastructure. En développant l'intégration d'AA, nous visons à fournir aux utilisateurs AA des moyens plus pratiques et efficaces d'interagir avec leurs comptes de portefeuille contractuels sur la blockchain, tout en positionnant BlockPI en tant que leader de l'industrie.
Dans cet article, je vais approfondir notre compréhension des AA et partager des réflexions du point de vue d'un fournisseur de services d'infrastructure.
EOA et portefeuille de contrats intelligents
Le concept d'AA découle des limites des comptes EOA. Un compte EOA (Externally Owned Account) est un compte utilisateur typique 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 d'interagir avec des contrats intelligents et d'exécuter des transactions sur le réseau. Cependant, l'utilisation d'EOA peut être difficile pour les utilisateurs et certains inconvénients peuvent affecter l'expérience utilisateur.
Le premier inconvénient de l'EOA est lié à l'utilisation du Gaz. Chaque transaction coûtera à l'utilisateur une grande quantité d'ETH en tant que frais de gaz (un simple frais de transfert ETH de 25 Gwei pour le prix du gaz est de 0,5 USD, et plus pour l'interaction contractuelle ou un prix du gaz plus élevé). Cela rend les frais de transaction très coûteux pour les petites transactions, en particulier pendant les périodes de pointe de congestion du réseau. De plus, seul l'ETH peut être utilisé pour payer le gaz, ce qui signifie que les utilisateurs doivent avoir de l'ETH dans leur portefeuille, ce qui constitue un obstacle important à l'entrée pour de nombreux utilisateurs.
Le deuxième inconvénient de l'EOA est que les transactions conditionnelles ne peuvent être effectuées que si une logique est mise en œuvre à l'aide d'autres contrats intelligents. Par exemple, si un utilisateur souhaite définir un transfert périodique chronométré, il doit transférer ETH vers un contrat intelligent tiers avec cette fonction pour réaliser cette fonction.
Le troisième inconvénient d'EOA est l'algorithme de cryptage de signature. Le réseau Ethereum utilise un algorithme de signature numérique spécifique appelé secp 256 k 1 pour garantir l'authenticité et la sécurité des transactions. Ceci est codé en dur dans le système et l'utilisateur ne peut pas choisir d'utiliser un autre algorithme.
Par conséquent, à partir de ces problèmes, les gens ont commencé à essayer de trouver des solutions. Les portefeuilles de contrats intelligents tels que MetaMask et Argent sont le résultat de ces efforts, remédiant à de nombreuses limitations d'EOA en utilisant des contrats intelligents Ethereum pour améliorer la fonctionnalité des comptes d'utilisateurs. Cependant, une telle solution présente encore certains inconvénients, obligeant principalement les utilisateurs à payer des frais de gaz pour les transactions et la popularité des portefeuilles de contrats intelligents.
Sur la base de ces défis, Ethereum a commencé à essayer d'introduire un nouveau concept, à savoir l'abstraction de compte. L'objectif de l'abstraction de compte est de résoudre ces problèmes au niveau du protocole, plutôt que de s'appuyer sur des contrats intelligents ou d'autres intergiciels. C'est ce que nous appelons maintenant l'abstraction de compte (AA).
Dans le reste de cet article, j'approfondirai le concept d'abstraction de compte et comment nous pouvons l'utiliser pour optimiser l'infrastructure de BlockPI.
En plus des trois inconvénients de l'EOA mentionnés ci-dessus, la relation de liaison entre la clé publique et la clé privée est également un problème. La clé privée est le seul moyen d'accéder à l'EOA, et en cas de perte, il n'y a aucun moyen de récupérer la clé privée. Cela signifie que si la clé privée est perdue, tous les actifs qui lui sont associés seront irrécupérables.
En outre, EOA est également confronté à des contraintes lors de l'exécution de tâches linéaires en une seule transaction. Par exemple, si un utilisateur souhaite approuver, échanger et désapprouver des jetons en une seule action, il doit effectuer trois transactions distinctes, ce qui est inefficace et prend du temps.
La bonne nouvelle est que tous les problèmes ci-dessus peuvent être résolus avec des portefeuilles de contrats intelligents. Un portefeuille de contrats intelligents est un type spécial de contrat intelligent qui implémente AA. Il est conçu pour agir comme le portefeuille d'un utilisateur sur le réseau Ethereum et fournir une manière plus adaptative et personnalisée de gérer ses fonds. Tant que la logique du contrat intelligent Ethereum peut être réalisée, le portefeuille de contrat intelligent peut fournir les fonctions requises.
Plus précisément, les transactions du portefeuille de contrats intelligents peuvent être regroupées dans une transaction en chaîne pour partager le coût du gaz.Si un tiers est prêt à payer, il peut même n'y avoir aucun coût de gaz. Une opération peut faciliter l'exécution de tâches séquentielles au sein de son portefeuille de contrats intelligents. Le portefeuille de contrat intelligent peut prendre en charge n'importe quel algorithme de cryptage de signature et définir des codes de récupération, etc.
Avec toutes les discussions sur les avantages des portefeuilles de contrats intelligents, la communauté Ethereum travaille en fait sur les portefeuilles de contrats depuis le début. Bien que de nombreux EIP aient été proposés pour explorer l'abstraction des comptes, aucune norme unifiée n'a été établie avant 2021. Voici quelques-unes des propositions les plus représentatives.
EIP-86
Créé à l'origine en 2017 par Vitalik Buterin. Mise en œuvre d'un ensemble de modifications apportées aux services de vérification de signature "abstraite" et de vérification nonce, permettant aux utilisateurs de créer des "contrats de compte" qui effectuent toutes les vérifications de signature/nonce souhaitées.
EIP-2938
Créé en 2020. Le titre de cet EIP est Account Abstraction. Cet EIP détaille le concept d'AA. Il introduit un nouveau type de transaction, la transaction AA. Cette transaction sera initialisée par l'adresse EntryPoint et appellera le contrat de portefeuille AA. Ce faisant, il fournit une spécification unifiée et introduit AA dans le consensus Ethereum. Plus précisément, il ajoute deux nouveaux opcodes, trois variables globales et une structure de charge utile différente au consensus Ethereum.
EIP-3074
Créé en 2020. Cet EIP introduit deux instructions EVM, AUTH et AUTHCALL. AUTH définit une variable de contexte appelée autorisée sur la base de la signature ECDSA. AUTHCALL envoie un appel au nom d'un compte autorisé. Cela permet à un contrat intelligent d'envoyer des transactions au nom d'EOA. Mais ce n'est pas une solution parfaite pour les AA. EIP-3074 impose certaines limitations sur les transferts de valeur native lors des transactions de parrainage. Si vous perdez l'accès à l'EOA, vous ne pourrez pas récupérer vos actifs, et en cas de vol, tous les actifs devront être transférés sur un nouveau compte.
Aucune des idées ci-dessus n'a été officiellement adoptée dans le protocole Ethereum pour des raisons majeures telles que la nécessité de modifications au niveau du consensus ou le fait de ne pas être complet. Par conséquent, la communauté Ethereum a continué à explorer comment introduire AA dans le protocole Ethereum sans changer le consensus, et a finalement créé EIP 4337.
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 révolutionnaire qui introduit AA sans apporter de modifications au protocole principal Ethereum. EIP-4337 guide la norme ERC-4337, que les constructeurs peuvent utiliser pour implémenter leurs propres portefeuilles de contrats intelligents, et inclut également une infrastructure supplémentaire, y compris des "Bundlers" et des pools de mémoire UserOperation. Ce faisant, il réplique essentiellement la fonctionnalité du mempool de transaction dans un système plus avancé. Au lieu d'envoyer des transactions, les utilisateurs soumettent des objets UserOperation, qui peuvent ensuite être regroupés en une seule transaction et inclus dans la chaîne Ethereum.
Ce qui suit est une explication technique plus spécifique de l'ERC-4337 à partir de la documentation officielle, ainsi que quelques commentaires pour une meilleure compréhension.
Définition et rôles clés de l'ERC-4337
UserOperation — structure décrivant les transactions envoyées au nom d'un utilisateur. Pour éviter toute confusion, il n'est pas nommé "transaction". Il est envoyé au Bundler pour être empaqueté avec d'autres UserOperations. Le package est ensuite envoyé au créateur du bloc en une seule transaction.
Expéditeur — le compte de contrat qui envoie la nouvelle UserOperation. Le portefeuille de contrats intelligents doit implémenter l'interface IAccount de ERC-4337.
EntryPoint — un contrat singleton qui implémente le package UserOperations. Bundlers/Clients whitelist pris en charge EntryPoints. Ce contrat est approuvé et examiné par l'équipe Infinitisme et est responsable de la gestion de toutes les opérations utilisateur et de la connexion d'autres contrats, y compris Wallet Factory, Aggregator, Paymaster. Il aura la même adresse sur la plupart des chaînes compatibles EVM.
Bundler — un nœud (constructeur de blocs) qui regroupe plusieurs UserOperations à partir d'un mempool et crée des transactions EntryPoint.handleOps(). Tous les validateurs au niveau de la couche de protocole ne doivent pas nécessairement être des bundlers. Le service Bundler peut s'exécuter indépendamment du générateur de blocs et utilise RPC pour envoyer des UserOperations groupées.
Agrégateur — Un contrat d'assistance approuvé par les comptes pour vérifier les signatures agrégées. Bundlers/Clients liste blanche des agrégateurs pris en charge. Les agrégateurs doivent implémenter l'interface ERC-4337 IAggregator.
Paymaster - Un contrat qui peut payer les frais de gaz de UserOperation pour l'expéditeur si suffisamment d'ETH sont déposés dans le contrat EntryPoint. Paymaster met en œuvre un prélèvement de gaz efficace. Paymaster doit implémenter l'interface Paymaster de l'ERC-4337. Paymaster peut avoir sa propre logique pour conclure un accord avec l'expéditeur. Par exemple, Sender paie USDC à Paymaster, et Paymaster parraine ses UserOperations avec ETH. En fait, tout jeton ERC 20 ou même les jetons sur d'autres chaînes peuvent être pris en charge tant que Paymaster est d'accord et que c'est techniquement faisable.
Wallet Factory - un contrat qui peut être appelé pour créer des portefeuilles de contrats intelligents pour les utilisateurs de l'ERC-4337. Le déploiement d'une fabrique de portefeuilles est sans autorisation. En tant que composant en chaîne, il est ouvert à un audit public et à un examen transparent. Wallet Factory, largement utilisé, doit être entièrement audité 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 prend une UserOperation comme entrée.
handleOps vérifie l'UserOperation sur la chaîne, vérifie si elle est signée par l'adresse de portefeuille de contrat intelligent spécifiée et si le portefeuille a suffisamment de gaz pour compenser Bundler.
Si la vérification réussit, handleOps exécutera la fonction de portefeuille de contrat intelligent en fonction de la signature de la fonction et des paramètres d'entrée définis dans les données d'appel 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 gaz aux Bundlers à partir de son propre solde de compte ou demander au contrat Paymaster de payer en son nom. Les UserOperations qui n'ont pas assez de Gas ne peuvent pas passer le processus de vérification dans le portefeuille de contrats intelligents cible et échouent donc avant l'exécution. Même s'il y a suffisamment de gaz, UserOperations peut échouer lors de l'exécution, par exemple, en raison d'erreurs d'exécution. Que l'exécution soit réussie ou non, le contrat EntryPoint paiera les frais de gaz au Bundler qui déclenche la fonction handleOps.
(Source : Documentation officielle :
Après l'entrée en vigueur de l'ERC-4337, les utilisateurs ont désormais deux façons d'initier des transactions blockchain. L'une est la manière originale, où l'EOA initie la transaction. L'autre consiste à utiliser la norme ERC-4337 pour démarrer UserOperation via Bundler, puis Bundler l'empaquetera avec d'autres UserOperations et l'initiera sur la chaîne. L'organigramme suivant illustre la différence entre la transaction d'envoi EOA normale et l'opération utilisateur d'envoi du portefeuille de contrat ERC-4337.
La route est goudronnée, mais il n'y a pas beaucoup de passagers
ERC-4337 fournit un cadre puissant permettant aux utilisateurs et aux développeurs d'utiliser et de créer des AA sur la plate-forme Ethereum. Bien que ce cadre soit une avancée importante, plusieurs défis et incertitudes doivent encore ê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 de @niftytable), seuls 65 k+ UserOperations sont exécutés sur la chaîne, dont 90% proviennent de Polygon. Par conséquent, le nombre d'opérations utilisateur effectuées à l'heure actuelle est encore très faible, dont la plupart sont des tests de développeur et seule une petite partie est attribuée aux utilisateurs. Nous notons que les produits qui ont intégré AA sont encore à leurs débuts. Dans le même temps, vous pouvez voir que le bénéfice de Bundler est négatif (-700 en termes MATIC). En effet, certains bundlers sur Polygon ne calculent pas correctement le gaz de pré-validation. Cet algorithme de vérification doit encore être optimisé.
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. Une fois que Bundler a regroupé plusieurs UserOperations, Bundler simule d'abord la transaction pour vérifier si elle sera annulée, puis calcule si les frais de gaz renvoyés par l'expéditeur ou le payeur sont supérieurs aux frais de gaz payés par la transaction. S'il est rentable, Bundler soumet ce lot d'opérations utilisateur ensemble en tant que transaction au constructeur de blocs. Cependant, la transaction peut toujours échouer, ce qui fait que le Bundler paie les frais de gaz mais ne reçoit pas le gaz du point d'entrée. Par exemple, un utilisateur peut envoyer des actions à différents Bundlers. Les bundlers sont prêts à soumettre toutes les opérations en chaîne si elles sont rentables et que leur simulation réussit. Cela signifie que si une UserOperation est soumise par différents Bundlers en même temps. Une seule transaction réussira, un seul Bundler recevra des frais de gaz d'EntryPoint, tous les autres Bundlers perdront du gaz en raison d'une défaillance de la chaîne. Bien que l'on puisse affirmer que les utilisateurs ne devraient pas faire cela, un tel comportement serait considéré comme une attaque malveillante et que Bundler pourrait interdire l'adresse de l'expéditeur et rejeter toutes les demandes futures de cette adresse, ce n'est pas une approche raisonnable car les utilisateurs Cette opération peut avoir été soumis par inadvertance. Ces problèmes doivent être correctement traités dans le code, éventuellement en développant un réseau de mempool public inachevé. De plus, en raison de fluctuations soudaines du gaz, les bundlers peuvent subir des pertes même si les transactions ont été soumises avec succès et simulées comme rentables.
Une autre chose est la valeur extractible maximale (MEV) qui peut être extraite 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 peuvent extraire en manipulant l'ordre des transactions dans un bloc ou en incluant leurs propres transactions dans un bloc. Quelqu'un a-t-il remarqué que la logique de MEV peut également s'appliquer à AA, puisque les Bundlers sont libres de commander des UserOperations ? Cependant, cela est conditionnel, suffisamment d'opérations utilisateur doivent être regroupées pour que les bundlers puissent extraire MEV. Maintenant, l'ensemble du marché AA en est encore à ses balbutiements, donc Bundler MEV peut également être considéré à ses balbutiements. En général, l'industrie AA peut se développer dans deux directions : l'une est similaire au réseau principal Ethereum, avec des participants comme Flashbots, Ultra Sound et BloXroute, et l'autre consiste à former un consensus Bundler pour imposer un ordre équitable. Cette dernière approche éliminerait complètement la possibilité de MEV dans AA.
développement futur
pool de mémoire public
Bien que l'écosystème AA fonctionne déjà, il reste encore beaucoup de travail de développement à faire. En regardant l'ensemble de l'écosystème AA, la plus grande lacune à 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. Le réseau p2p du mempool public devrait être disponible en août de cette année.
Algorithme d'emballage
En cours de route, la Fondation Ethereum a financé plusieurs équipes de développement AA composées de développeurs dévoués et travailleurs. A ce jour, plusieurs versions du client Bundler ont été développées et sont désormais disponibles. Certains d'entre eux sont très développés en termes de maturité du produit. 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), et bien d'autres.
Maintenant, plongeons dans l'algorithme d'emballage plus en détail. Actuellement, en raison du faible nombre d'opérations utilisateur, les bundlers peuvent utiliser une logique d'empaquetage simple et directe, comme des intervalles de temps fixes ou le 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 : sans protocole de consensus comme une blockchain, les Bundlers forment une forêt sombre, chacun priorisant le travail en fonction de ses propres intérêts, et se faisant concurrence. Les mempools privés, correspondant aux mempools publics, sont plus susceptibles de venir en premier. Parce que lorsqu'il n'est pas rentable de regrouper UserOperations à partir du mempool public, il peut devenir rentable de regrouper UserOperations dans le mempool privé. De cette façon, Bundler a un avantage concurrentiel en matière d'emballage.
De plus, à mesure que le mempool public est progressivement accepté, les UserOperations qu'il contient auront des caractéristiques différentes, telles que différentes attentes en matière de profit du gaz et la complexité de l'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 uniques. Emballer plus d'opérations utilisateur a le potentiel de générer des profits plus importants, mais 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. Les UserOperations moins packagées font le contraire. Les bundlers doivent définir leurs propres paramètres de gaz de transaction, ce qui affectera la priorité des constructeurs de blocs pour exécuter les transactions. Dans des conditions de prix et de volatilité du gaz de marché différentes, les bundlers peuvent avoir des stratégies de conditionnement différentes. Dans le même temps, ces calculs de vérification et de politique doivent consommer des ressources informatiques matérielles locales et des ressources de nœud de chaîne de blocs. Les bundlers doivent également s'assurer que les utilisateurs ont une bonne expérience et qu'ils ne sont pas confrontés à des retards excessifs après avoir soumis une UserOperation.
Bien que les solutions à ces défis restent incertaines, nous pouvons être sûrs que l'évolution de l'industrie AA et les efforts combinés des développeurs finiront par trouver des solutions. En tant que constructeur d'infrastructures, BlockPI espère résoudre les problèmes de développement de l'industrie AA, que ce soit en tant que développeur ou pour fournir une infrastructure AA conviviale à d'autres développeurs.
L'infrastructure doit s'adapter
AA résume divers rôles dans le comportement des transactions sur la chaîne, y compris les expéditeurs, les groupeurs, les payeurs de gaz, les portefeuilles de contrats et les signataires, permettant aux utilisateurs d'avoir un degré de liberté plus élevé lors de l'utilisation de la blockchain. En outre, les services au sein d'un AA peuvent être déployés séparément.
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, à savoir 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 assurer une bonne expérience utilisateur. Plus précisément, les fournisseurs d'infrastructure doivent intégrer divers clients Bundler pour garantir la robustesse des services Bundler. Ces clients Bundler sont développés dans différents langages de programmation, mais ils fournissent tous un ensemble standard de méthodes JSON RPC spécifiées par l'équipe principale ERC-4337. Actuellement, il n'y a pas beaucoup de méthodes disponibles, mais d'autres méthodes seront ajoutées à l'avenir. Les fournisseurs de services d'infrastructure doivent fournir un support continu et complet pour ces API.
De plus, il est important d'optimiser et d'adapter la relation entre l'API Bundler et le RPC client du nœud d'origine. Nous savons que le client de nœud actuel n'est pas bien optimisé pour la réactivité et l'adaptabilité d'AA. Certaines méthodes de l'API Bundler nécessitent l'index de données d'AA pour fonctionner. Par exemple, la recherche d'une UserOperation par hachage nécessite l'indexation de toutes les UserOperations. Sinon, la consommation matérielle de cette requête unique sera très élevée, et la requête mettra beaucoup de temps à revenir.
En outre, les fournisseurs d'infrastructures doivent également intégrer différents services Paymaster pour offrir aux clients une expérience utilisateur sans essence et leur proposer différentes options de service. Cela nécessite une bonne communication et une bonne intégration avec les fournisseurs de services Paymaster tiers.En même temps, selon la demande du marché, des solutions d'intégration plus pratiques basées sur les services Paymaster existants peuvent également être conçues. D'autres services, tels que les signatures agrégées, les fabriques de portefeuilles, etc., sont également des orientations possibles pour le développement et l'intégration futurs.
Actuellement, BlockPI essaie en fait d'atteindre tous les objectifs ci-dessus. De plus, nous communiquons avec presque tous les clients Bundler et les fournisseurs de services Paymaster de la communauté, et avons fait de l'intégration du service AA dans le réseau BlockPI notre priorité absolue. Nous avons également des discussions approfondies avec les développeurs de portefeuilles AA pour comprendre les besoins des utilisateurs. Par conséquent, nous nous félicitons sincèrement de la coopération et des échanges avec tous les bundlers, paymasters et wallets à mesure que nous progressons. Notre objectif global est de construire et de développer l'écosystème AA avec d'autres, en pilotant sa croissance et son développement au mieux de nos capacités. En travaillant ensemble, nous espérons apporter une contribution significative à l'industrie des AA dans son ensemble et soutenir son développement continu. Parce qu'après tout, notre mission ultime est d'être un pionnier dans l'industrie et de promouvoir le développement de l'écosystème AA afin que les utilisateurs du web2 puissent profiter de leur expérience blockchain sans barrières.
Résumer
Du point de vue des AA, nous sommes à un nouveau moment historique. Bien que nous ayons des routes pavées sur le boulevard, il n'y a pas encore beaucoup d'usagers. À l'heure actuelle, l'application des AA en est encore à ses balbutiements. ERC-4337 fournit un cadre puissant permettant aux utilisateurs et aux développeurs d'utiliser et de créer des AA sur la plate-forme Ethereum. Cependant, il reste encore de nombreux défis et incertitudes à résoudre.
Le fournisseur d'infrastructure d'AA doit fournir le service Bundler et le service Paymaster à ses utilisateurs, et doit intégrer divers clients Bundler et fournisseurs de services Paymaster pour assurer la robustesse du service. Pour optimiser la réactivité entre l'API et les clients de nœud, les données AA peuvent devoir être indexées afin de réduire la consommation de matériel pour une seule requête. Afin d'offrir une meilleure expérience utilisateur, les fournisseurs d'infrastructure doivent également offrir aux utilisateurs davantage d'options de service.
À l'avenir, à mesure que l'écosystème AA continuera de croître et que des mempools publics émergeront, la stratégie de sélection et de conditionnement des UserOperations deviendra plus complexe. Chaque Bundler priorise son travail en fonction de ses propres intérêts et est en concurrence avec les autres Bundlers. Les bundlers doivent définir leurs propres paramètres de gaz de transaction, qui affectent la priorité des constructeurs de blocs pour exécuter les transactions. Dans des conditions de prix et de volatilité du gaz de marché différentes, les bundlers peuvent avoir des stratégies de conditionnement différentes.
Bien que les solutions à ces défis soient incertaines, nous pouvons être sûrs que l'évolution de l'industrie AA et les efforts combinés des développeurs finiront par trouver des solutions. En tant que constructeur d'infrastructures, BlockPI espère être un résolveur de problèmes dans le développement de l'industrie AA, soit en tant que développeur, soit en fournissant une infrastructure AA conviviale pour d'autres développeurs. Notre mission est de promouvoir le développement de l'écosystème AA afin que les utilisateurs Web2 puissent profiter de leur expérience blockchain sans barrières.
Voir l'original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Comment faire abstraction des comptes pour renforcer l'infrastructure et servir des milliards d'utilisateurs ?
Auteur : Albert He, Scientifique en chef de BlockPI
Compilation originale : MarsBit, MK
Qu'il s'agisse d'un marché haussier ou d'un marché baissier, l'écosystème Ethereum s'est continuellement construit et s'est auto-optimisé. Parmi eux, l'abstraction de compte (AA) est devenue une avancée très importante ces dernières années et a pénétré dans divers composants de l'écosystème Ethereum, y compris les applications, l'infrastructure, les utilisateurs et les développeurs.
Nous pouvons prévoir que l'adoption généralisée de l'AA peut réduire les barrières à l'entrée pour les cas d'utilisation de la blockchain, apportant ainsi l'expérience utilisateur Web2 à l'industrie Web3.
Pour saisir la possibilité de former un marché de plusieurs milliards d'AA, BlockPI prévoit de consacrer des ressources à l'intégration de l'AA dans ses services d'infrastructure. En développant l'intégration d'AA, nous visons à fournir aux utilisateurs AA des moyens plus pratiques et efficaces d'interagir avec leurs comptes de portefeuille contractuels sur la blockchain, tout en positionnant BlockPI en tant que leader de l'industrie.
Dans cet article, je vais approfondir notre compréhension des AA et partager des réflexions du point de vue d'un fournisseur de services d'infrastructure.
EOA et portefeuille de contrats intelligents
Le concept d'AA découle des limites des comptes EOA. Un compte EOA (Externally Owned Account) est un compte utilisateur typique 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 d'interagir avec des contrats intelligents et d'exécuter des transactions sur le réseau. Cependant, l'utilisation d'EOA peut être difficile pour les utilisateurs et certains inconvénients peuvent affecter l'expérience utilisateur.
Le premier inconvénient de l'EOA est lié à l'utilisation du Gaz. Chaque transaction coûtera à l'utilisateur une grande quantité d'ETH en tant que frais de gaz (un simple frais de transfert ETH de 25 Gwei pour le prix du gaz est de 0,5 USD, et plus pour l'interaction contractuelle ou un prix du gaz plus élevé). Cela rend les frais de transaction très coûteux pour les petites transactions, en particulier pendant les périodes de pointe de congestion du réseau. De plus, seul l'ETH peut être utilisé pour payer le gaz, ce qui signifie que les utilisateurs doivent avoir de l'ETH dans leur portefeuille, ce qui constitue un obstacle important à l'entrée pour de nombreux utilisateurs.
Le deuxième inconvénient de l'EOA est que les transactions conditionnelles ne peuvent être effectuées que si une logique est mise en œuvre à l'aide d'autres contrats intelligents. Par exemple, si un utilisateur souhaite définir un transfert périodique chronométré, il doit transférer ETH vers un contrat intelligent tiers avec cette fonction pour réaliser cette fonction.
Le troisième inconvénient d'EOA est l'algorithme de cryptage de signature. Le réseau Ethereum utilise un algorithme de signature numérique spécifique appelé secp 256 k 1 pour garantir l'authenticité et la sécurité des transactions. Ceci est codé en dur dans le système et l'utilisateur ne peut pas choisir d'utiliser un autre algorithme.
Par conséquent, à partir de ces problèmes, les gens ont commencé à essayer de trouver des solutions. Les portefeuilles de contrats intelligents tels que MetaMask et Argent sont le résultat de ces efforts, remédiant à de nombreuses limitations d'EOA en utilisant des contrats intelligents Ethereum pour améliorer la fonctionnalité des comptes d'utilisateurs. Cependant, une telle solution présente encore certains inconvénients, obligeant principalement les utilisateurs à payer des frais de gaz pour les transactions et la popularité des portefeuilles de contrats intelligents.
Sur la base de ces défis, Ethereum a commencé à essayer d'introduire un nouveau concept, à savoir l'abstraction de compte. L'objectif de l'abstraction de compte est de résoudre ces problèmes au niveau du protocole, plutôt que de s'appuyer sur des contrats intelligents ou d'autres intergiciels. C'est ce que nous appelons maintenant l'abstraction de compte (AA).
Dans le reste de cet article, j'approfondirai le concept d'abstraction de compte et comment nous pouvons l'utiliser pour optimiser l'infrastructure de BlockPI.
En plus des trois inconvénients de l'EOA mentionnés ci-dessus, la relation de liaison entre la clé publique et la clé privée est également un problème. La clé privée est le seul moyen d'accéder à l'EOA, et en cas de perte, il n'y a aucun moyen de récupérer la clé privée. Cela signifie que si la clé privée est perdue, tous les actifs qui lui sont associés seront irrécupérables.
En outre, EOA est également confronté à des contraintes lors de l'exécution de tâches linéaires en une seule transaction. Par exemple, si un utilisateur souhaite approuver, échanger et désapprouver des jetons en une seule action, il doit effectuer trois transactions distinctes, ce qui est inefficace et prend du temps.
La bonne nouvelle est que tous les problèmes ci-dessus peuvent être résolus avec des portefeuilles de contrats intelligents. Un portefeuille de contrats intelligents est un type spécial de contrat intelligent qui implémente AA. Il est conçu pour agir comme le portefeuille d'un utilisateur sur le réseau Ethereum et fournir une manière plus adaptative et personnalisée de gérer ses fonds. Tant que la logique du contrat intelligent Ethereum peut être réalisée, le portefeuille de contrat intelligent peut fournir les fonctions requises.
Plus précisément, les transactions du portefeuille de contrats intelligents peuvent être regroupées dans une transaction en chaîne pour partager le coût du gaz.Si un tiers est prêt à payer, il peut même n'y avoir aucun coût de gaz. Une opération peut faciliter l'exécution de tâches séquentielles au sein de son portefeuille de contrats intelligents. Le portefeuille de contrat intelligent peut prendre en charge n'importe quel algorithme de cryptage de signature et définir des codes de récupération, etc.
Avec toutes les discussions sur les avantages des portefeuilles de contrats intelligents, la communauté Ethereum travaille en fait sur les portefeuilles de contrats depuis le début. Bien que de nombreux EIP aient été proposés pour explorer l'abstraction des comptes, aucune norme unifiée n'a été établie avant 2021. Voici quelques-unes des propositions les plus représentatives.
EIP-86
Créé à l'origine en 2017 par Vitalik Buterin. Mise en œuvre d'un ensemble de modifications apportées aux services de vérification de signature "abstraite" et de vérification nonce, permettant aux utilisateurs de créer des "contrats de compte" qui effectuent toutes les vérifications de signature/nonce souhaitées.
EIP-2938
Créé en 2020. Le titre de cet EIP est Account Abstraction. Cet EIP détaille le concept d'AA. Il introduit un nouveau type de transaction, la transaction AA. Cette transaction sera initialisée par l'adresse EntryPoint et appellera le contrat de portefeuille AA. Ce faisant, il fournit une spécification unifiée et introduit AA dans le consensus Ethereum. Plus précisément, il ajoute deux nouveaux opcodes, trois variables globales et une structure de charge utile différente au consensus Ethereum.
EIP-3074
Créé en 2020. Cet EIP introduit deux instructions EVM, AUTH et AUTHCALL. AUTH définit une variable de contexte appelée autorisée sur la base de la signature ECDSA. AUTHCALL envoie un appel au nom d'un compte autorisé. Cela permet à un contrat intelligent d'envoyer des transactions au nom d'EOA. Mais ce n'est pas une solution parfaite pour les AA. EIP-3074 impose certaines limitations sur les transferts de valeur native lors des transactions de parrainage. Si vous perdez l'accès à l'EOA, vous ne pourrez pas récupérer vos actifs, et en cas de vol, tous les actifs devront être transférés sur un nouveau compte.
Aucune des idées ci-dessus n'a été officiellement adoptée dans le protocole Ethereum pour des raisons majeures telles que la nécessité de modifications au niveau du consensus ou le fait de ne pas être complet. Par conséquent, la communauté Ethereum a continué à explorer comment introduire AA dans le protocole Ethereum sans changer le consensus, et a finalement créé EIP 4337.
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 révolutionnaire qui introduit AA sans apporter de modifications au protocole principal Ethereum. EIP-4337 guide la norme ERC-4337, que les constructeurs peuvent utiliser pour implémenter leurs propres portefeuilles de contrats intelligents, et inclut également une infrastructure supplémentaire, y compris des "Bundlers" et des pools de mémoire UserOperation. Ce faisant, il réplique essentiellement la fonctionnalité du mempool de transaction dans un système plus avancé. Au lieu d'envoyer des transactions, les utilisateurs soumettent des objets UserOperation, qui peuvent ensuite être regroupés en une seule transaction et inclus dans la chaîne Ethereum.
Ce qui suit est une explication technique plus spécifique de l'ERC-4337 à partir de la documentation officielle, ainsi que quelques commentaires pour une meilleure compréhension.
Définition et rôles clés de l'ERC-4337
UserOperation — structure décrivant les transactions envoyées au nom d'un utilisateur. Pour éviter toute confusion, il n'est pas nommé "transaction". Il est envoyé au Bundler pour être empaqueté avec d'autres UserOperations. Le package est ensuite envoyé au créateur du bloc en une seule transaction.
Expéditeur — le compte de contrat qui envoie la nouvelle UserOperation. Le portefeuille de contrats intelligents doit implémenter l'interface IAccount de ERC-4337.
EntryPoint — un contrat singleton qui implémente le package UserOperations. Bundlers/Clients whitelist pris en charge EntryPoints. Ce contrat est approuvé et examiné par l'équipe Infinitisme et est responsable de la gestion de toutes les opérations utilisateur et de la connexion d'autres contrats, y compris Wallet Factory, Aggregator, Paymaster. Il aura la même adresse sur la plupart des chaînes compatibles EVM.
Bundler — un nœud (constructeur de blocs) qui regroupe plusieurs UserOperations à partir d'un mempool et crée des transactions EntryPoint.handleOps(). Tous les validateurs au niveau de la couche de protocole ne doivent pas nécessairement être des bundlers. Le service Bundler peut s'exécuter indépendamment du générateur de blocs et utilise RPC pour envoyer des UserOperations groupées.
Agrégateur — Un contrat d'assistance approuvé par les comptes pour vérifier les signatures agrégées. Bundlers/Clients liste blanche des agrégateurs pris en charge. Les agrégateurs doivent implémenter l'interface ERC-4337 IAggregator.
Paymaster - Un contrat qui peut payer les frais de gaz de UserOperation pour l'expéditeur si suffisamment d'ETH sont déposés dans le contrat EntryPoint. Paymaster met en œuvre un prélèvement de gaz efficace. Paymaster doit implémenter l'interface Paymaster de l'ERC-4337. Paymaster peut avoir sa propre logique pour conclure un accord avec l'expéditeur. Par exemple, Sender paie USDC à Paymaster, et Paymaster parraine ses UserOperations avec ETH. En fait, tout jeton ERC 20 ou même les jetons sur d'autres chaînes peuvent être pris en charge tant que Paymaster est d'accord et que c'est techniquement faisable.
Wallet Factory - un contrat qui peut être appelé pour créer des portefeuilles de contrats intelligents pour les utilisateurs de l'ERC-4337. Le déploiement d'une fabrique de portefeuilles est sans autorisation. En tant que composant en chaîne, il est ouvert à un audit public et à un examen transparent. Wallet Factory, largement utilisé, doit être entièrement audité 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 prend une UserOperation comme entrée.
handleOps vérifie l'UserOperation sur la chaîne, vérifie si elle est signée par l'adresse de portefeuille de contrat intelligent spécifiée et si le portefeuille a suffisamment de gaz pour compenser Bundler.
Si la vérification réussit, handleOps exécutera la fonction de portefeuille de contrat intelligent en fonction de la signature de la fonction et des paramètres d'entrée définis dans les données d'appel 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 gaz aux Bundlers à partir de son propre solde de compte ou demander au contrat Paymaster de payer en son nom. Les UserOperations qui n'ont pas assez de Gas ne peuvent pas passer le processus de vérification dans le portefeuille de contrats intelligents cible et échouent donc avant l'exécution. Même s'il y a suffisamment de gaz, UserOperations peut échouer lors de l'exécution, par exemple, en raison d'erreurs d'exécution. Que l'exécution soit réussie ou non, le contrat EntryPoint paiera les frais de gaz au Bundler qui déclenche la fonction handleOps.
(Source : Documentation officielle :
Après l'entrée en vigueur de l'ERC-4337, les utilisateurs ont désormais deux façons d'initier des transactions blockchain. L'une est la manière originale, où l'EOA initie la transaction. L'autre consiste à utiliser la norme ERC-4337 pour démarrer UserOperation via Bundler, puis Bundler l'empaquetera avec d'autres UserOperations et l'initiera sur la chaîne. L'organigramme suivant illustre la différence entre la transaction d'envoi EOA normale et l'opération utilisateur d'envoi du portefeuille de contrat ERC-4337.
La route est goudronnée, mais il n'y a pas beaucoup de passagers
ERC-4337 fournit un cadre puissant permettant aux utilisateurs et aux développeurs d'utiliser et de créer des AA sur la plate-forme Ethereum. Bien que ce cadre soit une avancée importante, plusieurs défis et incertitudes doivent encore ê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 de @niftytable), seuls 65 k+ UserOperations sont exécutés sur la chaîne, dont 90% proviennent de Polygon. Par conséquent, le nombre d'opérations utilisateur effectuées à l'heure actuelle est encore très faible, dont la plupart sont des tests de développeur et seule une petite partie est attribuée aux utilisateurs. Nous notons que les produits qui ont intégré AA sont encore à leurs débuts. Dans le même temps, vous pouvez voir que le bénéfice de Bundler est négatif (-700 en termes MATIC). En effet, certains bundlers sur Polygon ne calculent pas correctement le gaz de pré-validation. Cet algorithme de vérification doit encore être optimisé.
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. Une fois que Bundler a regroupé plusieurs UserOperations, Bundler simule d'abord la transaction pour vérifier si elle sera annulée, puis calcule si les frais de gaz renvoyés par l'expéditeur ou le payeur sont supérieurs aux frais de gaz payés par la transaction. S'il est rentable, Bundler soumet ce lot d'opérations utilisateur ensemble en tant que transaction au constructeur de blocs. Cependant, la transaction peut toujours échouer, ce qui fait que le Bundler paie les frais de gaz mais ne reçoit pas le gaz du point d'entrée. Par exemple, un utilisateur peut envoyer des actions à différents Bundlers. Les bundlers sont prêts à soumettre toutes les opérations en chaîne si elles sont rentables et que leur simulation réussit. Cela signifie que si une UserOperation est soumise par différents Bundlers en même temps. Une seule transaction réussira, un seul Bundler recevra des frais de gaz d'EntryPoint, tous les autres Bundlers perdront du gaz en raison d'une défaillance de la chaîne. Bien que l'on puisse affirmer que les utilisateurs ne devraient pas faire cela, un tel comportement serait considéré comme une attaque malveillante et que Bundler pourrait interdire l'adresse de l'expéditeur et rejeter toutes les demandes futures de cette adresse, ce n'est pas une approche raisonnable car les utilisateurs Cette opération peut avoir été soumis par inadvertance. Ces problèmes doivent être correctement traités dans le code, éventuellement en développant un réseau de mempool public inachevé. De plus, en raison de fluctuations soudaines du gaz, les bundlers peuvent subir des pertes même si les transactions ont été soumises avec succès et simulées comme rentables.
Une autre chose est la valeur extractible maximale (MEV) qui peut être extraite 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 peuvent extraire en manipulant l'ordre des transactions dans un bloc ou en incluant leurs propres transactions dans un bloc. Quelqu'un a-t-il remarqué que la logique de MEV peut également s'appliquer à AA, puisque les Bundlers sont libres de commander des UserOperations ? Cependant, cela est conditionnel, suffisamment d'opérations utilisateur doivent être regroupées pour que les bundlers puissent extraire MEV. Maintenant, l'ensemble du marché AA en est encore à ses balbutiements, donc Bundler MEV peut également être considéré à ses balbutiements. En général, l'industrie AA peut se développer dans deux directions : l'une est similaire au réseau principal Ethereum, avec des participants comme Flashbots, Ultra Sound et BloXroute, et l'autre consiste à former un consensus Bundler pour imposer un ordre équitable. Cette dernière approche éliminerait complètement la possibilité de MEV dans AA.
développement futur
pool de mémoire public
Bien que l'écosystème AA fonctionne déjà, il reste encore beaucoup de travail de développement à faire. En regardant l'ensemble de l'écosystème AA, la plus grande lacune à 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. Le réseau p2p du mempool public devrait être disponible en août de cette année.
Algorithme d'emballage
En cours de route, la Fondation Ethereum a financé plusieurs équipes de développement AA composées de développeurs dévoués et travailleurs. A ce jour, plusieurs versions du client Bundler ont été développées et sont désormais disponibles. Certains d'entre eux sont très développés en termes de maturité du produit. 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), et bien d'autres.
Maintenant, plongeons dans l'algorithme d'emballage plus en détail. Actuellement, en raison du faible nombre d'opérations utilisateur, les bundlers peuvent utiliser une logique d'empaquetage simple et directe, comme des intervalles de temps fixes ou le 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 : sans protocole de consensus comme une blockchain, les Bundlers forment une forêt sombre, chacun priorisant le travail en fonction de ses propres intérêts, et se faisant concurrence. Les mempools privés, correspondant aux mempools publics, sont plus susceptibles de venir en premier. Parce que lorsqu'il n'est pas rentable de regrouper UserOperations à partir du mempool public, il peut devenir rentable de regrouper UserOperations dans le mempool privé. De cette façon, Bundler a un avantage concurrentiel en matière d'emballage.
De plus, à mesure que le mempool public est progressivement accepté, les UserOperations qu'il contient auront des caractéristiques différentes, telles que différentes attentes en matière de profit du gaz et la complexité de l'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 uniques. Emballer plus d'opérations utilisateur a le potentiel de générer des profits plus importants, mais 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. Les UserOperations moins packagées font le contraire. Les bundlers doivent définir leurs propres paramètres de gaz de transaction, ce qui affectera la priorité des constructeurs de blocs pour exécuter les transactions. Dans des conditions de prix et de volatilité du gaz de marché différentes, les bundlers peuvent avoir des stratégies de conditionnement différentes. Dans le même temps, ces calculs de vérification et de politique doivent consommer des ressources informatiques matérielles locales et des ressources de nœud de chaîne de blocs. Les bundlers doivent également s'assurer que les utilisateurs ont une bonne expérience et qu'ils ne sont pas confrontés à des retards excessifs après avoir soumis une UserOperation.
Bien que les solutions à ces défis restent incertaines, nous pouvons être sûrs que l'évolution de l'industrie AA et les efforts combinés des développeurs finiront par trouver des solutions. En tant que constructeur d'infrastructures, BlockPI espère résoudre les problèmes de développement de l'industrie AA, que ce soit en tant que développeur ou pour fournir une infrastructure AA conviviale à d'autres développeurs.
L'infrastructure doit s'adapter
AA résume divers rôles dans le comportement des transactions sur la chaîne, y compris les expéditeurs, les groupeurs, les payeurs de gaz, les portefeuilles de contrats et les signataires, permettant aux utilisateurs d'avoir un degré de liberté plus élevé lors de l'utilisation de la blockchain. En outre, les services au sein d'un AA peuvent être déployés séparément.
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, à savoir 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 assurer une bonne expérience utilisateur. Plus précisément, les fournisseurs d'infrastructure doivent intégrer divers clients Bundler pour garantir la robustesse des services Bundler. Ces clients Bundler sont développés dans différents langages de programmation, mais ils fournissent tous un ensemble standard de méthodes JSON RPC spécifiées par l'équipe principale ERC-4337. Actuellement, il n'y a pas beaucoup de méthodes disponibles, mais d'autres méthodes seront ajoutées à l'avenir. Les fournisseurs de services d'infrastructure doivent fournir un support continu et complet pour ces API.
De plus, il est important d'optimiser et d'adapter la relation entre l'API Bundler et le RPC client du nœud d'origine. Nous savons que le client de nœud actuel n'est pas bien optimisé pour la réactivité et l'adaptabilité d'AA. Certaines méthodes de l'API Bundler nécessitent l'index de données d'AA pour fonctionner. Par exemple, la recherche d'une UserOperation par hachage nécessite l'indexation de toutes les UserOperations. Sinon, la consommation matérielle de cette requête unique sera très élevée, et la requête mettra beaucoup de temps à revenir.
En outre, les fournisseurs d'infrastructures doivent également intégrer différents services Paymaster pour offrir aux clients une expérience utilisateur sans essence et leur proposer différentes options de service. Cela nécessite une bonne communication et une bonne intégration avec les fournisseurs de services Paymaster tiers.En même temps, selon la demande du marché, des solutions d'intégration plus pratiques basées sur les services Paymaster existants peuvent également être conçues. D'autres services, tels que les signatures agrégées, les fabriques de portefeuilles, etc., sont également des orientations possibles pour le développement et l'intégration futurs.
Actuellement, BlockPI essaie en fait d'atteindre tous les objectifs ci-dessus. De plus, nous communiquons avec presque tous les clients Bundler et les fournisseurs de services Paymaster de la communauté, et avons fait de l'intégration du service AA dans le réseau BlockPI notre priorité absolue. Nous avons également des discussions approfondies avec les développeurs de portefeuilles AA pour comprendre les besoins des utilisateurs. Par conséquent, nous nous félicitons sincèrement de la coopération et des échanges avec tous les bundlers, paymasters et wallets à mesure que nous progressons. Notre objectif global est de construire et de développer l'écosystème AA avec d'autres, en pilotant sa croissance et son développement au mieux de nos capacités. En travaillant ensemble, nous espérons apporter une contribution significative à l'industrie des AA dans son ensemble et soutenir son développement continu. Parce qu'après tout, notre mission ultime est d'être un pionnier dans l'industrie et de promouvoir le développement de l'écosystème AA afin que les utilisateurs du web2 puissent profiter de leur expérience blockchain sans barrières.
Résumer
Du point de vue des AA, nous sommes à un nouveau moment historique. Bien que nous ayons des routes pavées sur le boulevard, il n'y a pas encore beaucoup d'usagers. À l'heure actuelle, l'application des AA en est encore à ses balbutiements. ERC-4337 fournit un cadre puissant permettant aux utilisateurs et aux développeurs d'utiliser et de créer des AA sur la plate-forme Ethereum. Cependant, il reste encore de nombreux défis et incertitudes à résoudre.
Le fournisseur d'infrastructure d'AA doit fournir le service Bundler et le service Paymaster à ses utilisateurs, et doit intégrer divers clients Bundler et fournisseurs de services Paymaster pour assurer la robustesse du service. Pour optimiser la réactivité entre l'API et les clients de nœud, les données AA peuvent devoir être indexées afin de réduire la consommation de matériel pour une seule requête. Afin d'offrir une meilleure expérience utilisateur, les fournisseurs d'infrastructure doivent également offrir aux utilisateurs davantage d'options de service.
À l'avenir, à mesure que l'écosystème AA continuera de croître et que des mempools publics émergeront, la stratégie de sélection et de conditionnement des UserOperations deviendra plus complexe. Chaque Bundler priorise son travail en fonction de ses propres intérêts et est en concurrence avec les autres Bundlers. Les bundlers doivent définir leurs propres paramètres de gaz de transaction, qui affectent la priorité des constructeurs de blocs pour exécuter les transactions. Dans des conditions de prix et de volatilité du gaz de marché différentes, les bundlers peuvent avoir des stratégies de conditionnement différentes.
Bien que les solutions à ces défis soient incertaines, nous pouvons être sûrs que l'évolution de l'industrie AA et les efforts combinés des développeurs finiront par trouver des solutions. En tant que constructeur d'infrastructures, BlockPI espère être un résolveur de problèmes dans le développement de l'industrie AA, soit en tant que développeur, soit en fournissant une infrastructure AA conviviale pour d'autres développeurs. Notre mission est de promouvoir le développement de l'écosystème AA afin que les utilisateurs Web2 puissent profiter de leur expérience blockchain sans barrières.