作者 :Peter Pan, co-fondateur et directeur technique de Particle Network &Faust,极客Web3
Depuis 2022, l’abstraction des comptes est un sujet largement discuté, et le cadre de l’abstraction des comptes avec EIP-4337 comme noyau semble être devenu un consensus général dans l’industrie. La popularité du concept d’intention a incité à mettre davantage l’accent sur ces composants d’interaction utilisateur à bas seuil.
Cependant, EIP-4337 présente toujours les problèmes de fragmentation des comptes Smart Account et d’expérience utilisateur abstraite très fragmentée des comptes inter-chaînes. **Cet article utilise des projets tels que Biconomy, Safe Core et Particle Network comme exemples pour explorer comment faire progresser le domaine de l’abstraction de compte dans le cadre EIP-4337. **
Comprendre le concept d’abstraction de compte du point de vue de l’abstraction du processus transactionnel
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 obtenir une adoption massive, et sa vision principale est de permettre aux utilisateurs de personnaliser la méthode de vérification de la signature + de profiter du paiement du gaz et d’initier des transactions sur la chaîne sans aucun actif (communément appelées transactions sans gaz). Ce n’est qu’en mettant en œuvre ces conditions préalables que nous pourrons augmenter le taux de conversion des nouveaux utilisateurs d’applications Web3.
Dans le passé, les propositions abstraites hors compte ou les portefeuilles de contrats intelligents, bien qu’ils puissent réaliser une expérience similaire, sont loin d’être flexibles et efficaces, tels que Gnosis Safe nécessite toujours des adresses EOA pour déclencher des transactions, et le coût du gaz est extrêmement élevé.
L’abstraction des comptes vise à optimiser la couche inférieure de la structure des comptes de contrats intelligents afin d’ouvrir la voie à la prochaine génération de systèmes de comptes intelligents.
Mais à partir de la proposition d’abstraction de compte réelle, nous constaterons qu’ils ne se concentrent pas sur le modèle de compte lui-même. Par exemple, l’EIP-86, l’EIP-4337, l’EIP-6900 et d’autres propositions liées à l’abstraction de compte, se concentrent sur l’abstraction/modularité de l’ensemble du processus de traitement d’une transaction, de l’initiation à la réception du nœud, à la vérification de la signature, au paiement du gaz, etc., sans vraiment prêter attention à l’abstraction de la structure du compte. Il semble donc plus approprié d’appeler les propositions actuelles des « abstractions transactionnelles ».
Si nous comprenons ces propositions bien connues d’abstraction de compte du point de vue de « l’abstraction du processus de traitement des transactions », nous pouvons plus facilement comprendre leurs principaux points : cette abstraction des transactions veut en fait apporter l’expérience des utilisateurs de niveau Web2 entrant et utilisant des produits dans le système Ethereum, tels que la liste noire/blanche, l’absence de vérification d’identité pour initier des transactions dans un certain temps, l’absence de transactions de gaz, les frais de paiement en monnaie fiduciaire, etc.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-036e81bcee-dd1a6f-69ad2a.webp)
Mais certaines personnes demanderont : ces choses ne peuvent-elles pas être implémentées dans les portefeuilles de contrats intelligents dans le passé ? Quelle est la valeur des schémas abstraits comme EIP-4337 ?
L’essence de l’EIP-4337 : la solution optimale locale d’abstraction de compte dans l’écosystème Ethereum
Comme mentionné dans la question ci-dessus, bien que les portefeuilles intelligents puissent dans le passé remplir les fonctions mentionnées ci-dessus, les méthodes de mise en œuvre sont généralement rudimentaires et reposent souvent sur des installations tierces hautement centralisées. Par exemple, dans le passé, le système de paiement du gaz consistait à introduire un nœud de relais tiers (EIP-2771). De plus, l’absence de normes unifiées entre les différents portefeuilles intelligents n’est pas propice au développement et au déploiement de composants de support. **
L’attrait principal de l’EIP lié à diverses abstractions de compte est de résoudre ces défauts dans différents projets de portefeuille grâce à un cadre standardisé conçu pour les portefeuilles de contrats intelligents, et de promouvoir la structure de compte dans l’écosystème Ethereum d’une structure fonctionnelle de base à une structure intelligente avec un plafond plus élevé.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-c592064fab-dd1a6f-69ad2a.webp)
Par exemple, avant l’avènement de l’ERC-20 ou de l’ERC-721, de nombreuses implémentations de jetons, fonctions et fonctions/interfaces fournies en externe étaient incohérentes, et l'« incohérence » n’était pas propice au développement d’installations tierces et à l’audit de code (il est difficile d’imaginer comment les applications Defi auraient évolué jusqu’à la prospérité actuelle sans le protocole ERC-20).
Des normes standardisées de mise en œuvre de protocoles/fonctionnalités sont une condition préalable aux récits modulaires, et le développement modulaire est une condition préalable à l’épanouissement de presque tous les domaines (la division du travail est le premier principe de l’efficacité). **
En fin de compte, l’EIP-4337 a été mis en avant.
EIP-4337 est une solution locale optimale, mais il y a plusieurs angles dans son cadre qui doivent être optimisés
L’EIP-4337 définit un ensemble de normes d’interface, clarifiant quels modules doivent être au moins pour les portefeuilles intelligents qui suivent le protocole 4337, quelles fonctions/interfaces chaque module doit implémenter, telles que Bundler, EntryPoint, Paymaster et quelles fonctions exécutables doivent être fournies en externe.
Après avoir clarifié ces règles, l’interaction entre les différents composants est plus claire, ce qui est pratique pour introduire des idées de conception modulaire dans l’abstraction du compte et la conception du portefeuille intelligent, et les développeurs du module de portefeuille en bénéficient également grandement. **
Bien sûr, du point de vue de l’utilisateur, la valeur apportée par le paradigme de développement du portefeuille intelligent modulaire n’est pas claire, car les gens ne ressentent pas beaucoup de changement dans le portefeuille abstrait de compte lui-même à court terme. **Mais à moyen et long terme, des protocoles tels que EIP-4337 ont une valeur similaire à celle de l’ERC-20 et de l’ERC-721, qui jettent les bases du développement à long terme des portefeuilles abstraits de compte et constituent des jalons historiques.
Cependant, EIP-4337 a encore de nombreux problèmes non résolus : ** Par exemple :
La fonction d’abstraction de compte n’est pas assez plug-in, et il est facile pour différents développeurs de réinventer la roue ;
La compatibilité du module de compte est médiocre, et l’ensemble du système de compte montre une tendance à la fragmentation de l’écologie ;
L’écologie de l’abstraction des comptes entre les différentes chaînes est très fragmentée, ce qui rend difficile la fourniture d’une expérience unifiée et de haute qualité pour les utilisateurs finaux et les développeurs et l’obtention d’une meilleure expérience utilisateur.
Ci-dessous, nous allons explorer des solutions à ces problèmes.
Direction d’optimisation 1 : La fonction plug-in d’abstraction de compte deviendra la configuration de base
**On peut dire que l’un des principaux points de discussion liés à l’abstraction de compte est maintenant de savoir comment mieux réaliser la modularité du portefeuille abstrait de compte, et réduire la granularité de chaque module en plus de granularité. **
Par exemple, Biconomy propose une narration basée sur EIP-4337 (EIP-6900 avec une granularité plus fine sera introduite à l’avenir) pour promouvoir davantage le développement modulaire de l’écologie de l’abstraction des comptes.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-0204bbbe03-dd1a6f-69ad2a.webp)
Le plug-in de fonction d’abstraction de compte consiste en fait à clarifier à travers un ensemble de protocoles quels sont les modules clés impliqués dans le portefeuille de contrats intelligents, quelles interfaces/fonctions ces modules doivent implémenter, et quels sont les noms de ces interfaces et comment les appeler. Les développeurs tiers développent ensuite des composants avec des détails variables selon leurs propres idées, mais ces composants répondront aux exigences énoncées dans l’accord.
La version V2 de Biconomy, avec EIP-4337 comme épine dorsale du protocole, a développé des normes plus détaillées et ajouté un certain nombre d’interfaces non mentionnées dans 4337. Tout en précisant les fonctions que les modules tels que Bundler, Smart Contract Wallet et Paymaster doivent avoir, Biconomy permet aux développeurs tiers d’implémenter des modules avec les mêmes caractéristiques et différentes versions avec des détails de code différents, à condition qu’ils suivent les détails du protocole énoncés à l’avance par Biconomy (compatible avec EIP-4337).
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-8f424156ac-dd1a6f-69ad2a.webp)
Dans le même temps, Biconomy a également mis en avant le slogan de « Module Store », tout en lançant personnellement le SDK du module d’abstraction de compte, la majorité des développeurs sont encouragés à soumettre leurs propres modules d’abstraction de compte conçus, à développer « Module as a service », ** afin que tous les projets de portefeuille qui suivent le protocole EIP-4337 puissent adopter directement ces modules d’abstraction de compte écrits par des personnes extérieures. Lorsque les utilisateurs créent un compte intelligent via la page d’accueil, ils disposent également d’un choix plus diversifié de modules à utiliser.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-8bb885dd87-dd1a6f-69ad2a.webp)
Bien que la modularité soit pratique pour la division du travail, elle est également pratique pour les utilisateurs de basculer rapidement ou d’ajouter et de supprimer certaines fonctions dans le portefeuille intelligent (pour le dire franchement, il s’agit de diviser la granularité en morceaux plus fins).
Biconomy a souligné que plus un portefeuille de contrats intelligents est modulaire, moins il doit apporter de modifications lors de la mise à jour ou de la mise à niveau (il n’est pas nécessaire de mettre à jour les contrats de portefeuille de contrats intelligents existants des utilisateurs ou d’utiliser DelegateCall, seulement certains modules externes), ce qui facilite le remplacement de certains composants par différents utilisateurs ou développeurs.
Dans la future abstraction des nouveaux comptes de Biconomy, il fera également référence à la proposition EIP-6900, qui est plus modulaire que l’EIP-4337.
Direction d’optimisation 2 : Une segmentation plus fine des modules pour résoudre le problème de fragmentation des comptes
En ce qui concerne la proposition EIP-6900, **Safe (anciennement Gnosis Safe) a en fait lancé un livre blanc sur le protocole Safe Core en août de cette année, et le plus emprunté est l’EIP-6900. **
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-427d430661-dd1a6f-69ad2a.webp)
**L’EIP-6900 souligne que l’un des problèmes de l’abstraction actuelle des comptes modulaires est la « fragmentation » des comptes, ou le problème des silos. Par exemple, bien que différents fournisseurs de modules d’abstraction de compte ou différentes applications DAPP soient compatibles avec EIP-4337, EIP-4337 n’est pas assez élevé pour différents modules, et la granularité est relativement grossière, ce qui laisse un degré de liberté « trop élevé » aux développeurs de modules Smart Account (le compte intelligent est la partie essentielle du stockage des informations utilisateur et de l’enregistrement de la vérification des transactions personnalisées et de la logique de paiement du gaz).
De cette façon, les différentes parties du projet de portefeuille ont tendance à concevoir des modules de compte intelligents avec des propriétés uniques. **À long terme, les autres fournisseurs de modules d’abstraction de compte doivent donner la priorité à ceux qui fournissent des modules Smart Account compatibles et produire lentement une chaîne d’approvisionnement fixe en amont et en aval, ce qui conduira inévitablement à la fragmentation et à la séparation de l’écologie du module d’abstraction de compte. **(C’est comme aux débuts de l’industrie informatique, les développeurs de systèmes d’exploitation devaient se demander avec quel fabricant de matériel informatique était compatible.)
Pour résoudre le problème de la fragmentation écologique et améliorer la compatibilité des modules d’abstraction de compte développés par différents fournisseurs, le meilleur moyen est d’abstraire davantage les comptes de portefeuille de contrats intelligents et de rendre les modules plus granulaires.
Après avoir emprunté les idées de l’EIP-6900, le livre blanc sur le protocole Safe Core a apporté une optimisation plus détaillée de Smart Account (compte de portefeuille intelligent de l’utilisateur). Le protocole Safe Core divise les modules qui peuvent être appelés par chaque compte de portefeuille intelligent en plugins, hooks, vérificateurs de signatures, processeurs de fonctions et autres catégories. **
Le module de compte intelligent est aussi léger que possible, le contrat de compte ne stocke que les données et les fonctions les plus basiques, et les fonctions qui peuvent être déplacées vers l’extérieur sont toutes envoyées au module de subdivision « processeur de fonctions » ou « plugin » pour être implémentées. Cela fait écho au soi-disant principe du rasoir d’Occam : « n’ajoutez pas d’entités à moins que cela ne soit nécessaire ».
Si le compte intelligent lui-même est suffisamment léger et n’implique pas de détails trop encombrants, le compte intelligent développé par différents fabricants sera plus proche dans sa structure interne et plus compatible.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-0cf696a50a-dd1a6f-69ad2a.webp)
Le protocole Safe Core introduit également un registre, similaire à l’App Store de l’iPhone, qui contient tous les modules disponibles approuvés. L’utilisateur peut choisir les modules à activer, et chaque fois qu’un nouveau module est activé, il est géré par le contrat Minger.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cdcab8e9d3-dd1a6f-69ad2a.webp)
En général, UserOperation déclenchera d’abord un plugin de plugin, puis le contrat Manger vérifiera si l’état du plugin est normal (il y a un enregistrement dans le registre), et s’il est normal, il autorisera la requête du plugin. Si nécessaire, les plugins appellent ou non certaines des fonctionnalités fournies par le Hook. Des modifications sont ensuite apportées à l’état du compte intelligent impliqué dans UserOperation.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-6403d3e538-dd1a6f-69ad2a.webp)
Grâce à la méthode de partitionnement de module à grain fin et au processus de planification mentionnés ci-dessus, Safe Core Protocol tente de mettre en œuvre un ensemble de protocoles d’interopérabilité de modules abstraits de compte open source, dont l’idée de base est de rendre Smart Account aussi léger qu’un compte EOA, afin d’améliorer la compatibilité des modules Smart Account améliorés par différents fournisseurs.
Direction d’optimisation 3 : Abstraction des comptes full-chain, pour réaliser des comptes unifiés sur différentes chaines
Mais même avec la solution susmentionnée, il y a toujours un gros problème qui n’a pas été résolu : différentes chaînes et différentes couches 2 favorisent les abstractions de compte avec des détails différents, et beaucoup utilisent des formulaires qui entrent en conflit avec EIP-4337, tels que zkSync Era, Starknet, Flow, etc. Cela a conduit à une fragmentation de l’expérience utilisateur du portefeuille, par exemple l’adresse du portefeuille intelligent de l’utilisateur sur Starknet et l’adresse du portefeuille intelligent sur Arbitrum ne peuvent pas être unifiées du tout.
De plus, dans un environnement multi-chaînes, les utilisateurs ont déployé indépendamment des comptes intelligents sur différentes chaînes, et les données utilisateur correspondantes sont souvent dispersées dans ces contrats. Si les données de l’utilisateur, telles que les clés, doivent être mises à jour, il est nécessaire d’initier des transactions à plusieurs reprises dans plusieurs chaînes, et il est difficile d’assurer la cohérence de Smart Account.
Vitalik lui-même a déjà proposé un ensemble de schémas de comptes intelligents unifiés et faciles à gérer sur toute la chaîne, ** ce schéma utilise Ethereum ou un ZKRollup hautement sécurisé comme chaîne source, déploie le contrat Keystore, stocke la clé globale de l’utilisateur, puis tous les comptes de contrat intelligent de l’utilisateur sur L2 partagent la clé globale stockée dans le contrat Keystore.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-fad1fc1c55-dd1a6f-69ad2a.webp)
Cependant, cette solution est extrêmement coûteuse, c’est-à-dire que chaque fois que la clé globale enregistrée dans le contrat Keystore sur la chaîne source change, chaque compte de la chaîne L2/cible doit synchroniser la nouvelle clé par le biais d’une interaction inter-chaînes. L’interaction inter-chaînes entre Ethereum et L2 est trop coûteuse pour les utilisateurs. Et il convient de noter que les comptes de contrats intelligents sont différents des comptes EOA, qui sont intrinsèquement multi-chaînes unifiés (unifiés entre les chaînes EVM) en raison de leurs méthodes uniques de génération d’adresses, mais les comptes de contrats intelligents sont complètement différents, et il est difficile pour les utilisateurs d’obtenir des comptes de contrats intelligents avec la même adresse sur différentes chaînes.
Particle Network a mis au point sa propre approche à ce sujet. Bien que l’idée générale soit la même que celle de Vitalik, qui est également de séparer le stockage et le code du compte intelligent, Particle Network a l’intention d’utiliser une chaîne indépendante, Particle Network Chain, comme base de données de stockage complète du compte intelligent, par le biais de solutions de messagerie inter-chaînes tierces (LayerZero, CCIP, Axelar, Connext). Synchronisez les modifications apportées par un utilisateur au stockage du compte avec le compte local sur d’autres chaînes.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-2e6d60197a-dd1a6f-69ad2a.webp)
(Abstraction de compte multi-chaînes de Particle Network)
Plus précisément, le système d’abstraction de compte de la chaîne complète de Particle Network exige que les utilisateurs disposent d’une adresse de compte de contrat intelligent unifiée sur différentes chaînes EVM, ce qui 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 de réseau de particules, après quoi la chaîne de particules déclenche le contrat de déploiement sur toutes les chaînes, en veillant à ce que les adresses de compte de contrat intelligent générées pour les utilisateurs de différentes chaînes soient uniformes, ou les utilisateurs peuvent terminer le processus d’interaction multi-chaînes via le contrat sur la chaîne de particules sans être conscients des autres chaînes, et peuvent utiliser Unified Gas Token en tant que méthode de paiement des frais unifiée.
L’abstraction du compte de la chaîne complète rend également possible l’opération utilisateur de Cross-Chain, déclenchant la transaction de la chaîne cible via l’opération utilisateur de la chaîne source et le paiement de gaz correspondant, comme l’utilisation de l’USDC de Polygon pour acheter des NFT sur Base.
Cependant, la solution Particle Network nécessite un degré élevé de collaboration entre le contrat de déploiement et le composant de messagerie inter-chaînes pour réaliser la synchronisation du compte multi-chaînes et du stockage de la chaîne source, qui a en fait des exigences élevées pour l’oracle ou le pont de messages inter-chaînes qu’il utilise (ce problème semble exister dans tous les schémas liés à l’interopérabilité de la chaîne complète).
Toutefois, la synchronisation de compte inter-chaînes de l’utilisateur peut configurer de manière flexible une combinaison de différents ponts de message, plutôt que de s’appuyer uniquement sur un certain pont, telle qu’une stratégie qui peut être configurée en tant que 2/3, en s’appuyant sur la confirmation de deux de LayerZero, Axelar et Connext pour confirmer le changement de stockage sur la chaîne cible, ce qui peut résoudre approximativement ce problème de dépendance à point unique.
L’interopérabilité transparente de la chaîne complète entre les EVM et les non-EVM est un pas de plus dans l’abstraction des comptes de la chaîne complète au sein de l’écosystème Ethereum
Bien qu’il existe une gestion des clés et des comptes unifiés sur l’ensemble de la chaîne EVM, il y a encore place à l’optimisation dans l’abstraction des comptes de la chaîne complète : les chaînes qui ne sont pas compatibles avec EVM, telles que Aptos, Solana, Sui, etc., ne peuvent pas garantir que l’adresse du compte de contrat intelligent générée par l’utilisateur est cohérente avec la chaîne EVM ; Dans le même temps, si la chaîne non-EVM n’implémente pas le protocole EIP-4337 avec un schéma équivalent, il est difficile de suivre le concept abstrait du compte de la chaîne complète proposé par Vitalik et Particle Network ci-dessus.
De plus, le projet de portefeuille compatible EIP-4337 lui-même peut être amélioré. La plupart des nœuds de bundler utilisés par les portefeuilles intelligents sont officiellement gérés indépendamment et ne communiquent même pas entre eux, et de nombreux projets de portefeuilles intelligents forment en fait une chaîne qui leur est propre, ce qui comporte de nombreux risques (résistance à la censure, facilité d’utilisation). La création d’une interface frontale unique et unifiée sur la plupart des chaînes peut s’avérer très difficile. Une solution consiste à introduire une conception centrée sur l’intention, à ajouter une couche au-dessus de l’abstraction de compte de la chaîne complète et à traiter l’écosystème EIP-4337 d’Ethereum ou les installations d’abstraction de compte natives d’une autre chaîne (telles que zkSync) comme des instances spécifiques sous le type Solver/Reactor, et la façon de choisir le bon solveur est une tâche de niveau supérieur. **
En prenant l’exemple de Particle Network, il propose une implémentation concise de l’abstraction-Intention, tandis que les différentes abstractions de compte ne sont qu’une classe d’instances de solutions d’Intention qui sont incluses dans Solver.
Tout d’abord, le front-end utilisateur sera responsable de la transformation des requêtes en langage naturel ou des interactions utilisateur arbitraires en descriptions programmatiques spécifiques, y compris les contraintes d’entrée et les contraintes de sortie (pour le dire crûment, ce sont les conditions d’entrée et les intervalles de résultats de sortie qui répondent aux exigences de l’utilisateur), puis un ou plusieurs solveurs du réseau de solveurs contiendront des contraintes d’entrée et de sortie spécifiques des transactions. Transférer vers les contrats Solver déployés sur la chaîne (le solveur dispose non seulement d’installations de nœud, mais également de parties de contrat sur la chaîne). Le contrat Solveur transmettra l’instruction d’intention au contrat Reactor (qui gère le compte de l’utilisateur sur la chaîne), qui appellera d’autres modules pour terminer l’interaction finale.
La requête de l’utilisateur est d’abord connue par le réseau du solveur, de sorte que l’utilisateur n’a pas besoin de percevoir la chaîne sous-jacente ou la construction de différentes abstractions de compte, et cette partie est laissée au solveur pour construire une solution spécifique.
Bien sûr, ces idées ne sont encore qu’un cadre théorique, et les détails de la mise en œuvre derrière n’ont pas encore été officiellement définis par Particle Network.
À l’heure actuelle, il est clair qu’un marché concurrentiel des solveurs sera engendré à l’avenir, et les utilisateurs peuvent lancer des enchères pour permettre à plusieurs solveurs de proposer différentes solutions, et grâce à la forme de trading simulé local, la meilleure solution peut être sélectionnée et le solveur correspondant peut être incité. La forme de l’incitation dépend des concepteurs de protocole du réseau de solveurs (Particle Network a l’intention d’utiliser des jetons PNT comme jetons d’incitation pour son marché d’enchères de solveurs).
** L’intention actuelle protège essentiellement les détails complexes de la couche inférieure et les abstrait dans une couche supérieure, ** une telle conception en couches avec la nature du protocole TCP / IP est nécessaire pour l’expérience utilisateur et l’expérience du développeur dans le cadre de l’interopérabilité transparente de l’ensemble de la chaîne.
Adopter massivement les abstractions de compte
Lorsque nous optimisons le framework 4337 dans l’écosystème Ethereum sous tous les angles, et que nous promouvons également une interopérabilité transparente entre les écosystèmes Ethereum et non-Ethereum, afin de soutenir l’adoption à grande échelle de l’abstraction des comptes, nous pensons que nous avons toujours besoin d’un produit qui couvre le côté de l’offre et du côté de la demande. Il peut réduire l’utilisation de divers produits et services Web3 par les utilisateurs finaux, tout en se concentrant sur les développeurs de services et en abaissant le seuil pour les développeurs. **
L’un des meilleurs produits pour ce rôle est le portefeuille intelligent modulaire en tant que service de Particle Network :
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-3a8144f020-dd1a6f-69ad2a.webp)
Le service fournit un ensemble d’API faciles à utiliser qui permettent aux développeurs d’intégrer facilement une fonctionnalité d’abstraction de compte modulaire dans leurs applications ;
Les développeurs peuvent utiliser le service pour créer et gérer des comptes de chaîne complète, effectuer des interactions inter-chaînes et utiliser une méthode de paiement des frais unifiée ;
Un tel service offrira aux développeurs un moyen plus flexible et plus pratique de créer des applications multi-chaînes et de promouvoir l’adoption généralisée des abstractions de compte.
En plus des fonctionnalités conviviales ci-dessus pour les développeurs, la caractéristique la plus importante est que le produit Modular Smart Wallet-as-as-as-Service** de Particle Network construit une écologie ouverte basée sur l’informatique de signature et est orienté vers le champ d’abstraction de compte des développeurs, en plus de fournir des modules de produits abstraits de compte auto-développés, intégrant divers types de produits et services abstraits de compte. Il peut rapidement promouvoir l’adoption de produits et services de divers développeurs dans l’ensemble du domaine de l’abstraction de compte.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-20ede5c527-dd1a6f-69ad2a.webp)
Laissez la technologie servir la demande, après avoir résolu les limitations de tous les angles du cadre ERC-4337, l’amélioration de l’expérience des développeurs favorisera davantage de produits avec une excellente expérience utilisateur, accélérant l’industrie Web3 d’une industrie financière favorable aux crypto-punks à une industrie grand public.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle de l’EIP-4337 ?
作者 :Peter Pan, co-fondateur et directeur technique de Particle Network &Faust,极客Web3
Depuis 2022, l’abstraction des comptes est un sujet largement discuté, et le cadre de l’abstraction des comptes avec EIP-4337 comme noyau semble être devenu un consensus général dans l’industrie. La popularité du concept d’intention a incité à mettre davantage l’accent sur ces composants d’interaction utilisateur à bas seuil.
Cependant, EIP-4337 présente toujours les problèmes de fragmentation des comptes Smart Account et d’expérience utilisateur abstraite très fragmentée des comptes inter-chaînes. **Cet article utilise des projets tels que Biconomy, Safe Core et Particle Network comme exemples pour explorer comment faire progresser le domaine de l’abstraction de compte dans le cadre EIP-4337. **
Comprendre le concept d’abstraction de compte du point de vue de l’abstraction du processus transactionnel
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 obtenir une adoption massive, et sa vision principale est de permettre aux utilisateurs de personnaliser la méthode de vérification de la signature + de profiter du paiement du gaz et d’initier des transactions sur la chaîne sans aucun actif (communément appelées transactions sans gaz). Ce n’est qu’en mettant en œuvre ces conditions préalables que nous pourrons augmenter le taux de conversion des nouveaux utilisateurs d’applications Web3.
Dans le passé, les propositions abstraites hors compte ou les portefeuilles de contrats intelligents, bien qu’ils puissent réaliser une expérience similaire, sont loin d’être flexibles et efficaces, tels que Gnosis Safe nécessite toujours des adresses EOA pour déclencher des transactions, et le coût du gaz est extrêmement élevé.
L’abstraction des comptes vise à optimiser la couche inférieure de la structure des comptes de contrats intelligents afin d’ouvrir la voie à la prochaine génération de systèmes de comptes intelligents.
Mais à partir de la proposition d’abstraction de compte réelle, nous constaterons qu’ils ne se concentrent pas sur le modèle de compte lui-même. Par exemple, l’EIP-86, l’EIP-4337, l’EIP-6900 et d’autres propositions liées à l’abstraction de compte, se concentrent sur l’abstraction/modularité de l’ensemble du processus de traitement d’une transaction, de l’initiation à la réception du nœud, à la vérification de la signature, au paiement du gaz, etc., sans vraiment prêter attention à l’abstraction de la structure du compte. Il semble donc plus approprié d’appeler les propositions actuelles des « abstractions transactionnelles ».
Si nous comprenons ces propositions bien connues d’abstraction de compte du point de vue de « l’abstraction du processus de traitement des transactions », nous pouvons plus facilement comprendre leurs principaux points : cette abstraction des transactions veut en fait apporter l’expérience des utilisateurs de niveau Web2 entrant et utilisant des produits dans le système Ethereum, tels que la liste noire/blanche, l’absence de vérification d’identité pour initier des transactions dans un certain temps, l’absence de transactions de gaz, les frais de paiement en monnaie fiduciaire, etc.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-036e81bcee-dd1a6f-69ad2a.webp)
Mais certaines personnes demanderont : ces choses ne peuvent-elles pas être implémentées dans les portefeuilles de contrats intelligents dans le passé ? Quelle est la valeur des schémas abstraits comme EIP-4337 ?
L’essence de l’EIP-4337 : la solution optimale locale d’abstraction de compte dans l’écosystème Ethereum
Comme mentionné dans la question ci-dessus, bien que les portefeuilles intelligents puissent dans le passé remplir les fonctions mentionnées ci-dessus, les méthodes de mise en œuvre sont généralement rudimentaires et reposent souvent sur des installations tierces hautement centralisées. Par exemple, dans le passé, le système de paiement du gaz consistait à introduire un nœud de relais tiers (EIP-2771). De plus, l’absence de normes unifiées entre les différents portefeuilles intelligents n’est pas propice au développement et au déploiement de composants de support. **
L’attrait principal de l’EIP lié à diverses abstractions de compte est de résoudre ces défauts dans différents projets de portefeuille grâce à un cadre standardisé conçu pour les portefeuilles de contrats intelligents, et de promouvoir la structure de compte dans l’écosystème Ethereum d’une structure fonctionnelle de base à une structure intelligente avec un plafond plus élevé.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-c592064fab-dd1a6f-69ad2a.webp)
Par exemple, avant l’avènement de l’ERC-20 ou de l’ERC-721, de nombreuses implémentations de jetons, fonctions et fonctions/interfaces fournies en externe étaient incohérentes, et l'« incohérence » n’était pas propice au développement d’installations tierces et à l’audit de code (il est difficile d’imaginer comment les applications Defi auraient évolué jusqu’à la prospérité actuelle sans le protocole ERC-20).
Des normes standardisées de mise en œuvre de protocoles/fonctionnalités sont une condition préalable aux récits modulaires, et le développement modulaire est une condition préalable à l’épanouissement de presque tous les domaines (la division du travail est le premier principe de l’efficacité). **
En fin de compte, l’EIP-4337 a été mis en avant.
EIP-4337 est une solution locale optimale, mais il y a plusieurs angles dans son cadre qui doivent être optimisés
L’EIP-4337 définit un ensemble de normes d’interface, clarifiant quels modules doivent être au moins pour les portefeuilles intelligents qui suivent le protocole 4337, quelles fonctions/interfaces chaque module doit implémenter, telles que Bundler, EntryPoint, Paymaster et quelles fonctions exécutables doivent être fournies en externe.
Après avoir clarifié ces règles, l’interaction entre les différents composants est plus claire, ce qui est pratique pour introduire des idées de conception modulaire dans l’abstraction du compte et la conception du portefeuille intelligent, et les développeurs du module de portefeuille en bénéficient également grandement. **
Bien sûr, du point de vue de l’utilisateur, la valeur apportée par le paradigme de développement du portefeuille intelligent modulaire n’est pas claire, car les gens ne ressentent pas beaucoup de changement dans le portefeuille abstrait de compte lui-même à court terme. **Mais à moyen et long terme, des protocoles tels que EIP-4337 ont une valeur similaire à celle de l’ERC-20 et de l’ERC-721, qui jettent les bases du développement à long terme des portefeuilles abstraits de compte et constituent des jalons historiques.
Cependant, EIP-4337 a encore de nombreux problèmes non résolus : ** Par exemple :
La fonction d’abstraction de compte n’est pas assez plug-in, et il est facile pour différents développeurs de réinventer la roue ;
La compatibilité du module de compte est médiocre, et l’ensemble du système de compte montre une tendance à la fragmentation de l’écologie ;
L’écologie de l’abstraction des comptes entre les différentes chaînes est très fragmentée, ce qui rend difficile la fourniture d’une expérience unifiée et de haute qualité pour les utilisateurs finaux et les développeurs et l’obtention d’une meilleure expérience utilisateur.
Ci-dessous, nous allons explorer des solutions à ces problèmes.
Direction d’optimisation 1 : La fonction plug-in d’abstraction de compte deviendra la configuration de base
**On peut dire que l’un des principaux points de discussion liés à l’abstraction de compte est maintenant de savoir comment mieux réaliser la modularité du portefeuille abstrait de compte, et réduire la granularité de chaque module en plus de granularité. **
Par exemple, Biconomy propose une narration basée sur EIP-4337 (EIP-6900 avec une granularité plus fine sera introduite à l’avenir) pour promouvoir davantage le développement modulaire de l’écologie de l’abstraction des comptes.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-0204bbbe03-dd1a6f-69ad2a.webp)
Le plug-in de fonction d’abstraction de compte consiste en fait à clarifier à travers un ensemble de protocoles quels sont les modules clés impliqués dans le portefeuille de contrats intelligents, quelles interfaces/fonctions ces modules doivent implémenter, et quels sont les noms de ces interfaces et comment les appeler. Les développeurs tiers développent ensuite des composants avec des détails variables selon leurs propres idées, mais ces composants répondront aux exigences énoncées dans l’accord.
La version V2 de Biconomy, avec EIP-4337 comme épine dorsale du protocole, a développé des normes plus détaillées et ajouté un certain nombre d’interfaces non mentionnées dans 4337. Tout en précisant les fonctions que les modules tels que Bundler, Smart Contract Wallet et Paymaster doivent avoir, Biconomy permet aux développeurs tiers d’implémenter des modules avec les mêmes caractéristiques et différentes versions avec des détails de code différents, à condition qu’ils suivent les détails du protocole énoncés à l’avance par Biconomy (compatible avec EIP-4337).
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-8f424156ac-dd1a6f-69ad2a.webp)
Dans le même temps, Biconomy a également mis en avant le slogan de « Module Store », tout en lançant personnellement le SDK du module d’abstraction de compte, la majorité des développeurs sont encouragés à soumettre leurs propres modules d’abstraction de compte conçus, à développer « Module as a service », ** afin que tous les projets de portefeuille qui suivent le protocole EIP-4337 puissent adopter directement ces modules d’abstraction de compte écrits par des personnes extérieures. Lorsque les utilisateurs créent un compte intelligent via la page d’accueil, ils disposent également d’un choix plus diversifié de modules à utiliser.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-8bb885dd87-dd1a6f-69ad2a.webp)
Bien que la modularité soit pratique pour la division du travail, elle est également pratique pour les utilisateurs de basculer rapidement ou d’ajouter et de supprimer certaines fonctions dans le portefeuille intelligent (pour le dire franchement, il s’agit de diviser la granularité en morceaux plus fins).
Biconomy a souligné que plus un portefeuille de contrats intelligents est modulaire, moins il doit apporter de modifications lors de la mise à jour ou de la mise à niveau (il n’est pas nécessaire de mettre à jour les contrats de portefeuille de contrats intelligents existants des utilisateurs ou d’utiliser DelegateCall, seulement certains modules externes), ce qui facilite le remplacement de certains composants par différents utilisateurs ou développeurs.
Dans la future abstraction des nouveaux comptes de Biconomy, il fera également référence à la proposition EIP-6900, qui est plus modulaire que l’EIP-4337.
Direction d’optimisation 2 : Une segmentation plus fine des modules pour résoudre le problème de fragmentation des comptes
En ce qui concerne la proposition EIP-6900, **Safe (anciennement Gnosis Safe) a en fait lancé un livre blanc sur le protocole Safe Core en août de cette année, et le plus emprunté est l’EIP-6900. **
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-427d430661-dd1a6f-69ad2a.webp)
**L’EIP-6900 souligne que l’un des problèmes de l’abstraction actuelle des comptes modulaires est la « fragmentation » des comptes, ou le problème des silos. Par exemple, bien que différents fournisseurs de modules d’abstraction de compte ou différentes applications DAPP soient compatibles avec EIP-4337, EIP-4337 n’est pas assez élevé pour différents modules, et la granularité est relativement grossière, ce qui laisse un degré de liberté « trop élevé » aux développeurs de modules Smart Account (le compte intelligent est la partie essentielle du stockage des informations utilisateur et de l’enregistrement de la vérification des transactions personnalisées et de la logique de paiement du gaz).
De cette façon, les différentes parties du projet de portefeuille ont tendance à concevoir des modules de compte intelligents avec des propriétés uniques. **À long terme, les autres fournisseurs de modules d’abstraction de compte doivent donner la priorité à ceux qui fournissent des modules Smart Account compatibles et produire lentement une chaîne d’approvisionnement fixe en amont et en aval, ce qui conduira inévitablement à la fragmentation et à la séparation de l’écologie du module d’abstraction de compte. **(C’est comme aux débuts de l’industrie informatique, les développeurs de systèmes d’exploitation devaient se demander avec quel fabricant de matériel informatique était compatible.)
Pour résoudre le problème de la fragmentation écologique et améliorer la compatibilité des modules d’abstraction de compte développés par différents fournisseurs, le meilleur moyen est d’abstraire davantage les comptes de portefeuille de contrats intelligents et de rendre les modules plus granulaires.
Après avoir emprunté les idées de l’EIP-6900, le livre blanc sur le protocole Safe Core a apporté une optimisation plus détaillée de Smart Account (compte de portefeuille intelligent de l’utilisateur). Le protocole Safe Core divise les modules qui peuvent être appelés par chaque compte de portefeuille intelligent en plugins, hooks, vérificateurs de signatures, processeurs de fonctions et autres catégories. **
Le module de compte intelligent est aussi léger que possible, le contrat de compte ne stocke que les données et les fonctions les plus basiques, et les fonctions qui peuvent être déplacées vers l’extérieur sont toutes envoyées au module de subdivision « processeur de fonctions » ou « plugin » pour être implémentées. Cela fait écho au soi-disant principe du rasoir d’Occam : « n’ajoutez pas d’entités à moins que cela ne soit nécessaire ».
Si le compte intelligent lui-même est suffisamment léger et n’implique pas de détails trop encombrants, le compte intelligent développé par différents fabricants sera plus proche dans sa structure interne et plus compatible.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-0cf696a50a-dd1a6f-69ad2a.webp)
Le protocole Safe Core introduit également un registre, similaire à l’App Store de l’iPhone, qui contient tous les modules disponibles approuvés. L’utilisateur peut choisir les modules à activer, et chaque fois qu’un nouveau module est activé, il est géré par le contrat Minger.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cdcab8e9d3-dd1a6f-69ad2a.webp)
En général, UserOperation déclenchera d’abord un plugin de plugin, puis le contrat Manger vérifiera si l’état du plugin est normal (il y a un enregistrement dans le registre), et s’il est normal, il autorisera la requête du plugin. Si nécessaire, les plugins appellent ou non certaines des fonctionnalités fournies par le Hook. Des modifications sont ensuite apportées à l’état du compte intelligent impliqué dans UserOperation.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-6403d3e538-dd1a6f-69ad2a.webp)
Grâce à la méthode de partitionnement de module à grain fin et au processus de planification mentionnés ci-dessus, Safe Core Protocol tente de mettre en œuvre un ensemble de protocoles d’interopérabilité de modules abstraits de compte open source, dont l’idée de base est de rendre Smart Account aussi léger qu’un compte EOA, afin d’améliorer la compatibilité des modules Smart Account améliorés par différents fournisseurs.
Direction d’optimisation 3 : Abstraction des comptes full-chain, pour réaliser des comptes unifiés sur différentes chaines
Mais même avec la solution susmentionnée, il y a toujours un gros problème qui n’a pas été résolu : différentes chaînes et différentes couches 2 favorisent les abstractions de compte avec des détails différents, et beaucoup utilisent des formulaires qui entrent en conflit avec EIP-4337, tels que zkSync Era, Starknet, Flow, etc. Cela a conduit à une fragmentation de l’expérience utilisateur du portefeuille, par exemple l’adresse du portefeuille intelligent de l’utilisateur sur Starknet et l’adresse du portefeuille intelligent sur Arbitrum ne peuvent pas être unifiées du tout.
De plus, dans un environnement multi-chaînes, les utilisateurs ont déployé indépendamment des comptes intelligents sur différentes chaînes, et les données utilisateur correspondantes sont souvent dispersées dans ces contrats. Si les données de l’utilisateur, telles que les clés, doivent être mises à jour, il est nécessaire d’initier des transactions à plusieurs reprises dans plusieurs chaînes, et il est difficile d’assurer la cohérence de Smart Account.
Vitalik lui-même a déjà proposé un ensemble de schémas de comptes intelligents unifiés et faciles à gérer sur toute la chaîne, ** ce schéma utilise Ethereum ou un ZKRollup hautement sécurisé comme chaîne source, déploie le contrat Keystore, stocke la clé globale de l’utilisateur, puis tous les comptes de contrat intelligent de l’utilisateur sur L2 partagent la clé globale stockée dans le contrat Keystore.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-fad1fc1c55-dd1a6f-69ad2a.webp)
Cependant, cette solution est extrêmement coûteuse, c’est-à-dire que chaque fois que la clé globale enregistrée dans le contrat Keystore sur la chaîne source change, chaque compte de la chaîne L2/cible doit synchroniser la nouvelle clé par le biais d’une interaction inter-chaînes. L’interaction inter-chaînes entre Ethereum et L2 est trop coûteuse pour les utilisateurs. Et il convient de noter que les comptes de contrats intelligents sont différents des comptes EOA, qui sont intrinsèquement multi-chaînes unifiés (unifiés entre les chaînes EVM) en raison de leurs méthodes uniques de génération d’adresses, mais les comptes de contrats intelligents sont complètement différents, et il est difficile pour les utilisateurs d’obtenir des comptes de contrats intelligents avec la même adresse sur différentes chaînes.
Particle Network a mis au point sa propre approche à ce sujet. Bien que l’idée générale soit la même que celle de Vitalik, qui est également de séparer le stockage et le code du compte intelligent, Particle Network a l’intention d’utiliser une chaîne indépendante, Particle Network Chain, comme base de données de stockage complète du compte intelligent, par le biais de solutions de messagerie inter-chaînes tierces (LayerZero, CCIP, Axelar, Connext). Synchronisez les modifications apportées par un utilisateur au stockage du compte avec le compte local sur d’autres chaînes.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-2e6d60197a-dd1a6f-69ad2a.webp)
(Abstraction de compte multi-chaînes de Particle Network)
Plus précisément, le système d’abstraction de compte de la chaîne complète de Particle Network exige que les utilisateurs disposent d’une adresse de compte de contrat intelligent unifiée sur différentes chaînes EVM, ce qui 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 de réseau de particules, après quoi la chaîne de particules déclenche le contrat de déploiement sur toutes les chaînes, en veillant à ce que les adresses de compte de contrat intelligent générées pour les utilisateurs de différentes chaînes soient uniformes, ou les utilisateurs peuvent terminer le processus d’interaction multi-chaînes via le contrat sur la chaîne de particules sans être conscients des autres chaînes, et peuvent utiliser Unified Gas Token en tant que méthode de paiement des frais unifiée.
L’abstraction du compte de la chaîne complète rend également possible l’opération utilisateur de Cross-Chain, déclenchant la transaction de la chaîne cible via l’opération utilisateur de la chaîne source et le paiement de gaz correspondant, comme l’utilisation de l’USDC de Polygon pour acheter des NFT sur Base.
Cependant, la solution Particle Network nécessite un degré élevé de collaboration entre le contrat de déploiement et le composant de messagerie inter-chaînes pour réaliser la synchronisation du compte multi-chaînes et du stockage de la chaîne source, qui a en fait des exigences élevées pour l’oracle ou le pont de messages inter-chaînes qu’il utilise (ce problème semble exister dans tous les schémas liés à l’interopérabilité de la chaîne complète).
Toutefois, la synchronisation de compte inter-chaînes de l’utilisateur peut configurer de manière flexible une combinaison de différents ponts de message, plutôt que de s’appuyer uniquement sur un certain pont, telle qu’une stratégie qui peut être configurée en tant que 2/3, en s’appuyant sur la confirmation de deux de LayerZero, Axelar et Connext pour confirmer le changement de stockage sur la chaîne cible, ce qui peut résoudre approximativement ce problème de dépendance à point unique.
L’interopérabilité transparente de la chaîne complète entre les EVM et les non-EVM est un pas de plus dans l’abstraction des comptes de la chaîne complète au sein de l’écosystème Ethereum
Bien qu’il existe une gestion des clés et des comptes unifiés sur l’ensemble de la chaîne EVM, il y a encore place à l’optimisation dans l’abstraction des comptes de la chaîne complète : les chaînes qui ne sont pas compatibles avec EVM, telles que Aptos, Solana, Sui, etc., ne peuvent pas garantir que l’adresse du compte de contrat intelligent générée par l’utilisateur est cohérente avec la chaîne EVM ; Dans le même temps, si la chaîne non-EVM n’implémente pas le protocole EIP-4337 avec un schéma équivalent, il est difficile de suivre le concept abstrait du compte de la chaîne complète proposé par Vitalik et Particle Network ci-dessus.
De plus, le projet de portefeuille compatible EIP-4337 lui-même peut être amélioré. La plupart des nœuds de bundler utilisés par les portefeuilles intelligents sont officiellement gérés indépendamment et ne communiquent même pas entre eux, et de nombreux projets de portefeuilles intelligents forment en fait une chaîne qui leur est propre, ce qui comporte de nombreux risques (résistance à la censure, facilité d’utilisation). La création d’une interface frontale unique et unifiée sur la plupart des chaînes peut s’avérer très difficile. Une solution consiste à introduire une conception centrée sur l’intention, à ajouter une couche au-dessus de l’abstraction de compte de la chaîne complète et à traiter l’écosystème EIP-4337 d’Ethereum ou les installations d’abstraction de compte natives d’une autre chaîne (telles que zkSync) comme des instances spécifiques sous le type Solver/Reactor, et la façon de choisir le bon solveur est une tâche de niveau supérieur. **
En prenant l’exemple de Particle Network, il propose une implémentation concise de l’abstraction-Intention, tandis que les différentes abstractions de compte ne sont qu’une classe d’instances de solutions d’Intention qui sont incluses dans Solver.
Tout d’abord, le front-end utilisateur sera responsable de la transformation des requêtes en langage naturel ou des interactions utilisateur arbitraires en descriptions programmatiques spécifiques, y compris les contraintes d’entrée et les contraintes de sortie (pour le dire crûment, ce sont les conditions d’entrée et les intervalles de résultats de sortie qui répondent aux exigences de l’utilisateur), puis un ou plusieurs solveurs du réseau de solveurs contiendront des contraintes d’entrée et de sortie spécifiques des transactions. Transférer vers les contrats Solver déployés sur la chaîne (le solveur dispose non seulement d’installations de nœud, mais également de parties de contrat sur la chaîne). Le contrat Solveur transmettra l’instruction d’intention au contrat Reactor (qui gère le compte de l’utilisateur sur la chaîne), qui appellera d’autres modules pour terminer l’interaction finale.
La requête de l’utilisateur est d’abord connue par le réseau du solveur, de sorte que l’utilisateur n’a pas besoin de percevoir la chaîne sous-jacente ou la construction de différentes abstractions de compte, et cette partie est laissée au solveur pour construire une solution spécifique.
Bien sûr, ces idées ne sont encore qu’un cadre théorique, et les détails de la mise en œuvre derrière n’ont pas encore été officiellement définis par Particle Network.
À l’heure actuelle, il est clair qu’un marché concurrentiel des solveurs sera engendré à l’avenir, et les utilisateurs peuvent lancer des enchères pour permettre à plusieurs solveurs de proposer différentes solutions, et grâce à la forme de trading simulé local, la meilleure solution peut être sélectionnée et le solveur correspondant peut être incité. La forme de l’incitation dépend des concepteurs de protocole du réseau de solveurs (Particle Network a l’intention d’utiliser des jetons PNT comme jetons d’incitation pour son marché d’enchères de solveurs).
** L’intention actuelle protège essentiellement les détails complexes de la couche inférieure et les abstrait dans une couche supérieure, ** une telle conception en couches avec la nature du protocole TCP / IP est nécessaire pour l’expérience utilisateur et l’expérience du développeur dans le cadre de l’interopérabilité transparente de l’ensemble de la chaîne.
Adopter massivement les abstractions de compte
Lorsque nous optimisons le framework 4337 dans l’écosystème Ethereum sous tous les angles, et que nous promouvons également une interopérabilité transparente entre les écosystèmes Ethereum et non-Ethereum, afin de soutenir l’adoption à grande échelle de l’abstraction des comptes, nous pensons que nous avons toujours besoin d’un produit qui couvre le côté de l’offre et du côté de la demande. Il peut réduire l’utilisation de divers produits et services Web3 par les utilisateurs finaux, tout en se concentrant sur les développeurs de services et en abaissant le seuil pour les développeurs. **
L’un des meilleurs produits pour ce rôle est le portefeuille intelligent modulaire en tant que service de Particle Network :
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-3a8144f020-dd1a6f-69ad2a.webp)
En plus des fonctionnalités conviviales ci-dessus pour les développeurs, la caractéristique la plus importante est que le produit Modular Smart Wallet-as-as-as-Service** de Particle Network construit une écologie ouverte basée sur l’informatique de signature et est orienté vers le champ d’abstraction de compte des développeurs, en plus de fournir des modules de produits abstraits de compte auto-développés, intégrant divers types de produits et services abstraits de compte. Il peut rapidement promouvoir l’adoption de produits et services de divers développeurs dans l’ensemble du domaine de l’abstraction de compte.
! [Pourquoi l’abstraction de compte de la chaîne complète est-elle la dernière pièce du puzzle pour EIP-4337 ?] ](https://img-cdn.gateio.im/webp-social/moments-69a80767fe-20ede5c527-dd1a6f-69ad2a.webp)
Laissez la technologie servir la demande, après avoir résolu les limitations de tous les angles du cadre ERC-4337, l’amélioration de l’expérience des développeurs favorisera davantage de produits avec une excellente expérience utilisateur, accélérant l’industrie Web3 d’une industrie financière favorable aux crypto-punks à une industrie grand public.