Vision du portefeuille Ethereum idéal : une mise à niveau complète de l'expérience cross-chain à la protection de la vie privée

La couche de portefeuille dans la pile d'infrastructure Ethereum est cruciale, mais souvent sous-estimée par les chercheurs et les développeurs principaux. En tant que fenêtre entre l'utilisateur et le monde d'Ethereum, le portefeuille lui-même doit posséder des caractéristiques de décentralisation, de résistance à la censure, de sécurité et de confidentialité, afin que les utilisateurs puissent réellement profiter des attributs offerts par Ethereum et ses applications.

Récemment, les portefeuilles Ethereum ont fait des progrès significatifs en termes d'expérience utilisateur, de sécurité et de fonctionnalités. Cet article vise à partager certaines de mes réflexions sur les caractéristiques qu'un portefeuille Ethereum idéal devrait avoir. Ce n'est pas une liste complète, mais elle reflète davantage mes tendances de hacker éthique, en mettant l'accent sur la sécurité et la vie privée, ce qui peut ne pas être entièrement représentatif de l'expérience utilisateur. Cependant, je pense qu'il est peut-être plus précieux de se concentrer sur les attributs de sécurité et de vie privée que d'optimiser l'expérience utilisateur simplement en se basant sur des retours pour déployer et itérer.

Expérience utilisateur des transactions cross-chain L2

Il existe actuellement une feuille de route de plus en plus perfectionnée pour améliorer l'expérience utilisateur cross-chain entre les L2, comprenant des volets à court et à long terme. Ici, je vais discuter des idées pouvant être mises en œuvre à court terme.

L'idée principale est : (1) intégrant une fonction d'envoi cross-chain L2, (2) des adresses spécifiques à la chaîne et des demandes de paiement. Le portefeuille doit offrir aux utilisateurs une adresse conforme au style de brouillon ERC.

Lorsque l'utilisateur reçoit une adresse au format de ce type, il lui suffit de la coller dans le champ "Destinataire" du Portefeuille et de cliquer sur "Envoyer", le Portefeuille devrait automatiquement traiter l'envoi :

• Si la chaîne cible dispose déjà d'un nombre suffisant de jetons, envoyez directement.
• Comme d'autres chaînes nécessitant des tokens, utilisez le protocole DEX cross-chain pour envoyer.
• En cas de différents types de jetons, utilisez le DEX pour les convertir au bon type avant d'envoyer (, cela nécessite une confirmation de l'utilisateur ).

Dans le cas des demandes de dépôt par des dapps, la meilleure pratique consiste à étendre l'API web3 pour permettre aux dapps de soumettre des demandes de paiement spécifiques à la chaîne. Le portefeuille doit standardiser la demande getAvailableBalance et prendre en compte avec soin les chaînes sur lesquelles les actifs des utilisateurs sont par défaut stockés, afin de concilier sécurité et facilité de transfert.

Les demandes de paiement spécifiques à la chaîne peuvent également être intégrées dans un code QR, permettant au portefeuille mobile de les scanner. Dans des scénarios de paiement en personne ou en ligne, le code QR ou l'appel API émis par le receveur indique "Je veux Y unités de Z token sur la chaîne X, ID de référence W", le portefeuille peut librement choisir la méthode pour satisfaire cette demande. Une autre option est le protocole de lien de réclamation, le portefeuille de l'utilisateur génère un code QR ou une URL contenant l'autorisation, le receveur est responsable de l'extraction des fonds.

Le paiement des frais de gas est également un sujet connexe. Si un utilisateur reçoit des actifs sur un certain L2 mais n'a pas d'ETH, le portefeuille doit pouvoir utiliser automatiquement le protocole pour payer les frais de gas sur la chaîne où l'utilisateur a de l'ETH. Si le portefeuille prévoit que l'utilisateur effectuera davantage de transactions sur ce L2 à l'avenir, il peut également utiliser un DEX pour envoyer une certaine quantité d'ETH comme réserve de gas.

Sécurité du compte

Je pense que la clé de la sécurité des comptes réside dans la protection simultanée des utilisateurs contre les attaques de hackers ou les comportements malveillants des développeurs de portefeuilles, ainsi que contre les erreurs des utilisateurs eux-mêmes.

La solution que je privilégie depuis longtemps est un portefeuille avec récupération sociale et contrôle d'accès délégué, ainsi qu'une signature multiple. Les comptes utilisateurs disposent de deux niveaux de clés : une clé principale et N gardiens ( où N=5). La clé principale peut effectuer des opérations de faible valeur et non financières. La majorité des gardiens doivent exécuter : (1) des opérations de haute valeur, telles que l'envoi de tous les fonds du compte, (2) la modification de la clé principale ou de tout gardien. Si nécessaire, il peut être permis à la clé principale d'exécuter des opérations de haute valeur via un verrou temporel.

Cette conception de base peut être étendue. Les clés de session et les mécanismes d'autorisation peuvent soutenir différents applications pour atteindre un équilibre entre commodité et sécurité. Une architecture de gardien plus complexe, comme la mise en place de plusieurs périodes de verrouillage temporel sous différents seuils, aide à maximiser le taux de succès de la récupération des comptes légitimes tout en minimisant le risque de vol.

Pour le choix du tuteur, il existe plusieurs options :

1. Pour les utilisateurs de cryptomonnaie expérimentés, il est possible de choisir les clés de ses amis et de sa famille.
2. Gardien institutionnel : entreprise spécialisée dans la fourniture de services de signature, nécessitant une confirmation d'informations supplémentaires.
3. Plusieurs appareils personnels ( tels que des téléphones, des ordinateurs, des portefeuilles matériels ), mais les nouveaux utilisateurs peuvent avoir des difficultés à les configurer et à les gérer.
4. Solutions basées sur des gestionnaires de mots de passe, pouvant être sauvegardées localement ou dans le cloud, mais s'appuyer uniquement sur elles n'est pas suffisant pour protéger tous les actifs des utilisateurs.
5. ID centralisé emballé en ZK : comme zk-email, Anon Aadhaar, etc., qui peuvent convertir un ID centralisé en adresse Ethereum.

L'ID centralisé emballé dans ZK est plus convivial pour les nouveaux utilisateurs. Le portefeuille doit offrir une interface utilisateur simplifiée pour l'intégration, permettant aux utilisateurs de spécifier directement leur adresse e-mail en tant que tuteur, générant automatiquement l'adresse Ethereum zk-email correspondante. Les utilisateurs avancés devraient pouvoir vérifier l'exactitude de l'adresse générée.

Pour les nouveaux utilisateurs, le Portefeuille peut offrir des options simples, telles que le schéma 2-of-3 basé sur zk-email, les clés de stockage local et les clés de sauvegarde du fournisseur. À mesure que l'expérience des utilisateurs augmente ou que leurs actifs augmentent, il convient de les inciter à ajouter plus de gardiens.

L'intégration du portefeuille dans l'application est inévitable, mais les utilisateurs devraient pouvoir lier tous les portefeuilles ensemble pour gérer l'accès de manière unifiée. Une méthode simple consiste à adopter un schéma hiérarchique, permettant aux utilisateurs de définir le portefeuille principal comme le gardien de tous les portefeuilles dans l'application.

Protéger les utilisateurs contre les escroqueries et autres menaces externes

En plus de la sécurité des comptes, le portefeuille actuel a beaucoup travaillé sur la reconnaissance des adresses fausses, du phishing, des escroqueries, etc. Cependant, de nombreuses mesures restent assez rudimentaires, comme l'exigence uniforme de cliquer sur confirmer avant d'envoyer des jetons à une nouvelle adresse, quel que soit le montant. Cela nécessite une amélioration continue en fonction des différentes catégories de menaces, il n'existe pas de solution définitive.

Vie privée

Il est temps de prendre plus au sérieux la vie privée d'Ethereum. La technologie ZK-SNARK a atteint un niveau de maturité assez avancé, et les technologies de confidentialité sans porte dérobée (, comme les pools de confidentialité ), deviennent de plus en plus matures. Les infrastructures de niveau deux, comme Waku et les mempools ERC-4337, se stabilisent également progressivement. Cependant, pour effectuer des transferts privés, les utilisateurs doivent encore télécharger explicitement un "portefeuille de confidentialité", ce qui augmente les inconvénients et réduit le nombre d'utilisateurs. La solution consiste à intégrer directement les transferts privés dans le portefeuille.

Une mise en œuvre simple est : le Portefeuille stocke une partie des actifs de l'utilisateur comme "solde privé" dans le pool de confidentialité. Lors du transfert, il sort automatiquement du pool de confidentialité, et lors de la réception des fonds, une adresse invisible est générée automatiquement.

De plus, le portefeuille peut générer automatiquement une nouvelle adresse pour chaque application à laquelle l'utilisateur participe. Les dépôts proviennent du pool de confidentialité, et les retraits vont directement dans le pool de confidentialité. Cela permet aux utilisateurs de découpler leurs activités dans différentes applications.

Ce n'est pas seulement un moyen naturel de protéger la confidentialité des transferts d'actifs, mais aussi un moyen de protéger la confidentialité de l'identité. L'identité sur la chaîne existe déjà, comme les applications utilisant des preuves d'identité et les discussions verrouillées par des jetons. Nous espérons que cet écosystème pourra également protéger la vie privée, c'est-à-dire que les activités des utilisateurs sur la chaîne ne devraient pas être centralisées : chaque projet devrait être stocké séparément, et seul le portefeuille de l'utilisateur devrait pouvoir voir toutes les preuves en même temps. Un écosystème natif supportant plusieurs comptes par utilisateur aide à atteindre cet objectif, tout comme les protocoles de preuve hors chaîne tels que EAS et Zupass.

Cela représente une vision pragmatique à moyen terme pour la confidentialité d'Ethereum. Bien que certaines fonctionnalités puissent être introduites sur L1 et L2 pour rendre les transmissions de protection de la vie privée plus efficaces et fiables, cela peut déjà être réalisé maintenant. Certains défenseurs de la vie privée estiment que seule une confidentialité totale est acceptable, comme le cryptage de l'ensemble de l'EVM. Cela pourrait être un résultat idéal à long terme, mais cela nécessite une reconsidération plus fondamentale du modèle de programmation, qui n'a pas encore atteint un degré de maturité déployable. Nous avons vraiment besoin d'une confidentialité par défaut pour obtenir un ensemble d'anonymat suffisamment grand. Cependant, se concentrer d'abord sur le transfert entre comptes (1), (2) l'identité et les cas d'utilisation associés ( comme les preuves privées ) est un premier pas pragmatique, plus facile à réaliser, les portefeuilles peuvent déjà commencer à l'utiliser.

Portefeuille Ethereum doit également devenir un portefeuille de données

Toute solution de confidentialité valable entraînera la nécessité pour les utilisateurs de stocker des données hors chaîne, que ce soit pour le paiement, l'identité ou d'autres cas d'utilisation. Les protocoles de confidentialité modernes conservent parfois des données cryptées sur la chaîne, utilisant une seule clé privée pour déchiffrer. Cela comporte des risques, car si la clé est compromise ou si les ordinateurs quantiques deviennent viables, toutes les données seront rendues publiques. La preuve hors chaîne nécessite de manière plus significative un stockage de données hors chaîne.

Le portefeuille doit non seulement stocker les droits d'accès en chaîne, mais aussi les données privées des utilisateurs. Le monde non cryptographique prend également de plus en plus conscience de cela. Nous devons construire des garanties robustes autour de l'accessibilité des données et de la prévention des fuites. Peut-être que ces solutions peuvent être superposées : s'il y a N gardiens, utilisez un partage de secrets M-of-N entre ces N gardiens pour stocker les données. Les données sont essentiellement plus difficiles à protéger, car il est impossible de révoquer la part des données de quelqu'un, mais nous devrions proposer des solutions d'hébergement décentralisées aussi sécurisées que possible.

Accès sécurisé à la chaîne

Actuellement, le Portefeuille dépend des fournisseurs RPC pour obtenir des informations sur la chaîne, ce qui présente deux vulnérabilités :

1. Les fournisseurs RPC peuvent voler des fonds en fournissant de fausses informations ( telles que le prix du marché ).
2. Les fournisseurs RPC peuvent accéder aux informations privées des utilisateurs lors de leurs interactions avec les applications.

Idéalement, nous souhaitons combler ces deux failles. La résolution du premier problème nécessite une normalisation des clients légers L1 et L2, afin de valider directement le consensus de la blockchain. Helios a été réalisé pour L1 et a commencé à prendre en charge certains L2. Pour couvrir tous les L2, nous avons besoin d'une norme, qui obtient l'état racine récent et valide la logique des preuves d'état et de reçu via un contrat de configuration représentant le L2. Cela permettrait d'avoir un client léger universel, permettant aux portefeuilles de valider en toute sécurité tout état ou événement sur L1 et L2.

Pour la confidentialité, la seule méthode réaliste actuellement est de faire fonctionner son propre nœud complet. Cependant, avec la popularité des L2, il devient de plus en plus difficile de faire fonctionner un nœud complet pour tout. L'équivalent d'un client léger ici est la recherche d'informations privées (PIR). PIR implique des serveurs qui conservent toutes les copies de données et des clients qui envoient des requêtes cryptées aux serveurs. Les serveurs effectuent des calculs sur toutes les données et renvoient les données cryptées requises au client, sans savoir quelles données le client a consultées.

Pour garantir l'honnêteté du serveur, chaque élément de la base de données est lui-même une branche Merkle, le client peut vérifier avec un client léger.

Le calcul du PIR est très lourd. Les solutions incluent :

• Force brute : des améliorations algorithmiques ou matérielles dédiées pourraient permettre au PIR de fonctionner assez rapidement.
• Affaiblir les exigences en matière de confidentialité : par exemple, chaque recherche ne contient que 1 million de "mixins".
• PIR multi-serveurs : utilisation de plusieurs serveurs, en supposant 1-of-N honnête, l'algorithme PIR est généralement plus rapide.
• Anonymat plutôt que confidentialité : envoyer des demandes via un réseau de mélange, cachant l'expéditeur plutôt que le contenu. Mais cela augmente la latence.

Trouver la bonne combinaison technique pour maximiser la confidentialité tout en maintenant l'utilité dans l'environnement Ethereum est une question de recherche ouverte.

Portefeuille de coffre-fort idéal

Dans le contexte cross-chain L2, un autre processus important qui doit fonctionner sans heurts est le changement de la validation des comptes.