Analyse technique : La couche d'accès du web ouvert construite par Particle Network
TechFlow SélectionTechFlow Sélection
Analyse technique : La couche d'accès du web ouvert construite par Particle Network
Prenons l'exemple de Particle Network pour analyser en détail les problèmes actuels d'expérience utilisateur dans les produits Web3, ainsi que la manière de concevoir une solution technique globale et ciblée.
Dédié à des analyses Web3 approfondiesRédaction : Wuyue, Geek Web3
Introduction : Bien que les portefeuilles AA aient considérablement abaissé la barrière d'entrée pour les utilisateurs, en permettant initialement le paiement de frais de gaz par un tiers et une connexion similaire à celle des comptes Web2, des conceptions liées à l'adoption massive — telles que la connexion privée, les transactions privées, un compte AA unique sur toutes les chaînes, ou encore une architecture dédiée aux intentions (intents) — restent à construire au-delà du simple cadre AA.
Nous observons déjà de nombreuses solutions d'optimisation UX, comme les portefeuilles MPC tels que ZenGo, ou des portefeuilles intelligents comme Argent, qui réduisent efficacement la complexité pour l'utilisateur. Toutefois, elles ne résolvent qu'une partie des problèmes mentionnés ci-dessus, sans couvrir intégralement tous les aspects d'ergonomie produit.
Il est clair que la plupart des portefeuilles AA actuels ou produits similaires ne sont pas encore prêts à soutenir une adoption massive de Web3. D’un autre côté, du point de vue de l’écosystème, l’aspect développeur est crucial : un produit attrayant uniquement pour les utilisateurs finaux mais ayant peu d’impact auprès des développeurs peine à atteindre l’échelle. L’émergence croissante de solutions visant à améliorer l’expérience des développeurs montre bien l’importance stratégique de ce segment pour l’écosystème.
Nous prendrons ici l'exemple de Particle Network afin d’analyser en détail les lacunes actuelles des produits Web3 en matière d’expérience utilisateur, ainsi que la manière de concevoir une solution technique globale adaptée. Une telle approche intégrée pourrait bien être la condition nécessaire à une adoption massive. Par ailleurs, la stratégie commerciale BtoBtoC de Particle constitue également un modèle que de nombreux projets devraient étudier et s’approprier.
Analyse complète de l’architecture produit de Particle
Particle Network adopte une approche centrée sur la réduction des barrières d’utilisation, selon une logique B2B2C pour le développement produit et écosystémique, proposant ainsi une solution complète destinée à l’adoption massive de Web3. Son architecture repose sur trois modules principaux :
zkWaaS, un service Wallet-as-a-Service basé sur les preuves à divulgation nulle (ZK). Grâce à un SDK fourni par Particle, les développeurs peuvent rapidement intégrer un module de portefeuille intelligent dans leurs dApp. Ce portefeuille, basé sur l’abstraction de compte (account abstraction), est sans clé (keyless) et sous forme de contrat intelligent. Il permet non seulement des scénarios basiques d’AA comme le paiement de frais par un tiers, mais aussi une connexion privée via OAuth façon Web2, ainsi que des fonctionnalités de transaction privée.
Particle Chain —— une solution d’abstraction de compte omnichaîne (Omnichain Account Abstraction), conçue pour résoudre les problèmes liés au déploiement, à la maintenance et à l'appel de portefeuilles intelligents à travers plusieurs chaînes. Elle inclut également un jeton de gaz universel (Unified Gas Token), destiné à simplifier l'utilisation de différents jetons de gaz sur plusieurs chaînes.
Intent Fusion Protocol, comprenant un langage DSL (langage spécifique au domaine) simple, un cadre Intent, et un réseau de solveurs (Solver Network), afin de construire un cadre d'interaction Web3 fondé sur les intentions (intents). L'utilisateur déclare simplement son intention de transaction, sans avoir à exécuter chaque étape manuellement, ce qui lui évite de penser à des chemins complexes et réduit la nécessité de comprendre les infrastructures techniques sous-jacentes.
zkWaaS —— Portefeuille intelligent comme service combiné à la ZK
Du côté portefeuille, Particle propose principalement un service WaaS (Wallet-as-a-Service) aux développeurs de dApp via un SDK, dans l’objectif de les intégrer à son cadre complet d’adoption massive de Web3. Cette approche BtoBtoC présente plusieurs avantages du point de vue commercial et écosystémique :
La concurrence entre portefeuilles grand public (côté C) est déjà féroce, avec des fonctionnalités largement similaires ; ce n’est donc plus un bon point d’entrée. D’autre part, les développeurs de dApp préfèrent de plus en plus intégrer directement un portefeuille dans leur application pour éviter les frictions liées à la connexion externe, aux changements d’onglets lors des transactions, tout en offrant davantage de personnalisation.
L’acquisition d’utilisateurs côté C est coûteuse, contrairement au côté B. La croissance de l’utilisation de WaaS découle principalement des dApp ayant intégré le SDK. En se concentrant sur le développement commercial (BD) et les relations avec les développeurs, on peut étendre progressivement tout l’écosystème selon une logique de « conquête des villes entourant les campagnes ».
Les portefeuilles grand public se concentrent aujourd’hui surtout sur la finance et les actifs, mais cela ne représente probablement pas le principal scénario futur de Web3. Pour véritablement atteindre une adoption massive, certains projets doivent abstraire les fonctions fondamentales — identité utilisateur (compte) et actions utilisateur (envoi de transactions) — afin d’en faire un service de base, libérant ainsi les dApp pour explorer des cas d’usage plus riches.
En observant les points d’accès traditionnels aux dApp, on constate un lien étroit entre portefeuilles et dApp. Maximiser la pénétration du portefeuille au sein des dApp est donc essentiel — avantage dont bénéficie naturellement le modèle B2B2C.
Construire un WaaS capable de répondre aux besoins des utilisateurs, d’abaisser les seuils d’entrée, et d’être facilement intégré par les développeurs constitue un autre pilier du succès. zkWaaS de Particle repose sur trois piliers clés :
1. Connexion privée. Utilisation de méthodes de connexion Web2 classiques (Twitter, Google, WeChat, etc.) via des vérifications OAuth directement sur le contrat du portefeuille intelligent, permettant aux utilisateurs de se libérer complètement de la gestion des clés privées, en entrant dans Web3 de manière familière et simple. Le recours à la preuve à divulgation nulle (ZK) permet par ailleurs de masquer l’identité de l’utilisateur.
2. Transactions privées. Mise en œuvre d’un mécanisme d’adresse furtive intelligente (Smart Stealth Address) pour des transferts privés peer-to-peer universels, combiné au Paymaster d’ERC4337 pour permettre à ces adresses furtives d’utiliser des actifs sans frais de gaz (sponsorisés).
3. Fonctionnalités complètes de portefeuille AA. Le module portefeuille de Particle respecte pleinement les exigences de base de ERC-4337, y compris Bundler, EntryPoint, Paymaster et Smart Wallet Account, satisfaisant ainsi de manière exhaustive les besoins fonctionnels des dApp ou des utilisateurs en matière de portefeuille intelligent.
Connexion privée sur chaîne via compte Web2
La solution de connexion privée de Particle utilise le JWT (Json Web Token), permettant une authentification d’identité Web2 directement dans le contrat, ainsi que l’opération du portefeuille.
Le JWT est un jeton d’authentification largement utilisé sur Internet traditionnel, émis par un serveur vers un client. À chaque interaction avec le serveur, le client utilise ce jeton pour s’authentifier.
(Source : FlutterFlow Docs)
Certains champs clés du JWT servent de base à la vérification d’identité par le contrat :
-
« iss » (Issuer) indique l’émetteur du JWT, c’est-à-dire le serveur (Google, Twitter, etc.).
-
« aud » (Audience) précise le service ou l’application concernée par ce JWT. Par exemple, lors d’une connexion à Medium via Twitter, le champ « aud » spécifie que le JWT est valable pour Medium.
-
« sub » (Subject) correspond à l’identité de l’utilisateur recevant le JWT, généralement notée par un UID.
Dans la pratique, les valeurs de « iss » et « sub » restent presque toujours constantes, car leur modification entraînerait un grand désordre dans les systèmes internes et externes. Ces paramètres peuvent donc être utilisés par le contrat pour identifier l’utilisateur, ce qui signifie que l’utilisateur n’a absolument pas besoin de générer ou de gérer une clé privée.
Le concept associé au JWT est JWK (JSON Web Key), qui désigne une paire de clés côté serveur. Lors de l’émission d’un JWT, le serveur signe avec la clé privée du JWK, tandis que la clé publique est rendue publique pour permettre à d'autres services de vérifier la signature.
Par exemple, lorsque Medium utilise Twitter pour connecter un utilisateur, Medium vérifie le JWT à l’aide de la clé publique JWK publiée par Twitter, afin de confirmer son authenticité — c’est-à-dire qu’il a bien été émis par Twitter. Le contrat effectue également cette vérification via le JWK.
Le processus de connexion privée de Particle est illustré ci-dessous :
Nous omettons ici les détails du circuit ZK. Voici quelques points clés du processus :
-
Le contrat Verifier, chargé de valider les informations de connexion, ne perçoit qu’une preuve ZK liée à l’identité utilisateur - JWT et une clé temporaire inoffensive (eph_pk). Il ne peut pas accéder directement à la clé publique du portefeuille ou aux données JWT, préservant ainsi la confidentialité de l’utilisateur. Personne ne peut déduire l’identité du connecté à partir des données blockchain.
-
eph_pk (paire de clés temporaires) est utilisée pour une seule session, elle n’est pas la paire de clés du portefeuille, et l’utilisateur n’a pas à s’en soucier.
-
Ce système permet aussi une vérification hors chaîne, utile pour des portefeuilles contrats utilisant par exemple la MPC.
Étant donné qu’il s’agit d’un véritable schéma de vérification contractuel basé sur les méthodes de connexion traditionnelles, l’utilisateur peut désigner d’autres contacts sociaux comme gardiens, au cas où son compte Web2 serait supprimé dans des circonstances extrêmes.
Transactions privées basées sur l’échange de clés Diffie-Hellman
Avant d’examiner la solution de transaction privée de Particle, examinons comment réaliser une transaction privée du point de vue du bénéficiaire dans l’architecture EVM actuelle, c’est-à-dire masquer l’adresse du destinataire.
Nous supposons qu’Alice soit l’expéditeur et Bob le destinataire, tous deux partageant certaines connaissances communes :
1. Bob génère une clé de dépense racine (root spending key) m et une adresse-méta furtive (stealth meta-address) M. M peut être dérivée de m, avec la relation M = G * m, représentant une opération cryptographique mathématique.
2. Alice obtient par un moyen quelconque l’adresse-méta furtive M de Bob.
3. Alice génère une clé privée temporaire r et utilise l’algorithme generate_address(r,M) pour créer une adresse furtive A. Cette adresse est spécialement préparée pour Bob, qui acquiert ainsi le contrôle de cette adresse après réception des actifs.
4. Alice génère ensuite une clé publique temporaire R à partir de r, puis l’envoie à un contrat de registre de clés publiques temporaires (ou tout autre emplacement convenu accessible à Bob).
5. Bob doit régulièrement scanner le contrat de registre pour relever chaque nouvelle clé publique temporaire. Comme ce registre est public et contient des clés liées à d'autres transactions privées, Bob ne sait pas encore laquelle provient d’Alice.
6. Bob examine chaque nouvel enregistrement, exécute generate_address(R,m) pour calculer l’adresse furtive. Si cette adresse contient des actifs, c’est qu’elle a été créée et autorisée par Alice pour Bob ; sinon, elle ne le concerne pas.
7. Bob exécute generate_spending_key(R,m) pour obtenir la clé de dépense de cette adresse furtive, soit p = m + hash(A), puis peut contrôler l’adresse A créée par Alice.
Ce processus simplifie de nombreuses opérations mathématiques complexes. L’échange d’informations ressemble à celui de deux agents secrets écrivant sur un tableau public des messages codés que seul l’autre peut décoder. Bien que la méthode de génération et de décodage soit publique, seuls les deux agents connaissent les données critiques intermédiaires, empêchant ainsi toute tierce partie de déchiffrer les messages.
Ce mécanisme rappelle fortement l’échange de clés Diffie-Hellman, permettant à deux parties de calculer un secret partagé — ici l’adresse furtive A — sans divulguer leurs secrets respectifs (la clé racine m de Bob et la clé temporaire r d’Alice). Pour mieux comprendre DH, voici une analogie visuelle avec des mélanges de couleurs.
Une étape supplémentaire par rapport à DH : après avoir calculé le secret partagé (l’adresse furtive A), on ne peut pas l’utiliser directement comme clé privée, car Alice la connaît aussi. On construit donc une clé de dépense p = m + hash(A), et on utilise A comme clé publique. Étant donné que seule Bob connaît la clé racine m, Bob devient ainsi le seul contrôleur de cette adresse furtive.
Avec cette méthode, lorsqu’un destinataire reçoit une nouvelle transaction, les fonds sont envoyés vers une nouvelle adresse EOA. Le destinataire peut utiliser sa clé racine pour tenter de calculer successivement les clés de dépense de chaque adresse, afin de voir laquelle lui appartient.
Mais un problème subsiste : la nouvelle adresse furtive créée est initialement un compte EOA, qui peut ne pas contenir de jeton de gaz (ETH, etc.), empêchant Bob d’initier une transaction. Il faut donc recourir à la fonction Paymaster du portefeuille intelligent pour payer les frais de gaz, rendant ainsi possible la transaction privée. Il faut donc adapter l’adresse de destination :
Utiliser la méthode CREATE2 lors du déploiement du contrat, avec des paramètres appropriés (comme définir l’adresse furtive A comme propriétaire du contrat), pour calculer une adresse contre-factuelle. Il s’agit d’une adresse de contrat calculée mais non encore déployée, donc temporairement un EOA.
Alice transfère directement vers cette adresse contre-factuelle. Quand Bob souhaite l’utiliser, il déploie simplement le contrat de portefeuille intelligent à cette adresse, activant ainsi le service de paiement de frais (cette étape pouvant aussi être réalisée par Alice ou le réseau Particle à l’avance).
Nous appelons cette adresse contre-factuelle une adresse furtive intelligente. Bob utilise anonymement les actifs de cette adresse selon le processus suivant :
Il crédite un Paymaster depuis n’importe quelle adresse, obtenant en retour une preuve de fonds (sous forme ZK).
Grâce au mécanisme AA, il envoie une UserOperation à un nœud Bundler depuis n’importe quelle adresse (même sans solde), afin d’utiliser les actifs situés sous l’adresse furtive. Il suffit que Bob fournisse la preuve de fonds à partir d’une nouvelle adresse au Paymaster, qui paiera alors les frais de traitement au Bundler.
Ce fonctionnement est similaire à Tornado Cash : la preuve de fonds (sous forme ZK) permet de prouver qu’un dépôt a eu lieu dans un ensemble de feuilles d’un arbre de Merkle, sans révéler laquelle est dépensée, rompant ainsi le lien entre déposant et consommateur.
En résumé, Particle combine ingénieusement l’AA et les adresses furtives pour réaliser des virements privés via un portefeuille furtive intelligent.
Particle Chain et l’abstraction de compte omnichaîne
Particle Chain est une chaîne de type POS spécialement conçue pour l’abstraction de compte omnichaîne (Omnichain Account Abstraction). Étant donné que ni le présent ni l’avenir ne seront dominés par une seule chaîne, améliorer l’expérience utilisateur dans un contexte multi-chaînes est essentiel.
Actuellement, le système d’abstraction de compte ERC4337 pose certains problèmes en environnement multi-chaînes :
-
L’adresse d’un même utilisateur peut varier selon les chaînes, en fonction de la conception du contrat.
-
La gestion des portefeuilles contrats sur différentes chaînes oblige l’utilisateur à répéter manuellement des opérations (ex : changement d’administrateur). Pire encore, si l’utilisateur met à jour ses droits sur une chaîne puis abandonne l’ancienne méthode de vérification, il ne pourra plus modifier ni utiliser son portefeuille sur les autres chaînes.
-
Utiliser différentes chaînes requiert posséder leur jeton de gaz respectif, ou disposer de fonds préchargés sur les Paymaster correspondants. Pour les développeurs, c’est également contraignant : s’ils veulent permettre un usage gratuit sous certaines conditions, ils doivent déployer un Paymaster personnalisé sur chaque chaîne et y précharger des fonds.
L’abstraction de compte omnichaîne de Particle Chain répond précisément à ces douleurs :
-
Création du portefeuille AA sur Particle Chain.
-
Utilisation de protocoles de ponts arbitraires (AMB) comme LayerZero pour synchroniser des opérations (création, mise à niveau, changement de permissions) vers d’autres chaînes. Les portefeuilles sur les autres chaînes sont des références du portefeuille principal : modifier le principal synchronise automatiquement tous les autres.
-
Utilisation d’un contrat Deployer avec paramètres identiques pour garantir que l’adresse du portefeuille soit la même sur toutes les chaînes.
-
Les portefeuilles sur différentes chaînes peuvent s’appeler mutuellement via AMB, sans forcément passer par Particle Chain.
-
Émission d’un Unified Gas Token, un jeton de gaz universel valable sur toutes les chaînes. Via le mécanisme Paymaster, un jeton ERC20 peut servir de frais de gaz. Même sans jeton de gaz local ni fonds préchargés sur le Paymaster, on peut initier une transaction inter-chaînes en consommant le Unified Gas Token, sous réserve de conditions remplies.
Outre ces usages, Particle Chain pourrait à l’avenir servir à :
-
Un réseau décentralisé pour la génération de preuves et de sel dans zkWaaS.
-
Une couche d’incitation pour les Bundlers sur chaque chaîne, favorisant une meilleure décentralisation.
-
Le réseau de solveurs pour le Intent Fusion Protocol.
Dans la narration de Particle Chain, le Unified Gas Token est le levier central de valeur de tout l’écosystème :
-
La fonction de paiement des frais de gaz est un besoin fort et un mécanisme de capture de valeur largement validé dans le crypto.
-
Le Unified Gas Token introduit une couche de gaz abstraite issue des écosystèmes existants, abstraction impossible sans Particle Chain et ses portefeuilles. Le token incarne donc une valeur intrinsèque à l’écosystème. Avec cette couche de gaz, l’interaction utilisateur, la croissance multi-chaînes et la valeur du jeton natif deviennent mutuellement bénéfiques.
-
Le gaz unifié contribue aussi à la vision Chainless. Pour l’utilisateur, payer avec une seule devise simplifie considérablement l’usage et la compréhension. À l’avenir, même dans un contexte multi-chaînes, l’utilisateur pourrait ne rien ressentir, ignorant complètement l’infrastructure sous-jacente — tout comme aujourd’hui, sur Web2, nous interagissons avec des serveurs sans savoir où se trouvent les datacenters, ni leur configuration ou technologie utilisée.
-
Les utilisateurs importés par les dApp renforcent directement l’utilité du Unified Gas Token, qui dispose ainsi de nombreux cas d’usage.
Intent Fusion Protocol
En général, lors de l’utilisation de diverses dApp, nous devons constamment réfléchir au chemin à suivre :
-
Si un DEX ne dispose pas d’une certaine liquidité, il faut en consulter un autre.
-
On ignore souvent quel dApp du même type permettrait de mieux accomplir une transaction.
-
Il faut approuver (approve) pour beaucoup de fonctions, mais qu’est-ce que approve ?
-
Nettoyer un portefeuille (wallet dust), convertir plusieurs petits jetons en une seule devise — un processus fastidieux.
-
Atteindre un objectif final impliquant plusieurs applications. Par exemple, un emprunt à effet de levier élevé : swap, mise en gage, prêt, puis swap du jeton obtenu, nouveau gage, nouveau prêt, etc.
Tout cela n’est qu’un aperçu de la complexité actuelle dans le monde DeFi. À l’ère de l’adoption massive de Web3, avec des dApp de plus en plus variés, la complexité des interactions pourrait dépasser l’imaginaire.
Ainsi, remplacer les étapes opérationnelles par des intentions (intents) fait une différence radicale en termes d’expérience utilisateur. Les intents par rapport aux opérations sont comme la programmation déclarative par rapport à la programmation fonctionnelle. Les instructions déclaratives semblent simples : il suffit de dire ce que l’on veut, sans se soucier des détails. Mais cela repose sur une couche profonde d’instructions fonctionnelles encapsulées.
L’utilisation d’intentions n’échappe pas à cette règle : elle nécessite un ensemble d’infrastructures. Examinons le processus global :
1. L’utilisateur exprime son intention d’une certaine manière (langage naturel, etc.), sous forme de RFS (Request For Solver), envoyée au réseau de solveurs. Le solveur est l’interprète de l’intention. Actuellement, des agrégateurs comme 1inch jouent ce rôle, trouvant le meilleur DEX pour l’utilisateur, mais ils ne sont pas assez universels ni puissants par rapport à la vision recherchée.
2. Plusieurs solveurs répondent, en concurrence. Ces réponses, écrites en langage DSL d’intention, sont analysées par le client pour être présentées clairement à l’utilisateur. Elles incluent Input Constraints et Output Constraints, définissant les limites d’entrée et de sortie. L’utilisateur peut aussi définir ses propres contraintes. Exemple simple : lors d’un swap, on indique le minimum attendu après échange — une contrainte. L’utilisateur choisit parmi les propositions.
3. Signature de l’intention.
4. Le solveur désigne un contrat d’exécution (Executor) spécifique et transmet l’intention au contrat de réponse (Reactor).
5. Le Reactor récupère les entrées nécessaires (ex : un actif) depuis le compte utilisateur, transmet l’intention à l’Executor, qui appelle les contrats logiques pertinents, puis renvoie le résultat au Reactor. Ce dernier vérifie les contraintes, et si tout est conforme, renvoie le résultat à l’utilisateur.
On peut imaginer ce processus comme expliquer une demande à ChatGPT : quelle que soit sa complexité, il vous fournit un résultat final. Si vous êtes satisfait, vous pouvez l’utiliser directement, sans vous soucier du processus interne.
Conclusion
Particle Network propose une solution globale : combinant zkWaaS, Particle Chain et Intent Fusion Protocol, il réalise une connexion privée OAuth façon Web2, des transactions privées, une abstraction de compte omnichaîne et un paradigme de transaction basé sur les intentions. Chaque fonctionnalité vise à résoudre une partie des difficultés d’utilisation de Web3. Ces avancées et optimisations deviendront les bases techniques et produit nécessaires à l’adoption massive de Web3. Sur le plan écosystémique et commercial, le modèle B2B2C, utilisant WaaS comme porte d’entrée pour standardiser et élargir la chaîne produit, permet de construire conjointement l’écosystème avec les développeurs de dApp, créant ainsi un monde Web3 accessible et hautement ergonomique.
Bien sûr, les visions diffèrent selon les projets quant au chemin vers l’adoption massive de Web3. Au-delà de l’analyse de projets spécifiques, nous espérons que ces différentes approches stimuleront une réflexion sur les frictions actuelles d’intégration (onboard friction), sur les besoins et douleurs des utilisateurs, ainsi que sur la manière dont l’ensemble de l’écosystème peut coopérer et évoluer collectivement.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@godrealmx
