Web3 账户概念梳理，钱包使用不迷路
TechFlow SélectionTechFlow Sélection
Web3 账户概念梳理，钱包使用不迷路
Quelles sont les significations des différents termes et concepts apparus lors du récent Devcon ?
Dédié à des analyses Web3 approfondies
Par : Zhi Xian, fondateur de UniPass
Lors du récent Devcon, l'abstraction des comptes (account abstraction) a été l'un des sujets les plus discutés. Récemment, on voit fréquemment apparaître dans divers exposés, panels et flux d'information des abréviations comme AA / EOA / SCW / 4337.
Ajoutez à cela que la narration commence à se tourner vers « Onboarding next billion users », de nouveaux adjectifs commencent à qualifier les produits, tels que seedless / gasless / social recovery / non-custodial.
Si vous commencez déjà à avoir mal à la tête après ces deux phrases, laissez-moi vous aider à clarifier ce que signifient tous ces termes.
Note avant lecture : Cet article n'est pas un document technique rigoureux. J'utiliserai probablement un langage peu précis mais facile à comprendre, parfois sous forme de métaphores. N'hésitez pas à approfondir ensuite les détails techniques à partir de cet article.
EOA - Comptes Contrôlés Externement
EOA signifie en chinois compte externe. L'adresse générée par MetaMask, que nous connaissons bien, est un exemple typique d'EOA. Son principe est simple, par exemple sa règle de génération est :
On voit que cette règle est très directe, entièrement basée sur des transformations mathématiques. L'adresse générée n'a aucune structure ni logique interne. La vérification par les nœuds qu'une transaction est bien autorisée par le propriétaire de l'adresse suit aussi une règle fixe :
Si la comparaison correspond, la signature est validée et le processus continue ; sinon, la transaction est rejetée sans être diffusée davantage.
Un autre aspect important de l'EOA est qu'il doit initier les transactions et payer les frais de gaz. À l’inverse, un CA (compte contrat) ne peut être appelé que par un autre CA ou un EOA. Autrement dit, l’EOA est le déclencheur des transactions : quelle que soit la complexité des appels contractuels ultérieurs, toute transaction doit initialement être lancée par un EOA disposant de suffisamment de gaz.
Précisons que l'EOA est un concept propre à Ethereum et aux chaînes compatibles EVM (ou de type EVM). Strictement parlant, les principales blockchains non-EVM, y compris Bitcoin, n'ont pas ce mécanisme.
CA - Comptes Contrats
CA signifie en chinois compte contrat (anciennement appelé compte interne). Les contrats courants comme les jetons ERC-20 ou les protocoles DeFi ont une adresse qui ressemble beaucoup à celle d’un EOA — c’est justement un CA.
Dans leur conception, les CA sont les citoyens natifs du monde Ethereum. Les EOA et ETH servent respectivement de déclencheurs et de carburant pour la logique métier des CA. En pratique, tous les actifs d’Ethereum autres que l’ETH sont gérés par des CA, et toutes les logiques métier comme le DeFi sont réalisées via des CA. Toutefois, la limitation du CA — ne pouvoir initier des opérations ni payer les frais de gaz — restreint ses capacités. Dès 2016, une proposition souhaitait permettre aux CA de payer eux-mêmes les frais de gaz.
En bref, un CA est un compte Ethereum doté d’une logique interne, pouvant contenir des règles métier (par exemple un contrat de jeton pour la comptabilité, ou un contrat de prêt pour les prêts et liquidations), ou des règles de gestion de compte (comme la logique multisignature de Gnosis Safe), ce dernier cas étant précisément ce qu’on appelle un « SCW – Portefeuille basé sur contrat intelligent ».
Les adresses CA sont générées par calcul, via les méthodes CREATE ou CREATE2, que nous n’aborderons pas ici. Retenez simplement qu’il n’existe pas de lien nécessaire entre un CA et une clé publique. Par exemple, un CA créé via Gnosis Safe peut être configuré pour accepter plusieurs clés publiques afin de débloquer ses actifs. Un CA peut même ne comporter aucune clé, et son accès peut être décidé par la logique d’un autre CA, comme dans un contrat de prêt DeFi où il suffit de rembourser pour récupérer ses actifs mis en garantie.
SCW/A - Portefeuille/Compte Basé sur Contrat Intelligent
Portefeuille basé sur contrat intelligent est probablement le terme le plus intuitif : il s’agit d’une solution de portefeuille utilisant un CA comme adresse, contrairement à la solution classique EOA qui utilise la transformation de la clé publique comme adresse.
Grâce à sa logique interne, un tel portefeuille peut réaliser de nombreuses fonctionnalités impossibles avec un EOA, comme le paiement de gaz par un tiers, les transactions groupées, la gestion des permissions, l’autorisation hors ligne, la récupération sociale, etc.
Voici quelques exemples illustrant le potentiel d’extension des portefeuilles intelligents :
-
Gnosis Safe utilise une architecture de contrat intelligent pour implémenter une logique multisignature ;
-
Un utilisateur peut envoyer différents jetons à plusieurs adresses dans une seule transaction blockchain, ou combiner les étapes approve et swap d’Uniswap en une seule transaction, limitant ainsi les autorisations au strict nécessaire et évitant les risques liés à une sur-autorisation.
-
Un utilisateur peut définir différents niveaux d'autorisation pour différents actifs. Par exemple, transférer un PFP pourrait nécessiter une clé admin stockée dans un portefeuille matériel, empêchant ainsi un pirate d'emporter les actifs de valeur même si la clé principale est compromise, trouvant ainsi un équilibre entre sécurité et commodité.
-
Un utilisateur peut signer une autorisation hors ligne du type « Celui qui me donne 100 ETH peut transférer mon BAYC ». Ainsi, sans autoriser un contrat tiers, l'utilisateur peut effectuer une transaction atomique P2P.
AA - Abstraction des Comptes
L'abstraction des comptes n’est pas un concept nouveau. Elle remonte aux discussions de 2015, où Vitalik estimait que l’algorithme cryptographique utilisé par Ethereum pour valider les transactions devrait être remplaçable, par exemple par ed25519, plus performant (voir ici). Pendant sept ans, Vitalik et la Fondation Ethereum n’ont cessé d’explorer différentes pistes. Ce lien compile utilement l’historique du sujet.
Comment comprendre l’abstraction des comptes ? Citons ici l’objectif décrit dans ERC-4337 :
Réaliser l'objectif principal de l'abstraction des comptes : permettre aux utilisateurs d'utiliser des portefeuilles intelligents contenant une logique de vérification arbitraire comme compte principal, au lieu des EOA. Éliminer complètement la nécessité pour les utilisateurs de posséder également un EOA (contrairement à l’état actuel où les portefeuilles SC et EIP-3074 le requièrent).
On voit donc qu’Ethereum souhaite changer la situation actuelle où la majorité des utilisateurs utilisent des EOA, en encourageant l’adoption des SCW et en supprimant totalement la dépendance de l’écosystème aux EOA. Outre EIP-3074, mentionné ici, il existe une proposition encore plus radicale et à long terme : EIP-5003. Voici quelques extraits (abrégés) :
Les EOA [...] sont limités de plusieurs façons critiques par le protocole. Ces comptes ne supportent pas la rotation des clés pour la sécurité, le regroupement pour économiser du gaz, ou les transactions sponsorisées pour réduire la nécessité de détenir soi-même de l’ether. Il existe d’innombrables autres avantages offerts par un compte contrat ou l’abstraction des comptes : choisir son propre algorithme d’authentification, définir des plafonds de dépenses, activer la récupération sociale, permettre la rotation des clés, déléguer des droits arbitrairement et transitivement, et presque tout ce que l’on peut imaginer.
[...] Ce EIP propose une voie non pas pour sanctifier les EOA, mais pour fournir une migration définitive vers d’autres solutions.
Il est clair que l’objectif d’EIP-5003 est de convertir une fois pour toutes les EOA en CA, permettant à tous les utilisateurs d’utiliser des SCW, résolvant ainsi complètement les problèmes de compatibilité ascendante. (Après les explications précédentes, ces acronymes semblent-ils plus clairs ?)
À ce stade, vous devriez avoir une bonne idée des origines et objectifs futurs de l’AA. Mais précisons que le concept d’AA n’est pas exclusif à Ethereum ou aux chaînes EVM : de nombreuses blockchains intègrent nativement des formes d’AA.
Par exemple, EOS / Polkadot / Near / Solana / Flow / Aptos… voire même BTC (single-sig / multi-sig / Taproot) — ces chaînes ont conçu leurs comptes avec une structure interne et parfois des capacités de gestion des permissions. Des chaînes comme StarkNet ou CKB offrent même des capacités d’abstraction encore plus avancées.
Vous aurez compris : l’AA d’Ethereum vise à corriger le problème historique posé par la popularité inattendue des EOA, rendant ainsi la couche compte plus avancée et flexible.
4337 - ERC 4337
D’après la discussion précédente sur l’AA, on voit que ERC-4337 n’est qu’une proposition parmi d’autres. Alors pourquoi est-ce lui qu’on mentionne systématiquement quand on parle d’AA ou de SCW ? Regardons le sous-titre de ce document :
Une proposition d’abstraction des comptes qui évite complètement les modifications du protocole au niveau consensus, s’appuyant plutôt sur des infrastructures de niveau supérieur.
Autrement dit, ERC-4337 marque le passage de l’AA d’une « révolution violente » à une « évolution pacifique » : au lieu de chercher à modifier la couche consensus, il opte pour une solution utilisateur basée sur les SCW. Pour améliorer l’interopérabilité, ERC-4337 définit certaines interfaces que les SCW doivent implémenter, ainsi qu’un cadre pour l’empaquetage des métatransactions, le paiement de gaz par tiers, etc.
Son apparition permet aux diverses solutions SCW, aujourd’hui très hétérogènes, de partager une interface utilisateur commune et d’utiliser des infrastructures ouvertes développées par l’écosystème, facilitant ainsi la mise en œuvre rapide de SCW adaptés à différents cas d’usage.
Par ailleurs, la promotion d’ERC-4337 pousse les autres acteurs de l’écosystème à améliorer leur compatibilité avec les SCW, par exemple en intégrant EIP-1271 pour la vérification des signatures, ou en levant certaines restrictions imposées par certains protocoles DeFi contre les interactions avec des CA.
Seedless
Ici, « seed » fait référence à la phrase-seed, c’est-à-dire les mots de passe que l’on nous demande souvent de sauvegarder lors de la création d’un portefeuille. « Seedless » signifie donc « sans phrase-seed », ou encore « sans clé privée visible ». Attention, ce « sans » ne signifie pas qu’il n’y a réellement aucune clé, mais que l’utilisateur n’a pas besoin de sauvegarder la phrase-seed / clé privée ni même d’en prendre conscience.
Une question fréquente : si l’utilisateur ne sauvegarde pas sa phrase-seed, perd-il le contrôle de son compte ? Et s’il change d’appareil, ne risque-t-il pas de ne plus y accéder ?
Exact. Supprimer simplement la sauvegarde de la phrase-seed reviendrait à une mauvaise conception produit. Le but du « seedless » est que l’utilisateur n’ait pas besoin de connaître l’existence de la phrase-seed, tout en conservant pleinement le contrôle de son compte.
En d'autres termes, l'utilisateur (et uniquement lui) doit pouvoir restaurer seul son compte sur un nouvel appareil, sans dépendre d'une méthode UX médiocre et trop geek comme la phrase-seed. La récupération sociale, dont nous allons parler, en est un excellent exemple.
Gasless
Ici, « gas » désigne les frais de transaction. « Gasless » signifie donc « sans frais de gaz ». Encore une fois, cela ne veut pas dire que les frais n’existent pas, mais que l’utilisateur n’a pas besoin de comprendre le concept de gaz, ni d’acheter préalablement des jetons natifs pour les payer.
Alors qui paie les frais ? Deux cas se présentent :
-
Quand le compte de l’utilisateur contient déjà des actifs cryptos : jetons gagnés en jouant, airdrops reçus ou transferts reçus. Tant que ces jetons ont de la valeur et de la liquidité, des relayers peuvent accepter de les utiliser pour payer les frais à sa place, en tirant profit de la différence.
-
Quand le compte est vide, par exemple juste après création. Si l’utilisateur doit interagir avec la blockchain, l’application peut choisir de subventionner temporairement ses frais pour faciliter son démarrage, réduisant ainsi l’abandon. Même en tenant compte du coût de cette subvention, le coût total d’acquisition d’utilisateurs peut finalement être moindre. Ou encore, l’utilisateur peut regarder une publicité pour obtenir des frais gratuits.
Ces deux stratégies sont particulièrement efficaces sur les L2 où les coûts de gaz sont faibles.
Récupération Sociale
La récupération sociale désigne un mécanisme utilisant des relations sociales pour aider un utilisateur à retrouver l’accès à son compte en cas de perte de clé. Si vous avez déjà utilisé WeChat pour vous connecter à un nouvel appareil, vous avez peut-être vu une instruction du type « Faites envoyer xxx par deux amis à votre compte pour vous connecter » — c’est exactement l’effet que vise la récupération sociale, sauf que le vérificateur passe de WeChat à un contrat intelligent.
Une erreur courante consiste à qualifier de « récupération sociale » une solution utilisant des comptes sociaux pour créer ou se connecter à un portefeuille. Cela revient à confondre « relation sociale » et « compte sur plateforme sociale ». Le portefeuille intelligent Argent intègre une fonction de récupération sociale : il demande à vos « gardiens » de fournir une adresse Ethereum, qui pourront signer pour vous lors d’une connexion sur un nouvel appareil. Mais cette approche suppose que vos gardiens soient plus compétents que vous dans la gestion d’adresses Ethereum. Sinon, si leur propre compte est inaccessible au moment où vous avez besoin d’eux, votre compte sera également bloqué. Une solution plus viable serait d’utiliser des preuves cryptographiques comme celles des emails (signature DKIM) ou des passeports électroniques, des outils courants dans la vie quotidienne, pour renforcer la praticité de la récupération sociale.
Non-custodial
Non-custodial est sans doute l’un des concepts les plus politiquement corrects — et les plus abusés — de l’industrie crypto, car chaque acteur a souvent sa propre définition. Voici notre vision, basée sur deux critères principaux :
-
Le développeur du portefeuille ne peut pas manipuler arbitrairement le compte de l’utilisateur
-
Le développeur du portefeuille ne peut pas empêcher l’utilisateur d’opérer sur son propre compte
Si vous partagez ces deux principes, vous pouvez utiliser ces critères pour juger si un portefeuille est custodial, semi-custodial ou non-custodial :
Mais à quoi bon connaître ce niveau de custody ? L’utilisateur s’en moque peut-être, tant que c’est pratique ! C’est vrai, je partage en partie ce point de vue, surtout à ce stade du développement industriel, où les mentalités n’ont pas encore changé. Je pense que chacun de ces modèles convient à des scénarios différents :
-
Solutions custodiales : adaptées aux bourses, services financiers institutionnels, environnements fortement réglementés, par exemple certains services de Coinbase ou Fireblocks. Caractérisées par un petit nombre d’utilisateurs, pas besoin d’interactions fréquentes, mais une valeur moyenne par client élevée, ce qui permet aux prestataires d’investir massivement dans des systèmes de haute sécurité.
-
Solutions semi-custodiales : destinées à des utilisateurs individuels plus avertis. Ils comprennent que le service peut filtrer leurs transactions et savent préparer à l’avance un plan de secours (ex : exporter leur clé privée), afin de protéger leurs actifs en cas de refus de service. Ainsi, ils bénéficient de confort au quotidien, tout en pouvant sauver leurs actifs en cas d’urgence. Cette solution exige aussi une grande fiabilité du prestataire : volume élevé d’utilisateurs, nombreuses interactions quotidiennes, et exigence forte de disponibilité des données — car la perte des données côté serveur pourrait rendre irrécupérable le compte de tous les utilisateurs non sauvegardés.
-
Solutions non-custodiales : idéales pour les scénarios de large adoption. Cela peut sembler contre-intuitif, mais du point de vue coût, la solution non-custodiale est la seule capable d’assurer sécurité et accessibilité dans des contextes à faible valeur moyenne par utilisateur. Si une application grand public choisit l’une des deux premières options, elle doit s’assurer que le prestataire peut offrir un service suffisamment fiable. Sinon, en cas de malversation interne, piratage ou force majeure entraînant l’arrêt du service, tous ses utilisateurs seront touchés, et son activité pourrait s’effondrer. L’histoire l’a maintes fois montré : la sécurité n’est jamais une affaire secondaire. Prendre soin des utilisateurs, c’est aussi se protéger soi-même.
MPC - Calcul Multi-Parties
Le calcul multipartite sécurisé peut être considéré, avec la preuve à divulgation nulle (ZKP), comme l’une des deux « magies » actuelles de la Web3. Dès qu’on y touche, des choses auparavant impossibles deviennent soudain faisables. Dans certains cas, c’est vrai : le ZKP utilise la probabilité pour atteindre la faisabilité, tandis que le MPC distribue le contrôle pour améliorer la gestion des risques ou assurer la continuité d’activité.
Le MPC est en réalité un paradigme englobant de nombreuses solutions techniques. Dans le contexte actuel de la Web3, il fait généralement référence au TSS.
TSS - Schéma de Signature Seuil
Le schéma de signature seuil est un protocole de signature distribué entre plusieurs parties, incluant des algorithmes de génération distribuée de clés, de signature, et de redistribution (re-sharing) des fragments de clé privée sans changer la clé publique.
Un TSS m-n signifie qu’une clé publique correspond à n fragments de clé privée, dont m fragments combinés permettent de produire une signature vérifiable par la clé publique. On remarque que cette logique ressemble à la multisignature (multi-sig), mais la différence principale réside dans le nombre de clés publiques.
Par exemple, une multisignature 2-2 est comme une porte avec deux serrures : les deux clés doivent être utilisées simultanément pour ouvrir. Un TSS 2-2 est comme une porte avec une seule serrure, mais dont la clé est composée de deux morceaux qui doivent être assemblés pour fonctionner. Pour simplifier, cette analogie n’est pas parfaitement rigoureuse : assembler deux morceaux de clé correspond davantage au secret partagé de Shamir. Dans le TSS, les fragments de clé ne se rencontrent jamais physiquement ; chacun signe séparément, puis un algorithme spécifique permet de valider la signature globale avec la clé publique.
Le TSS implique-t-il nécessairement un modèle custodial ou non-custodial ? Pas du tout. Cela dépend entièrement de la conception finale de la solution. Une solution non-custodiale exige que l’utilisateur puisse agir indépendamment, donc il doit détenir au moins m fragments. Par exemple, dans un schéma 2-3, l’utilisateur doit détenir 2 fragments. Un schéma 2-2 ne peut pas être non-custodial, au mieux semi-custodial (comme ZenGo). Mais si l’utilisateur détient la majorité des fragments, cela augmente la complexité pour lui, rendant difficile une adoption massive.
En conclusion
Nous avons couvert ici les principaux termes liés aux comptes Web3. Après comptage, cela fait environ 5 000 caractères. Malgré mes efforts, des erreurs ou omissions sont possibles. N’hésitez pas à me signaler tout problème ou désaccord via Twitter (@frank_lay2). Je partagerai toute mise à jour ou correction sur Twitter dès que possible.
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
