L'infrastructure du portefeuille joue un rôle crucial dans le déverrouillage de l'expérience web3 pour la prochaine génération de dapps.

Jusqu'à présent, les utilisateurs ont dû installer un logiciel supplémentaire, le sourcer et le financer avec une nouvelle devise, et faire face à des écrans de confirmation inconnus avant même d'effectuer la première interaction en web3. Malgré l'amélioration du pare-feu et un éloignement des phrases de récupération, ces obstacles restent des points de désabonnement élevés pour les applications décentralisées.

L'environnement a été propice aux innovations qui abstractisent les couches techniques, permettant une intégration intuitive à de nouvelles expériences financières, sociales et ludiques sans compromettre l'éthique originale de l'auto-garde et de la décentralisation.

2023 a été une année cruciale pour l'écosystème du portefeuille, avec l'abstraction de compte et les développements à travers toutes les couches de la pile, modifiant les structures du marché et changeant notre perception de la relation entre les utilisateurs, les dapps et les portefeuilles.

Abstraction de compte : Quoi, Pourquoi et Comment

Nous pouvons considérer l'abstraction de compte comme le découplage de la gestion de compte de la gestion de clés. Un compte est une entité sur la blockchain qui peut détenir des actifs et avoir un historique de transactions. Les signataires (clés) sont des entités ayant l'autorité pour effectuer des actions au nom des comptes.

Avec les comptes traditionnels (EOAs), une clé privée conserve un contrôle unique et total sur son compte associé. La correspondance stricte de 1 à 1 entre la clé privée et le compte signifie que :

Les utilisateurs sont limités à utiliser des solutions de gestion de clés dédiées (par exemple Metamask, Ledger) lorsqu'ils interagissent avec la blockchain.

Il n'y a aucun moyen de recours en cas de perte d'une clé privée, et la clé qui contrôle un compte ne peut pas être remplacée.

Toutes les actions initiées par cette clé privée sont traitées de manière égale, de la création d'un NFT gratuit au déplacement de millions de dollars.

L'abstraction de compte fait du compte un contrat intelligent avec sa logique dynamique pour quel(s) clé(s) peut effectuer des actions en son nom, étendre les autorisations et effectuer des contrôles et des équilibres supplémentaires selon le cas d'utilisation.

Nous pouvons approfondir ses avantages en examinant ce qui est abstrait.

Parce que le protocole Ethereum ne reconnaît que les transactions provenant d'EOA, l'abstraction de compte nécessite une infrastructure hors chaîne pour relayer les transactions d'origine de contrat intelligent à la chaîne.

ERC-4337 a été introduit en 2021 comme une manière standardisée de le faire sans modifier le protocole de base. Cependant, certains projets avaient déjà mis en œuvre les avantages de AA bien avant que la norme ne soit complètement élaborée.

Portefeuille multisig sécurisé lancé en 2017 et a grandi pour sécuriser plus de 50 milliards de dollars d'actifs pour les DAO, les entreprises et les particuliers

Le portefeuille mobile d'Argent est alimenté par des comptes de contrats intelligents depuis 2018

Le portefeuille Sequence, lancé en 2021, a permis à Skyweaver de créer et de se connecter à leurs comptes intelligents en utilisant leur e-mail et de payer des frais en utilisant des jetons non natifs

Cela nécessitait la construction et la maintenance d'une infrastructure de relais personnalisée par le projet respectif.

Entrez ERC-4337. La norme offre une alternative décentralisée et résistante à la censure pour la couche de relais, définissant une interface pour les comptes, les payeurs et les agrégateurs de signatures pour interagir avec des relais tiers via un mempool alternatif partagé de transactions abstraites de compte ("Opérations d'utilisateur").

Les relayers (« bundlers ») regroupent plusieurs UserOps en une transaction à envoyer à un contrat EntryPoint singleton, qui vérifie ensuite que les frais seront payés (par le compte lui-même ou par l'intermédiaire de paymasters), et exécute les UserOps respectifs aux comptes intelligents.

Nous pouvons contraster cela avec la manière dont la validation et l'exécution se déroulent sur des chaînes qui offrent nativement une abstraction de compte et ne nécessitent donc pas de relais supplémentaires (par exemple zkSync* et Starknet), ainsi que la proposition RIP-7560 récemment publiée pour l'AA natif sur Ethereum et ses rollups.

En mars 2023, le contrat 4337 EntryPoint a été déployé sur mainnet. Sa communauté a connu un immense succès en incitant les développeurs à participer au mouvement d'abstraction de compte.

Cela a ouvert la voie à une vague de nouveaux fournisseurs d'infrastructures et de services pour l'écosystème des portefeuilles, et a poussé les projets existants à garantir que leurs stratégies commerciales et leurs ensembles de produits continuent de répondre aux besoins des développeurs d'applications cherchant à tirer parti de AA pour offrir à leurs utilisateurs une expérience web3 transparente.

Infrastructure du portefeuille et pile AA

Signataires & Gestion des clés

Les signataires et l'infrastructure de gestion des clés sont responsables de la génération et de la sécurisation des paires de clés publiques utilisées pour signer des messages, des transactions et des opérations utilisateur. L'exemple le plus simple ici sont les portefeuilles EOA traditionnels, mais des fournisseurs de portefeuilles en tant que service ont émergé pour permettre l'intégration sans graine et la gestion de portefeuille via des méthodes d'authentification alternatives telles que les réseaux sociaux et les e-mails.

Sous le capot, ces services stockent soit le matériel clé dans des HSM comme AWS KMS auxquels seul l'utilisateur peut accéder via ses informations d'authentification (Magic, Turnkey), soit fonctionnent selon un schéma SSS/MPC (Privy, Web3Auth, Portal, Capsule) pour protéger les matériaux.

Lit* améliore cette conception de stockage de clés côté serveur en décentralisant les clés. Chaque nœud du réseau stocke une partie d'une clé privée ECDSA générée via un algorithme DKG, toutes les opérations se déroulant dans une virtualisation chiffrée. Des règles d'authentification arbitraires peuvent être attribuées au couple de clés, donnant à l'application ou à l'utilisateur un contrôle complet sur les interactions autorisées, et imposer par exemple des limites de dépenses. Le réseau peut en outre être utilisé par des portefeuilles MPC 2-sur-N comme option de sauvegarde et de récupération.

Cette année, il y a eu une expérimentation rapide pour tirer parti des signataires matériels et des clés d'accès en tant que signataires d'un compte pour donner aux utilisateurs une gestion des clés prête à l'emploi avec des appareils mobiles ou de bureau modernes. Ces signataires fonctionnent nativement avec l'authentification biométrique (par exemple, FaceID, TouchID) pour offrir une sécurité supplémentaire avec une UX familière.

Les signataires matériels utilisent des sous-systèmes isolés tels que l'enclave sécurisée de l'iPhone et le module matériel de sécurité Titan d'Android pour générer des clés et signer des messages, garantissant une sécurité au niveau matériel. Étant donné que les clés ne peuvent pas être extraites de l'appareil, cela est le plus puissant en tandem avec des méthodes de récupération supplémentaires ou dans le cadre d'un système 2FA.

Les passkeys sont une norme pour l'authentification sans mot de passe construite sur WebAuthn. Ici, une paire de clés est générée dans le système d'exploitation de l'appareil et peut être synchronisée sur plusieurs appareils via des services comme iCloud, donc la récupération est possible si l'utilisateur a choisi de le faire.

Une limitation ici est que les passkeys et les signatures produites par le matériel Signer ne sont pas nativement reconnues par des chaînes comme Bitcoin et Ethereum. Ils utilisent la courbe elliptique secp256r1 (R1), tandis que ces chaînes fonctionnent sur la variation K1. Alors qu'il y a un travail en cours pour vérifier de manière fiable et efficace le R1, certains produits compatibles avec les passkeys passent par des services comme Lit et Turnkey pour produire une signature K1 une fois que l'utilisateur s'est authentifié avec sa clé.

Une norme à surveiller ici est l'EIP-7212, qui propose d'ajouter directement la courbe R1 à l'EVM en tant que contrat précompilé afin que chaque appareil moderne puisse signer nativement des transactions sans services tiers ou intermédiaires.

À mesure que le volume des transactions abstraites de compte augmente, l'agrégation de signatures à l'aide de signatures BLS pourrait permettre que les frais de compte intelligents soient moins chers que les EOAs sur les L2s. 4337 définit une interface pour les contrats d'assistant d'agrégateur qui valide une signature agrégée unique approuvant plusieurs UserOps au lieu de valider chacun séparément.

Relais

Les relayers (par exemple, 4337 Bundlers) relaient les transactions ou les UserOps vers un mempool. Sur les chaînes avec des AA natifs, les opérateurs réseau et les séquenceurs jouent ce rôle, éliminant le besoin de relayers dédiés externes.

De la même manière qu'il existe plusieurs implémentations client pour Ethereum (par exemple geth, erigon, reth), l'écosystème 4337 dispose de plusieurs implémentations de bundler dans différentes langues, rendant le réseau plus robuste face aux vulnérabilités d'une seule implémentation. Les spécifications 4337 incluent une suite de tests pour garantir la compatibilité du bundler sur l'ensemble du réseau. Les implémentations comprennent Stackup (Golang), Pimlico, Biconomy, Etherspot (Typescript), Candide (Python), OKX (Java) et Alchemy (Rust).

Le modèle d'incitation pour les regroupeurs est similaire à celui des constructeurs de blocs, prélevant des frais sur les opérations utilisateur qu'ils regroupent au lieu des transactions. En pratique, les regroupeurs ont besoin d'une API dans le constructeur de blocs pour voir le bloc actuel et créer un regroupement qui est valide par rapport à ce bloc et devrait donc être considéré comme faisant partie du constructeur de blocs.

Avec la croissance de 4337, nous pouvons nous attendre à ce que les constructeurs soient aussi des bundlers car cet hybride sera plus rentable qu'un simple constructeur car ils pourront sélectionner à la fois dans les pools de transaction et de UserOps.

Paymasters

Les paymasters permettent l'abstraction des frais en permettant aux dapps de parrainer le gaz pour les utilisateurs, en permettant aux utilisateurs de payer des frais avec des jetons non natifs, ou de régler hors chaîne via des rails de paiement traditionnels. Les services de paymaster ont 2 composants principaux :

Un gestionnaire de politique de gaz pour les développeurs afin de définir les conditions auxquelles ils parraineront le gaz. Cela peut être limité à l'ensemble du projet, ou sur une base par contrat ou par adresse de portefeuille. Les développeurs peuvent également définir comment ils souhaitent limiter le parrainage du gaz, par exemple par prix du gaz, nombre de demandes ou montant parrainé par mois. Les coûts de parrainage du gaz sont généralement inclus dans la facture mensuelle des développeurs du fournisseur de services avec une majoration d'environ 5% pour le montant parrainé.

Un contrat intelligent de payeur valide si une transaction donnée est éligible à être couverte, soit en fonction de l'état onchain comme les soldes de compte, soit en fonction des politiques de gestion du gaz hors chaîne. Le contrat de payeur détient un solde de jetons natifs qui est utilisé pour payer le gaz, et peut contenir une logique d'oracle de prix qui vérifie périodiquement le taux de change entre le jeton de paiement (par exemple, USDC) et le jeton natif (par exemple, ETH).

Les paymasters peuvent être classés en onchain ou offchain :

Les Paymasters Onchain (par exemple, ERC20Paymaster, StablecoinPaymaster) ne se fient qu'à l'état onchain pour vérifier si une transaction peut être couverte par le paymaster ou non. Cela signifie que certains paymasters, comme ceux qui acceptent le paiement de frais en ERC-20, peuvent être rendus sans autorisation, à condition que le paymaster soit approuvé par le compte pour transférer les jetons de paiement. Les administrateurs de contrat Paymaster peuvent retirer des jetons et les convertir en monnaie native pour recharger le contrat, fixer une majoration sur le prix de l'ERC20, définir un seuil pour la différence de prix pour laquelle le paymaster met à jour le prix de l'ERC20 pour le prochain UserOp, ou mettre à jour manuellement le prix.

Les Paymasters hors chaîne (par exemple VerifyingPaymaster) impliquent des interactions avec l'API du paymaster d'un fournisseur de services pour parrainer l'OpérationUtilisateur. Le service hors chaîne vérifie l'éligibilité et approuve la transaction en utilisant les clés du paymaster. Bien que cette solution soit autorisée, les paymasters hors chaîne offrent les avantages d'économies de gaz en minimisant les vérifications sur la chaîne. Les politiques de gaz peuvent être rendues plus granulaires et prendre en compte des activités hors chaîne telles que l'activité Discord.

Usines de comptes & Cadres

Les usines de comptes et les cadres fournissent des mises en œuvre de comptes intelligents « sans tête » et des SDK sur lesquels les dapps et les clients de portefeuille peuvent construire, créant des comptes intégrés auto-gérés au nom de leurs utilisateurs. Les comptes eux-mêmes sont des portefeuilles de contrats intelligents qui ont leur propre validation de signature, exécution et logique de protection de rejeu (gestion de nonce). Les propriétaires autorisent les opérations des utilisateurs provenant de leurs comptes intelligents en utilisant leur clé.

À un niveau élevé, les fournisseurs de comptes intelligents provisionnent 3 choses essentielles :

Une implémentation de base pour un portefeuille de contrat intelligent, avec sa propre logique pour la validation, l'exécution des transactions, et toutes les actions supplémentaires à effectuer avant et après l'exécution. Il contient également la logique pour ajouter des fonctionnalités supplémentaires au portefeuille via des modules natifs et tiers.

Un contrat d'usine qui déploie de nouvelles instances de la mise en œuvre du portefeuille, initiées avec le signataire initial pour ce compte. En vertu de l'ERC-4337, les dapps peuvent créer des comptes intelligents pour leurs utilisateurs en spécifiant l'adresse du contrat d'usine de leur fournisseur de choix.

Un SDK qui offre aux développeurs une personnalisation plug-and-play pour les comptes intelligents qu'ils créent. Cela peut inclure différentes options de signature, d'activation/désactivation et de technologies de relais.

Sous l'ERC-4337, le expéditeurLe champ d'un UserOp fait référence au compte intelligent sous lequel la transaction est effectuée. Si le compte n'a pas encore été déployé, EntryPoint déploie le compte à partir du contrat d'usine spécifié dans le initCode. Les clés de l'utilisateur peuvent être utilisées pour réclamer le compte intelligent afin de réaliser des interactions ultérieures avec les dapps.

Des fournisseurs de comptes comme Safe, Zerodev et Biconomy s'intègrent avec des gestionnaires de clés et une infrastructure d'authentification pour donner aux dapps la possibilité de choisir la manière dont ils veulent que les utilisateurs gèrent leurs comptes intelligents. Par exemple, l'intégration Web3Auth de Safe permet aux utilisateurs d'utiliser leurs comptes via les réseaux sociaux ou par e-mail, et l'intégration de Zerodev avec Turnkey offre la possibilité de gérer les comptes avec des Passkeys.

Safe est surtout connu pour son produit de portefeuille intelligent éprouvé au combat, largement utilisé par des individus, des équipes et des DAOs. À ce jour, plus de 5 millions de Safes ont été déployés sur plus de 12 chaînes, exécutant plus de 22 millions de transactions. Avant la version 1.4.1 (lancée en juillet 2023), les développeurs pouvaient déjà utiliser le relais Gelato pour permettre des transactions abstraites de gaz. Cette combinaison alimente actuellement des produits de carte de débit cryptographique comme Gnosis Pay et BasedApp, où les utilisateurs peuvent acheter auprès de n'importe quel vendeur acceptant Visa en utilisant des fonds dans leur Safe. La version 1.4.1 apporte le support ERC-4337 à travers des modules pour offrir une optionnalité supplémentaire dans les fournisseurs de relais.

ZeroDev est un fournisseur de compte intelligent lancé plus tôt cette année, conçu pour ERC-4337 dès le départ. Zerodev agrège plusieurs fournisseurs de bundler pour abstraire les services de relais UserOp, et expose un tableau de bord de gestion du gaz où les développeurs peuvent définir la portée et la logique de limitation du débit pour parrainer les frais pour les utilisateurs. Zerodev et Biconomy (qui gère également son propre réseau de bundler) dominent actuellement la part de marché des comptes 4337-enabled.

Le AccountKit d'Alchemy propose une implémentation de compte intelligent conforme à la norme 4337, appelée “LightAccount”, qui est basée sur l'implémentation de l'EF et ajoute le support EIP-1271 (validation des signatures provenant de contrats intelligents) ainsi que des transferts de propriété, une rotation de clés et un stockage de namespace.

Modules de compte

Les modules de compte sont des contrats intelligents qui agissent comme des composants installables pour un compte intelligent. Bien que l'infrastructure des modules en soit encore à ses débuts, nous envisageons que les modules seront découvrables et installables par :

Développeurs : les comptes intelligents intégrés peuvent être accompagnés de modules "préinstallés" tels que décidés par le développeur d'application décentralisée, construisant un portefeuille de démarrage avec des fonctionnalités personnalisées pour leur cas d'utilisation

Les utilisateurs finaux : les interfaces de portefeuille peuvent exposer un « magasin de modules » où les utilisateurs peuvent découvrir de nouvelles fonctionnalités et les ajouter à leur portefeuille

Avec AA séparant formellement la manière dont la validation et l'exécution de UserOp sont gérées, les modules peuvent contenir une logique de validation uniquement ou d'exécution uniquement.

Valideurs. Appelés pendant la phase de validation d'une UserOperation. Leur fonction principale est de vérifier la signature d'une UserOperation et de déterminer si elle est valide et doit être exécutée. Les exemples incluent la validation multisig, ECDSA, les passkeys, la validation multichaîne et les clés de session. Les clés de session permettent aux dapps de signer au nom de l'utilisateur pour simplifier l'UX, se comportant comme des clés privées temporaires avec des autorisations personnalisables et un délai d'expiration.

Les exécuteurs. Appelé pendant la phase d'exécution d'une UserOperation. Ils étendent la logique d'exécution du compte et permettent un ensemble plus diversifié d'actions qu'il peut effectuer nativement. Les exemples incluent des actions automatisées déclenchées en dehors du flux d'exécution régulier ERC-4337 telles que des échanges automatiques de jetons lorsque le prix atteint un certain seuil.

Hooks. Exécutez des contrôles pré- ou post-exécution et appliquez des contrôles contre le compte. Par exemple, un hook pourrait s'exécuter post-exécution et annuler toutes les transactions qui répondent à certains critères pour créer une sécurité accrue pour l'utilisateur.

Alors que certains portefeuilles comme Candide ont développé des modules que leurs utilisateurs peuvent installer directement, nous anticipons un écosystème riche de modules tiers découvrables dans une interface de type magasin d'applications de leurs portefeuilles, ou composés dans un portefeuille embarqué "starter" par les développeurs d'applications décentralisées.

Les cadres de compte intelligents sont déjà conçus en tenant compte des modules. Le contrat principal de Safe gère la logique de gestion des modules pour ajouter et supprimer des modules du compte, mais laisse la logique et le stockage réellement liés aux modules complètement délimités à un contrat séparé. Cette séparation des préoccupations atténue le risque que des modules tiers écrivent le même état, compromettant la sécurité et le comportement attendu du compte.

Le protocole Safe{Core} introduit un cadre ouvert avec des modules, des crochets, un gestionnaire et des registres visant à favoriser un écosystème de comptes intelligents composable inspiré des enseignements du produit de portefeuille de Safe.

ZeroDev classifie explicitement ses modules ("plugins") comme validation ou exécution. Les modules d'exécution sont conçus pour être associés à des modules de validation, permettant à des fonctions personnalisées d'être "routées" à travers différents validateurs. Par exemple, une fonction de "transfert NFT" qui autorise uniquement les NFT à être transférés via 2FA.

Quelques considérations dans la construction d'un écosystème robuste de comptes intelligents modulaires :

Interopérabilité. Avec plusieurs fournisseurs de comptes intelligents, chacun avec sa propre approche quant à la façon dont les tiers peuvent ajouter de nouvelles fonctionnalités aux comptes, les développeurs de modules se dirigent vers un verrouillage du fournisseur ou doivent gérer la surcharge technique du développement des mêmes fonctionnalités pour être conforme à plusieurs implémentations de comptes. Certaines solutions pour atténuer cela:

ERC-6900 pour les comptes de contrat intelligent modulaire et les plugins définit des interfaces pour les comptes de contrat intelligent modulaires (MSCAs), des modules (plugins) permettant à toutes les implémentations de compte conformes aux normes et aux plugins d'interagir les uns avec les autres.

Le ModuleKit de Rhinestone pour la construction et le test de modules de compte intelligents fournit des modèles et des cadres pour tester des modules contre différentes implémentations de compte, une bibliothèque d'intégrations (par exemple, protocoles DeFi), des conditions pré-construites pour l'exécution et une automatisation de la sécurité pour analyser le code du module et signaler les vulnérabilités de sécurité.

Sécurité. Donner aux utilisateurs la possibilité d'installer des logiciels tiers dans leurs portefeuilles soulève d'importantes questions sur la manière dont les interfaces devraient organiser et exposer des informations pertinentes sur les modules.

EIP-7484 fournit un moyen de vérifier la légitimité et la sécurité des modules de compte intelligent construits de manière indépendante. Ici, un registre permet aux auditeurs de faire des attestations sur la sécurité de ces modules. Les interfaces et les comptes intelligents peuvent interroger le registre pour récupérer les données d'attestation, vérifiant qu'un module est sûr à utiliser. Consultez le registre Rhinestone pour une mise en œuvre de référence de ceci.

Plus largement, l'EIP-7512 vise à créer une norme pour une représentation en chaîne de rapports d'audit analysables par des contrats intelligents pour extraire des informations pertinentes sur qui a effectué les audits et quels standards ont été vérifiés.

Découvrabilité. Les registres peuvent être exposés et interrogés par des plateformes de compte intelligentes et des interfaces de portefeuille à installer par des développeurs ou des utilisateurs finaux.

La capacité d'étendre les fonctionnalités du portefeuille transforme les comptes en plateformes de développement et en nouveaux canaux de distribution pour les produits et services Web3. Nous voyons déjà cela avec Metamask Snaps, qui permet aux utilisateurs de personnaliser leur portefeuille d'extension de navigateur avec des alertes de sécurité (via WalletGuard), des fonctionnalités de confidentialité (via Nocturne) et une interopérabilité avec des chaînes non EVM telles que Starknet et Bitcoin.

Lorsque Chrome a permis à un écosystème de développeurs d'étendre les fonctionnalités du navigateur grâce à des extensions, cela les a propulsés vers la domination du marché malgré leur décennie de jeunesse par rapport aux jardins clos existants. Bien qu'il soit difficile pour la plupart d'entre nous d'imaginer à quoi ressemblera l'expérience du portefeuille lorsque les comptes modulaires deviendront monnaie courante, les bases sont déjà posées pour que l'innovation sans permission suive son cours.

Modèles de développement émergents et leurs implications

Le stack de portefeuille évolué signifie que:

Les développeurs peuvent créer des comptes non dépositaires pour leurs utilisateurs dans le contexte de leurs applications, et chercheront des outils comme les SDK de connecteur pour leur donner des options sur la manière de construire le parcours d'intégration de bout en bout.

Les portefeuilles intégrés sont une nouvelle catégorie de portefeuilles, chaque vendeur ayant ses propres caractéristiques et compromis en termes de portabilité du compte, de personnalisation et d'hypothèses de confiance.

Si vous avez joué avec des dapps Ethereum en 2018, vous vous souviendrez peut-être avoir reçu une fenêtre contextuelle Metamask dès que vous avez chargé le site. Cela était dû à un manque de bonnes pratiques en matière d'UX concernant la connexion des portefeuilles et des dapps, et les développeurs ont souvent eu recours à des vérifications codées en dur pour vérifier si un utilisateur avait installé un portefeuille d'extension en utilisant le navigateur window.ethereumCela a entraîné un comportement imprévisible si les utilisateurs avaient plusieurs portefeuilles d'extension installés, les obligeant à en choisir un et créant un marché moins concurrentiel pour les portefeuilles.

Le protocole de communication WalletConnect* est apparu pour permettre aux utilisateurs de connecter n'importe quel portefeuille à n'importe quelle dapp, aux côtés de Web3Modal, une bibliothèque qui enveloppe des boutons et des composants modaux pour permettre aux utilisateurs de choisir le portefeuille avec lequel ils souhaitaient utiliser la dapp.

Aujourd'hui, Web3Modal est l'une des nombreuses bibliothèques de connecteurs de portefeuille comme RainbowKit, Web3Onboard et ConnectKit qui simplifient le processus de détection de portefeuille et d'authentification basée sur le portefeuille pour les développeurs d'applications. Ces bibliothèques offrent des options de thématisation prêtes à l'emploi, des fonctionnalités de recherche de portefeuille et des écrans qui redirigent les utilisateurs vers l'installation de portefeuilles s'ils n'en ont pas déjà un.

Plus récemment, l'EIP-6963 a été finalisé comme un mécanisme de découverte de portefeuille alternatif à window.ethereum, permettant aux dapps et scripts injectés fournis par des extensions de communiquer de manière prévisible. Grâce à la norme, les utilisateurs ont désormais plus d'options pour choisir un portefeuille d'extension de leur choix pour se connecter aux dapps, et ouvrent un marché plus concurrentiel pour les portefeuilles.

Alors que les bibliothèques de connecteurs ont considérablement amélioré DevEx et UX, l'attente que les utilisateurs possèdent déjà ou installeront un logiciel supplémentaire pour interagir avec les dapps pose toujours une barrière élevée à l'adoption.

Nous commençons déjà à voir un aperçu de ce à quoi ressemble l'avenir de l'UX d'intégration des dapp, avec la prochaine génération de bibliothèques de portefeuilles, que nous appellerons ici des "SDK d'intégration" pleinement développés. En plus de l'authentification basée sur le portefeuille, ces SDK offrent des options alternatives d'inscription et de connexion telles que l'e-mail, les réseaux sociaux, les SMS, et créent des portefeuilles intégrés pour les utilisateurs sans avoir besoin de leur faire installer un logiciel supplémentaire ou de les faire naviguer loin de la dapp.

Les développeurs peuvent intégrer directement des connecteurs proposés par des fournisseurs clés (par exemple Magic, Privy, Web3Auth) ou utiliser ceux qui enveloppent plusieurs services (par exemple Dynamic, Thirdweb, 0xPass) pour offrir une option plug-and-play sur les options d'authentification qu'ils souhaitent exposer et le type de portefeuille qu'ils souhaitent créer, personnalisant complètement le flux d'intégration. Les SDK d'intégration peuvent également se connecter à des fournisseurs de comptes intelligents pour créer des portefeuilles intelligents intégrés, offrant des améliorations supplémentaires de l'expérience utilisateur telles que des transactions sans gaz et des rampes d'accès.

Avec une adoption croissante des portefeuilles "sans tête" et un mouvement vers des portefeuilles intégrés, ce qui était autrefois une ligne de séparation claire entre les portefeuilles et les dapps commence à s'estomper.

Portefeuilles autonomes vs. Portefeuilles intégrés vs. Portefeuilles spécifiques à une application

Les utilisateurs de Web3 sont habitués à interagir avec des dapps via des portefeuilles autonomes comme Metamask ou ceux offerts par WalletConnect, accumulant leurs actifs et empreinte onchain sur un ou quelques comptes.

Alors que de plus en plus de dapps cherchent à attirer des utilisateurs grâce à des portefeuilles intégrés et à plusieurs fournisseurs disponibles, la gestion des comptes devient rapidement compliquée à la fois pour les développeurs de dapps et les utilisateurs finaux. Les développeurs de dapps devront évaluer et gérer plusieurs fournisseurs tout en essayant d'éviter de se retrouver coincés. Pour les utilisateurs finaux, la création d'un nouveau portefeuille par dapp entraînera une expérience de gestion des actifs et de l'identité fragmentée.

Bien que des portefeuilles spécifiques à une application soient souhaitables pour certains cas d'utilisation tels que les jeux, il existe de nombreuses situations où les utilisateurs pourraient s'embarquer dans leur première application décentralisée, créer un portefeuille intégré avec leurs signataires web2 ou Passkey, et vouloir utiliser les actifs qu'ils accumulent dans ce compte sur une autre application décentralisée en se connectant avec le même signataire.

Capsule est un fournisseur de portefeuille intégré basé sur MPC qui offre une portabilité du portefeuille sur les dapps utilisant leur service, donnant aux utilisateurs l'accès à un portefeuille existant en utilisant le même login par e-mail. Nous pouvons anticiper que cela deviendra bientôt une offre incontournable chez les fournisseurs de WaaS.

Moonchute aide les utilisateurs à gérer plusieurs comptes intelligents dans l'intérim. Leur gestionnaire de compte unifié est une application et une API permettant de découvrir les portefeuilles intelligents créés par un signataire donné, permettant aux utilisateurs de gérer les actifs de plusieurs comptes au même endroit.

ERC-7555 propose une interface normalisée inspirée du SSO et un modèle de demande/réponse pour que les applications découvrent les comptes d'utilisateur créés à l'aide de schémas de signature alternatifs. Ici, l'application redirigerait l'utilisateur vers l'URI d'un fournisseur donné (qui pourrait être un domaine auto-hébergé) et analyserait la réponse pour un signataire et une adresse de compte intelligent associée.

Migration depuis les EOAs

Un autre défi majeur d'AA est de trouver un moyen transparent pour les utilisateurs existants, qui possèdent déjà des actifs et un historique onchain accumulés sur plusieurs EOAs, de migrer vers des comptes intelligents.

EIP-7377 propose un mécanisme en protocole permettant aux EOAs d'envoyer une transaction unique qui déploie du code sur leur compte, transformant efficacement un EOA en portefeuille intelligent.

Aarc vise à résoudre la migration d'actifs pour les dapps et les utilisateurs finaux. Leur interface utilisateur et leur index SDK les actifs et les autorisations d'une adresse source particulière, et permet aux utilisateurs de sélectionner les actifs qu'ils souhaitent déplacer vers n'importe quelle adresse de destination, qui pourrait être un compte intelligent, un autre EOA ou un portefeuille MPC intégré créé avec une connexion sociale. Pour les dapps avec des utilisateurs existants qui sont habitués au flux de portefeuille autonome, Aarc offre une solution pour rationaliser le processus de migration alors qu'ils cherchent à ajouter des portefeuilles intégrés ou des fonctionnalités AA à leur produit.

Implications AA pour la gestion de compte multichaîne

Compte tenu de l'élan des activités AA et L2, nous pouvons anticiper un avenir où les comptes intelligents deviennent courants par rapport aux EOAs, les utilisateurs ayant des actifs sur plusieurs chaînes.

Un avantage UX des EOAs est que les utilisateurs ont automatiquement accès à la même adresse sur différentes chaînes EVM en utilisant la même clé privée. L'inconvénient est qu'il n'est pas possible de changer les clés qui contrôlent une adresse donnée, et tous les fonds peuvent être perdus si l'utilisateur perd sa clé privée.

Parce que l'abstraction de compte sépare le stockage des clés du stockage des actifs, il est possible de faire tourner les clés pour un compte donné sans avoir à migrer les fonds tout en conservant la même adresse. Les comptes intelligents sont capables de maintenir la même adresse à travers les chaînes en utilisant CREATE2, donnant aux utilisateurs accès au compte même si le contrat n'a pas encore été déployé sur une chaîne donnée en utilisant la même clé de vérification initiale et l'implémentation du compte.

Cependant, conserver la même adresse sur l'ensemble des chaînes peut être un anti-pattern à long terme.

CREATE2 n'est possible que sur des chaînes avec une équivalence de bytecode EVM. Dans un monde multichaîne avec des zk-Rollups (par exemple zkSync) avec de légères déviations par rapport à l'EVM, cette approche ne suffira pas.

On peut s'attendre à ce que les clés nécessaires pour accéder à divers comptes changent avec le temps, car les portefeuilles exposent des fonctionnalités supplémentaires de signature et de rotation de clés. Dans la configuration actuelle, cela peut rapidement entraîner une dérive de l'état des autorisations de compte sur les chaînes, car les changements apportés aux signataires sur un compte sur une chaîne ne propagent pas automatiquement les nouvelles autorisations à ceux sur d'autres chaînes.

Les solutions à plus long terme qui ont été proposées pour le multichaîne AA incluent :

Un contrat de stockage de clés dédié qu'un compte utilisateur à travers les chaînes lit lorsqu'il vérifie les autorisations. Voir une implémentation de cela à partir de Soul Wallet.

Utilisation des solveurs multichaînes ENS comme couche d'abstraction pour différentes adresses.

La gestion des comptes et des signataires inter-chaînes est encore un domaine de recherche active. L'objectif final est qu'un utilisateur puisse changer les clés qui ont accès à plusieurs comptes sur différentes chaînes sans effectuer un nombre extrêmement élevé de transactions.

Conclusion et réflexions finales

L'abstraction de compte est un mouvement visant à dissocier les signataires des comptes en rendant les comptes basés sur des contrats (au lieu des EOAs) comme des entités de premier plan sur la blockchain, offrant aux utilisateurs une flexibilité dans la gestion des clés et la permission des comptes.

ERC-4337 en tant que norme pour relayer les transactions initiées par compte intelligent a catalysé l'évolution de l'infrastructure du portefeuille pour accueillir AA, donnant naissance à de nouvelles structures de marché, catégories de portefeuille, développement de dapp et modèles d'intégration des utilisateurs.

La pile de portefeuille a été dégroupée en signataires, relayeurs, fournisseurs de compte et modules de compte donnant aux développeurs la possibilité de personnaliser l'expérience utilisateur finale. Cela s'accompagne du surcoût supplémentaire d'évaluer chaque fournisseur sur leurs compromis en termes de surcoût en gaz, de résistance à la censure, de verrouillage fournisseur et d'interopérabilité.

Les chemins de migration des EOAs et l'abstraction de compte dans un contexte multi-chaînes sont encore des domaines de recherche en cours. Nous prévoyons de voir les premières implémentations des solutions proposées dans l'année à venir.

Nous croyons que ces développements ont des implications significatives dans tout l'écosystème :

Pour les nouveaux utilisateurs, les portefeuilles ne sont plus le seul point d'entrée dans le web3. Les applications disposeront d'une intégration nettement améliorée grâce aux portefeuilles intégrés, aux transactions sans frais et aux rampes d'accès intégrées dans le portefeuille.

Pour les utilisateurs actuels, les expériences onchain deviendront plus fluides à mesure que les applications tirent parti de fonctionnalités telles que les clés de session. Les utilisateurs avancés ont un contrôle plus précis sur les autorisations de compte et des fonctionnalités de portefeuille supplémentaires grâce à des modules.

Pour les développeurs, une infrastructure de compte modulaire transforme les portefeuilles en systèmes d'exploitation. Les marchés de modules sont un nouveau canal de distribution sans autorisation pour les produits et services web3.

L'infrastructure du portefeuille continuera à catalyser l'adoption de web3. Nous, chez 1kx, sommes fiers d'avoir soutenu des équipes qui ont été des pionniers des idées discutées dans cet article, et continuerons à surveiller l'espace pour ce qui est à venir.

Si vous travaillez sur des solutions dans ce domaine ou si vous avez des réflexions supplémentaires sur le sujet, veuillez nous contacter@nichanank - aimerait discuter avec vous.

Un grand merci à David Sneider, John Rising, Konrad Kopp, Kurt Larsen, Marc Sednaoui, Dogan Alparslan, Vivian Phung, Derek Rein, Tom Terado, Diana Biggs, Mel Quarto et pet3rpan pour avoir examiné les brouillons de ceci.

*désigne les sociétés du portefeuille 1kx

Déclaration :

1. Ce texte est reproduit à partir de [ 1kx]，les droits d'auteur appartiennent à l'auteur original[1kx]，如对转载有异议，请联系Équipe Gate LearnL'équipe traitera rapidement selon les procédures pertinentes.
2. Clause de non-responsabilité : Les opinions exprimées dans cet article ne représentent que l'avis personnel de l'auteur et ne constituent pas un conseil en investissement.
3. Les autres versions linguistiques de l'article sont traduites par l'équipe Gate Learn, si non mentionnéGate.ioDans le cas où il est interdit de copier, diffuser ou plagier des articles traduits.