Si l’on prend l’exemple de Particle Network, la technologie interprète les problèmes d’expérience des produits Web3 actuels

Auteur : Wuyue, Geek Web3

Introduction : Bien que le portefeuille AA ait abaissé le seuil pour les utilisateurs dans une large mesure et qu’il ait initialement réalisé le paiement de gaz et la connexion au compte web2, la conception liée à l’adoption massive, telle que la connexion à la vie privée - transaction privée, le compte AA unifié à chaîne complète et l’architecture dédiée à l’intention, doit encore être ajoutée sur la base de l’AA.

Bien que l’on puisse voir de nombreuses solutions d’optimisation de l’expérience utilisateur, telles que les portefeuilles MPC tels que ZenGo ou les portefeuilles de contrats intelligents tels qu’Argent, qui abaissent effectivement le seuil pour les utilisateurs, elles ne résolvent qu’une partie des problèmes ci-dessus et ne couvrent pas entièrement la facilité d’utilisation du produit.

De toute évidence, la plupart des portefeuilles AA ou des produits similaires ne sont pas encore en mesure de prendre en charge l’adoption massive du Web3. D’autre part, d’un point de vue écologique, le côté développeur est un niveau très important, qui n’est attrayant que pour les utilisateurs ordinaires en termes de produits, mais il est difficile de former une échelle en raison de son influence insuffisante sur le côté développeur. **L’émergence de plus en plus de solutions d’optimisation de l’expérience de développement a démontré l’importance du côté développeur dans l’écosystème produit.

Nous prendrons Particle Network comme exemple pour expliquer en détail les problèmes d’expérience actuels des produits Web3, et comment concevoir une solution technique complète, ce qui peut être une condition nécessaire à une adoption massive. Dans le même temps, la stratégie commerciale BtoBtoC de Particle se trouve être une idée dont de nombreuses parties prenantes du projet doivent s’inspirer. **

Solution complète de structure du produit de particules

Dans le but de résoudre le seuil d’utilisation, Particle Network propose un ensemble complet de solutions pour l’adoption à grande échelle du Web3 avec l’idée de la construction de produits B2B2C et du développement écologique. Ses modules de base sont au nombre de trois :

**zkWaaS, un service Wallet-as-a-Service (WaaS) basé sur des preuves à divulgation nulle de connaissance. **Les développeurs peuvent rapidement intégrer le module de portefeuille intelligent dans leur propre dApp en fonction du SDK fourni par Particle. Le portefeuille est un portefeuille de contrats intelligents sans clé basé sur l’abstraction de compte, qui peut non seulement réaliser des scénarios de base AA tels que le paiement de gaz, mais également fournir des méthodes de connexion à la confidentialité OAuth de style Web2 et des transactions privées et d’autres fonctions.

Particle Chain - Une solution d’abstraction de compte Omnichain dédiée à Particle, dédiée à la résolution du déploiement, de la maintenance et de l’appel inter-chaînes des portefeuilles de contrats intelligents. Il existe également un jeton de gaz unifié (jeton de gaz unifié) pour résoudre le problème de l’utilisation de différentes pièces de gaz pour les transactions multi-chaînes.

**Le protocole Intent Fusion, qui comprend un langage DSL (Domain Specific Language) concis, un cadre d’intention, un réseau de solveurs d’intention, etc., est utilisé pour créer un ensemble de frameworks d’interaction Web3 basés sur l’intention. Les utilisateurs déclarent directement leur intention de transaction au lieu d’effectuer chaque action spécifique, ce qui libère les utilisateurs d’une réflexion fastidieuse et réduit leur compréhension de l’infrastructure sous-jacente complexe.

zkWaaS – Smart Wallet-as-a-Service combiné avec ZK

Du côté des portefeuilles, Particle fournit principalement des SDK pour les développeurs de dApp sous la forme de WaaS (Smart Contract Wallet-as-a-Service), afin de permettre aux développeurs d’accéder à son cadre complet d’options de masse Web3. Cette solution BtoBtoC présente plusieurs avantages d’un point de vue business et écologique :

**La concurrence des portefeuilles C-end purs est devenue chauffée à blanc, et les fonctions sont relativement similaires, et les portefeuilles C-end ne sont plus un bon point d’entrée. D’autre part, les développeurs de dApps sont de plus en plus enclins à intégrer des portefeuilles dans les dApps pour éviter la perte d’expérience lorsque les utilisateurs doivent changer de portefeuille lors de la connexion de portefeuilles et de transactions, et fournir des fonctionnalités plus personnalisables.

**Le coût d’acquisition client est élevé sur le côté C, mais il est différent sur le côté B. **La croissance du nombre d’utilisateurs de WaaS est principalement due aux dApps intégrées aux SDK. Tant que la relation entre BD et les développeurs est bonne, l’ensemble de l’écosystème peut être étendu dans un style « ville entourant la campagne ».

**À l’heure actuelle, les portefeuilles C-end sont principalement axés sur la finance et les actifs, et il est difficile pour nous de dire que c’est le scénario principal du Web3 à l’avenir. Pour vraiment parvenir à une adoption massive du Web3, il doit y avoir des projets qui font abstraction des fonctionnalités les plus élémentaires - l’identité de l’utilisateur (compte) et le fonctionnement de l’utilisateur (envoi de transactions/transactions) en tant que service de bas niveau, et qui transmettent les scénarios les plus riches de la couche supérieure à la dApp.

À partir de l’entrée précédente de la connexion dApp, vous pouvez observer la relation de liaison étroite entre le portefeuille et la dApp. **Il est très important d’augmenter autant que possible la part de marché des portefeuilles du côté des dApps. C’est la première priorité pour le modèle B2B2C. **

La création d’un WaaS qui répond aux besoins des utilisateurs, réduit la barrière à l’entrée et est facile d’accès pour les développeurs est un autre pilier du succès de la solution. Le zkWaaS de Particle possède trois cœurs :

**1. Connexion à la confidentialité. **En utilisant les méthodes de connexion Web2 traditionnelles sur les portefeuilles contractuels, telles que Twitter, Google, WeChat et d’autres méthodes de vérification OAuth, les utilisateurs peuvent se débarrasser complètement des chaînes de la gestion des clés privées et entrer dans le Web3 de la manière la plus familière et la plus simple. Dans le même temps, les preuves à divulgation nulle de connaissance sont utilisées pour masquer l’identité des utilisateurs.

2. Transactions de confidentialité. **Mettez en œuvre des transferts privés universels peer-to-peer via le mécanisme Smart Stealth Address, et utilisez ERC4337 Paymaster pour permettre à l’adresse furtive d’utiliser des actifs (sponsors de gaz) sans gaz.

**3. Complétez la fonction de portefeuille AA. **Le module de portefeuille de Particle est entièrement conforme aux exigences de base de l’ERC-4337, y compris Bundler, EntryPoint, Paymaster, Smart Wallet Account et d’autres parties importantes des flux de travail ERC-4337, un guichet unique pour répondre aux exigences fonctionnelles des DAPP ou des utilisateurs de portefeuilles intelligents.

Connexion à la confidentialité du portefeuille on-chain basée sur les comptes web2

La solution de connexion privée de Particle utilise JWT (Json Web Token), qui peut être utilisé pour l’authentification de l’identité Web2 et le fonctionnement du portefeuille dans le cadre du contrat.

JWT est une sorte de certificat d’identité émis par le serveur au client qui est largement utilisé dans l’Internet traditionnel, et le client s’appuie sur cette preuve pour s’authentifier chaque fois qu’il interagit avec le serveur.

Il y a plusieurs champs clés dans le JWT qui constituent la base du contrat de vérification de l’identité :

·" iss » (Émetteur) désigne l’éditeur du JWT, c’est-à-dire le serveur, tel que Google, Twitter, etc.

·" aud » (Audience) indique le service ou l’application utilisé par le JWT, si vous vous connectez à Medium avec Twitter, alors ce champ indiquera que le JWT s’applique à Medium lorsque Twitter émet le JWT.

·" sub » (Sujet) fait référence à l’identité de l’utilisateur qui accepte le JWT, qui est généralement marqué par un UID.

Dans la pratique, l’ISS et le sous-marin ne changeront pas dans la grande majorité des cas, sinon cela apportera un énorme gâchis de systèmes internes et de références externes. Par conséquent, ces paramètres peuvent être utilisés par le contrat pour déterminer l’identité de l’utilisateur**, de sorte que l’utilisateur n’a pas du tout besoin de générer et de conserver la clé privée. **

Le concept correspondant à JWT est JWK (JSON Web Key), qui est un ensemble de paires de clés côté serveur. Lorsque le serveur émet un JWT, il signe avec la clé privée du JWK, et la clé publique correspondante est publique et utilisée pour vérifier sa signature pour d’autres services.

Par exemple, si vous vous connectez à Twitter sur Medium, Medium vérifiera le JWT avec la clé publique JWK que Google a rendue publique pour confirmer que le JWT est authentique, c’est-à-dire qu’il a bien été émis par Google. JWK est également utilisé pour la validation des contrats de JWT.

Le flux de solution de connexion privée de Particle est illustré dans la figure suivante :

Parmi eux, nous sauterons ici le circuit spécifique de ZK. Énumérez quelques-uns des points clés du processus :

**Le contrat de vérification qui vérifie les informations de connexion ne percevra qu’une preuve ZK liée à l’identité de l’utilisateur-JWT, ainsi qu’un eph_pk inoffensif, et ne peut pas obtenir directement la clé publique du portefeuille correspondante ou les informations JWT, afin de protéger la vie privée de l’utilisateur, et le monde extérieur ne peut pas connaître l’identité de la personne de connexion à partir des données on-chain. **

Eph_pk (paire de clés éphémères) est une paire de clés utilisée dans une seule session, et non la clé publique ou privée du portefeuille, et l’utilisateur n’a pas besoin de s’en soucier.

Ce système peut également être utilisé pour la vérification hors chaîne, et peut être utilisé pour les portefeuilles contractuels qui utilisent une logique telle que MPC.

Puisqu’il s’agit d’un véritable système de vérification des contrats basé sur des connexions traditionnelles, les utilisateurs peuvent également désigner d’autres contacts sociaux comme tuteurs en cas de situations très extrêmes telles que l’annulation d’un compte Web2.

Transactions privées basées sur la méthode d’échange de clés DH

Avant de parler de la solution de transaction privée de Particle, examinons d’abord comment réaliser des transactions privées vers destinataire dans le système EVM existant, c’est-à-dire masquer l’adresse du destinataire.

Supposons qu’Alice soit l’expéditeur et Bob le destinataire, et nous avons des connaissances communes :

1. Bob génère la clé de dépense racine m et la méta-adresse furtive M. M peut être généré par m, et la relation entre les deux est M = G * m, ce qui représente une relation mathématique dans les opérations cryptographiques.

2. Alice obtient l’adresse méta furtive de Bob M de toute façon.

3. Alice génère une clé privée temporaire r et utilise des generate_address algorithmiques (r,M) pour générer une adresse cachée A. **Cette adresse est l’adresse furtive exclusive de Bob, et Bob a le contrôle de l’adresse après avoir reçu les actifs. **

4. Alice génère ensuite une clé publique temporaire R basée sur la clé privée temporaire r et l’envoie au contrat d’enregistrement de clé publique temporaire (ou à tout autre emplacement convenu d’un commun accord, quel que soit le canal, tant que Bob peut l’obtenir).

5. Bob doit analyser périodiquement le contrat d’enregistrement de clé publique temporaire et enregistrer chaque clé publique temporaire mise à jour. Étant donné que le contrat de clé publique éphémère est public et contient des clés liées à des transactions privées envoyées par d’autres, Bob ne sait pas laquelle Alice lui a envoyée.

6. Bob scanne chaque enregistrement mis à jour et effectue generate_address (R,m) pour calculer l’adresse expurgée. S’il y a un actif dans l’adresse, il est généré par Alice et autorisé à être contrôlé par Bob, sinon il n’a rien à voir avec Bob.

7. Bob exécute le generate_spending_key(R,m) pour générer la clé privée du consommateur pour l’adresse furtive, c’est-à-dire p = m + hash(A), puis peut contrôler l’adresse A générée par Alice.

La description du processus ci-dessus simplifie en fait beaucoup d’opérations mathématiques complexes, ** L’ensemble du processus d’échange de renseignements est comme deux espions écrivant des mots de code qui ne peuvent être déchiffrés que l’un par l’autre sur un tableau d’affichage public, ** Bien que les méthodes de génération et de décryptage des mots de code soient publiques, seuls deux espions connaissent les données importantes nécessaires au milieu, donc même si le monde extérieur connaît les méthodes de génération et de décryptage des mots de code, ils ne peuvent toujours pas être déchiffrés en douceur.

Ce processus d’échange est à peu près le même que la méthode d’échange de clés bien connue de Diffie-Hellman, dans laquelle les deux parties peuvent calculer le secret partagé – l’adresse cachée A ci-dessus – sans révéler leurs secrets respectifs (la clé privée du consommateur racine m de Bob et la clé privée temporaire d’Alice r). **Si vous ne connaissez pas l’échange DH, vous pouvez utiliser le diagramme de coloration suivant pour le comprendre métaphoriquement.

Une étape supplémentaire par rapport à DH est qu’une fois que chacun d’entre eux a trouvé l’adresse secrète partagée A, ils ne peuvent pas l’utiliser comme clé privée, car Alice connaît également A. Il est nécessaire de construire la clé privée consommateur p = m + hash(A), et de traiter A comme une clé publique. Comme mentionné précédemment, la clé privée du consommateur racine m n’est connue que de Bob, de sorte que Bob devient le seul contrôleur de l’adresse furtive. **

Évidemment, avec cette méthode de transferts privés, chaque fois que le destinataire reçoit une nouvelle transaction, les fonds de cette transaction seront versés dans une toute nouvelle adresse EOA. Le destinataire peut utiliser la clé privée de consommation racine pour calculer la clé privée de consommation de chaque adresse séparément afin de voir laquelle est vraiment liée à lui.

Mais maintenant, il y a un autre problème, cette adresse furtive nouvellement générée est toujours un compte EOA au début, il se peut qu’il n’y ait pas de jetons de gaz tels que ETH dessus, Bob n’a aucun moyen d’initier directement des transactions, ** besoin d’utiliser la fonction Paymaster du portefeuille de contrat intelligent pour le paiement de gaz, afin de réaliser des transactions privées. **Par conséquent, il est nécessaire d’apporter quelques modifications à l’adresse de réception :

Calculez une adresse contrefactuelle à l’aide de la méthode de calcul d’adresse de la méthode CREATE2 lors du déploiement du contrat, avec les paramètres correspondants (définition de l’adresse furtive A comme propriétaire du contrat, etc.). Il s’agit d’une adresse de contrat calculée, mais le contrat n’a pas encore été déployé et il s’agit toujours d’une EOA pour le moment.

**Alice transférera l’argent directement à l’adresse contrefactuelle. **Lorsque Bob souhaite l’utiliser, il peut créer un portefeuille de contrat directement sur cette adresse, afin de pouvoir appeler le service de paiement de gaz (cette étape peut également être effectuée par Alice ou Particle network en son nom).

Nous pouvons appeler l’adresse contrefactuelle ci-dessus une adresse furtive intelligente. Bob utilise le processus suivant pour utiliser de manière anonyme les ressources sous l’adresse Smart Cloak :

Rechargez Paymaster à l’une de vos propres adresses, et Paymaster vous renverra une preuve de fonds (ZK).

Avec le mécanisme AA, envoyez une UserOperation au nœud Bundler avec n’importe quelle autre adresse (ne peut pas avoir de solde) pour appeler les ressources sous l’adresse cachée ci-dessus. Bob fournit simplement une preuve de fonds à Paymaster avec une nouvelle adresse, et Paymaster paie pour la transaction d’emballage Bundler.

C’est en fait similaire à la façon dont Tornado Cash fonctionne, par le biais d’une preuve de fonds (ZK), qui peut prouver qu’il y a eu une recharge dans l’ensemble des nœuds feuilles de l’arbre de Merkle, et personne ne peut savoir quel nœud feuille a été consommé lorsqu’il a été dépensé, afin de couper la connexion entre le consommateur et le déposant.

Pour résumer, Particle combine des adresses AA et cachées, et réalise intelligemment des transferts privés sous la forme de portefeuilles cachés intelligents.

Abstraction de la chaîne de particules et du compte de la chaîne complète

Particle Chain est une chaîne de point de vente conçue pour l’abstraction de compte Omnichain. En se concentrant sur la situation actuelle et l’avenir, il est impossible d’être un monde à chaîne unique, et il est crucial d’améliorer l’expérience utilisateur dans un environnement de travail multi-chaînes.

À l’heure actuelle, ERC4337 système d’abstraction de compte aura certains problèmes dans le cas de multi-chaînes :

L’adresse d’un même utilisateur dans différentes chaînes peut ne pas être uniforme, selon la conception du contrat.

Les utilisateurs doivent répéter manuellement les opérations de gestion entre plusieurs chaînes pour gérer les portefeuilles de contrats sur différentes chaînes, par exemple en changeant d’administrateur. Pire encore, si les privilèges d’administrateur sont mis à jour sur une chaîne et que l’ancienne méthode d’authentification administrateur est supprimée, le portefeuille ne peut pas être modifié sur d’autres chaînes.

Pour utiliser différentes chaînes, vous devez avoir des pièces de gaz dans chaque chaîne, ou avoir des fonds pré-déposés dans Paymaster sur chaque chaîne. Il y a aussi un certain nombre de problèmes pour les développeurs, s’ils veulent que les utilisateurs utilisent ou implémentent d’autres fonctions à un coût nul sous certaines conditions, ils doivent également déployer leur propre Paymaster personnalisé sur chaque chaîne et y déposer des fonds.

L’abstraction de compte de la chaîne complète de Particle Chain résout les problèmes ci-dessus :

Construisez un portefeuille AA sur Particle Chain.

Grâce au protocole inter-chaînes AMB (Arbitrary Message Bridge) tel que LayerZero, diverses opérations, telles que la création, la mise à niveau, les autorisations de modification, etc., sont synchronisées avec d’autres chaînes. **Il peut être entendu que les autres portefeuilles de la chaîne sont des références aux portefeuilles de la chaîne, et que seul le corps principal doit être modifié pour être synchronisé avec tous les portefeuilles.

**Contrat de déploiement avec des paramètres cohérents pour s’assurer que l’adresse du portefeuille sur chaque chaîne est la même. **

Les portefeuilles entre les chaînes peuvent également s’appeler entre eux via AMB, qui ne sont pas tous initiés à partir de Particle Chain.

**Émission d’Unified Gas Token, une pièce de gaz à chaîne complète. **L’ERC20 est mis en œuvre par le mécanisme Paymaster sous la forme d’une redevance de gaz. Même s’il n’y a pas de gaz ou de fonds pré-déposés Paymaster sur une certaine chaîne, vous pouvez initier une transaction inter-chaînes sur une chaîne éligible pour consommer des jetons de gaz unifiés.

En plus des utilisations ci-dessus, la chaîne de particules peut également être utilisée à l’avenir :

Un réseau décentralisé généré par Proof and Salt de zkWaaS.

La couche d’incitation de chaque Bundler de chaîne aide Bundler à obtenir une meilleure décentralisation.

Un réseau de solveurs en tant que protocole de fusion d’intention.

Dans le récit de Particle Chain, Unified Gas Token est la valeur fondamentale de l’ensemble de l’écosystème :

La fonction de paiement des frais de gaz est une forte logique de capture de la demande et de la valeur qui a été vérifiée à plusieurs reprises dans la cryptographie.

Le jeton de gaz unifié abstrait le concept de couche de gaz de l’écologie de la chaîne publique existante, et cette abstraction ne peut être réalisée sans la chaîne de particules et le portefeuille, de sorte que le jeton de gaz unifié est un retrait de valeur de l’ensemble de l’écologie de la particule. Avec la couche de gaz, l’interaction de l’utilisateur et la croissance de chaque chaîne et la valeur de la monnaie locale sont mutuellement bénéfiques et symbiotiques avec le jeton de gaz unifié.

Le gaz unifié est également l’un des facteurs déterminants pour la réalisation de Chainless. Pour les utilisateurs, le paiement dans une seule devise simplifie considérablement le processus et la compréhension des coûts. À l’avenir, même dans le scénario multi-chaînes, les utilisateurs seront probablement insensibles et n’auront pas besoin de se soucier du fonctionnement de l’infrastructure sous-jacente. Tout comme actuellement dans le Web2, nous ne nous soucions pas de la région dans laquelle se trouve la salle informatique, de la configuration, de la langue utilisée et de la base de données qui fonctionne.

Les utilisateurs importés par la dApp renforcent directement l’Unified Gas Token, et les scénarios d’utilisation sont très riches.

Protocole de fusion d’intention

Habituellement, nous devons constamment réfléchir au chemin d’utilisation lors de l’utilisation de diverses dApps :

S’il n’y a pas de liquidité sur un DEX, vous devez en examiner un autre.

Je ne sais pas quelle dApp de la même catégorie devrait choisir pour mieux compléter la transaction ou la transaction.

· Approve a alors beaucoup de fonctionnalités à utiliser, et qu’est-ce que l’approbation ?

Dépoussiérage de portefeuille, plusieurs petits jetons dans une certaine devise, le processus est fastidieux.

Afin d’atteindre l’objectif final, il faut plusieurs applications. Tels que les prêts à fort effet de levier : échangez, nantissez, empruntez, obtenez des jetons, puis échangez, nantissez, empruntez…

Ce qui précède n’est que la partie émergée de l’iceberg dans notre monde DeFi actuel, et à l’ère de l’adoption massive du Web3 où les dApps deviennent de plus en plus diversifiées, les interactions peuvent être beaucoup plus complexes que vous ne le pensez.

Par conséquent, le remplacement d’étapes d’opération spécifiques par une intention d’intention peut être très différent pour l’expérience utilisateur. L’intention est plus qu’opérationnelle, tout comme la programmation déclarative l’est à la programmation fonctionnelle. Les énoncés déclaratifs ont tendance à sembler simples et directs, il suffit de déclarer ce que je vais faire et de ne pas se soucier des détails, et cela nécessite une variété d’énoncés de programmation fonctionnelle qui sont encapsulés en bas.

Dans ce cas, l’utilisation d’Intents ne fait pas exception, et elle doit également être soutenue par une série d’installations. Jetons un coup d’œil à l’ensemble du processus :

**1. L’utilisateur soumet au réseau Solver sous forme de RFS (Request For Solver), tel que le langage naturel. **Solver est un interpréteur d’intention, et il existe des agrégateurs tels que 1inch qui peuvent trouver le meilleur dex pour les utilisateurs, mais ils ne sont pas assez génériques et puissants par rapport à notre vision.

**2. Plusieurs solveurs se répondent les uns aux autres, et ils sont en concurrence. Ces réponses sont écrites dans le langage DSL d’intention et analysées par le client dans un formulaire facile à comprendre pour l’utilisateur. Ces réponses sont constituées de contraintes d’entrée et de contrainte de sortie, qui définissent les limites entre l’entrée et la sortie. Les utilisateurs peuvent également spécifier leurs propres contraintes. Un exemple simple à comprendre : lors de l’utilisation de Swap, l’utilisateur sera invité à indiquer le montant minimum pouvant être obtenu après l’échange, ce qui est une contrainte. L’utilisateur choisit lui-même parmi les réponses de plusieurs solveurs.

3. Signez l’intention.

**4.Le solveur spécifie un contrat d’exécution spécifique et soumet l’intention au contrat de réponse Reactor. **

5. Reactor collecte l’entrée requise (telle qu’un actif) à partir du compte utilisateur, soumet une intention à utor, puis appelle le contrat logique approprié pour renvoyer la sortie de la transaction à Reactor. Le réacteur vérifie les contraintes et renvoie la sortie à l’utilisateur si elle est correcte.

Nous pouvons penser à ce processus lorsque vous parlez à ChatGPT des exigences, quelle que soit la complexité des exigences, il peut générer un résultat final pour vous, tant que vous êtes satisfait des résultats, vous pouvez l’utiliser directement, sans vous soucier du processus.

Résumé

Particle Network propose une solution complète : grâce à la trinité de zkWaaS, de Particle Chain et d’Intent Fusion Protocol, Web2 OAuth privacy login, les transactions privées, l’abstraction de compte de la chaîne complète et les paradigmes de transaction d’intention sont réalisés. Chaque fonctionnalité couvrira certains des points sensibles de l’utilisation du Web3, et ces avancées et optimisations deviendront la base du produit et de la technologie pour l’adoption massive du Web3 à l’avenir. En termes d’écologie et de modèle économique, le paradigme B2B2C est adopté, le WaaS est utilisé comme porte d’entrée pour conduire la standardisation à grande échelle de l’ensemble de la chaîne de produits, et l’écosystème est construit avec les développeurs de dApp pour créer conjointement un monde Web3 avec un seuil bas et une expérience élevée pour les utilisateurs.

Bien sûr, différents projets ont des compréhensions différentes du chemin de mise en œuvre de l’adoption massive du Web3. En plus de l’examen de projets spécifiques, nous espérons mener à une compréhension des frictions internes auxquelles le Web3 est actuellement confronté, à une réflexion sur les besoins et les points faibles des utilisateurs, et à une prise en compte de la connexion et du développement conjoints de l’ensemble de l’écosystème.