Aperçu rapide de l'abstraction des comptes multichaînes de Particle Network : motivations, composants de base et plans futurs
TechFlow SélectionTechFlow Sélection
Aperçu rapide de l'abstraction des comptes multichaînes de Particle Network : motivations, composants de base et plans futurs
Particle publie officiellement son infrastructure fondamentale d'abstractisation des comptes blockchain complète.
Dédié à des analyses Web3 approfondiesRédaction : Peter Pan & Vijay Singh, Particle Network
Traduction : Peng SUN, Foresight News
Ces deux derniers mois, Particle Network n’a cessé d’annoncer de grands projets : depuis la présentation de sa conception v2 dotée de fonctionnalités ZK et centrées sur les intentions, jusqu’aux détails de son économie axée sur les jetons. Nous dévoilons progressivement notre feuille de route globale afin d’accueillir le prochain milliard d’utilisateurs dans l’univers Web3.
Le CTO de Particle a récemment publié un article analysant diverses approches existantes pour résoudre les défis du domaine de l’abstraction des comptes (Account Abstraction, AA). Cet article expose également la solution proposée par Particle : une abstraction de compte omnichain fondée sur ces solutions existantes, conçue pour régler plusieurs problèmes d’expérience utilisateur et de robustesse liés à l’infrastructure et à la conception de l’AA. En outre, cette abstraction omnichain peut également répondre aux difficultés persistantes de l’industrie en matière d’interopérabilité et de transferts inter-chaînes.
Aujourd’hui, Particle annonce officiellement l'infrastructure de son abstraction de compte omnichain.
TL;DR
L’abstraction de compte omnichain (Omnichain AA) de Particle résout les problèmes existants relatifs aux transactions inter-chaînes et à l’abstraction multi-chaîne des comptes, en dissociant le stockage et le code des comptes intelligents. Elle introduit la Particle Chain comme hub centralisé de stockage des comptes. Dans ce cadre, les messages inter-chaînes synchronisent les modifications de stockage. L’abstraction omnichain inclut aussi des contrats déployeurs (Deployer Contracts) permettant une génération d’adresses unifiée et une gestion centralisée du stockage multi-chaîne, ainsi qu’une solution de messagerie inter-chaînes exploitant des protocoles d’interopérabilité existants pour faciliter les interactions entre différentes chaînes. Enfin, nous proposons d’utiliser le jeton Particle comme gaz universel, afin de résoudre les inefficacités énergétiques liées à l’exécution multi-chaîne. Cette architecture simplifie la gestion des comptes intelligents sur plusieurs chaînes et améliore l’efficacité des opérations inter-chaînes.
I. Motivation derrière l’abstraction omnichain
Comme l’a analysé notre CTO, le cadre actuel de l’AA ERC-4337 ressemble davantage à une « abstraction du flux de transaction », car il se concentre principalement sur l’optimisation des processus sous-jacents d’exécution des transactions, plutôt que sur le compte lui-même.
Cette solution est importante car elle pose les bases de l’adoption des portefeuilles intelligents et de leur intégration au niveau des protocoles, mais elle soulève également plusieurs problèmes spécifiques :
-
Les solutions d’AA sont difficiles à intégrer, obligeant les développeurs à créer leurs propres implémentations personnalisées ;
-
La compatibilité entre modules de compte est médiocre, ce qui fragmente l’écosystème ;
-
Le fossé important entre différentes blockchains nuit à l’expérience utilisateur et développeur, rendant difficile l’offre d’une expérience unifiée et de haute qualité.
Face à ces défis, trois approches principales ont émergé :
-
Biconomy propose une méthode modulaire standardisée, où les développeurs peuvent construire leurs propres solutions sans adopter directement l’implémentation ERC-4337 des comptes intelligents. Cette proposition inclut aussi la création d’un marché hautement spécialisé pour différents modules pouvant s’intégrer aux comptes intelligents (Bundlers, Paymasters, etc.).
-
Safe (anciennement Gnosis Safe) propose une approche similaire mais avec des différences clés. Il vise à créer un protocole simple, semblable aux EOA, pour des comptes intelligents légers. Sur cette base, un marché de modules émergera, permettant à différents fournisseurs de développer leurs propres implémentations tout en maintenant la compatibilité.
-
Vitalik Buterin propose un système utilisant Ethereum ou un zk-rollup très sécurisé comme chaîne source, avec un contrat Keystore déployé pour stocker les clés globales des utilisateurs. Dans ce système, les comptes contractuels intelligents des utilisateurs sur les L2 partagent les clés globales stockées dans le contrat Keystore.
Les deux premières approches mettent l’accent sur la modularité et la compatibilité, deux caractéristiques essentielles de l’AA ; celle de Vitalik Buterin se concentre quant à elle sur l’activation de l’AA dans un écosystème multi-chaînes composé de multiples L2 et chaînes EVM. Examinons maintenant en détail les effets multi-chaînes des comptes intelligents dans les cadres actuels, ainsi que la solution proposée par Vitalik.
II. Le problème multi-chaînes des comptes intelligents
L’environnement EVM multi-chaînes actuel oblige les utilisateurs à déployer leurs comptes intelligents indépendamment sur chaque chaîne. Pour chaque compte, les informations liées à la gestion (notamment les autorisations) sont stockées dans le Storage du contrat. Mettre à jour ces informations nécessite que l’utilisateur lance des transactions sur plusieurs chaînes, ce qui rend techniquement difficile et chronophage l’assurance de la cohérence entre les réseaux.
Conception proposée par Vitalik Buterin
Dans la conception ERC-4337, les comptes intelligents utilisent une adresse globalement unique déterminée par initCode. Les droits de gestion initiaux sont codés dans initCode, ce qui signifie que si un utilisateur déploie un compte intelligent sur une nouvelle chaîne après avoir modifié ses autorisations sur une autre chaîne, il doit reproduire manuellement ces changements. Cela ajoute une complexité inutile pour les utilisateurs et les portefeuilles.
Pour illustrer l’importance et les défis posés par ces problèmes, considérons le scénario suivant :
-
Alice déploie un compte intelligent sur Polygon et Arbitrum, dont le propriétaire initial est Owner1. Elle a l’habitude de changer régulièrement ses propriétaires.
-
Elle remplace Owner1 par Owner2, puis oublie la clé privée de Owner1.
-
Bob lui envoie des USDC via Linea à son adresse.
-
Alice réalise alors qu’elle a besoin de la clé privée de Owner1 pour initier une transaction, car initCode dépend de Owner1. Malheureusement, elle a perdu cette clé et ne peut donc plus accéder à ses actifs.
La solution de Vitalik résout effectivement le problème de la gestion multi-chaînes des adresses, notamment les modifications de stockage comme le transfert de propriété ou la récupération sociale. Toutefois, elle présente aussi des inconvénients, notamment des coûts élevés. Outre des frais de configuration non négligeables, chaque changement de clé globale dans le contrat Keystore sur la chaîne source (Ethereum) exige une synchronisation inter-chaînes pour chaque compte sur les L2/chaînes cibles. Or, les coûts d’interaction entre Ethereum et les L2 sont trop élevés pour être acceptables par la majorité des utilisateurs.
Par ailleurs, les comptes contractuels intelligents fonctionnent différemment des EOA, ce qui rend difficile pour les utilisateurs de conserver la même adresse sur différentes chaînes, même si celles-ci sont compatibles EVM. C’est pourquoi Particle Network apporte des modifications clés à la proposition de Vitalik afin de minimiser l’impact sur l’utilisateur.
III. La solution de Particle Network
Particle propose une alternative capable de pallier les insuffisances des solutions AA multi-chaînes, tout en tirant parti d’autres composants de l’infrastructure Web3.
Plus précisément, Particle Network suggère d’utiliser une chaîne indépendante — la Particle Chain — comme base de données de stockage omnichain pour les comptes intelligents. Grâce à des solutions tierces de messagerie inter-chaînes (telles que LayerZero, CCIP, Axelar, Connext, etc.), toute modification du stockage d’un compte sera finalement synchronisée avec son stockage local sur d'autres chaînes. Particle Network introduit aussi les opérations utilisateur inter-chaînes (Cross-chain UserOperations), qui abstraient davantage la notion de chaîne et facilitent les interactions inter-chaînes transparentes. Enfin, le jeton Particle est utilisé comme gaz unifié, simplifiant ainsi les mécanismes complexes de paiement du gaz et améliorant l’utilisation des comptes intelligents inter-chaînes. Comme illustré ci-dessous :
Architecture d’abstraction de compte intelligent omnichain de Particle Network
L’abstraction de compte omnichain de Particle Network permet aux utilisateurs de disposer d'une même adresse de compte intelligent sur différentes chaînes EVM. Pour y parvenir, notre conception prévoit le déploiement d’un ensemble de contrats déployeurs (Deployer Contracts) sur chaque chaîne. L’utilisateur doit d’abord créer un nouveau compte sur la Particle Chain, ce qui déclenche l’exécution des contrats déployeurs sur toutes les autres chaînes, garantissant ainsi que l’adresse du compte intelligent généré reste identique à travers les chaînes. De plus, l’utilisateur peut interagir avec plusieurs chaînes via le contrat sur Particle Chain, sans avoir à gérer activement plusieurs adresses, et utiliser le jeton Particle comme moyen de paiement unique.
Grâce au paiement du gaz sur la chaîne source lors de l’exécution d’une transaction sur la chaîne cible, l’abstraction omnichain permet aussi les opérations utilisateur inter-chaînes. Par exemple, un utilisateur peut utiliser des USDC sur Polygon pour acheter un NFT sur Base.
L’abstraction omnichain AA exige une coordination étroite entre les contrats déployeurs et les composants de messagerie inter-chaînes pour synchroniser les comptes multi-chaînes et le stockage sur la chaîne source. Cela impose des exigences élevées aux oracles ou ponts de messagerie inter-chaînes utilisés — un problème courant dans les solutions d’interopérabilité complète. Toutefois, la synchronisation des comptes inter-chaînes peut être configurée de manière flexible avec différentes combinaisons de ponts, évitant ainsi la dépendance à un seul pont. Par exemple, une stratégie 2/3 peut être mise en œuvre : deux protocoles parmi LayerZero, Axelar et Connext doivent confirmer le changement de stockage sur la chaîne cible, éliminant ainsi le risque de point de défaillance unique.
Particle Network résout également un autre problème : assurer la compatibilité entre les chaînes EVM compatibles, qui ont souvent des implémentations AA différentes et ne peuvent donc pas uniformiser leurs adresses ERC-4337.
IV. Composants clés de l’abstraction de compte omnichain
Les composants clés de l’Omnichain AA incluent la Particle Chain, les contrats déployeurs, la messagerie inter-chaînes et le jeton.
Particle Chain
En séparant la gestion des autorisations du compte intelligent de sa logique (ce qui revient à dissocier le stockage et le code), nous avons besoin d’une blockchain sécurisée pour stocker les autorisations (Storage/KeyStore). Ainsi, la Particle Chain devient l’élément le plus critique. Elle stocke les données des comptes intelligents des utilisateurs (Storage), coordonne les contrats déployeurs sur différentes chaînes et gère les composants de messagerie inter-chaînes pour assurer la synchronisation du stockage et des mises à jour des comptes intelligents multi-chaînes.
Contrats déployeurs
Un compte intelligent multi-chaînes requiert une adresse unifiée, déterminée par les contrats déployeurs (via Create2). Ces contrats, combinés aux composants de messagerie inter-chaînes, assurent un stockage unifié à travers les chaînes. Pour le déploiement initial, le contrat déployeur rejette toute tentative venant d’une chaîne autre que la Particle Chain, garantissant ainsi que les données de stockage restent identiques dès le départ.
Messagerie inter-chaînes
La mise à jour du stockage du compte sur la Particle Chain nécessite le soutien d’un composant de messagerie inter-chaînes. À cet effet, nous utilisons directement des solutions telles que LayerZero. Que ce soit pour un déploiement initial ou une mise à jour ultérieure, l’utilisateur peut appeler la méthode xManage du compte intelligent sur la Particle Chain pour synchroniser l’état du compte sur n’importe quelle autre chaîne. L’utilisateur peut aussi appeler xExecuteTx depuis n’importe quelle chaîne source où le compte est déployé, lançant ainsi une opération utilisateur inter-chaînes et garantissant l’exécution correcte de la transaction sur la chaîne cible.
Jeton
Nous introduisons également le jeton Particle Network pour résoudre les problèmes de consommation de gaz lors des exécutions multi-chaînes, améliorant ainsi l’efficacité et l’expérience utilisateur. Dans le modèle ERC-4337, les Paymasters permettent d’utiliser n’importe quel jeton ERC-20 pour payer le gaz. Dans les transactions inter-chaînes, le jeton Particle provenant de n’importe quelle chaîne peut être utilisé directement pour payer les frais de gaz sur une autre chaîne.
Proposer un seul jeton de paiement pour les transactions inter-chaînes réduit considérablement la charge liée à la gestion de multiples jetons. Actuellement, toute interaction inter-chaînes exige au moins deux types de jetons pour couvrir les frais de gaz sur chaque chaîne. Dans les transactions quotidiennes, l’utilisateur doit détenir autant de types de jetons qu’il y a de chaînes avec lesquelles il interagit.
Pour l’utilisateur, l’abstraction de compte omnichain permet les scénarios suivants :
-
Alice lance une opération utilisateur sur la chaîne A, en consommant des jetons Particle sur cette chaîne.
-
En appelant xExecuteTx sur son compte intelligent de la chaîne A, elle déclenche une exécution inter-chaînes vers la chaîne B, réalisant ainsi l’opération souhaitée sur cette dernière.
V. Perspectives futures et Particle Network v2
Étant donné que l’abstraction de compte omnichain de Particle est encore en développement, sa conception peut être encore améliorée. Par exemple, nous étudions actuellement l’utilisation de protocoles inter-chaînes optimistes pour atténuer les retards de règlement et accélérer les opérations utilisateur omnichaines. Étant donné que la version v2 de Particle intégrera l’abstraction de compte omnichain, la modularité et l’adaptabilité à l’écosystème seront des éléments stratégiques clés de son lancement.
La version v2 de Particle Network adoptera également une approche centrée sur les intentions, visant à abstraire les difficultés inhérentes à la gestion des différents modules AA et des comptes intelligents. Dans cette architecture, l’écosystème ERC-4337 d’Ethereum — ou les infrastructures natives d’abstraction de compte d’autres chaînes comme zkSync — pourra être vu comme des instances spécifiques dans la catégorie Solver/Reactor.
La version v2 de Particle Network sera publiée dans le cadre du cadre d’écosystème WaaS (Wallet as a Service) basé sur la cryptographie à connaissances nulles (zk), dont les fonctionnalités renforceront la confidentialité des identités et des transactions des utilisateurs. Grâce à l’expérience de développement simplifiée et à la modularité du zkWaaS v2, les DApp intégrant Particle pourront bénéficier de flux de transaction cohérents et optimisés, réduisant ainsi les coûts de développement liés à la logique transactionnelle. Le modèle WaaS vise à offrir une expérience utilisateur fluide et un onboarding sans friction, permettant aux développeurs de se concentrer sur la logique centrale de leur application et sur l’innovation fonctionnelle.
Il convient de noter que certaines fonctionnalités de la version v2, au-delà de leurs objectifs initiaux, contribuent à réduire les coûts d’utilisation et de configuration pour les utilisateurs de l’abstraction omnichain. Trois facteurs peuvent aider à réduire ces coûts :
-
Agrégation confidentielle des activités utilisateur via Paymaster/groupement de transactions : l’abstraction omnichain de la v2 utilisera un Paymaster confidentiel pour préserver la vie privée des transactions, tout en regroupant les transactions pour réduire les frais pour les utilisateurs ;
-
Le développement centré sur les intentions favorisera une optimisation continue : la conception centrée sur les intentions de la v2 incitera le marché des Solveurs à constamment améliorer l’expérience d’expression des intentions par les utilisateurs, réduisant ainsi leurs coûts.
Le modèle d’abstraction omnichain fournit un cadre multi-chaînes crucial pour les DApp qui exigent une flexibilité de l’AA dans un écosystème diversifié. Parallèlement, la conception centrée sur les intentions transformera également la manière dont les utilisateurs interagissent avec les DApp.
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
@ParticleNtwrk
