Redéfinir l'architecture des comptes : pourquoi le système à trois clés est-il la solution idéale ?
TechFlow SélectionTechFlow Sélection
Redéfinir l'architecture des comptes : pourquoi le système à trois clés est-il la solution idéale ?
Il est inapproprié de demander à l'utilisateur d'installer un logiciel de portefeuille et de sauvegarder la phrase de récupération dès le début. Nous avons besoin d'une méthode conviviale, relativement sécurisée et dotée d'une certaine vision prospective.
Dédié à des analyses Web3 approfondiesRédaction : Norswap
Traduction : TechFlow
J'ai beaucoup réfléchi aux portefeuilles et à l'entrée des utilisateurs pour 0xFable. Voici quelques-unes de mes réflexions. Nous allons aborder :
-
Mon architecture de compte idéale ;
-
Les considérations de sécurité ;
-
Un aperçu des fournisseurs actuels de connexion Web3,
Il est évidemment indésirable d'exiger que les utilisateurs installent un logiciel de portefeuille et sauvegardent une phrase de récupération lors du processus d'entrée. Nous avons besoin d'une méthode conviviale, relativement sécurisée et un peu prospective.
Architecture
Chaque utilisateur obtient son propre compte intelligent, comprenant trois clés :
-
Clé d'appareil — initialement stockée localement, mais avec l'espoir futur d'utiliser des clés d'accès / webauthn.
-
Clé complémentaire, par exemple contrôlée par un fournisseur et déverrouillée via une connexion sociale.
-
Clé de sauvegarde, par exemple conservée par un tiers (peut simplement être en pièce jointe d’e-mail ou stockée sur Dropbox / Google Drive).
Si cela semble techniquement faible ou peu sûr, vous êtes probablement déjà trompé par les fournisseurs qui vantent leurs solutions, car celles-ci ne sont en réalité pas plus sûres (souvent même moins — par exemple, les clés (2) et (3) sont contrôlées par la même entité).
Dans cette configuration, vous pouvez utiliser la clé d'appareil pour effectuer des opérations sans interaction utilisateur. Pour les transferts et transactions impliquant des actifs, vous pouvez exiger l'utilisation de la clé complémentaire.
Le modèle simple consiste à permettre aux utilisateurs de se connecter via Google/Apple/Facebook, puis à ajouter une invite de confirmation. Cela rend l’entrée très facile. Toutefois, si un utilisateur souhaite davantage de sécurité, il peut remplacer cette clé par un EOA traditionnel. En outre, n'importe quelle paire de clés peut être utilisée pour régénérer la clé de sauvegarde, qui n'est qu'un fichier hébergé dans le cloud.
Analyse de sécurité
À quel point est-ce sécurisé ? Dans la plupart des cas, c’est suffisamment sécurisé. Deux appareils ou entités doivent être compromis simultanément pour entraîner une perte de fonds.
Cependant, certains risques de configuration peuvent réduire la sécurité. Par exemple, héberger la clé de sauvegarde sur Google Drive tout en attribuant la clé complémentaire à votre compte Google. Ou encore utiliser un portefeuille chaud comme clé complémentaire, ce qui présente le même risque que la clé d’appareil. L’utilisateur peut perdre sa sauvegarde. Il est préférable de rappeler régulièrement à l’utilisateur de renouveler sa clé d’appareil, ce qui le forcera à retrouver sa clé de sauvegarde.
Si la clé de sauvegarde est stockée publiquement, elle est également très vulnérable au vol. C’est pire qu’un portefeuille chaud, qui chiffre la clé sur le disque (et nécessite un mot de passe pour la déchiffrer en mémoire). Quoi qu’il en soit, l’ajout des clés d’accès (qui permettent de se connecter à une application via l’authentification de l’appareil) résoudra ce problème.
Il faut comprendre que la connexion sociale implique de faire confiance à un fournisseur. Ce dernier possède essentiellement une clé qu’il peut utiliser à sa guise, mais il vous promet de ne l’utiliser qu’après votre connexion via votre compte social, et uniquement selon vos instructions. Enfin, notez que lorsque la clé complémentaire est fournie par le créateur de la dApp, ou qu’il n’y a pas d’invite de confirmation, alors le créateur de la dApp peut facilement tromper l’utilisateur (car il contrôle le frontend possédant la clé d’appareil, et détient ou peut contrôler la clé complémentaire).
Aperçu des fournisseurs existants
Qui propose cela aujourd’hui ? À ma connaissance, personne. Le problème est généralement soit l’absence de clé de sauvegarde, soit le fait qu’elle soit détenue par la même entité (par exemple, le portefeuille Coinbase).
Le marché se divise principalement en deux catégories :
-
Les fournisseurs proposant des solutions multi-clés intégrées, utilisant soit des comptes intelligents, soit la MPC (calcul multipartite, une technique cryptographique) pour combiner plusieurs clés en un seul EOA.
-
Les fournisseurs de niveau inférieur, qui conservent la clé utilisateur pour leur compte et leur permettent de signer après connexion.
Il existe de nombreux fournisseurs full-stack : Particle Network, Privy, Alembic Tech, Magic, Web3Auth, Turnkey, Dynamic, 0xPass, Fireblocks, Portal, Capsule, ZeroDev, Keyp, Circle Developers.
Fournisseurs de stockage de clés tels que : Lit Protocol, Amazon.
Oui, il y en a beaucoup. Ils sont fondamentalement similaires. Lorsque leur modèle économique est transparent, ils facturent généralement entre 0,02 et 0,05 USD par utilisateur et par an. Ce tarif me semble raisonnable.
Ce qui est intéressant, c’est que tous sont positionnés comme des outils de développement. Aucune entreprise ne semble chercher à appliquer ces technologies pour devenir le portefeuille principal des utilisateurs.
Bien sûr, pour collaborer avec les dApps existantes, vous devez installer un logiciel de portefeuille. Ainsi, l'avantage du système se réduit à l'élimination de la phrase de récupération. Mais vous pouvez aussi inciter les dApps à promouvoir votre solution comme étant la plus facile à adopter (surtout si elles vous intègrent directement, sans nécessiter d'installation de portefeuille). Vous gagnez des utilisateurs, et la dApp bénéficie d’une entrée gratuite et simple. Une situation gagnant-gagnant.
Préoccupations concernant les fournisseurs
Outre le fait de ne pas implémenter mon architecture idéale, ces solutions introduisent souvent de forts facteurs de centralisation, comme des API REST ou certains calculs MPC, que vous ne pouvez pas effectuer vous-même si le fournisseur cesse ses activités (ces éléments sont-ils publiés ? audités ?).
Il n’est pas non plus clair ce qui se passe si vous arrêtez de collaborer avec un fournisseur. Ils détiennent (en partie) les clés de vos utilisateurs ! Cela ressemble beaucoup à mes inquiétudes concernant les Rollups-as-a-service.
Après cela, un fondateur de RaaS m’a dit qu’il existait un compromis entre permettre un départ facile et éviter que les fondateurs trichent leurs utilisateurs (ce qui nuirait au RaaS).
Voici comment basculer facilement de fournisseur en utilisant l’architecture ci-dessus : l'utilisateur soumet sur la chaîne le hachage de son compte social (par exemple [email protected]). Chaque fournisseur de connexion sociale possède sa propre clé privée (pas besoin d'une clé par utilisateur, et ce n'est généralement pas plus sûr). Le compte intelligent fait référence à un contrat singleton qui conserve le compte du fournisseur actuel. Changer de fournisseur revient simplement à modifier ce compte.
Réflexions finales
Nous progressons clairement vers un onboarding idéal. Idéalement, ces portefeuilles faciles d’accès établiraient une relation directe avec les utilisateurs. Les dApps pourraient alors ignorer complètement le problème, en concluant simplement des partenariats avec des portefeuilles pour déterminer lequel est utilisé par défaut.
Si cela échoue, ma solution serait de lancer mon propre système — créer son propre fournisseur de connexion sociale selon l’architecture décrite n’est pas difficile. Toutefois, je « préférerais » utiliser un fournisseur externe. Comme mentionné ci-dessus, si le créateur de la dApp contrôle la clé gratuite, le système n’est pas pleinement décentralisé.
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
@norswap
