Depuis 2022, l'abstraction de compte est un sujet largement discuté, et le cadre dans le domaine de l'abstraction de compte centré autour de l'EIP-4337 semble être devenu un consensus de l'industrie. La popularité du concept d'intention a souligné l'importance de ces composants d'interaction utilisateur à faible seuil.

Cependant, l'EIP-4337 présente toujours des points douloureux tels que la fragmentation des comptes intelligents et une expérience utilisateur fortement fragmentée de l'abstraction de compte inter-chaîne. Cet article explore comment promouvoir davantage le développement du domaine de l'abstraction de compte dans le cadre de l'EIP-4337, en prenant des projets tels que Biconomy, Safe Core et Particle Network comme exemples.

Comprendre le concept d'abstraction de compte du point de vue de l'abstraction du flux de transaction

En ce qui concerne l’abstraction des comptes, Vitalik a souligné à plusieurs reprises qu’il s’agit d’une condition nécessaire pour abaisser le seuil des utilisateurs d’Ethereum et parvenir à une adoption massive. Sa vision principale est de permettre aux utilisateurs de personnaliser la méthode de vérification de la signature et de profiter du paiement du gaz, et peuvent initier une transaction sur la chaîne sans aucun actif (communément appelée transaction sans gaz). Ce n’est qu’en réalisant ces conditions préalables que les applications Web3 peuvent améliorer leurs taux de conversion des utilisateurs. Bien que les précédentes propositions abstraites sans compte ou les portefeuilles de contrats intelligents puissent permettre d’obtenir des expériences similaires, ils sont loin d’être suffisamment flexibles et efficaces. Par exemple, Gnosis Safe nécessite toujours une adresse EOA pour déclencher des transactions, et les coûts de gaz qu’il implique sont extrêmement élevés. L’abstraction des comptes vise à optimiser la structure sous-jacente des comptes de contrats intelligents, ouvrant ainsi la voie à la prochaine génération de systèmes de comptes intelligents. Mais si nous examinons les propositions d’abstraction de compte réelles, nous constaterons qu’elles ne se concentrent pas sur le modèle de compte lui-même. Par exemple, les propositions liées à l’abstraction de compte telles que EIP-86, EIP-4337 et EIP-6900 se concentrent sur l’abstraction/modularisation de l’ensemble du processus de traitement d’une transaction, de l’initiation à la réception par les nœuds, ainsi que sur la vérification de la signature, le paiement du gaz, etc., plutôt que de se concentrer sur l’abstraction de la structure de compte en tant que telle. Une abstraction de la structure du compte. Par conséquent, il semble plus approprié d’appeler les différentes propositions actuelles des « abstractions de flux de transactions ». Si nous comprenons ces propositions d’abstraction de compte bien connues du point de vue de l’abstraction des flux de transactions, nous pouvons plus facilement saisir leurs principaux points : ce type d’abstraction des transactions vise en fait à apporter l’expérience utilisateur de l’entrée au niveau Web2 et de l’utilisation du produit dans le système Ethereum. Cela peut prendre la forme de listes noires/blanches, d’initier des transactions sans vérification d’identité dans un certain laps de temps, de transactions sans gaz, de paiements en monnaie fiduciaire, etc.

(Source de l'image: Zengo)

Cependant, certains pourraient demander : ces choses ne pourraient-elles pas être réalisées avec les portefeuilles de contrats intelligents existants dans le passé ? Quelle est la valeur des solutions d'abstraction de compte telles que l'EIP-4337 ?

Essence de l'EIP-4337 : Solutions optimales locales pour l'abstraction de compte dans l'écosystème Ethereum

Comme le souligne la question ci-dessus, même si les portefeuilles intelligents précédents pouvaient effectivement accomplir les fonctionnalités mentionnées, les méthodes de mise en œuvre étaient généralement rudimentaires et reposaient souvent sur des infrastructures tierces hautement centralisées. Par exemple, dans le passé, la solution de relais de gaz nécessitait l'introduction de nœuds relais tiers (EIP-2771). De plus, il y avait un manque de normes unifiées entre différents portefeuilles intelligents, ce qui a entravé le développement et le déploiement de composants complémentaires. La demande principale de divers EIP liés à l'abstraction de compte est de remédier à ces lacunes présentes dans différents projets de portefeuille en introduisant un cadre normalisé conçu spécifiquement pour les portefeuilles de contrats intelligents. Cette avancée vise à déplacer la structure de compte au sein de l'écosystème Ethereum d'une structure fonctionnelle de base vers une structure intelligente plus sophistiquée offrant des capacités supérieures.

(Source de l'image: Springer Link)

Cela ressemble à la situation avant ERC-20 ou ERC-721, où les méthodes de mise en œuvre, les fonctionnalités et les fonctions/interfaces fournies de nombreux jetons étaient incohérentes. De telles incohérences ont entravé le développement d'infrastructures tierces complémentaires et d'audits de code (il est difficile d'imaginer comment les applications DeFi auraient pu prospérer jusqu'à leur niveau actuel sans le protocole ERC-20).

Les normes de mise en œuvre des protocoles/fonctionnalités normalisés sont des préalables à la conception modulaire, et le développement modulaire est presque une condition préalable à tout domaine visant une croissance dynamique (la division du travail étant le premier principe pour améliorer l'efficacité).

Finalement, EIP-4337 se démarque.

EIP-4337 est une solution optimale locale, mais plusieurs perspectives au sein de son cadre doivent être optimisées

EIP-4337 définit un ensemble complet de normes d'interface, clarifiant les modules attendus dans les portefeuilles intelligents qui adhèrent au protocole 4337 et les fonctions/interfaces que chaque module doit implémenter. Par exemple, quelles fonctions appelables les composants tels que le regroupeur, les points d'entrée et le paymaster doivent offrir externement. Avec ces directives en place, les interactions entre les différents composants deviennent plus claires, facilitant l'intégration des idées de conception modulaire dans la conception de l'abstraction de compte et des portefeuilles intelligents. Les développeurs travaillant sur les modules de portefeuille en bénéficient également de manière significative. Cependant, du seul point de vue de l'utilisateur, la valeur apportée par le paradigme de développement modulaire de portefeuille intelligent pourrait ne pas être immédiatement évidente, car les changements dans les portefeuilles d'abstraction de compte eux-mêmes pourraient ne pas être palpables à court terme. Cependant, à moyen et long terme, la valeur des protocoles comme EIP-4337 ressemble à celle de ERC-20 et ERC-721. Il pose les bases du développement à long terme des portefeuilles d'abstraction de compte, marquant une étape importante. Néanmoins, EIP-4337 présente encore de nombreux problèmes non résolus, tels que:

1. L'abstraction de compte n'est pas suffisamment facile à intégrer, ce qui amène différents développeurs à "réinventer la roue" involontairement.

2. Compatibilité médiocre entre les modules de compte, entraînant un écosystème fragmenté.

3. Fragmentation élevée des écosystèmes d'abstraction de compte à travers différentes chaînes, ce qui rend difficile d'offrir une expérience unifiée et de haute qualité pour les utilisateurs finaux et les développeurs.

Ci-dessous, nous allons plonger dans les solutions à ces problèmes.

Solution d'optimisation 1 : Le plug-in d'abstraction de compte deviendra la configuration de base

L'un des points centraux des discussions actuelles concernant l'abstraction de compte est d'améliorer la modularisation des portefeuilles d'abstraction de compte et de affiner davantage la granularité de chaque module. Par exemple, Biconomy, basé sur l'EIP-4337 (l'EIP-6900 plus fin sera introduit à l'avenir), propose l'abstraction de compte plug-and-play pour propulser davantage le développement modulaire de l'écosystème d'abstraction de compte.

(Source de l'image : Biconomy)

Le soi-disant plugin d'abstraction de compte consiste en réalité à établir un protocole qui définit explicitement les modules clés impliqués dans un portefeuille de contrat intelligent, en décrivant les interfaces/fonctions que ces modules devraient implémenter, et en spécifiant les noms et les méthodes d'appel de ces interfaces. Les développeurs tiers créeront ensuite des composants avec des détails variés basés sur leurs idées, en veillant à ce que ces composants soient conformes aux exigences énoncées dans le protocole.

La v2 de Biconomy, en s'appuyant sur l'EIP-4337 comme cadre de protocole, a élaboré des normes plus détaillées et introduit un ensemble d'interfaces non mentionnées dans l'EIP-4337. En déclarant les fonctionnalités que les regroupeurs, les portefeuilles de contrats intelligents, les maîtres de paiement et autres modules doivent posséder, Biconomy permet aux développeurs tiers d'implémenter des modules avec les mêmes fonctionnalités mais des versions différentes en utilisant des détails de code différents, tant qu'ils respectent les directives du protocole établies par Biconomy (compatibles avec l'EIP-4337).

(Les normes d'interface proposées par Biconomy indiquent les fonctions que les développeurs de modules tiers devraient implémenter dans leurs modules pour les appels externes). De plus, Biconomy a introduit le slogan de « Module Store », en promouvant activement le lancement d'un SDK de module d'abstraction de compte tout en encourageant les développeurs à soumettre leurs propres modules d'abstraction de compte conçus. Cette initiative vise à promouvoir le « module en tant que service », permettant à tous les projets de portefeuille adhérant au protocole EIP-4337 d'adopter directement ces modules d'abstraction de compte développés à l'externe. Les utilisateurs ont désormais un choix plus diversifié quant aux modules à utiliser lors de la création de comptes intelligents via l'interface utilisateur.

La modularité facilite non seulement la division du travail, mais permet également aux utilisateurs de changer ou d'ajouter/supprimer rapidement certaines fonctions dans un portefeuille intelligent. Autrement dit, cela permet de raffiner la granularité des composants. Biconomy souligne que plus le degré de modularité dans un portefeuille de contrat intelligent est élevé, moins de modifications seront nécessaires lors de sa mise à jour ou de sa mise à niveau. Il n'est pas nécessaire de mettre à jour le contrat de portefeuille de contrat intelligent existant de l'utilisateur ou d'utiliser DelegateCall, seuls certains modules externes doivent être mis à jour, ce qui facilite le remplacement de certains composants pour différents utilisateurs ou développeurs.

Dans le prochain schéma d'abstraction de compte mis à jour de Biconomy, ils prendront également en considération l'EIP-6900, qui est plus propice à la modularisation que l'EIP-4337.

Solution d'optimisation 2 : Segmentation des modules plus granulaire pour résoudre les problèmes de fragmentation des comptes

Concernant l'EIP-6900, Safe (anciennement Gnosis Safe) a publié un livre blanc sur le protocole Safe Core en août de cette année, s'inspirant largement de l'EIP-6900.

(Schéma EIP-6900) L’EIP-6900 met en évidence un problème répandu dans l’abstraction modulaire actuelle des comptes, à savoir la « fragmentation » des comptes, ou le problème de l’îlot. Par exemple, bien que différents fournisseurs de modules d’abstraction de compte ou diverses DApps puissent être compatibles avec EIP-4337, son niveau d’abstraction entre différents modules est insuffisant, avec une granularité relativement faible. Ce scénario offre une liberté « excessive » aux développeurs de modules de compte intelligent (le compte intelligent est le composant principal qui stocke les informations sur l’utilisateur, enregistre la validation des transactions personnalisées et gère la logique de paiement du gaz) pour créer des modules avec des attributs uniques. Par conséquent, au fil du temps, les différents projets de portefeuille ont tendance à concevoir des modules de compte intelligents avec des propriétés distinctes. Cette tendance oblige d’autres fournisseurs de modules d’abstraction de comptes à donner la priorité à la compatibilité avec des fournisseurs de modules de comptes intelligents spécifiques, formant progressivement des chaînes d’approvisionnement fixes en amont et en aval. Cela conduit inévitablement à la fragmentation et à l’isolement de l’écosystème des modules d’abstraction de compte (similaire aux débuts de l’industrie informatique, où les développeurs de systèmes d’exploitation devaient tenir compte de la compatibilité avec le matériel de différents fabricants). Pour résoudre le problème de la fragmentation de l’écosystème et améliorer la compatibilité entre les modules d’abstraction de compte développés par divers fournisseurs, l’approche optimale consiste à abstraire davantage les comptes de portefeuilles de contrats intelligents et à affiner la granularité de la segmentation des modules. Conformément aux principes énoncés dans l’EIP-6900, le livre blanc Safe Core Protocol a apporté des optimisations détaillées aux comptes intelligents (comptes de portefeuille intelligents des utilisateurs). Le protocole Safe Core décompose les modules pouvant être appelés au sein de chaque compte de portefeuille intelligent en différentes catégories telles que les plug-ins, les hooks, les validateurs de signature, les processeurs de fonctions, etc. Les modules de compte intelligents visent à être aussi légers que possible, ne stockant que les données et les fonctions essentielles, tout en déléguant les fonctions mobiles à des « processeurs de fonctions » ou à des modules segmentés similaires. Cette approche s’aligne sur le principe du rasoir d’Occam : « les entités ne doivent pas être multipliées inutilement ». Si les comptes intelligents eux-mêmes sont suffisamment légers et n’impliquent pas de détails trop compliqués, les comptes intelligents développés par différents fournisseurs présenteront des structures internes plus étroites et une plus grande compatibilité.

Le protocole Safe Core introduit également un registre (similaire à l'App Store de l'iPhone), qui contient tous les modules approuvés et disponibles. Les utilisateurs peuvent choisir quels modules activer, et chaque fois qu'un nouveau module est activé, il doit être traité par le Manger.

En général, UserOperation déclenchera d'abord un plugin, puis le gestionnaire vérifiera si l'état du plugin est normal (enregistré dans le registre). Si c'est le cas, la demande du plugin sera autorisée. Si nécessaire, le plugin appellera certaines fonctions fournies par Hook ou choisira de ne pas le faire. Ensuite, l'état du compte intelligent impliqué dans UserOperation sera modifié.

Grâce à la méthode de segmentation des modules à grain fin et au processus de planification mentionnés ci-dessus, le protocole Safe Core tente de mettre en œuvre un ensemble de protocoles d'interopérabilité de modules d'abstraction de compte open-source. L'idée principale est de rendre les comptes intelligents légers et aussi simples qu'un compte EOA pour améliorer la compatibilité entre les modules de compte intelligent de différents fournisseurs.

Solution d'optimisation 3 : Abstraction de compte omnichaîne pour des comptes unifiés sur différentes chaînes

Cependant, malgré les solutions susmentionnées, il reste un problème significatif à résoudre : les différentes chaînes et diverses solutions de couche 2 avancent des détails de mise en œuvre de l'abstraction de compte divergents, dont beaucoup entrent en conflit avec l'EIP-4337, tels que zkSync Era, Starknet, Flow, etc. Cela fragmente l'expérience utilisateur du portefeuille. Par exemple, les adresses de portefeuille intelligent sur Starknet ne peuvent pas être unifiées avec celles sur Arbitrum. De plus, dans un environnement multi-chaînes, les utilisateurs ont déployé indépendamment des comptes intelligents sur différentes chaînes, et leurs données utilisateur correspondantes sont souvent dispersées dans ces contrats. Si les données utilisateur telles que les clés doivent être mises à jour, des transactions doivent être lancées à plusieurs reprises sur plusieurs chaînes, ce qui rend difficile d'assurer la cohérence du Compte Intelligent. Vitalik a proposé précédemment une solution de compte intelligent unifiée sur l'ensemble de la chaîne et facile à gérer. Cette solution utilise Ethereum ou un ZK-Rollup hautement sécurisé comme chaîne source et déploie le contrat Keystore pour stocker la clé globale de l'utilisateur. Ensuite, tous les comptes de contrat intelligent sur la couche 2 partagent la clé globale stockée dans le contrat Keystore.

(Source de l'image: https://vitalik.ca/general/2023/06/20/deeperdive.html)

Cependant, cette solution engendre des coûts importants. Chaque fois que les clés globales enregistrées dans le contrat Keystore sur la chaîne source changent, chaque compte sur L2/la chaîne cible doit synchroniser les nouvelles clés par le biais d’interactions inter-chaînes. La surcharge des interactions inter-chaînes entre Ethereum et la couche 2 est trop élevée pour les utilisateurs. De plus, il est essentiel de noter que les comptes de contrats intelligents diffèrent des EOA. Ces derniers, en raison de leur approche unique de génération d’adresses, sont intrinsèquement unifiés sur plusieurs chaînes EVM. Mais les comptes de contrats intelligents sont entièrement différents, ce qui rend difficile pour les utilisateurs d’obtenir des comptes de contrats intelligents avec les mêmes adresses sur différentes chaînes. En réponse, Particle Network a proposé sa propre méthode. Alors que l’idée générale de leur méthode s’aligne sur le concept de Vitalik, en se concentrant sur la séparation du stockage et du code des comptes intelligents, Particle Network a l’intention d’utiliser une chaîne indépendante, Particle Network Chain, comme base de données de stockage complète pour les comptes intelligents. Ils prévoient de synchroniser les modifications apportées au stockage d’un compte avec le stockage local du compte sur d’autres chaînes via des solutions de messagerie inter-chaînes tierces (telles que LayerZero, CCIP, Axelar, Connext, etc.).

(Structure d'abstraction de compte multi-chaîne du réseau de particules)

En particulier, le système d'abstraction de compte Omnichain du réseau Particle Network permet aux utilisateurs d'avoir une adresse de compte de contrat intelligent unifiée sur différentes chaînes EVM. Cela nécessite le déploiement d'un ensemble de contrats de déploiement sur différentes chaînes ; les utilisateurs doivent déclencher la génération de nouveaux comptes sur la chaîne Particle Network, puis la chaîne Particle déclenchera les contrats de déploiement sur toutes les chaînes pour garantir que les adresses de compte de contrat intelligent générées pour les utilisateurs sur différentes chaînes sont cohérentes. Alternativement, les utilisateurs peuvent participer à des interactions multi-chaînes via des contrats sur la chaîne Particle sans être conscients des autres chaînes, et peuvent utiliser le jeton de gaz unifié comme méthode de paiement universelle pour les frais de transaction.

L'abstraction de compte Omnichain permet également des opérations transversales d'utilisateurs en initiant des transactions sur la chaîne cible via des opérations d'utilisateurs et en payant le gaz correspondant sur la chaîne source. Par exemple, cela permet aux utilisateurs d'acheter des NFT sur Base en utilisant le $USDC de Polygon.

Cependant, la solution du réseau Particle Network nécessite un haut degré de collaboration entre le Contrat du Déployeur et le composant de messagerie inter-chaînes pour parvenir à la synchronisation des comptes multi-chaînes et du stockage de la chaîne source. Cela place en fait des exigences plus élevées sur l'oracle ou le pont de messagerie inter-chaînes utilisé (ce qui semble être un problème courant dans toutes les solutions liées à l'interopérabilité omnichaîne). Cependant, la synchronisation du compte inter-chaînes de l'utilisateur peut configurer de manière flexible la combinaison de différents Ponts de Messagerie, au lieu de dépendre d'un seul pont. Par exemple, il peut être configuré comme une stratégie 2/3, en se basant sur la confirmation de deux des couches LayerZero, Axelar et Connext pour confirmer les changements de stockage sur la chaîne cible. Cela pourrait être une solution potentielle au problème de dépendance à un seul point.

L'interopérabilité transparente Omnichain à travers EVM et non-EVM est une étape supplémentaire vers l'abstraction de compte Omnichain au sein de l'écosystème Ethereum

Malgré la gestion des clés et l’unification des comptes sur l’ensemble des chaînes EVM, il existe encore des domaines d’optimisation au sein de l’abstraction des comptes omnichain. Les chaînes non compatibles EVM telles que Aptos, Solana, Sui, etc., ne peuvent pas garantir que les adresses de compte des contrats intelligents sont cohérentes avec celles des chaînes EVM. De plus, les chaînes non-EVM auraient du mal à adopter le concept d’abstraction de compte inter-chaînes proposé dans la discussion précédente si elles n’implémentent pas le protocole ERC-4337 avec une solution équivalente. De plus, il y a place à l’amélioration dans les projets de portefeuille compatibles avec EIP-4337. Les nœuds Bundler utilisés par la plupart des portefeuilles intelligents sont officiellement gérés indépendamment, parfois même de manière isolée les uns des autres, ce qui crée divers risques (tels que des risques liés à la résistance à la censure et à la disponibilité). La construction d’une interface frontale unifiée couvrant la majorité des chaînes s’avère extrêmement difficile. Une solution potentielle consiste à introduire une conception centrée sur l’intention, en ajoutant une couche supplémentaire au-dessus de l’abstraction des comptes omnichain. Cette couche intègre l’écosystème EIP-4337 d’Ethereum ou les fonctions d’abstraction de compte natives d’autres chaînes (par exemple, zkSync) en tant qu’instances spécifiques sous le type Solver/Reactor, la tâche de sélectionner le solveur approprié étant une responsabilité de niveau supérieur. En prenant l’exemple de Particle Network, il propose une implémentation centrée sur l’intention concise et abstraite. Les différents projets d’abstraction de compte sont simplement des instances incluses dans la catégorie Solveur dans le schéma d’intention. Tout d’abord, l’interface utilisateur transforme les requêtes en langage naturel ou toute interaction de l’utilisateur en descriptions programmatiques spécifiques englobant les contraintes d’entrée et de sortie (en d’autres termes, ce sont des conditions qui permettent des entrées qui répondent aux exigences de l’utilisateur et des résultats de sortie se situant dans une plage spécifique). Par la suite, au sein du réseau de solveurs, des solveurs spécifiques transfèrent des transactions contenant des contraintes d’entrée et de sortie précises aux contrats de solveur déployés sur la chaîne (les solveurs englobent non seulement l’infrastructure de nœuds, mais également les composants de contrat on-chain). Le contrat Solver transmet la directive Intent au contrat Reactor (gestion des comptes utilisateurs on-chain), déléguant à ce dernier le soin d’appeler d’autres modules pour réaliser l’interaction finale. Cette infrastructure permet aux demandes des utilisateurs d’être initialement traitées par le réseau du solveur, ce qui évite aux utilisateurs d’avoir à comprendre les chaînes sous-jacentes ou les différents schémas d’abstraction des comptes, une tâche déléguée au solveur pour la construction de solutions spécifiques. Cependant, ces conceptualisations sont encore des cadres théoriques, avec des détails d’implémentation en attente d’une élaboration plus approfondie par Particle Network. Il est évident qu’un marché concurrentiel des solveurs émergera à l’avenir, permettant aux utilisateurs de lancer des enchères lorsque plusieurs solveurs proposent des solutions distinctes. Grâce à des transactions simulées localement, la solution optimale peut être sélectionnée et des incitations correspondantes peuvent être fournies à leur solveur. La structure d’incitation sera façonnée par les concepteurs de protocoles du réseau Solver (Particle Network vise à utiliser les jetons PNT comme jetons d’incitation pour son marché d’enchères Solver). À l’heure actuelle, l’essence de l’intention masque les détails complexes des couches inférieures et abstrait une couche supérieure. Cette conception en couches, qui ressemble au protocole TCP/IP, est essentielle pour améliorer à la fois l’expérience utilisateur et l’expérience des développeurs grâce à une interopérabilité transparente entre les chaînes.

Adopter l’adoption massive de l’abstraction de compte

Après avoir optimisé le cadre EIP-4337 au sein de l'écosystème Ethereum sous divers aspects et favorisé l'interopérabilité transparente entre les écosystèmes Ethereum et non-Ethereum, nous croyons que, pour soutenir l'adoption massive de l'abstraction de compte, nous avons encore besoin d'un produit qui couvre les côtés offre et demande. Ce produit devrait réduire la complexité pour les utilisateurs finaux utilisant divers services de produits Web3 tout en se concentrant sur la réduction des barrières à l'entrée des développeurs. L'un des produits optimaux remplissant ce rôle est la pile de services de portefeuille intelligent modulaire de Particle Network :

Architecture de portefeuille intelligent en tant que service du réseau de particules

• Le service propose une API conviviale, permettant aux développeurs d'intégrer de manière transparente des fonctionnalités d'abstraction de compte modulaire dans leurs applications.
• Les développeurs peuvent utiliser ce service pour créer et gérer des comptes omnichaîne, réaliser des interactions inter-chaînes et utiliser une méthode de paiement de frais unifiée.
• De tels services fourniront aux développeurs un moyen plus flexible et pratique de construire des applications multi-chaînes et de promouvoir l'adoption généralisée de l'abstraction de compte.

En plus des fonctionnalités conviviales pour les développeurs mentionnées ci-dessus, l'aspect le plus crucial de la pile de services de portefeuille intelligent modulaire de Particle Network est qu'elle a construit un écosystème ouvert pour le domaine d'abstraction de compte, basé sur le calcul de signature et orienté vers les développeurs. Aux côtés de leurs propres modules de produits d'abstraction de compte, Particle Network intègre divers types de produits et services d'abstraction de compte. Cette intégration accélère l'adoption de produits et services dans l'ensemble du domaine d'abstraction de compte pour les développeurs.

(Conception modulaire du Smart Wallet-as-a-Service de Particle Network)Laissez la technologie répondre aux besoins des utilisateurs. Après avoir résolu les limites du cadre ERC-4337, l’amélioration de l’expérience des développeurs conduira à l’émergence de plus de produits offrant une excellente expérience utilisateur, accélérant ainsi la transition du Web3 d’une industrie financière favorable aux crypto-punks à une industrie conviviale pour les masses.

Avertissement：

1. Cet article est repris de [Gate.io]Web3 Geek]. Tous les droits d'auteur appartiennent à l'auteur original [Peter Pan, Co-fondateur et CTO de Particle Network & Faust，极客Web3]. Si vous avez des objections à cette réimpression, veuillez contacter le Porte Apprendrel'équipe s'en chargera rapidement.
2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.