Les mois qui viennent promettent d’apporter des avancées significatives en termes d’expérience utilisateur des Blockchains et contribuer à la résolution d’un pain point majeur de l’écosystème.
Qui n’a eu une pensée émue - ou amusée - pour le gallois James Howells qui multiplie depuis 2013 les démarches pour obtenir l’autorisation de fouiller de fond en comble la décharge publique où il a malencontreusement jeté le disque dur contenant la clé de son compte Bitcoin, comprenant près de 150 millions de dollars au cours d’aujourd’hui.
Les anecdotes de perte de clés d’accès à son Wallet - et donc des fonds associés - sont légion.
Elles illustrent l’inévitable contrepartie à la notion de Self-Custody : si l’utilisateur est le seul à contrôler son compte via sa clé cryptographique, nul droit à l’erreur et nulle hotline à appeler en cas de perte de clé : « Not your keys, not your coins » comme le dit l’adage.
Si cette notion de Self-Custody est au cœur du propos des Blockchains, cette responsabilité qui incombe à l’utilisateur constitue à juste titre un frein majeur à l’adoption de la technologie auprès d’un plus large public.
Pour assurer la conservation de ses clés cryptographiques il est certes possible de recourir à des tiers de confiance, comme, par exemple, à des Exchanges centralisés. Mais cela restreint nettement la portée de l’expérience utilisateur en la limitant majoritairement à la détention et au transfert de crypto-actifs, sans possibilité d’interactions poussées avec des applications Web3.
Pour autant, des solutions existent, notamment sur Ethereum, via l’utilisation de Social Recovery Wallets, où :
• Comme dans un Wallet traditionnel, l’utilisateur détient une signing key qui lui permet d’agir sur ses fonds et d’interagir avec la Blockchain.
• Il peut en outre associer à son Wallet un ou plusieurs comptes « Guardians » (pouvant être par exemple des comptes contrôlés par l’utilisateur - compte de back-up, comptes mail, etc.-, des comptes contrôlés par des membres de son environnement familial ou amical ou des comptes contrôlés par des institutionnels).
• En cas de perte de sa signing key, l’utilisateur peut demander aux Guardians de changer l’adresse de la signing key perdue par celle d’une nouvelle clé, contrôlée par ses soins, cette opération ne pouvant se faire que si un quorum prédéfini de Guardians effectue conjointement l’opération.
Avec ce type de mécanismes l’utilisateur peut donc agir en cas de perte de sa clé, avec des modalités fines de paramétrage, couvrant tout un spectre de possibilités: de la Self-Custody intégrale (les comptes Guardians sont contrôlés par ses soins) à un système de Custody classique (un seul Guardian institutionnel).
De tels systèmes sont d’ores et déjà opérants, mais leur mise en œuvre doit se conformer aux modalités techniques d’implémentation des Comptes sur Ethereum, où il existe deux types de Comptes :
• Les Externally-Owned Accounts (EOA), comptes détenus par des utilisateurs physiques, comprenant une adresse et un solde en Ether, la possibilité d’agir sur ce compte étant assurée par une signing key. L’adresse du compte étant déterminée à partir de la signing key, ces deux éléments sont strictement liés, d’où l’impossibilité irrévocable d’agir sur son compte en cas de perte de cette signing key.
• Les Contracts Accounts : comprenant du code, sous la forme d’un Smart Contract, et donc la possibilité d’instancier de la logique applicative.
Si un EOA ne comprend pas de possibilités de programmation, il peut appeler via une transaction une fonction d’un Smart Contract. Auquel cas, pour que son instruction soit traitée par la Blockchain, il doit payer des frais en Ethers (dénommés gas), le montant de ces frais étant, entre autres, fonction de la complexité de l’opération à réaliser, et pouvant s’avérer non négligeable en cas de recours à des Smart Contracts élaborés.
L’implémentation de toute la logique applicative associée à un Social Recovery Wallet ne peut donc se faire dans ce paradigme technique que via un Smart Contract dédié, ce qui implique :
• Des coûts en gas potentiellement élevés en termes de déploiement et d’utilisation.
• La nécessité de payer du gas pour appeler les fonctions du contrat, ce qui requiert paradoxalement de détenir un autre compte crédité en Ethers… ; ce point pouvant être contourné par la mise en place d’infrastructures spécifiques (des « Relayers »), ce qui peut néanmoins être complexe et sous optimal car bien souvent centralisé.
Aussi, ces contraintes techniques pèsent fortement sur les possibilités d’adoption à large échelle des Social Recovery Wallets et ceci d’autant plus que beaucoup d’applicatifs Web3 n’ont été conçus que pour interagir avec des compte utilisateurs classiques et ne sont donc pas compatibles avec des Social Recovery Wallets.
Ces différentes contraintes pourraient être adressées au niveau du protocole en :
• Supprimant la dépendance entre adresse du compte et signing key, actuellement codée en dur.
• Introduisant de la logique applicative permettant d’instancier des règles de gestion pouvant autoriser, sous condition, d’autres clés à agir sur ce compte.
Ce qui pourrait en outre être mis en œuvre en abolissant la distinction entre Externally-Owned Accounts et Contracts Accounts, et en ne définissant qu’un seul type de compte, porteur de logique applicative.
C’est la notion d’Account Abstraction, dont l'implémentation est discutée depuis 2016 dans la communauté Ethereum via des propositions d’aménagement du protocole (EIPs).
Mais le déploiement en production de ces différents EIPs n’a pu se faire en raison de la nécessité d’intervenir en profondeur sur la couche technique du protocole Ethereum, qui plus est dans une période extrêmement chargée pour les développeurs notamment en raison des travaux sur le passage en Proof Of Stake.
Mais la donne a récemment changé.
Un nouvel EIP (4337) définit une implémentation plus réalisable de l’Account Abstraction car ne nécessitant pas une intervention sur la couche du protocole gérant le consensus.
De plus, certaines des solutions de Layer 2 d’Ethereum, tirant les enseignements de l’usage d’Ethereum sans être contraints par son héritage technique, implémentent en natif la notion d’Account Abstraction, en cohérence avec les spécifications de l’EIP 4337. C’est par exemple le cas des ZK Rollups ZKSync et Starknet. Et certains Wallets implémentent d’ores et déjà des fonctionnalités de Social Recovery à base d’Account Abstraction (Argent sur ZKSync) ou l’ont inscrit dans leur roadmap court terme (ArgentX et Braavos sur Starknet).
Nous assisterons donc vraisemblablement dans les mois à venir à des avancées significatives en termes d’expérience utilisateur en matière de conservation des clés, contribuant ainsi à résoudre un pain point majeur et récurrent de l’écosystème.
Et, au-delà de la mise en place de Social Recovery Wallets, fusionner logique applicative et compte utilisateurs va également permettre des avancées conséquentes en termes :
• de sécurité, avec notamment la possibilité d’intégrer au sein d’un Wallet de nouveaux schémas de signatures cryptographiques, y compris des signatures résistant au quantique ;
• de performance, avec la possibilité d’agréger transactions ou signatures ;
• d’onboarding utilisateur, avec la possibilité de créer et créditer un Wallet utilisateur alimenté via sa Carte bleue en prenant en charge ses frais de gas, ou plus généralement de permettre de payer ces frais avec tout type de Token ;
• d’expérience utilisateur, avec la possibilité pour des applications ou services de payer tout ou une partie des frais de gas liés à leur utilisation, ou de définir des seuils de dépense préapprouvés par l’utilisateur (utiles notamment dans l’univers du jeu, pour ne pas multiplier les confirmations par l’utilisateur de tous les micropaiements à chaque action du jeu).
----
Pour aller plus loin
EIP-4337: Account Abstraction using alt mempool
----
Photo by Silas Köhler on Unsplash
