TL;DR

Depuis 2022, l'abstraction de compte a été largement discutée dans le domaine, et le cadre centré autour de l'EIP-4337 semble être devenu un consensus général dans l'industrie. La popularité du concept d'abstraction a incité les gens à prêter plus d'attention à de tels composants d'interaction utilisateur à faible seuil.

Cependant, l'EIP-4337 rencontre toujours des points douloureux tels que la fragmentation des comptes intelligents et des expériences utilisateur hautement fragmentées à travers les chaînes. Cet article prend des projets comme Biconomy, Safe Core et Particle Network comme exemples pour explorer comment promouvoir davantage le développement du domaine de l'abstraction de compte au sein du cadre de l'EIP-4337.

Du point de vue de l'abstraction du processus de transaction, comprendre le concept d'"abstraction de compte"

En ce qui concerne l'abstraction de compte, Vitalik a souligné à plusieurs reprises qu'il s'agit d'une condition nécessaire pour réduire le seuil d'utilisateur pour Ethereum et réaliser une adoption massive. Sa vision principale est de permettre aux utilisateurs de personnaliser les méthodes de vérification de signature + de profiter du paiement de gaz, et d'initier des transactions on-chain sans aucun actif (communément appelé transactions sans gaz). Ce n'est qu'en réalisant ces prérequis que le taux de conversion des nouveaux utilisateurs aux applications Web3 peut être amélioré.

Les propositions précédentes de portefeuilles intelligents sans abstraction de compte, bien qu'elles puissent offrir des expériences similaires, ne sont toujours pas assez flexibles et efficaces. Par exemple, Gnosis Safe nécessite toujours une adresse EOA pour déclencher des transactions, et le coût en gaz est extrêmement élevé.

L'abstraction de compte vise à optimiser la structure sous-jacente des comptes de contrats intelligents, ouvrant la voie à la prochaine génération de systèmes de compte intelligents.

Cependant, si nous examinons les propositions d'abstraction de compte actuelles, nous constaterons que leur focus n'est pas sur le modèle de compte lui-même. Par exemple, les propositions liées à l'abstraction de compte telles que l'EIP-86, l'EIP-4337 et l'EIP-6900 se concentrent sur l'abstraction/modularisation de l'ensemble du flux de traitement d'une transaction, de son initiation à sa réception par les nœuds, la vérification de la signature, le paiement de gaz, etc., plutôt que de se concentrer véritablement sur l'abstraction de la structure du compte. Par conséquent, il semble plus approprié de désigner ces différentes propositions comme une “abstraction de transaction”.

Si nous comprenons les propositions bien connues d'abstraction de compte du point de vue de "l'abstraction du flux de traitement des transactions", nous pouvons plus facilement comprendre leurs points clés : ce type d'abstraction de transaction vise en fait à apporter l'expérience des utilisateurs de niveau Web2 lors de l'entrée et de l'utilisation de produits dans le système Ethereum, tels que les listes noires/listes blanches, les transactions initiées dans une période sans vérification d'identité, les transactions sans frais de gaz, le paiement en monnaie fiduciaire des frais, etc.

Certains pourraient se demander : Ces fonctionnalités ne pouvaient-elles pas être réalisées dans le passé avec les portefeuilles de contrats intelligents existants ? Quelle est la valeur des schémas d'abstraction de compte comme l'EIP-4337 ?

L'essence de l'EIP-4337: l'abstraction de compte comme solution locale optimale dans l'écosystème Ethereum

Comme le suggère la question, alors que les anciens portefeuilles intelligents pouvaient en effet atteindre les fonctionnalités mentionnées, leurs méthodes de mise en œuvre étaient souvent rudimentaires et reposaient fréquemment sur des installations de tiers hautement centralisées. Par exemple, les anciens schémas de paiement de gaz nécessitaient l'introduction de nœuds de relais tiers (EIP-2771). De plus, le manque de normes unifiées parmi les différentes mises en œuvre de portefeuilles intelligents a entravé le développement et le déploiement de composants complémentaires.

L'objectif principal des divers EIP liés à l'abstraction de compte est de remédier aux lacunes présentes dans différents projets de portefeuille en introduisant un cadre standard spécifiquement conçu pour les portefeuilles de contrats intelligents. Ce cadre vise à faire passer la structure de compte au sein de l'écosystème Ethereum d'une structure fonctionnelle de base à une structure intelligente plus sophistiquée, améliorant ainsi l'efficacité et la scalabilité de l'ensemble de l'écosystème.

Cela est analogue à la situation avant l'émergence de l'ERC-20 ou de l'ERC-721, où les méthodes de mise en œuvre, les fonctionnalités et les fonctions/interfaces fournies de nombreux jetons étaient incohérentes. Une telle incohérence n'était pas propice au développement d'installations tierces complémentaires et à l'audit de code (il est difficile d'imaginer dans quelle mesure les applications DeFi auraient pu prospérer sans le protocole ERC-20).

Les protocoles normalisés / les normes de mise en œuvre fonctionnelle sont des prérequis pour les récits modulaires, et les approches de développement modulaire sont presque des prérequis pour un développement dynamique dans n'importe quel domaine (la division du travail étant le premier principe d'amélioration de l'efficacité).

Finalement, l'EIP-4337 a émergé.

L'EIP-4337 est une solution optimale locale, mais il existe plusieurs angles au sein de son cadre qui nécessitent une optimisation urgente.

EIP-4337 définit un ensemble complet de normes d'interface, clarifiant les modules qu'un portefeuille intelligent suivant le protocole 4337 devrait avoir, et quelles fonctions/interfaces chaque module devrait implémenter, telles que Bundler, EntryPoint et Paymaster, et quelles fonctions appelables ces composants devraient fournir.

Une fois que ces spécifications sont clairement définies, l'interaction entre les différents composants devient plus claire, ce qui rend plus facile d'introduire une pensée de conception modulaire dans la conception de l'abstraction de compte et des portefeuilles intelligents, bénéficiant grandement aux développeurs de modules de portefeuille.

Bien sûr, du seul point de vue de l'utilisateur, la valeur apportée par le paradigme de développement du portefeuille intelligent modulaire n'est pas encore claire car les utilisateurs peuvent ne pas ressentir de grands changements dans le portefeuille d'abstraction de compte lui-même à court terme. Cependant, à moyen et long terme, la valeur des protocoles comme l'EIP-4337 est similaire à l'ERC-20 et à l'ERC-721. Il pose les bases du développement à long terme des portefeuilles d'abstraction de compte et constitue une étape d'une importance révolutionnaire.

Cependant, l'EIP-4337 présente encore de nombreux problèmes non résolus, tels que:

1. La fonctionnalité de l'abstraction de compte n'est pas suffisamment plug-and-play, ce qui rend facile pour différents développeurs de réinventer la roue.

2. La compatibilité médiocre des modules de compte entraîne un écosystème fragmenté de systèmes de compte.

3. L'écosystème d'abstraction de compte hautement fragmenté entre différentes chaînes rend difficile la fourniture aux utilisateurs finaux et aux développeurs d'une expérience unifiée et de haute qualité pour obtenir une meilleure UX.

Dans les sections suivantes, nous discuterons des solutions à ces problèmes.

Direction d'optimisation un: La modularisation de l'abstraction de compte deviendra une configuration de base plug-and-play

On peut dire que l'un des points de discussion centraux actuels concernant l'abstraction de compte est comment mieux réaliser la modularisation des portefeuilles d'abstraction de compte et rendre la division de chaque module plus raffinée.

Par exemple, Biconomy, basé sur l'EIP-4337 (et introduira ultérieurement le raffinement de l'EIP-6900), propose le récit de la modularisation de la fonctionnalité plug-and-play de l'abstraction de compte pour promouvoir davantage le développement modulaire de l'écosystème d'abstraction de compte.

La fonctionnalité de modularisation d'abstraction de compte, dite plug-and-play, est essentiellement réalisée grâce à un protocole qui définit explicitement les modules clés impliqués dans les portefeuilles de contrats intelligents, les interfaces/fonctions que ces modules doivent implémenter, ainsi que la manière dont ces interfaces sont nommées et appelées. Par la suite, des développeurs tiers développeront des composants avec des détails variés selon leurs propres idées, mais ces composants respecteront tous les exigences définies dans le protocole.

La version V2 de Biconomy, basée sur l'EIP-4337 en tant que cadre de protocole, a établi des normes plus détaillées et ajouté un lot d'interfaces non mentionnées dans le 4337. En spécifiant les fonctionnalités que Bundler, Smart Contract Wallet, Paymaster et d'autres modules devraient avoir, Biconomy permet aux développeurs tiers d'implémenter des modules avec des détails de code différents mais des fonctionnalités similaires et des versions différentes, à condition qu'ils respectent les règles de protocole prédéfinies par Biconomy (compatibles avec l'EIP-4337).

Pendant ce temps, Biconomy a également introduit le slogan du "Module Store". Tout en lançant activement le SDK du module d'abstraction de compte, Biconomy encourage les développeurs à soumettre leurs propres modules d'abstraction de compte conçus et initie le "Module en tant que Service", permettant à tous les projets de portefeuille conformes au protocole EIP-4337 d'adopter directement ces modules d'abstraction de compte écrits par des tiers. Lorsque les utilisateurs créent des comptes intelligents via l'interface frontale, ils auront également un choix plus diversifié de modules à choisir.

La modularisation facilite non seulement la division du travail, mais permet également aux utilisateurs de basculer rapidement, d'ajouter ou de supprimer des fonctionnalités spécifiques dans les portefeuilles intelligents (en termes plus simples, elle décompose la granularité en composants plus fins).

Biconomy souligne que plus le degré de modularisation dans les portefeuilles de contrats intelligents est élevé, moins de modifications sont nécessaires lors de la mise à jour ou de la mise à niveau (il n'est pas nécessaire de mettre à jour les contrats de portefeuilles de contrats intelligents existants des utilisateurs ou d'utiliser DelegateCall, seuls certains modules externes doivent être mis à jour), ce qui facilite le remplacement de certains composants par différents utilisateurs ou développeurs.

Dans la future version de la solution d'abstraction de compte de Biconomy, il fera également référence à l'EIP-6900, qui est plus propice à la modularisation que l'EIP-4337.

Deuxième direction d'optimisation : segmentation plus fine des modules pour résoudre les problèmes de fragmentation de compte

En ce qui concerne la proposition EIP-6900, Safe (anciennement Gnosis Safe) a en fait publié un livre blanc sur le protocole Safe Core en août de cette année, qui s'inspire fortement de l'EIP-6900.

EIP-6900 souligne qu'un problème actuel avec l'abstraction de compte modularisée est le problème de « fragmentation » ou « île » des comptes. Par exemple, bien que différents fournisseurs de modules d'abstraction de compte ou différentes applications DApp puissent être compatibles avec l'EIP-4337, le niveau d'abstraction de l'EIP-4337 pour différents modules n'est pas suffisamment élevé, et la granularité est relativement grossière. Cela laisse une « liberté excessive » aux développeurs de modules Smart Account (les comptes intelligents stockent les informations utilisateur et enregistrent la partie centrale de la vérification personnalisée des transactions et de la logique de paiement des frais).

En conséquence, les différents projets de portefeuille ont tendance à concevoir des modules de compte intelligent avec des attributs uniques. Au fil du temps, d'autres fournisseurs de module d'abstraction de compte doivent donner la priorité à la compatibilité avec le module de compte intelligent fourni, ce qui conduit à l'émergence d'une chaîne d'approvisionnement fixe en amont et en aval. Cela conduit inévitablement à la fragmentation et à la déconnexion dans l'écosystème du module d'abstraction de compte. (Cela est similaire aux premiers jours de l'industrie informatique lorsque les développeurs de systèmes d'exploitation devaient tenir compte de la compatibilité avec les périphériques matériels de différents fabricants de matériel informatique.)

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 différents fournisseurs, la meilleure approche est d'abstraire davantage les comptes de portefeuille de contrat intelligent et de rendre la granularité de la segmentation du module plus fine.

Après avoir puisé dans les idées de l'EIP-6900, le livre blanc du protocole Safe Core a apporté des optimisations plus détaillées au Smart Account (comptes de portefeuille de contrats intelligents des utilisateurs). Le protocole Safe Core divise chaque module appelable d'un compte de portefeuille de contrat intelligent en différentes catégories telles que les Plugins, les Hooks, les validateurs de signature et les processeurs de fonctions.

Les modules de compte intelligents sont aussi légers que possible, le contrat de compte ne stockant que les données et fonctions les plus basiques, tandis que les fonctions pouvant être déplacées à l'extérieur sont mises en œuvre par des modules spécialisés tels que des "processeurs de fonctions" ou des "plugins." Cela respecte le principe du Rasoir d'Ockham : "Les entités ne doivent pas être multipliées inutilement."

Si le compte intelligent lui-même est assez léger et ne comporte pas trop de détails complexes, les comptes intelligents développés par différents fabricants seront plus similaires en termes de structure interne, et la compatibilité sera également plus élevée.

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 contrat Manger.

En général, l'UserOperation déclenchera d'abord un Plugin spécifique, puis le contrat Manager vérifiera si l'état du Plugin est normal (enregistré dans le registre). S'il est normal, le contrat Manager autorisera la demande du Plugin à se poursuivre. Si nécessaire, le Plugin peut appeler certaines fonctionnalités fournies par certains Hooks, ou non. Ensuite, l'état du compte intelligent impliqué dans l'UserOperation sera modifié.

À travers le processus de segmentation et de planification des modules à grain fin mentionné ci-dessus, le protocole Safe Core tente de promouvoir un protocole d'interopérabilité de modules d'abstraction de compte open-source. Son idée principale est de rendre les Comptes Intelligents aussi légers que possible, les rendant aussi simples que des comptes EOA, afin d'améliorer la compatibilité entre les modules de Comptes Intelligents développés par différents fabricants.

Optimiser la troisième direction : Abstraction de compte unifiée à travers les chaînes, permettant d'obtenir des comptes cohérents sur différentes chaînes

Cependant, même avec les solutions susmentionnées, il reste un problème majeur non résolu : différentes chaînes et différentes solutions de couche 2 font avancer divers schémas de mise en œuvre d'abstraction de compte avec des formes conflictuelles, dont bon nombre entrent en conflit avec l'EIP-4337, comme zkSync Era, Starknet, Flow, etc. Cette fragmentation dans l'expérience utilisateur du portefeuille, par exemple, rend impossible d'unifier l'adresse du portefeuille intelligent d'un utilisateur sur Starknet avec celle sur Arbitrum.

De plus, dans un environnement multi-chaîne, les utilisateurs ont déployé indépendamment des comptes intelligents sur différentes chaînes, et leurs données utilisateur correspondantes sont souvent stockées dans ces contrats. Si des données utilisateur telles que des clés doivent être mises à jour, les transactions doivent être répétées sur plusieurs chaînes, ce qui rend difficile de garantir la cohérence des comptes intelligents.

Vitalik lui-même a précédemment proposé une solution de compte intelligent unifiée et facilement gérable sur toutes les chaînes. Cette solution utilise Ethereum ou un ZKRollup hautement sécurisé comme chaîne source, déploie un contrat Keystore pour stocker les clés globales des utilisateurs, puis tous les comptes de contrats intelligents sur la couche 2 partagent les clés globales stockées dans le contrat Keystore.

Cependant, cette solution s'accompagne de coûts extrêmement élevés. Chaque fois qu'il y a un changement dans les clés mondiales enregistrées par le contrat Keystore sur la chaîne source, chaque compte sur la chaîne L2/cible doit synchroniser les nouvelles clés via des interactions entre chaînes. Cependant, le coût des interactions entre chaînes entre Ethereum et L2 est trop élevé pour que les utilisateurs puissent se le permettre. De plus, il est important de noter que les comptes de contrats intelligents sont différents des comptes EOA. Alors que ces derniers, en raison de leur méthode unique de génération d'adresses, sont naturellement unifiés sur plusieurs chaînes (au sein de l'écosystème EVM), les comptes de contrats intelligents sont totalement différents, ce qui rend difficile pour les utilisateurs d'obtenir des comptes de contrats intelligents avec la même adresse sur différentes chaînes.

En réponse à cela, Particle Network a proposé sa propre approche. Bien que l'idée générale soit alignée sur le concept de Vitalik de séparer le stockage et le code des comptes intelligents, Particle Network prévoit d'utiliser une chaîne séparée—la chaîne Particle Network—comme base de données de stockage complète pour les comptes intelligents. À travers des solutions de messagerie inter-chaînes tierces (telles que LayerZero, CCIP, Axelar, Connext, etc.), Particle Network a l'intention de synchroniser les modifications apportées au stockage d'un compte avec les comptes locaux d'autres chaînes.

(Structure d'abstraction de compte multi-chaîne de Particle Network)

Plus précisément, le système d'abstraction de compte complet de Particle Network vise à fournir aux utilisateurs une adresse de compte de contrat intelligent unifiée sur différents 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 d'un nouveau compte sur la chaîne Particle Network, après quoi Particle Chain déclenchera tous les contrats de déploiement sur différentes 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 effectuer des interactions multi-chaînes via des contrats sur la chaîne Particle sans être conscients des autres chaînes, et ils peuvent utiliser le jeton Gaz Unifié comme méthode de paiement des frais unifiée.

L'abstraction de compte full-chain permet également les opérations d'utilisateurs inter-chaînes, permettant aux utilisateurs de déclencher des transactions sur la chaîne cible via les opérations d'utilisateurs et de payer le gaz correspondant sur la chaîne source. Par exemple, elle permet l'achat de NFT sur Base en utilisant des USDC de Polygon.

Cependant, la solution du réseau Particle Network nécessite des efforts hautement coordonnés entre les contrats de déploiement et les composants de messagerie inter-chaînes pour synchroniser les comptes multi-chaînes et le stockage de la chaîne source. Cela place des exigences élevées sur l'oracle ou le pont de messagerie inter-chaînes utilisé (un défi qui semble exister dans toutes les solutions liées à l'interopérabilité complète des chaînes).

Néanmoins, la synchronisation des comptes inter-chaînes des utilisateurs peut être configurée de manière flexible avec différentes combinaisons de ponts de message, plutôt que de dépendre d'un seul pont. Par exemple, elle peut être configurée avec une politique 2/3, où les modifications apportées au stockage sur la chaîne cible ne sont confirmées qu'après que deux des LayerZero, Axelar ou Connext ont confirmé le changement, ce qui peut atténuer le problème de dépendance à un seul point.

L'interopérabilité transparente entre les chaînes EVM et non EVM représente une avancée supplémentaire dans l'abstraction complète des comptes de chaînes au sein de l'écosystème Ethereum. Malgré les progrès réalisés dans la gestion des clés et les comptes unifiés à travers les chaînes EVM, il reste encore de la place pour optimiser l'abstraction complète des comptes de chaînes. Les chaînes qui ne sont pas compatibles avec l'EVM, telles que Aptos, Solana et Sui, ne peuvent garantir la cohérence des adresses de compte de contrat intelligent générées par les utilisateurs avec celles des chaînes EVM. De plus, les chaînes non EVM peuvent avoir du mal à adopter le concept d'abstraction complète des comptes de chaînes proposé par Vitalik et Particle Network sans mettre en œuvre des solutions équivalentes au protocole EIP-4337.

De plus, il existe des possibilités d'amélioration dans les projets de portefeuille compatibles avec l'EIP-4337. La plupart des portefeuilles intelligents utilisent des nœuds Bundler exploités indépendamment par les plates-formes respectives, qui ne sont souvent pas interconnectés. Cette isolation présente des risques tels que la résistance à la censure et la disponibilité. Concevoir une interface frontend unifiée sur la plupart des chaînes serait extrêmement difficile. Une approche pour y remédier consiste à introduire une conception centrée sur l'intention, ajoutant une couche au-dessus de l'abstraction de compte complète de la chaîne, traitant l'écosystème EIP-4337 d'Ethereum ou les installations d'abstraction de compte natives d'autres chaînes (comme zkSync) comme des instances spécifiques sous la catégorie Solver/Reactor, la sélection de Solvers adaptés étant une tâche de niveau supérieur.

En prenant Particle Network comme exemple, il propose une abstraction concise de la mise en œuvre centrée sur l'intention, où différents projets d'abstraction de compte ne sont que des instances incluses dans la catégorie Solver dans le schéma d'intention.

Tout d'abord, l'interface utilisateur est responsable de traduire les demandes en langage naturel ou toute interaction utilisateur en descriptions programmatiques spécifiques, qui incluent des contraintes d'entrée et des contraintes de sortie (en d'autres termes, des conditions pour des entrées acceptables et des plages pour des résultats de sortie acceptables). Ensuite, un ou plusieurs Solvers dans le réseau de Solveurs transmettront la Transaction contenant des contraintes spécifiques d'entrée-sortie aux contrats Solver déployés sur la chaîne (Solver englobe non seulement les installations de nœuds mais aussi les composants de contrat on-chain). Le contrat Solver transmettra ensuite les instructions d'intention au contrat Reactor (qui gère les comptes on-chain de l'utilisateur), déléguant l'exécution pour compléter l'interaction finale.

La demande de l'utilisateur est initialement reçue par le réseau Solver, permettant aux utilisateurs de ne pas être trop préoccupés par les chaînes sous-jacentes ou la construction de différents schémas d'abstraction de compte, car cette partie est gérée par le Solver pour construire des solutions spécifiques.

Bien sûr, ces idées ne sont actuellement qu'un cadre théorique, et les détails de mise en œuvre sont toujours en attente de déploiement officiel par Particle Network. Ce qui est clair, c'est qu'un marché concurrentiel de Solveurs émergera inévitablement à l'avenir, où les utilisateurs pourront lancer des enchères pour plusieurs Solveurs proposant différentes solutions. Grâce à des transactions simulées locales, la solution optimale peut être sélectionnée et le Solveur correspondant peut être récompensé. En ce qui concerne la forme des incitations, cela dépend des considérations des concepteurs de protocole du réseau de Solveurs (Particle Network a l'intention d'utiliser des jetons PNT comme incitations pour son marché aux enchères de Solveurs).

L'Intention actuelle protège essentiellement les détails complexes sous-jacents et abstrait une couche supérieure. Un tel design en couches ressemblant au protocole TCP/IP est nécessaire pour les expériences des utilisateurs et des développeurs dans l'interopérabilité transparente entre les chaînes.

Adoptant une adoption généralisée de l'abstraction de compte

Lorsque nous optimisons le cadre 4337 au sein de l'écosystème Ethereum sous différents angles et promouvons simultanément l'interopérabilité transparente entre les écosystèmes Ethereum et non-Ethereum, afin de soutenir l'adoption généralisée de l'abstraction de compte, nous croyons qu'il existe encore un besoin pour un produit qui couvre à la fois l'offre et la demande. Il ne devrait pas seulement réduire les obstacles pour les utilisateurs finaux à utiliser divers services Web3, mais aussi se concentrer sur les développeurs de services pour abaisser leur seuil.

Un des meilleurs produits pour jouer ce rôle est le produit de Porte-réseau Modular Smart Wallet-as-a-Service (Modular Smart Wallet-as-a-Service) de Particle Network :

Le service fournit une API facile à utiliser qui permet aux développeurs d'intégrer de manière transparente la fonctionnalité d'abstraction de compte modulaire dans leurs applications. Les développeurs peuvent utiliser ce service pour créer et gérer des comptes sur différentes chaînes, effectuer des interactions entre chaînes et utiliser une méthode de paiement de frais unifiée. Un tel service offrira aux développeurs un moyen plus flexible et pratique de construire des applications multi-chaînes, favorisant ainsi 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 significatif est que le produit Modular Smart Wallet-as-a-Service du Réseau Particle a construit un écosystème ouvert pour l'abstraction de compte dans la communauté des développeurs, basé sur le calcul de signature. En plus de fournir des modules de produits d'abstraction de compte auto-développés, il intègre divers types de produits et services d'abstraction de compte, facilitant l'adoption rapide de produits et services de divers développeurs dans l'ensemble du domaine de l'abstraction de compte.

En alignant la technologie avec la demande et en abordant les limites du cadre ERC-4337 sous tous les angles, l'amélioration de l'expérience des développeurs catalysera l'émergence de plus de produits offrant des expériences utilisateur exceptionnelles. Cela accélérera la transition de l'industrie Web3, autrefois axée sur les passionnés de crypto-finance, vers une approche conviviale pour le consommateur et le grand public.

Avertissement：

1. Cet article est reproduit à partir de[腾讯网], 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 effectuées par l'équipe de Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.