TL; DR

La clé privée est le cœur qui nous permet de signer des transactions sur Ethereum, mais la gérer a été un cauchemar, même sous forme lisible de "phrases de récupération". Pourtant, notre objectif n'a jamais été de transformer la blockchain en un jeu sophistiqué.

Authentifier les utilisateurs autorisés est crucial pour des transactions sécurisées. Avec l'évolution de la sécurité sur internet et de l'expérience utilisateur, nous sommes passés de l'authentification par mot de passe aux biométriques comme la reconnaissance faciale et les empreintes digitales. WebAuthn est un développement clé dans cette progression. Cet article discute de près de trois termes :

WebAuthn: Une norme d'authentification Web utilise des identifiants basés sur des clés publiques, souvent créés par des authentificateurs externes. Elle élimine le besoin de mots de passe et permet une authentification sécurisée de l'utilisateur.

Enclave sécurisée : Une zone sécurisée basée sur le matériel à l'intérieur des appareils informatiques, l'enclave sécurisée est conçue pour protéger les données sensibles. Des versions d'une enclave sécurisée se trouvent dans les appareils iOS, Android et Windows. Elle peut servir d'authentificateur sécurisé en mettant en œuvre WebAuthn, mais la clé privée, liée à l'ES, présente souvent des défis inter-appareils.

Clé d’accès : une implémentation de WebAuthn au niveau du système d’exploitation, personnalisée par divers fournisseurs d’appareils et de systèmes. Par exemple, la clé d’accès d’Apple utilise la clé stockée dans le trousseau iCloud pour la synchronisation entre les appareils. Cependant, cette approche est généralement verrouillée sur des plates-formes ou des systèmes spécifiques.

Comme décrit ci-dessus, les implémentations webAuthn s'alignent sur notre objectif pour les utilisateurs quotidiens de la blockchain, pour atteindre un niveau élevé de sécurité contre le phishing et une expérience conviviale. Voici l'idée de les fusionner dans la blockchain :

Couche clé : Les utilisateurs s'authentifient en utilisant des méthodes biométriques transparentes comme la reconnaissance faciale ou l'empreinte digitale. Sous le capot, c'est le processeur de sécurité basé sur le matériel comme Secure Enclave ou les services cloud comme iCloud et Google Cloud qui gèrent la gestion des clés. Je vais aborder plus tard les problèmes inter-appareils et inter-plateformes.

Couche de compte : Un compte de contrat intelligent (SCA) offre la possibilité d'attribuer des signataires arbitraires (par exemple, SE et Passkey) et des mécanismes de seuil. De plus, sa conception modulaire améliore la flexibilité et la capacité de mise à niveau. Par exemple, un SCA peut adapter dynamiquement ses exigences de signature en fonction de facteurs tels que le montant de la transaction, le temps ou l'adresse IP. D'autre part, un compte traditionnel détenu par un utilisateur externe (EOA) peut être augmenté avec des services de MPC, leur combinaison offre une meilleure interopérabilité et rentabilité par rapport au SCA, bien qu'il manque de fonctionnalités avancées que les SCA fournissent, notamment pour la rotation des clés.

La couche de signature : Ethereum prend en charge nativement la courbe k1, mais la vérification de signature de WebAuthn entraîne des coûts plus élevés, car elle utilise la courbe r1 pour la génération de clés. Par conséquent, certaines solutions de couche 2 comme zkSync, prévoient des précompilations de la courbe native EIP-7212 r1. De plus, il existe des services tiers, des vérificateurs de Solidity, des vérificateurs de preuves à divulgation nulle (ZK) et des systèmes de gestion de clés distribués, pour faciliter la signature de la courbe r1 de manière plus rentable.

Avertissement :

L'avancée technologique ne garantit pas le succès sur le marché; Tous les appareils et plates-formes n'ont pas adopté Passkey; L'utilisation de SCA peut être plus coûteuse que EOA; La solution proposée évolue avec le progrès technologique.

L'expérience utilisateur de la crypto est nulle ? La gestion des clés est nulle !

Dans le domaine de la blockchain, le véritable contrôle des actifs de la blockchain n'est pas entre les mains de l'utilisateur ou du fournisseur de portefeuille, mais réside plutôt dans la clé privée. Cette clé est la plus fondamentale pour l'ensemble du processus d'exécution d'une transaction sur Ethereum. Pour mieux comprendre cela, prenons l'EOA comme exemple :

Génération de clé : Un nombre aléatoire sélectionné à partir de la courbe elliptique secp256k1 sert de clé privée. Cette clé est ensuite multipliée par un point prédéfini sur la courbe pour générer la clé publique. L'adresse Ethereum est dérivée des 20 derniers octets de la clé publique hachée. La 'phrase de passe' est généralement introduite pour une sauvegarde lisible par l'homme, permettant la dérivation déterministe des clés privées et publiques.

Signature des transactions : Une transaction, contenant des détails tels que le nonce (un numéro séquentiel), le montant, le prix du gaz et l'adresse du destinataire, est signée à l'aide de la clé privée. Ce processus, impliquant l'ECDSA, un algorithme de signature numérique qui utilise la cryptographie à courbe elliptique et adopte secp256k1 comme courbe, génère une signature composée de valeurs (r, s, v). La signature et la transaction originale sont ensuite diffusées sur le réseau.

Vérification des transactions : Une fois qu’une transaction atteint les nœuds Ethereum, elle subit un processus de validation dans le mempool du nœud. Pour vérifier le signataire, les nœuds utilisent la signature et la transaction hachée pour dériver la clé publique de l’expéditeur et confirmer l’authenticité de la transaction en faisant correspondre l’adresse dérivée avec celle de l’expéditeur.

Comme décrit ci-dessus, la clé privée est une entité essentielle on-chain. À l'origine, les comptes Ethereum, connus sous le nom de comptes détenus par des entités externes (EOAs), reposaient uniquement sur une seule clé privée, ce qui posait des risques importants, car perdre la clé signifiait perdre l'accès au compte.

Beaucoup peuvent penser que l'abstraction de compte (AA) est la solution à tout ce qui concerne la mauvaise expérience utilisateur, ce que je dirais pas exactement. AA consiste à modifier les règles de validité pour les rendre programmables, et la programmabilité des comptes de contrats intelligents (SCA) le rend possible. AA est puissant, permet l'envoi de plusieurs transactions en parallèle (nonce abstrait), le parrainage de gaz et le paiement de gaz en ERC20 (gaz abstrait), et plus pertinent pour le sujet de cet article, pour rompre la validation de signature fixe (signature ECDSA abstraite). Au lieu de EOA, les SCA peuvent attribuer des signataires arbitraires et des mécanismes de signature comme la multi-signature (multisigs) ou les clés délimitées (clés de session). Cependant, malgré la flexibilité et l'avancement de la mise à niveau de l'AA, la dépendance fondamentale aux clés pour la signature des transactions reste inchangée.

Même lorsqu'elle est convertie en une phrase de récupération de 12 mots, la gestion d'une clé privée reste difficile, exposant à des risques de perte ou d'attaques de phishing. Les utilisateurs doivent naviguer entre des couches complexes de solutions décentralisées ou l'accueil chaleureux d'un service centralisé, aucun des deux n'étant idéal.

Pourquoi l'expérience Crypto est-elle nulle? Une grande partie en est due au fait que la gestion des clés est mauvaise. Cela nécessite toujours des compromis entre l'expérience, la sécurité et la décentralisation. Cet article explore des solutions optimales potentielles pour la gestion de la clé.

Couches de gestion des clés

Il n'y aura jamais de solution universelle, la meilleure façon de préserver la clé est adaptée aux scénarios d'utilisateurs spécifiques, influencée par des facteurs tels que le type d'utilisateur (institutionnel ou individuel), le montant de capital, la fréquence des transactions et les types d'interaction.

Pour clarifier les choses, j'évite d'utiliser les méthodes populaires de 'self, semi et fully custody' pour cataloguer. À mon avis, la vraie auto-garde signifie signer une transaction de manière indépendante, sans avoir recours à une autre partie, même si la solution n'est pas de nature custodiale au sens traditionnel (comme étant stockée dans les TEE des nœuds décentralisés). Classer les solutions simplement comme 'bonnes' ou 'mauvaises' en fonction du type de garde est trop simpliste et ne tient pas compte de leur adaptation variable. Pour une évaluation plus nuancée des méthodes de gestion des clés, je suggère de les analyser à travers trois couches distinctes:

Responsabilité

S'il faut partager la responsabilité de la gestion d'une clé entre différentes parties.

Étant donné que les individus sont souvent confrontés à des défis dans la gestion de la clé, la distribution de la responsabilité de sauvegarde de la clé apparaît comme une stratégie naturelle d'atténuation des risques. Cette catégorie comprend des méthodes telles que l'utilisation de plusieurs clés pour signer de manière collaborative, comme on le voit dans les systèmes de signature multiple (multi-sig), et la division de la clé privée en parts à travers un schéma de partage de secret (SSS) ou une computation multipartite (MPC).

Multi-sig: Exiger plusieurs clés privées complètes pour générer des signatures de transaction. Cette méthode nécessite une communication on-chain sur les différents signataires, entraînant des frais de transaction plus élevés et ayant un impact sur la confidentialité car le nombre de signataires est visible on-chain.

SSS: une clé privée est générée en un seul endroit, et un distributeur distribue des morceaux de cette clé à différentes parties. Toutes les parties doivent reconstruire la clé privée complète pour signer une transaction. Cependant, cette reconstruction temporaire peut introduire une vulnérabilité.

MPC-TSS(Schéma de signature seuillée): en tant qu'implémentation de MPC, une approche cryptographique permettant à plusieurs parties d'effectuer des calculs tout en gardant conjointement leurs entrées privées. Chaque partie crée indépendamment une part de clé secrète, et les transactions sont signées sans que ces parties aient jamais besoin de se rencontrer physiquement. Il introduit des frais plus bas car il est hors chaîne, et aucun risque de point de défaillance unique comme SSS.

Stockage

Stockez la clé ou les parts, affectées par la sécurité, l'accessibilité, le coût et les facteurs de décentralisation.

Services cloud centralisés tels qu’AWS, iCloud et d’autres serveurs. Ils sont pratiques pour les transactions fréquentes, mais plus vulnérables à la censure.

Stockage décentralisé comme IPFS et Filecoin.

Ordinateur/mobile local : Les clés sont stockées localement dans le stockage sécurisé du navigateur.

Portefeuilles papier: Impression physique des clés privées ou des codes QR.

Environnement d'exécution sécurisé (TEE) : TEE fournit une zone sécurisée au sein du processeur principal pour exécuter ou stocker des données sensibles, isolées du système d'exploitation principal.

Enclave sécurisée : L'enclave sécurisée sur les appareils modernes est isolée du processeur principal pour fournir une couche supplémentaire de sécurité et est conçue pour garder les données sensibles de l'utilisateur en sécurité même lorsque le noyau du processeur d'application est compromis.

Portefeuilles matériels: Appareils physiques comme Ledger et Trezor, spécialement conçus pour stocker en toute sécurité des clés privées.

Module de sécurité matérielle (HSM) : Les HSM sont des dispositifs matériels spécialisés conçus pour la gestion sécurisée des clés et les opérations cryptographiques. Ils sont généralement utilisés dans les environnements d'entreprise et offrent des fonctionnalités de sécurité de haute qualité.

Accès

Comment vérifier l'identité de l'utilisateur pour accéder à la clé stockée

L'authentification est impliquée dans l'accès à la clé stockée. Il s'agit de valider que l'individu tentant d'accès est effectivement autorisé à le faire. En revenant en arrière dans l'histoire, nous pouvons catégoriser l'histoire de cette manière :

Quelque chose que vous connaissez : mots de passe, NIP, réponses aux questions de sécurité ou motifs spécifiques.

Quelque chose que vous avez : Incluez des cartes intelligentes, des jetons matériels (mots de passe à usage unique basés sur le temps) ou des facteurs numériques comme les vérifications de compte social et les codes SMS envoyés à un téléphone.

Quelqu’un que vous êtes :Impliquez les caractéristiques physiques uniques de l’utilisateur, telles que les empreintes digitales, la reconnaissance faciale (comme Face ID d’Apple ou Windows Hello), la reconnaissance vocale ou les scans de l’iris/de la rétine.

Sur ces bases, l’authentification à 2 facteurs et l’authentification multifacteur sont des méthodes qui combinent deux facteurs ou plus, comme la notification push combinée par SMS, pour ajouter plus de couches de sécurité aux comptes d’utilisateurs.

Analyse des joueurs existants

MetaMask permet aux utilisateurs d'utiliser un mot de passe pour accéder à la clé stockée dans le stockage local du navigateur de l'utilisateur.

Trust Wallet permet aux utilisateurs d'utiliser un mot de passe ou FaceID pour accéder à la clé stockée dans le stockage du navigateur local de l'utilisateur, l'utilisateur peut également choisir un service cloud pour sauvegarder la clé privée.

Privy permet aux utilisateurs d'utiliser plusieurs méthodes de connexion sociale comme l'e-mail, en utilisant SSS pour diviser en trois parts :

Partage d’appareils : Navigateur-iFrame, enclave sécurisée mobile.

Partage d’authentification : Stocké par privy, lien vers privy id).

Partage de récupération : Mot de passe utilisateur ou crypté par Privy stocké dans le module de sécurité matérielle (HSM).

Particle permet aux utilisateurs d'utiliser la connexion sociale, en utilisant MPC-TSS qui a deux parts:

Partage de périphérique : navigateur-iFrame

Partage de clé de serveur: serveur de Particle

Nouvelle solution

Couche clé: WebAuthn, Secure Enclave et Passkey

Les solutions existantes ci-dessus ont été cruciales pour initier les utilisateurs à web3. Cependant, elles sont souvent accompagnées de défis : les mots de passe peuvent être oubliés ou ciblés dans des attaques de phishing, et même l'authentification à deux facteurs, bien que plus sécurisée, peut être fastidieuse avec ses multiples étapes. De plus, tout le monde n'est pas à l'aise de confier la gestion des clés à un tiers, les utilisateurs dépendent toujours de la disponibilité et de la vivacité de leur système alors que certains services garantissent qu'ils ne peuvent pas accéder à la clé.

Cela nous amène à nous demander s'il existe une solution plus efficace - une solution qui offre la solution la plus proche d'une expérience utilisateur sans confiance, hautement sécurisée et fluide. Cette recherche nous conduit aux méthodes web2 optimales. Plusieurs termes sont étroitement liés au sujet, comme je l'ai décrit au début de l'article, WebAuthn est le standard d'authentification lui-même, tandis que Secure Enclave et Passkey sont des implémentations ou des composants liés à ce standard.

WebAuthn

La norme WebAuthn standardise l'interface d'authentification des utilisateurs aux applications Web. Elle permet aux utilisateurs de se connecter à des comptes Internet en utilisant des authentificateurs externes au lieu d'un mot de passe. Les authentificateurs peuvent être des Authentificateurs Itinérants (Yubikey, Clé Titan) ou un Authentificateur de Plateforme (Clé intégrée sur les appareils Apple), et ainsi de suite.

L'Alliance FIDO (Fast IDentity Online) a initialement développé les technologies derrière WebAuthn. Il a été officiellement déclaré norme Web par le W3C en mars 2019 et, avec sa normalisation, les principaux navigateurs tels que Google Chrome, Mozilla Firefox, Microsoft Edge et Apple Safari ont adopté WebAuthn, augmentant considérablement sa portée et sa convivialité. Il est maintenant pris en charge par de nombreux appareils avancés.

Avantages de webAuthn :

Sécurité renforcée: Élimine la dépendance aux mots de passe, réduisant la vulnérabilité aux attaques de hameçonnage, de force brute et de rejeu.

Expérience utilisateur améliorée: Offre un processus de connexion plus simple et plus rapide, souvent avec un simple toucher ou une vérification biométrique.

Protection de la vie privée : Aucun secret partagé n'est transmis lors de l'authentification, et les sites Web individuels ne reçoivent aucune information personnellement identifiable.

Scalabilité et normalisation : En tant que norme Web, WebAuthn garantit la cohérence et l'interopérabilité entre différents navigateurs et plates-formes.

WebAuthn lié à l'appareil, par exemple, Secure Enclave

Dans les cas modernes, nous pouvons utiliser le processeur matériel comme authentificateur, comme Secure Enclave pour les appareils Apple, Trustzone pour Android, et Strongbox pour Google Pixel.

Génération de clé : En utilisant la cryptographie à clé publique, une paire de clés est générée conformément aux normes WebAuthn, généralement en utilisant la courbe P-256 r1. La clé publique est envoyée au service, tandis que la clé privée NE QUITTE JAMAIS l'Enclave Sécurisée. L'utilisateur ne manipule jamais la clé en texte brut, ce qui rend difficile la compromission de la clé privée.

Stockage des clés : la clé privée est stockée de manière sécurisée dans l'Enclave sécurisée du périphérique, un sous-système fortifié séparé du processeur principal. Il protège les données sensibles, garantissant que même si le système principal est compromis, le matériau de clé brut reste inaccessible. La barre pour compromettre l'Enclave sécurisée est extrêmement élevée, c'est pourquoi les types de données les plus sensibles tels que Apple Pay et les données FaceID y sont stockés. Voici une explication approfondie du fonctionnement de l'ES.

Authentification: Les utilisateurs utilisent leur reconnaissance faciale ou leur empreinte digitale pour accéder, la Secure Enclave utilise la clé privée pour signer un défi du service, et le service vérifie en utilisant la clé publique.

Avantages de webAuthn basé sur l'appareil :

Sécurité au niveau matériel : Utilisation de l'Enclave Sécurisée, un gestionnaire de clés basé sur le matériel isolé pour fournir une couche supplémentaire de sécurité.

Résistance au phishing: Ne saisissez aucune information sur des appareils ou des sites potentiellement compromis.

Expérience pratique: ils offrent une expérience plus conviviale. Les utilisateurs n'ont plus besoin de se souvenir de mots de passe complexes pour différents sites.

Inconvénients de webAuthn basé sur l'appareil :

Contraintes du périphérique : La clé privée ne peut pas être exportée ou récupérée si le périphérique est perdu ou endommagé, l'opération entre périphériques est impossible.

WebAuthn basé sur le cloud, Passkey

Pour relever le défi de la fonctionnalité multi-appareils, les géants de la technologie ont introduit une implémentation webAuthn basée sur le cloud, Passkey est largement connu en raison d'Apple.

Prenons la Passkey d'Apple comme exemple :

Génération de clés : L'appareil macOS, iOS ou iPadOS de l'utilisateur, en tant qu'authentificateur, génère une paire de clés publique-privée lorsque l'utilisateur crée le compte. Ensuite, envoie la clé publique au serveur, et la clé privée est stockée dans le trousseau de clés iCloud de l'appareil. Les données du trousseau iCloud sont chiffrées avec une paire de clés liée au matériel, et stockées dans un module de sécurité matérielle (HSM). La clé est inaccessible à Apple.

Synchronisation sur tous les appareils : Ce processus sera le même que l'accès à iCloud. Authentifiez-vous sur le compte iCloud, recevez un code SMS et saisissez le code d'accès de l'un des appareils.

Avantages de webAuthn basés sur le cloud :

Multi-appareils : les clés d’accès ont été conçues pour être pratiques et accessibles à partir de tous les appareils utilisés régulièrement. Mais actuellement limité aux appareils Apple, pour Android, c’est plus difficile en raison de ses diverses versions et variations matérielles.

Résistance au phishing : Identique à ce qui précède.

Expérience pratique: Identique à ci-dessus.

Cloud-based Passkey inconvénients :

S'appuyer sur le service cloud : Comparé à WebAuthn basé sur un appareil, le passkey basé sur le cloud déplace le niveau de sécurité du matériel de l'Enclave sécurisée vers le trousseau iCloud, certains peuvent argumenter qu'il est dépositaire de votre service cloud. Certains aspects clés à considérer incluent : Le compte AppleID de l'utilisateur utilisé avec iCloud est compromis ; Alors que le trousseau iCloud utilise le chiffrement de bout en bout pour protéger les données, des erreurs opérationnelles ou des vulnérabilités posent un risque.

Restreindre à la plateforme : Par exemple, l'utilisation d'une clé de passe basée sur iCloud sur un appareil Android est extrêmement difficile. De plus, contrairement aux méthodes traditionnelles, Apple et Google n'envoient pas d'assertions spécifiques à l'appareil. Cela signifie qu'il est actuellement impossible de vérifier le type d'appareil qui a généré une clé, ce qui soulève des questions sur la fiabilité de la clé et de ses métadonnées associées.

Couche de compte: SCA et EOA

Jusqu'à présent, nous pouvons constater que maintenir la sécurité au niveau du matériel tout en abordant la compatibilité inter-appareils et inter-plateformes est un défi. Tout aussi crucial est l'option de récupération sociale, telle que l'ajout de plusieurs gardiens pour une sécurité renforcée. Dans ce contexte, la blockchain peut nous montrer un chemin.

Un écart notable lorsque nous essayons d'implémenter le web2 webAuthn sur le web3: Web2 exige seulement de prouver la propriété, tandis que le web3 nécessite également d'autoriser la transaction simultanément. Avec Passkey, les développeurs manquent de contrôle sur le message de signature, qui est généralement générique, comme 'se connecter.' Cela peut entraîner une manipulation potentielle du frontend, les utilisateurs signant des messages à l'aveugle - une préoccupation apparemment mineure mais cruciale.

Les comptes de contrats intelligents (SCA), qui sont eux-mêmes des contrats intelligents, fonctionnent en tant qu'entités sur chaîne, capables d'attribuer des signataires arbitraires. Cette flexibilité permet de programmer divers appareils et plates-formes - tels que la configuration d'un téléphone Android, d'un Macbook et d'un iPhone - en tant que signataires. De plus, le compte de contrat intelligent modulaire permet l'évolutivité, le remplacement de nouveaux signataires, le changement du seuil de signature de 2 sur 3 à des configurations encore plus complexes.

Imaginez un portefeuille qui adapte ses exigences de sécurité en fonction du contexte : il permet une authentification à un seul signataire lorsque l'utilisateur se trouve sur une adresse IP locale familière, mais exige plusieurs signataires pour les transactions à partir d'adresses IP inconnues ou au-dessus d'une certaine valeur. Avec la modularité et la programmabilité, notre imagination est la seule limite à de telles innovations. De nombreux fournisseurs de services SCA construisent activement cet espace, notamment Safe, Zerodev, Biconomy, Etherspots, Rhinestone, etc. Mention spéciale également à des infrastructures comme Stackup, Plimico, Alchemy qui rendent cela possible.

Veuillez vérifier que mes recherches précédentes fournissent un contexte plus complet autour de l'ACS.

Les EOAs peuvent réaliser une récupération sociale et une compatibilité inter-appareils/interplates-formes grâce aux services MPC. Malgré le fait que les EOAs aient des signataires fixes, les fournisseurs de MPC peuvent diviser les clés en parts pour une sécurité et une flexibilité accrues. Cette méthode ne dispose pas des fonctionnalités programmables et évolutives de la SCA, telles que la récupération par verrouillage temporel et la désactivation facile de la clé. Cependant, elle offre toujours des capacités inter-chaînes supérieures en étant agnostique vis-à-vis de la chaîne et est actuellement plus rentable que les SCA. Les principaux fournisseurs de MPC comprennent Privy, Particle Network, web3Auth, portefeuille OKX, portefeuille Binance, etc.

Couche de signature: support R1

Reculons un peu pour comprendre le contexte : Sur Ethereum, les clés privées sont des nombres aléatoires sélectionnés à partir de la courbe k1, et le processus de signature utilise également cette courbe.

Cependant, les paires de clés générées selon les normes WebAuthn utilisent la courbe r1. Par conséquent, la vérification d'une signature r1 sur Ethereum est environ trois fois plus coûteuse qu'une signature k1. Voici quelques approches pour résoudre ce problème :

Crédit à Dogan, pour des connaissances plus approfondies, veuillez consulter sa recherche.

Solution de protocole :

Solution : EIP7212, Precompiled pour le support de la courbe secp256r1 proposé par l'équipe Clave.

Évaluation : Cette proposition crée un contrat précompilé qui effectue des vérifications de signature dans la courbe elliptique "secp256r1" en fonction des paramètres donnés du hachage du message, des composants r et s de la signature, et des coordonnées x, y de la clé publique. Ainsi, toute chaîne EVM - principalement les rollups Ethereum - pourra intégrer ce contrat précompilé facilement. Jusqu'à présent, le précompilé de protocole est peut-être la solution la plus efficace en termes de gaz.

Mise en œuvre : zkSync

Service de tiers

Solution: Clefs en main

Évaluation : un TEE Turquie garantit que la clé privée est accessible uniquement à l'utilisateur via leur PassKey et jamais accessible pour le Turnkey lui-même, cependant cela nécessite toujours la vivacité du service.

Mise en œuvre : Goldfinch

Solutions de vérification de la Solidité :

Solution: Vérificateur Solidity de FCL, Vérificateur Solidity de FCL avec précalcul, Vérificateur P256 de Daimo

Mise en œuvre : Clave, Portefeuille Évident

Vérificateur de Zéro-Connaissance (ZK) :

Solution : Risc0 Bonsai, halo2-ecc d'Axiom

Évaluation: Cette approche utilise des preuves de connaissance nulle pour vérifier les calculs en dehors de la machine virtuelle Ethereum (EVM), réduisant les coûts de calcul sur chaîne.

Mise en œuvre : Portefeuille Bonfire (Risc0), Laboratoires Know Nothing (Axiom)

Chacune de ces solutions offre une méthode différente pour permettre une vérification de signature r1 moins chère et plus réalisable dans l'écosystème d'Ethereum, et voici une évaluation par Dogan.

Étude de cas de mise en œuvre

*Veuillez noter qu'à partir de décembre 2023, la plupart de ces solutions en sont à leurs débuts et peuvent changer ou s'améliorer à tout moment. Ces exemples sont uniquement à des fins d'apprentissage ; veuillez toujours vous référer à leurs sites web officiels pour des informations précises.

Portefeuille Clave : (Secure Enclave webAuthn) + (SCA)

Basics:

Manif: https://getclave.io/

Compte: SCA

Chaîne : ZkSync

Processus de transaction :

Création de clé : L'utilisateur fournit une authentification biométrique comme une empreinte digitale ou une reconnaissance faciale, une paire de clés est générée à l'intérieur de la Secure Enclave, qui ne révèle jamais ou ne quitte l'extérieur.

Signature de clé : L'application prend un message de transaction requis et transmet une demande de signature à Secure Enclave, l'utilisateur fournit une bio-authentification pour approuver la signature, et Secure Enclave signe le message avec la clé, et doit être diffusé aux nœuds de la blockchain.

Fonctions supplémentaires : Le compte de contrat intelligent permet de nombreuses fonctions puissantes. Tout d'abord, le parrainage de gaz. Grâce au payeur, d'autres parties comme dApp ou annonceurs peuvent payer les frais de gaz de l'utilisateur, rendant le processus de transaction plus fluide, et ils peuvent également permettre aux utilisateurs de payer le gaz en ERC20 au lieu d'Ether ou de jeton natif. Et en utilisant la clé de session, l'utilisateur peut effectuer une transaction sans signature pendant un certain temps.

Mécanisme de récupération :

Le processus de récupération est effectué par le contrat intelligent de Clave sur zkSync, l'utilisateur peut annuler la récupération pendant un verrouillage de 48 heures, pour prévenir les activités non autorisées et malveillantes.

Sauvegarde cloud : Un EOA sera créé lorsque l'utilisateur choisit la sauvegarde cloud, la clé privée de l'EOA est stockée soit dans iCloud soit dans Google Drive, l'utilisateur peut utiliser cette clé privée stockée dans le cloud pour accéder à son compte à partir d'un autre appareil, et les utilisateurs peuvent supprimer ou écraser cette section de sauvegarde à tout moment.

Récupération sociale : l'utilisateur peut attribuer l'adresse de clé de sa famille ou de son ami comme sauvegarde, si M des N gardiens donnent une confirmation pour la récupération, la récupération sera exécutée après un verrouillage de 48 heures s'il n'est pas annulé.

Portefeuille Soul: (Passkey) + (4337 SCA)

Fondamentaux :

Démo: https://alpha.soulwallet.io/wallet

Compte : ERC4337 SCA

Chaîne : Ethereum, Optimism, Arbitrum, et bientôt tous les calques EVM de niveau 2

Processus de transaction :

Création de clé : Les utilisateurs fournissent une authentification biométrique telle que l'empreinte digitale ou la reconnaissance faciale, et le système d'exploitation génère une clé d'accès et la sauvegarde en utilisant un service cloud. Vous pouvez ajouter plus d'une clé d'accès inter-appareils et inter-plateformes.

Ajouter des gardiens (facultatif) : L'utilisateur peut assigner une adresse EVM EOA différente en tant que gardien et définir un seuil pour la récupération du compte.

Génération de compte : En utilisant le déploiement contrefactuel, les utilisateurs n'ont pas besoin de payer de frais jusqu'à la première transaction

Mécanisme de récupération :

Passkey: Utilisez n'importe quelle passkey définie pour vous connecter au portefeuille à l'aide d'un appareil arbitraire.

Récupération des gardiens : Les gardiens assignés peuvent faire tourner le portefeuille selon le seuil, et un verrou temporel pourra être envisagé ultérieurement pour prévenir tout comportement malveillant.

Portefeuille OKX : (MPC-TSS + Passkey) + (4337 SCA)

Principes :

Démo : https://www.okx.com/help/what-is-an-aa-smart-contract-wallet

Chaîne: 30+ chaînes

Clé: MPC-TSS, 2/3

Compte : 4337 SCA

Processus de transaction :

Création de clés : En créant un portefeuille, l'OKX transforme une clé privée unique en trois parts distinctes. La part 1 est stockée sur le serveur OKX, la part 2 est stockée sur le stockage local de l'appareil de l'utilisateur, et la part 3 est générée par l'appareil, cryptée et peut être sauvegardée sur les services cloud préférés de l'appareil, tels que Google Cloud, iCloud et Huawei Cloud.

Signature de clé : OKX utilise la technologie MPC-TSS, l'utilisateur peut obtenir la signature complète en utilisant deux des trois parts de clé privée lors de la signature de la transaction, les parts de clé ne se rencontrent jamais pendant ce processus.

Mécanisme de récupération :

Mécanisme 2/3 : Lorsque l'utilisateur se déconnecte, que l'appareil n'est pas disponible ou qu'une des clés de l'appareil est compromise, vous pouvez utiliser un nouvel appareil pour vous connecter au portefeuille OKX (obtenir la part du serveur) et obtenir la part du service cloud, combinez ces 2 parts pour récupérer le portefeuille, le portefeuille OKX générera de nouvelles parts secrètes.

Web3Auth : (MPC-TSS + Clé d’accès)+ (EOA/SCA)

Basics:

Démo: https://w3a.link/passkeysDemo

Chaîne : Tous les EVM et Solana

Clé : MPC-TSS, généralement 2/3

Compte : Tout compte comme EOA, 4337 SCA ou SCA général

Processus de transaction:

Création de clé : En créant un portefeuille, trois parts de clé sont générées. Share1 est une part de connexion sociale, l'utilisateur peut saisir son e-mail, et un réseau décentralisé de nœuds stocke la clé de chaque utilisateur ; Share2 est une part de l'appareil stockée sur le stockage local de l'appareil de l'utilisateur ; Share3 est générée par l'ordinateur local et sauvegardée par les services cloud préférés de l'utilisateur.

Signature de clé : L'architecture Web3Auth MPC-TSS garantit que la clé de l'utilisateur est toujours disponible, même en utilisant la signature seuil, les clés ne sont jamais reconstruites ou stockées à un seul endroit.

Mécanisme de récupération:

Récupération du seuil Lorsque l'utilisateur est déconnecté, que le périphérique n'est pas disponible ou qu'une des clés du périphérique est compromise, vous pouvez utiliser la méthode de connexion sociale pour vous connecter au compte webAuthn et obtenir le partage cloud de la clé d'accès, combinez ces 2 partages pour récupérer le portefeuille.

Protocole Lit (MPC-TSS + nœuds décentralisés + Passkey) + (EOA/SCA)

Informations de base :

Démo: https://lit-pkp-auth-demo.vercel.app/

Chaîne : La plupart de l'EVM, Cosmos, Solana.

Compte : MPC-TSS, 20 sur 30 de réseau, peut être adopté à la fois par SCA et EOA.

Processus de transaction :

Création de clés : Lorsque l'utilisateur souhaite créer un portefeuille, il doit d'abord sélectionner une méthode d'authentification (passkey, connexion sociale oAuth prise en charge), une requête est ensuite envoyée au relayer pour créer des paires de clés et stocker la logique d'authentification dans le contrat intelligent. Chaque paire de clés est générée collectivement par les nœuds Lit à travers un processus appelé génération de clés distribuée (DKG). Fonctionnant comme un réseau décentralisé, 30 nœuds Lit fonctionnant à l'intérieur de TEE, chaque nœud détient une partie de la clé mais la clé privée n'existe jamais dans son intégralité.

Signature de clé : En recevant la demande, les nœuds Lit valident ou rejettent de manière indépendante la demande par rapport à la méthode d'authentification assignée, et en utilisant la technologie MPC-TSS, 1. Les parts de clé sont collectées au-dessus du seuil (20 sur 30) pour générer une signature et combinées par le client pour répondre à la demande.

Mécanisme de récupération :

Mécanisme 2/3 : Utilisez les méthodes d'authentification stockées dans le contrat intelligent pour accéder au compte, les nœuds Lit valident les demandes et cela se poursuivra si plus de 2/3 des nœuds confirment.

Conclusion :

Alimenté par l'enthousiasme pour les solutions de couche 2, couche 3 et la disponibilité des données, nous sommes désireux d'améliorer les performances de la blockchain. De plus, en recherchant une réelle sécurité, en combinant la confidentialité de la preuve de connaissance nulle avec la nature de la transparence. Tous les efforts visent un seul objectif : être prêts pour de vrais utilisateurs qui interagissent fréquemment avec la blockchain et adoptent la crypto dans leur vie.

Il est facile de tomber dans un rêve de technologie optimale, mais nous devons nous demander : quel genre d'expérience visons-nous ? Nous imaginons un monde où la crypto est basée sur l'intuition plutôt que sur des termes techniques intimidants, où un utilisateur se lance dans le terrier du lapin sans hésitation ni tracas.

Imaginez un utilisateur Rui : Elle découvre une fantastique dApp, s'inscrit facilement en utilisant la reconnaissance faciale ou une empreinte digitale, avec la possibilité de mettre en place des sauvegardes ou des gardiens. En interagissant avec la dApp, elle exécute les transactions en douceur, éventuellement avec de petits frais ERC20 ou même aucun. Plus tard, elle personnalise les paramètres de son portefeuille - peut-être en activant un verrouillage temporel pour les transactions automatisées, en ajoutant un autre appareil comme signataire de sauvegarde ou en révisant sa liste de gardiens.

Nos constructeurs font que cela se produise. En intégrant WebAuthn et Passkey, nous améliorons la gestion des clés privées, la rendant à la fois sécurisée et conviviale. En plus de la clé, SCA en tant qu'entité ouvre un univers de sécurité et de fonctionnalités personnalisées. Et en ce qui concerne les frais de gaz? Ils deviennent moins contraignants, grâce aux fournisseurs de Paymaster qui peuvent créer un 'coffre' pour les échanges ou même permettre aux annonceurs de couvrir les frais pour les utilisateurs. Au cœur de cette évolution, particulièrement pour le principal réseau Ethereum et ses équivalents Layer2s, se trouve l'ERC4337. Il introduit un mempool alternatif qui distingue les transactions SCA des EOAs, sans modifications majeures du protocole. D'autre part, certains réseaux Layer 2 intègrent même nativement les SCAs, les incorporant sans problème dans leurs systèmes.

Il faut d’énormes efforts pour que tout soit facile. De nombreux défis existent, tels que la réduction des frais de déploiement, de validation et d’exécution pour la SCA ; Standardiser l’interface pour accroître l’interopérabilité des comptes ; Synchronisation de l’état du compte inter-chaînes ; et bien d’autres encore. Crédit à tous les constructeurs, nous nous rapprochons de jour en jour de la résolution de l’énigme. Et les entreprises de crypto-monnaies comme nous, SevenX, sont prêtes à aider les grandes entreprises à réaliser leur vision.

Démenti:

1. Cet article est repris de [CryptoSevenX Ventures]. Tous les droits d'auteur appartiennent à l'auteur original [@Rui]. Si vous avez des objections à cette réimpression, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdite.