Analyse technique : couche d'accès du Web ouvert créée par Particle Network

Introduction : Alors que les portefeuilles AA ont considérablement réduit les barrières à l'entrée des utilisateurs et ont permis de payer le gaz et de se connecter à des comptes Web2, les aspects liés à l'adoption massive, tels que la connexion confidentielle, les transactions confidentielles, l'omnicain AA et le protocole de fusion d'intentions, doivent encore être développés sur la base des AA.

Bien que différentes solutions d'optimisation de l'expérience utilisateur, comme le portefeuille MPC de ZenGo ou les portefeuilles de contrats intelligents comme Argent, réduisent efficacement les obstacles rencontrés par les utilisateurs, elles ne résolvent qu'une partie des problèmes susmentionnés, sans couvrir complètement les problèmes généraux d'utilisabilité du produit.

De toute évidence, la plupart des portefeuilles AA ou des produits similaires ne peuvent pas encore supporter l'adoption généralisée du Web3. D'un autre côté, du point de vue de l'écosystème, le côté développeur est un aspect crucial. L'attractivité pour les utilisateurs réguliers uniquement, sans impact suffisant du côté des développeurs, a peu de chances d'atteindre l'évolutivité. L'émergence de nouvelles solutions d'optimisation de l'expérience des développeurs témoigne de l'importance croissante du côté développeur dans l'écosystème des produits.

En prenant l'exemple de Particle Network, nous aborderons les défis actuels en matière d'expérience utilisateur auxquels sont confrontés les produits Web3 et expliquerons comment concevoir une solution technique complète et ciblée. Ce type de solution intégrée peut être une condition nécessaire à une adoption massive. En outre, la stratégie commerciale BtoBtoC de Particle constitue une approche remarquable qui pourrait être bénéfique pour de nombreuses équipes de projet.

Répartition de la structure des produits particulaires

Particle Network, dont l'objectif principal est de réduire les obstacles à l'utilisation, adopte une approche de construction de produits B2B2C et de développement écologique, fournissant ainsi une solution complète pour l'adoption généralisée du Web3. Ses modules de base se composent de trois éléments clés :

zKWaas fait référence à un portefeuille en tant que service à connaissance zéro. Les développeurs peuvent intégrer rapidement des modules de portefeuille intelligent à leurs dApps à l'aide du SDK de Particle. Le portefeuille est un portefeuille de contrats intelligents sans clé basé sur l'abstraction des comptes, qui permet le paiement du gaz et propose une connexion confidentielle et des transactions confidentielles OAuth de style Web2.

Particle Chain - Le système d'abstraction de comptes omnicain dédié conçu pour Particle vise à relever les défis liés au déploiement, à la maintenance et à l'invocation des portefeuilles de contrats intelligents sur plusieurs chaînes. Il inclut également le jeton de gaz unifié, qui simplifie l'utilisation de différents jetons de gaz dans les transactions multichaînes.

Protocole de fusion d'intention : inclut un langage spécifique au domaine (DSL) concis, un framework d'intention, un réseau Intent Solver, etc., pour créer un cadre d'interaction Web3 basé sur l'intention. Les utilisateurs déclarent leurs intentions de transaction directement au lieu d'exécuter chaque opération en particulier, ce qui les libère de considérations complexes en matière de cheminement et n'a pas besoin de comprendre la complexité de l'infrastructure sous-jacente.

ZKWaas - Portefeuille Zero-Knowledge en tant que service

En ce qui concerne les portefeuilles, Particle fournit principalement des SDK aux développeurs de dApp sous la forme de Wallet-as-a-Service (WaaS). L'objectif est de permettre aux développeurs de s'intégrer à son cadre complet d'adoption massive du Web3. Cette approche BtoBtoC présente plusieurs avantages, tant du point de vue de l'entreprise que de l'écosystème :

Le marché des portefeuilles grand public est très compétitif et les fonctionnalités sont de plus en plus similaires. Les portefeuilles des consommateurs ne sont plus le point d'entrée idéal. D'autre part, les développeurs de DApp préfèrent intégrer des portefeuilles à leurs applications afin d'améliorer l'expérience utilisateur et de proposer des fonctionnalités plus personnalisables.

Acquérir des utilisateurs du côté des consommateurs coûte cher, mais le côté commercial diffère. La croissance du nombre d'utilisateurs de WaaS provient principalement des DApps intégrées au SDK. Grâce à un développement commercial et à des relations avec les développeurs efficaces, l'écosystème peut se développer de manière organique.

Les portefeuilles des consommateurs actuels se concentrent principalement sur les finances et les actifs, ce qui ne représente peut-être pas les principaux scénarios pour l'avenir du Web3. Pour parvenir à une adoption généralisée du Web3, les fonctionnalités fondamentales telles que l'identité des utilisateurs (comptes) et les opérations des utilisateurs (initiation de transactions) doivent être considérées comme un service fondamental, laissant les dApps gérer des scénarios plus riches.

Historiquement, le point d'entrée des DApps a démontré l'existence d'une relation étroite entre les portefeuilles et les DApps. Il est crucial d'augmenter la part de marché du portefeuille du côté des DApp. C'est particulièrement avantageux pour le modèle B2B2C.

Pour créer une solution qui réponde aux besoins des utilisateurs, abaisse les barrières à l'entrée et facilite l'intégration des développeurs, zkWAAS de Particle joue un rôle central avec trois fonctionnalités principales :

1. Connexion confidentielle : utilisation des méthodes de connexion Web2 traditionnelles, telles que la vérification OAuth sur des plateformes telles que Twitter, Google, WeChat, etc., sur le portefeuille de contrats intelligents. Cela permet aux utilisateurs de se libérer complètement des contraintes liées à la gestion des clés privées, en accédant au Web3 de la manière la plus familière et la plus simple qui soit. Simultanément, l'identité des utilisateurs est dissimulée à l'aide de preuves à connaissance nulle.

2. Transactions confidentielles : mise en œuvre de transferts de confidentialité point à point via le mécanisme Smart Stealth Address, garantissant ainsi la confidentialité universelle des transactions. De plus, l'utilisation de Paymaster de l'ERC-4337 permet d'utiliser les actifs sans gaz pour les Smart Stealth Addresses (parrainage de gaz).

3. Fonctionnalité complète du portefeuille AA : le module de portefeuille de Particle est totalement conforme aux exigences fondamentales de l'ERC-4337. Il inclut des composants essentiels tels que Bundler, EntryPoint, Paymaster, Smart Wallet Account, etc., et couvre tous les aspects critiques du flux de travail de l'ERC-4337. Cette solution unique répond efficacement aux exigences fonctionnelles des DApps ou des utilisateurs en matière de portefeuilles intelligents.

Connexion confidentielle pour les portefeuilles en chaîne basés sur des comptes Web2

La solution de connexion confidentielle de Particle utilise des jetons Web JSON (JWT), qui permettent l'authentification de l'identité Web2 et les opérations de portefeuille dans le cadre d'un contrat intelligent.

Le JWT est une forme de preuve d'identité largement utilisée dans les applications Internet traditionnelles, délivrée par le serveur au client. Le client utilise cette preuve pour authentifier son identité à chaque interaction avec le serveur.

(Source : FlutterFlow Docs)

JWT contient plusieurs champs clés qui constituent la base de la vérification d'identité dans le cadre du contrat :

· « iss » (émetteur) indique l'émetteur de JWT, c'est-à-dire le serveur, tel que Google, Twitter, etc.

· « aud » (Audience) : Spécifie le service ou l'application auquel le JWT est destiné. Par exemple, lorsque vous vous connectez à Medium via Twitter, le JWT émis par Twitter inclura ce champ indiquant son applicabilité à Medium.

· « sub » (Objet) : fait référence à l'identité de l'utilisateur qui reçoit le JWT, généralement identifiée par un UID.

Dans la pratique, « iss » et « sub » restent généralement constants afin d'éviter toute confusion entre les systèmes internes et les références externes. Ces paramètres peuvent donc être utilisés par le contrat pour déterminer l'identité des utilisateurs, évitant ainsi à ceux-ci d'avoir à générer et à protéger des clés privées.

Le concept de clé Web JSON (JWK) correspond à JWT, un ensemble de paires de clés sur le serveur. Lors de l'émission de JWT, le serveur le signe avec la clé privée de JWK, tandis que la clé publique correspondante est rendue publique pour que d'autres services puissent vérifier la signature.

Par exemple, lorsque Medium utilise Twitter pour se connecter, Medium valide le JWT à l'aide du JWK public de Google pour confirmer son authenticité, c'est-à-dire qu'il a bien été émis par Google. La vérification de JWT dans le cadre du contrat impliquera également l'utilisation de JWK.

Le processus de connexion confidentielle de Particle est décrit dans le schéma ci-dessous :

Nous allons ignorer le circuit ZK spécifique ici, juste pour souligner quelques points clés du processus :

Le contrat Verifier qui valide les informations de connexion ne percevra qu'un ZK Proof lié à l'identité de l'utilisateur (JWT) et un eph_pk. Il ne peut pas obtenir directement la clé publique du portefeuille ou les informations JWT correspondantes, ce qui garantit la confidentialité des utilisateurs et empêche les entités externes d'identifier l'utilisateur connecté à partir des données de la chaîne.

eph_pk (paire de clés éphémères) est une paire de clés utilisée en une seule session et il ne s'agit pas de la paire de clés publique-privée du portefeuille. Les utilisateurs n'ont pas à s'en préoccuper.

Ce système prend en charge la vérification hors chaîne et peut être utilisé pour les portefeuilles contractuels utilisant une logique telle que le MPC (calcul multipartite).

Comme il s'agit d'une solution de vérification des contrats réellement basée sur les méthodes de connexion traditionnelles, les utilisateurs peuvent également désigner d'autres contacts sociaux comme tuteurs dans les cas extrêmes, par exemple en cas de désactivation du compte Web2.

Transactions confidentielles basées sur DH Key Exchange

Avant de parler des transactions confidentielles de Particle, voyons comment réaliser des transactions confidentielles pour le destinataire dans le cadre du système EVM existant, en masquant notamment l'adresse du destinataire.

En supposant qu'Alice soit l'expéditeur et Bob le destinataire, les deux parties ont des connaissances communes :

1. Bob génère une clé de dépenses racine (m) et une méta-adresse furtive (M). M peut être généré par m, et leur relation est représentée par M = G * m, ce qui indique une relation mathématique dans les opérations cryptographiques.

2. Alice obtient la méta-adresse furtive M de Bob par tous les moyens.

3. Alice génère une clé privée éphémère (r) et utilise l'algorithme generate_address (r, M) pour créer une adresse furtive (A). Cette adresse est une adresse furtive dédiée préparée pour Bob, qui en prend le contrôle une fois les actifs reçus.

4. Alice génère une clé publique éphémère (R) à partir de la clé privée éphémère r et l'envoie au contrat d'enregistrement de la clé publique éphémère (ou à tout autre endroit convenu d'un commun accord auquel Bob peut accéder).

5. Bob scanne régulièrement le contrat d'enregistrement éphémère par clé publique, enregistrant chaque clé publique éphémère mise à jour. Comme le contrat de clé publique éphémère est public et contient des clés liées à des transactions de confidentialité envoyées par d'autres personnes, Bob ne sait pas laquelle Alice lui a envoyée.

6. Bob scanne chaque enregistrement mis à jour en exécutant generate_address (R, m) pour calculer l'adresse furtive. S'il y a des actifs dans cette adresse, cela signifie qu'Alice l'a générée et autorisée pour le contrôle de Bob ; sinon, cela n'a aucune importance pour Bob.

7. Bob exécute generate_spending_key (R, m) pour générer la clé de dépenses pour cette adresse furtive, à savoir p = m + hash (A). Bob peut alors contrôler l'adresse A générée par Alice.

Le processus décrit simplifie de nombreuses opérations mathématiques complexes. L'ensemble du processus d'échange d'informations ressemble à ce que deux agents secrets écrivent des messages cryptés sur un babillard public, messages uniquement déchiffrables l'un par l'autre. Bien que les méthodes de génération et de décryptage de ces messages soient publiques, les données cruciales nécessaires aux deux agents ne sont connues que d'eux. Par conséquent, même si des personnes extérieures comprennent les méthodes, le déchiffrement n'est pas réussi.

Ce processus d'échange est assez similaire à la célèbre méthode d'échange de clés Diffie-Hellman. Sans révéler leurs secrets (la clé de dépense racine de Bob (m) et la clé privée éphémère d'Alice (r)), les deux parties peuvent calculer un secret partagé, à savoir l'adresse furtive (A) mentionnée plus haut. Si vous n'êtes pas familière avec DH exchange, la compréhension métaphorique peut être facilitée à l'aide du schéma ci-dessous.

Une étape ajoutée par rapport à DH est qu'après avoir calculé le secret partagé, l'adresse furtive (A), celle-ci ne peut pas être utilisée directement comme clé privée car Alice connaît également A. Il est nécessaire de construire la clé de dépense (p = m + hash (A)) en traitant A comme une clé publique. Comme indiqué précédemment, seul Bob connaît la clé de dépenses racine (m), ce qui fait de Bob le seul responsable de cette adresse furtive.

De toute évidence, avec cette méthode de transfert de confidentialité, pour chaque nouvelle transaction reçue, les fonds seront transférés vers une toute nouvelle adresse EOA. Le destinataire peut utiliser la clé de dépenses racine pour calculer de manière itérative la clé de dépenses pour chaque adresse, en essayant de trouver celle qui lui est réellement associée.

Cependant, il y a toujours un problème. Au départ, cette adresse furtive nouvellement générée est toujours un compte EOA et il se peut qu'il ne manque pas d'ETH ou d'autres jetons Gas. Bob ne peut pas initier de transactions directement et doit utiliser le Paymaster, un portefeuille de contrats intelligents pour le paiement de l'essence afin de réaliser des transactions confidentielles. Certaines modifications sont donc nécessaires pour l'adresse du destinataire :

En utilisant la méthode de calcul d'adresse de la fonction CREATE2 lors du déploiement du contrat, ainsi que les paramètres correspondants (définition de l'adresse furtive A en tant que propriétaire du contrat, etc.), calculez une adresse contrefactuelle. Il s'agit d'une adresse contractuelle calculée qui n'a pas encore été déployée, actuellement une EOA.

Alice transfère des fonds directement à cette adresse contrefactuelle. Lorsque Bob veut l'utiliser, il crée directement un portefeuille contractuel à cette adresse, ce qui permet d'invoquer le service de paiement du gaz (cette étape peut également être gérée par Alice ou le réseau Particle à l'avance).

Nous pouvons qualifier l'adresse contrefactuelle susmentionnée d'adresse furtive intelligente. Bob utilise les actifs de manière anonyme sous cette adresse furtive intelligente selon le processus suivant :

·Déposez Paymaster depuis n'importe laquelle de ses adresses, et Paymaster vous renverra une preuve de fonds (basée sur ZK).

·Avec le mécanisme AA, utilisez n'importe quelle autre adresse, qui n'a peut-être pas de solde, pour envoyer UserOperation au nœud Bundler, en invoquant les actifs sous l'adresse furtive mentionnée. Bob n'a qu'à fournir une preuve de fonds à Paymaster en utilisant une nouvelle adresse, et Paymaster paie le Bundler pour le regroupement des transactions.

Ce processus est similaire à celui de Tornado Cash. La preuve documentaire (basée sur ZK) peut prouver qu'une recharge s'est produite dans l'ensemble des nœuds foliaires de l'arbre Merkle. Cependant, lorsqu'il s'agit de dépenser, personne ne peut déterminer quel compte Leaf Node a été consommé, rompant ainsi le lien entre le consommateur et le chargeur.

En résumé, Particle associe intelligemment AA et adresses furtives, réalisant ainsi des transferts confidentiels grâce à des portefeuilles furtifs intelligents.

Particle Chain & Abstraction des comptes omnicains

Particle Chain est une chaîne de point de vente conçue pour l'abstraction de comptes omnicain. Si l'on considère à la fois le présent et le futur, il est peu probable qu'une seule chaîne domine. Il est crucial d'améliorer l'expérience utilisateur dans un scénario multichaîne.

Actuellement, le système d'abstraction de comptes ERC4337 peut rencontrer certains problèmes dans une situation impliquant plusieurs chaînes :

• Les adresses des mêmes utilisateurs sur différentes chaînes peuvent ne pas être uniformes, selon la conception du contrat.
• La gestion de différents portefeuilles de contrats de chaîne nécessite des opérations manuelles sur plusieurs chaînes, comme le changement d'administrateur. Dans le pire des cas, si les autorisations d'administrateur sont mises à jour sur une chaîne, puis si l'on abandonne l'ancienne méthode de validation des administrateurs, il devient impossible d'apporter des modifications sur les autres chaînes, ce qui rend le portefeuille inutilisable.
• Pour utiliser différentes chaînes, il faut avoir des jetons Gas pour chaque chaîne, ou des fonds préstockés dans le Paymaster de chaque chaîne. Pour les développeurs, cela peut être gênant. S'ils veulent que les utilisateurs utilisent certaines conditions gratuitement ou mettent en œuvre d'autres fonctions, ils doivent déployer leurs Paymasters personnalisés sur chaque chaîne et les préfinancer.

L'abstraction omnicaine des comptes de Particle Chain répond aux problèmes ci-dessus :

• Créez des portefeuilles AA sur Particle Chain.
• Utilisez LayerZero et d'autres protocoles inter-chaînes Arbitrary Message Bridge (AMB) pour synchroniser diverses opérations, telles que la création, la mise à niveau et la modification des autorisations, avec d'autres chaînes. Cela peut être compris comme les portefeuilles d'autres chaînes faisant référence au portefeuille de cette chaîne, les modifications apportées au corps principal étant synchronisées avec tous les portefeuilles.
• Garantissez des adresses uniformes pour les portefeuilles de chaque chaîne grâce à un contrat de déploiement à paramètres cohérents.
• Les portefeuilles de différentes chaînes peuvent également s'appeler via AMB, pas nécessairement depuis Particle Chain.
• Émettez un jeton de gaz unifié. Le mécanisme Paymaster met en œuvre l'ERC20 sous forme de frais de gaz. Même sur une chaîne sans gaz ni fonds préstockés dans Paymaster, les transactions inter-chaînes utilisant des jetons de gaz unifiés peuvent être initiées sur des chaînes conformes.

Outre les cas d'utilisation mentionnés ci-dessus, Particle Chain peut également être utilisée pour :

• Le réseau décentralisé pour les preuves ZKWaas et la production de sel.
• Des niveaux d'incitation pour les Bundlers des différentes chaînes, afin d'aider les Bundlers à parvenir à une plus grande décentralisation.
• Faire office de réseau de résolution pour le protocole Intent Fusion.

Dans le récit de Particle Chain, le jeton de gaz unifié constitue une proposition de valeur fondamentale pour l'ensemble de l'écosystème :

• La fonctionnalité de paiement des frais de gaz est une logique de forte demande et de capture de valeur validée à plusieurs reprises dans l'espace cryptographique.
• Le jeton de gaz unifié fait abstraction du concept de couches de gaz des écosystèmes de chaînes publiques existants. Cette abstraction, sans Particle Chain et sans portefeuilles, n'est pas réalisable. Le jeton de gaz unifié représente donc une prise de valeur pour l'ensemble de l'écosystème Particle. En ce qui concerne la couche de gaz, l'interaction avec les utilisateurs, la croissance et la valeur du jeton natif sur les différentes chaînes entretiennent une relation mutuellement bénéfique avec le jeton de gaz unifié.
• Le gaz unifié est également l'un des facteurs déterminants pour atteindre Chainless. Pour les utilisateurs, l'utilisation d'une monnaie unique simplifie grandement le processus d'utilisation et la compréhension des coûts. À l'avenir, même dans un scénario multichaîne, les utilisateurs n'en seront peut-être pas conscients et n'auront pas à se préoccuper du fonctionnement de l'infrastructure sous-jacente. De la même manière que, actuellement sur Web2, nous interagissons avec les serveurs sans nous soucier de l'emplacement des centres de données, de leur configuration, des langues et des bases de données qu'ils utilisent.
• Les utilisateurs importés par dApps accèdent directement au jeton de gaz unifié, offrant ainsi un large éventail de cas d'utilisation.

Protocole Intent Fusion

En général, lorsqu'ils utilisent différentes DApps, les utilisateurs doivent constamment tenir compte des modes d'utilisation :

• S'il n'y a pas de liquidité sur un DEX, il faut en vérifier un autre.
• Choisir la DApp la plus adaptée dans la même catégorie pour une transaction ou une tâche.
• Comprendre le concept « Approuver » avant de pouvoir utiliser de nombreuses fonctionnalités.
• Dépoussiérer les portefeuilles, convertir plusieurs petits montants en un jeton spécifique, c'est un processus fastidieux.
• Effectuer plusieurs étapes dans différentes applications pour atteindre l'objectif final. Par exemple, dans le domaine des prêts à fort effet de levier : échange, jalonnement, emprunt, obtention de jetons, puis échange à nouveau, jalonnement et emprunt.

Le contenu ci-dessus ne représente qu'un aperçu du paysage actuel de la DeFi, et alors que nous entrons dans l'ère de l'adoption généralisée de diverses applications sur le Web3, la complexité des interactions pourrait bien dépasser notre imagination.

Par conséquent, le remplacement d'étapes opérationnelles spécifiques par des intentions offre une expérience totalement différente aux utilisateurs. Les intentions, comparées aux opérations, s'apparentent à de la programmation déclarative à une programmation fonctionnelle. Les déclarations déclaratives donnent souvent une impression directe, puisqu'elles ne nécessitent qu'une déclaration sur ce qui doit être fait, sans se préoccuper des détails ultérieurs. Cela nécessite différents niveaux d'instructions de programmation fonctionnelle encapsulées dans les couches sous-jacentes.

De même, l'utilisation d'Intents nécessite l'assistance de nombreuses installations. Examinons l'ensemble du processus :

1. Les utilisateurs soumettent leurs intentions en les décrivant d'une manière ou d'une autre, par exemple en langage naturel, sous forme de RFS (Request For Solver), soumis au réseau Solver. The Solver est un interprète des intentions et des solveurs courants, comme 1inch, un agrégateur, qui recherche le DEX optimal pour les utilisateurs. Cependant, ces solveurs, par rapport à notre vision, ne sont peut-être pas assez polyvalents et puissants.

2. Plusieurs solveurs répondent et s'affrontent. Ces réponses sont écrites dans le langage DSL d'intention, puis analysées par le client sous une forme facile à comprendre pour les utilisateurs. Ces réponses incluent les contraintes d'entrée et de sortie, qui définissent les limites des entrées et des sorties. Les utilisateurs peuvent également spécifier eux-mêmes les contraintes. Un exemple simple pour comprendre : lorsque vous utilisez Swap, l'utilisateur est invité à indiquer le montant minimum qu'il peut recevoir après l'échange, ce qui est une forme de contrainte. Les utilisateurs font leur choix parmi les réponses fournies par plusieurs solveurs.

3. Signez l'intention.

4. Le solveur spécifie un exécuteur de contrat d'exécution spécifique et soumet l'intention au réacteur du contrat de réponse.

5. Le réacteur collecte les informations requises (comme un actif spécifique) sur le compte de l'utilisateur, soumet l'intention à l'exécuteur et, après avoir appelé le contrat logique correspondant, renvoie le résultat de la transaction au réacteur. Le réacteur vérifie les contraintes et, si elles sont correctes, renvoie la sortie à l'utilisateur.

Nous pouvons envisager ce processus comme si vous expliquiez vos besoins à ChatGPT. Quelle que soit la complexité des exigences, cela peut générer un résultat final pour vous. Tant que vous êtes satisfaite du résultat, vous pouvez l'utiliser directement sans vous préoccuper du processus sous-jacent.

Conclusion

Particle Network a proposé une solution complète : grâce à la forme intégrée de zKWaas, Particle Chain et Intent Fusion Protocol, il permet de se connecter en toute confidentialité via Web2 OAuth, de réaliser des transactions de confidentialité, d'abstraire des comptes omnicains et d'adopter un paradigme transactionnel basé sur l'intention. Chaque fonctionnalité répond à une partie des problèmes liés à l'utilisation du Web3. Ces avancées et optimisations serviront de base à la future adoption généralisée des produits et technologies Web3. En termes d'écosystème et de modèles commerciaux, adopter le paradigme B2B2C, utiliser le WaaS comme point d'entrée pour améliorer l'évolutivité et la standardisation de l'ensemble de la chaîne de produits, co-construire l'écosystème avec les développeurs de dApp et créer conjointement un monde Web3 à seuil bas et riche en expérience pour les utilisateurs.

Bien entendu, les différents projets ont des interprétations différentes de la procédure de mise en œuvre pour l'adoption massive du Web3. Outre l'examen de projets spécifiques, nous espérons utiliser différentes solutions pour mieux comprendre les difficultés d'intégration auxquelles le Web3 est actuellement confronté, prendre en compte les besoins et les problèmes des utilisateurs, et prendre en compte les considérations relatives à la connexion collective et au développement de l'ensemble de l'écosystème.

Avertissement：

1. Cet article est reproduit depuis [Web3]. Tous les droits d'auteur appartiennent à l'auteur original []. En cas d'objection à cette réimpression, contactez l'équipe de Gate Learn, elle s'en occupera rapidement.
2. Avertissement en matière de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas un conseil d'investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.