Vision du portefeuille Ethereum idéal : mise à niveau complète de l'expérience cross-chain à la protection de la vie privée
La couche portefeuille dans la pile d'infrastructure Ethereum est cruciale, mais souvent sous-estimée par les chercheurs et développeurs principaux de L1. Le portefeuille est la fenêtre par laquelle les utilisateurs interagissent avec le monde d'Ethereum, et la capacité des utilisateurs à profiter des caractéristiques de décentralisation, d'anti-censure, de sécurité et de vie privée offertes par Ethereum et ses applications dépend des propriétés de ce portefeuille.
Récemment, les portefeuilles Ethereum ont réalisé des progrès significatifs en matière d'expérience utilisateur, de sécurité et de fonctionnalités. Cet article vise à partager quelques réflexions sur les caractéristiques qu'un portefeuille Ethereum idéal devrait avoir. Ce n'est pas une liste exhaustive, elle reflète mes tendances de cyberpunk, mettant l'accent sur la sécurité et la confidentialité, ce qui peut faire défaut en termes d'expérience utilisateur. Je pense qu'en optimisant l'expérience utilisateur, il est plus efficace de déployer simplement et d'itérer en fonction des retours que de faire une liste de souhaits, c'est pourquoi je pense qu'il est le plus précieux de se concentrer sur les attributs de sécurité et de confidentialité.
Expérience utilisateur des transactions cross-chain L2
Il existe désormais une feuille de route de plus en plus détaillée pour améliorer l'expérience des utilisateurs inter-L2, comprenant des volets à court et à long terme. Ici, nous mettons l'accent sur le volet à court terme : des idées qui peuvent encore théoriquement être mises en œuvre aujourd'hui.
L'idée principale est : (1) fonction d'envoi intégrée cross-chain L2, (2) adresse spécifique de la chaîne et demande de paiement. Votre portefeuille devrait être en mesure de vous fournir une adresse spécifique de la chaîne, en suivant le style des projets ERC pertinents.
Lorsque quelqu'un ( ou une application ) vous fournit une adresse au format suivant, vous devez être en mesure de la coller dans le champ "destinataire" de votre portefeuille, puis de cliquer sur "envoyer". Le portefeuille doit traiter automatiquement les données d'envoi de toutes les manières possibles :
Si vous avez déjà suffisamment de jetons du type requis sur la chaîne cible, envoyez-les directement.
Si vous avez des jetons du type requis sur d'autres chaînes, utiliser des protocoles comme ERC-7683 ( est en réalité un DEX cross-chain ).
Si vous avez différents types de jetons sur la même chaîne ou sur d'autres chaînes, utilisez un DEX pour les convertir en la bonne monnaie du bon type sur la bonne chaîne et envoyez-les. Cela nécessite l'autorisation explicite de l'utilisateur : l'utilisateur verra les frais de paiement ainsi que le montant reçu par le destinataire.
Le cas décrit ci-dessus s'applique à "copier-coller l'adresse ( ou ENS, comme vitalik.eth@optimism.eth) si quelqu'un vous envoie un paiement". Pour les cas où dapp demande un dépôt, le processus idéal consiste à étendre l'API web3, permettant à dapp d'émettre des demandes de paiement spécifiques à la chaîne. Votre portefeuille pourra satisfaire cette demande de toutes les manières nécessaires. Pour garantir une bonne expérience utilisateur, il est également nécessaire de normaliser la demande getAvailableBalance, et le portefeuille doit sérieusement considérer sur quelles chaînes stocker par défaut les actifs des utilisateurs, afin de maximiser la sécurité et la facilité des transferts.
Les demandes de paiement spécifiques à la chaîne peuvent également être intégrées dans un code QR, pour être scannées par un portefeuille mobile. Dans les scénarios de paiement en face à face ( ou en ligne ), le destinataire émettra un code QR ou un appel API web3, indiquant "Je veux Y unités du jeton Z sur la chaîne X, référence ID ou rappel W", le portefeuille peut librement choisir la manière de 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 de réclamation, pour obtenir un certain montant de fonds depuis leur contrat sur la chaîne, le destinataire doit déterminer comment transférer les fonds vers son propre portefeuille.
Un autre sujet connexe est le paiement des frais de gas. Si vous recevez des actifs sur un L2 sans ETH, vous devez envoyer des transactions sur ce L2, le portefeuille doit pouvoir utiliser automatiquement le protocole ( tel que RIP-7755) pour payer les frais de gas à partir de la chaîne où vous avez de l'ETH. Si le portefeuille prévoit que vous effectuerez plus de transactions sur le L2 à l'avenir, il doit également utiliser uniquement DEX pour envoyer des ETH d'une valeur de plusieurs centaines de frais de gas, afin que les futures transactions puissent payer directement les frais de gas ( car c'est moins cher ).
Sécurité du compte
Une façon de conceptualiser le défi de la sécurité des comptes est que d'excellents portefeuilles doivent jouer un rôle à la fois dans deux domaines : ( protéger les utilisateurs contre les attaques de pirates ou les comportements malveillants des développeurs de portefeuilles, ) protéger les utilisateurs contre les impacts de leurs propres erreurs.
Ma solution préférée est la récupération sociale et le portefeuille multi-signatures, avec un contrôle d'accès hiérarchique. Les comptes utilisateurs ont deux niveaux de clés : une clé principale et N tuteurs ( où N=5). La clé principale peut exécuter des opérations de faible valeur et non financières. La plupart des tuteurs doivent exécuter : (1) des opérations de haute valeur, comme envoyer toute la valeur du compte, (2) changer la clé principale ou tout tuteur. Si nécessaire, il peut être permis à la clé principale d'exécuter des opérations de haute valeur via un verrouillage temporel.
C'est un design de base, extensible. Les mécanismes d'autorisation tels que la clé de session et l'ERC-7715 peuvent aider à équilibrer la commodité et la sécurité entre différentes applications. Une architecture de gardien plus complexe, avec plusieurs durées de verrouillage temporel sous différents seuils, peut aider à maximiser les chances de récupération réussie des comptes légitimes tout en minimisant les risques de vol.
Choix du tuteur
Pour les utilisateurs de crypto expérimentés, une option viable est la clé des amis et de la famille. Si chacun est invité à fournir une nouvelle adresse, personne n'a besoin de savoir qui ils sont - en fait, les gardiens n'ont même pas besoin de connaître l'identité des autres. S'ils ne communiquent pas, la possibilité de collusion est très faible. Cependant, pour la plupart des nouveaux utilisateurs, cette option n'est pas disponible.
La deuxième option est le gardien institutionnel : des entreprises qui offrent spécifiquement des services de signature de transactions uniquement sur demande d'informations de confirmation supplémentaires, comme un code de confirmation, ou des appels vidéo pour les utilisateurs de grande valeur. Cela fait longtemps que les gens essaient de créer cela, comme ma présentation de CryptoCorp en 2013. Cependant, jusqu'à présent, ces entreprises n'ont pas connu un grand succès.
La troisième option est plusieurs appareils personnels ( tels que des téléphones, des ordinateurs de bureau, des portefeuilles matériels ). Cela est faisable, mais la configuration et la gestion sont difficiles pour les utilisateurs inexpérimentés. Il existe également un risque de perte ou de vol simultané des appareils, surtout lorsqu'ils se trouvent au même endroit.
Récemment, nous avons commencé à voir davantage de solutions basées sur des clés universelles. Les clés peuvent être uniquement sauvegardées sur votre appareil, en faisant une solution pour appareil personnel, ou sauvegardées dans le cloud, rendant leur sécurité dépendante d'une combinaison complexe de sécurité par mot de passe, d'institutions et d'hypothèses matérielles de confiance. En réalité, les clés universelles représentent un précieux gain de sécurité pour les utilisateurs ordinaires, mais elles ne suffisent pas à elles seules à protéger les économies d'une vie des utilisateurs.
Heureusement, avec ZK-SNARK, nous avons une quatrième option : l'ID centralisé enveloppé dans ZK. Ce type inclut zk-email, Anon Aadhaar, Myna Wallet, etc. Fondamentalement, vous pouvez utiliser diverses formes d'ID centralisé d'une entreprise ou d'un gouvernement ( et les convertir en adresse Ethereum, et vous ne pouvez envoyer des transactions qu'en générant une preuve de possession de l'ID centralisé via ZK-SNARK.
Avec cet ajout, nous avons maintenant un large choix, les ID centralisés empaquetés en ZK ont une "facilité d'utilisation pour les débutants" unique.
Pour cela, il est nécessaire de réaliser une interface utilisateur simplifiée et intégrée : vous devriez pouvoir spécifier uniquement "example@gmail.com" comme tuteur, et cela devrait automatiquement générer l'adresse Ethereum zk-email correspondante. Les utilisateurs avancés devraient pouvoir saisir l'email ) ainsi que la valeur de sel de confidentialité potentiellement sauvegardée ( dans une application tierce open source et confirmer que l'adresse générée est correcte. Il en va de même pour tout autre type de tuteur pris en charge.
Il convient de noter qu'un défi réel auquel est confronté le zk-email est qu'il dépend de la signature DKIM, qui utilise des clés renouvelées tous les quelques mois, et ces clés ne sont elles-mêmes signées par aucune autre entité. Cela signifie que le zk-email actuel a un certain niveau d'exigence de confiance qui dépasse celui du fournisseur lui-même ; si le zk-email utilise la vérification TLSNotary pour mettre à jour les clés dans du matériel de confiance, cela pourrait réduire cette situation, mais ce n'est pas idéal. J'espère que les fournisseurs de services de messagerie commenceront à signer directement leurs clés DKIM. Actuellement, je recommande d'utiliser un gardien zk-email, mais je ne conseille pas à la plupart des gardiens de le faire : ne stockez pas de fonds dans un zk-email endommagé, ce qui signifie que les fonds ne peuvent pas être utilisés.
![Vitalik nouvel article : La vision du portefeuille idéal, une mise à niveau complète de l'expérience cross-chain à la protection de la vie privée])https://img-cdn.gateio.im/webp-social/moments-6e92b6b051653e68d5f93ed0d91891eb.webp(
Nouveaux utilisateurs et Portefeuille dans l'application
Les nouveaux utilisateurs ne souhaitent en réalité pas saisir un grand nombre de gardiens lors de leur première inscription. Par conséquent, le portefeuille devrait leur offrir une option très simple. Un moyen naturel est d'utiliser zk-email sur leur adresse e-mail, une clé stockée localement sur l'appareil de l'utilisateur ) qui pourrait être la clé universelle ( ainsi qu'une clé de sauvegarde détenue par le fournisseur, pour faire un choix 2 sur 3. À mesure que les utilisateurs deviennent plus expérimentés ou accumulent plus d'actifs, ils devraient être invités à un moment donné à ajouter plus de gardiens.
L'intégration du Portefeuille dans l'application est inévitable, car les applications cherchant à attirer des utilisateurs non cryptographiques ne souhaitent pas que les utilisateurs téléchargent simultanément deux nouvelles applications, ) et le Portefeuille Ethereum (, ce qui engendre une expérience utilisateur confuse. Cependant, de nombreux utilisateurs de portefeuilles intégrés devraient pouvoir lier tous les portefeuilles ensemble, de sorte qu'ils n'aient qu'à se soucier d'un "problème de contrôle d'accès". La méthode la plus simple consiste à adopter un schéma hiérarchique, avec un processus de "lien" rapide, permettant aux utilisateurs de définir le portefeuille principal comme le gardien de tous les portefeuilles intégrés. Le client Farcaster Warpcast a déjà pris en charge cela.
![Vitalik nouvel article : la vision d'un portefeuille idéal, une mise à niveau complète de l'expérience cross-chain à la protection de la vie privée])https://img-cdn.gateio.im/webp-social/moments-2439f49163d0212333ea4207f34cdbef.webp(
Protéger les utilisateurs contre la fraude et d'autres menaces externes
En plus de la sécurité des comptes, les portefeuilles d'aujourd'hui ont également beaucoup travaillé pour identifier les fausses adresses, le phishing, les escroqueries et d'autres menaces externes, et s'efforcent de protéger les utilisateurs. En même temps, de nombreuses contre-mesures restent assez rudimentaires : par exemple, exiger un clic pour envoyer de l'Éther ou d'autres jetons à toute nouvelle adresse, que ce soit 100 dollars ou 100 000 dollars. Il n'existe pas de solution miracle unique. Il s'agit d'une série de réparations et d'améliorations lentes et continues ciblant différentes catégories de menaces. Cependant, il est très précieux de continuer à travailler à l'amélioration.
![Vitalik nouvel article : la vision du portefeuille idéal, une mise à niveau complète de l'expérience cross-chain à la protection de la vie privée])https://img-cdn.gateio.im/webp-social/moments-9852b894445658cf6d25e8e105ea1445.webp(
Confidentialité
Il est maintenant temps de prendre plus au sérieux la confidentialité d'Ethereum. La technologie ZK-SNARK est très avancée, ne dépendant pas de portes dérobées pour réduire les risques de réglementation, et la technologie de confidentialité comme les pools de confidentialité ) devient de plus en plus mature. Des infrastructures de niveau secondaire, comme les mempools Waku et ERC-4337, se stabilisent également progressivement. Cependant, effectuer des transferts privés sur Ethereum nécessite actuellement que les utilisateurs téléchargent et utilisent explicitement un "portefeuille de confidentialité", tel que Railway ( ou Umbra ) pour les adresses invisibles. Cela augmente considérablement les inconvénients et réduit le nombre de personnes prêtes à effectuer des transferts privés. La solution consiste à intégrer directement les transferts privés dans le portefeuille.
Une implémentation simple est la suivante. Le portefeuille peut stocker une partie des actifs de l'utilisateur comme "solde privé" dans le pool de confidentialité. Lorsqu'un utilisateur effectue un transfert, il sort automatiquement du pool de confidentialité. Si l'utilisateur doit recevoir des fonds, le portefeuille peut générer automatiquement une adresse invisible.
De plus, le portefeuille peut générer automatiquement une nouvelle adresse ( pour chaque application à laquelle l'utilisateur participe, comme le protocole defi ). Les dépôts proviennent d'un pool de confidentialité, et les retraits vont directement dans le pool de confidentialité. Cela permet aux utilisateurs de dissocier leurs activités dans une application de celles dans d'autres applications.
Cette technologie est non seulement une voie naturelle pour le transfert d'actifs de confidentialité, mais aussi une voie naturelle pour la protection de l'identité privée. L'identité est sur la chaîne : toute application contrôlée par une preuve d'identité ( comme Gitcoin Grants ), tout chat contrôlé par des jetons, les protocoles conformes à Ethereum, etc. sont des identités sur la chaîne. Nous espérons que cet écosystème pourra également protéger la confidentialité. Cela signifie 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 le portefeuille de l'utilisateur devrait être la seule chose ayant une "vue globale".
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
23 J'aime
Récompense
23
6
Partager
Commentaire
0/400
SandwichDetector
· 07-16 06:01
La vie privée est la première force de production ah ah ah
Voir l'originalRépondre0
MiningDisasterSurvivor
· 07-13 07:07
18 ans de leçons du désastre du minage ne sont pas oubliées, d'abord protégeons le portefeuille avant de parler d'autre chose.
Voir l'originalRépondre0
HappyToBeDumped
· 07-13 07:06
Il suffit de regarder un chiffre pour voir du vert partout, quel portefeuille !
Voir l'originalRépondre0
DeepRabbitHole
· 07-13 06:48
Ce portefeuille est tellement génial, pourquoi perd-on toujours sa clé privée partout ?
Voir l'originalRépondre0
HalfBuddhaMoney
· 07-13 06:45
Je ne peux pas voir, buddy, je me concentre sur la confidentialité.
Voir l'originalRépondre0
Rugpull幸存者
· 07-13 06:45
En termes de confidentialité, c'est toujours un peu inutile.
Évolution du portefeuille Ethereum : une mise à niveau complète de l'expérience cross-chain à la protection de la vie privée.
Vision du portefeuille Ethereum idéal : mise à niveau complète de l'expérience cross-chain à la protection de la vie privée
La couche portefeuille dans la pile d'infrastructure Ethereum est cruciale, mais souvent sous-estimée par les chercheurs et développeurs principaux de L1. Le portefeuille est la fenêtre par laquelle les utilisateurs interagissent avec le monde d'Ethereum, et la capacité des utilisateurs à profiter des caractéristiques de décentralisation, d'anti-censure, de sécurité et de vie privée offertes par Ethereum et ses applications dépend des propriétés de ce portefeuille.
Récemment, les portefeuilles Ethereum ont réalisé des progrès significatifs en matière d'expérience utilisateur, de sécurité et de fonctionnalités. Cet article vise à partager quelques réflexions sur les caractéristiques qu'un portefeuille Ethereum idéal devrait avoir. Ce n'est pas une liste exhaustive, elle reflète mes tendances de cyberpunk, mettant l'accent sur la sécurité et la confidentialité, ce qui peut faire défaut en termes d'expérience utilisateur. Je pense qu'en optimisant l'expérience utilisateur, il est plus efficace de déployer simplement et d'itérer en fonction des retours que de faire une liste de souhaits, c'est pourquoi je pense qu'il est le plus précieux de se concentrer sur les attributs de sécurité et de confidentialité.
Expérience utilisateur des transactions cross-chain L2
Il existe désormais une feuille de route de plus en plus détaillée pour améliorer l'expérience des utilisateurs inter-L2, comprenant des volets à court et à long terme. Ici, nous mettons l'accent sur le volet à court terme : des idées qui peuvent encore théoriquement être mises en œuvre aujourd'hui.
L'idée principale est : (1) fonction d'envoi intégrée cross-chain L2, (2) adresse spécifique de la chaîne et demande de paiement. Votre portefeuille devrait être en mesure de vous fournir une adresse spécifique de la chaîne, en suivant le style des projets ERC pertinents.
Lorsque quelqu'un ( ou une application ) vous fournit une adresse au format suivant, vous devez être en mesure de la coller dans le champ "destinataire" de votre portefeuille, puis de cliquer sur "envoyer". Le portefeuille doit traiter automatiquement les données d'envoi de toutes les manières possibles :
Le cas décrit ci-dessus s'applique à "copier-coller l'adresse ( ou ENS, comme vitalik.eth@optimism.eth) si quelqu'un vous envoie un paiement". Pour les cas où dapp demande un dépôt, le processus idéal consiste à étendre l'API web3, permettant à dapp d'émettre des demandes de paiement spécifiques à la chaîne. Votre portefeuille pourra satisfaire cette demande de toutes les manières nécessaires. Pour garantir une bonne expérience utilisateur, il est également nécessaire de normaliser la demande getAvailableBalance, et le portefeuille doit sérieusement considérer sur quelles chaînes stocker par défaut les actifs des utilisateurs, afin de maximiser la sécurité et la facilité des transferts.
Les demandes de paiement spécifiques à la chaîne peuvent également être intégrées dans un code QR, pour être scannées par un portefeuille mobile. Dans les scénarios de paiement en face à face ( ou en ligne ), le destinataire émettra un code QR ou un appel API web3, indiquant "Je veux Y unités du jeton Z sur la chaîne X, référence ID ou rappel W", le portefeuille peut librement choisir la manière de 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 de réclamation, pour obtenir un certain montant de fonds depuis leur contrat sur la chaîne, le destinataire doit déterminer comment transférer les fonds vers son propre portefeuille.
Un autre sujet connexe est le paiement des frais de gas. Si vous recevez des actifs sur un L2 sans ETH, vous devez envoyer des transactions sur ce L2, le portefeuille doit pouvoir utiliser automatiquement le protocole ( tel que RIP-7755) pour payer les frais de gas à partir de la chaîne où vous avez de l'ETH. Si le portefeuille prévoit que vous effectuerez plus de transactions sur le L2 à l'avenir, il doit également utiliser uniquement DEX pour envoyer des ETH d'une valeur de plusieurs centaines de frais de gas, afin que les futures transactions puissent payer directement les frais de gas ( car c'est moins cher ).
Sécurité du compte
Une façon de conceptualiser le défi de la sécurité des comptes est que d'excellents portefeuilles doivent jouer un rôle à la fois dans deux domaines : ( protéger les utilisateurs contre les attaques de pirates ou les comportements malveillants des développeurs de portefeuilles, ) protéger les utilisateurs contre les impacts de leurs propres erreurs.
Ma solution préférée est la récupération sociale et le portefeuille multi-signatures, avec un contrôle d'accès hiérarchique. Les comptes utilisateurs ont deux niveaux de clés : une clé principale et N tuteurs ( où N=5). La clé principale peut exécuter des opérations de faible valeur et non financières. La plupart des tuteurs doivent exécuter : (1) des opérations de haute valeur, comme envoyer toute la valeur du compte, (2) changer la clé principale ou tout tuteur. Si nécessaire, il peut être permis à la clé principale d'exécuter des opérations de haute valeur via un verrouillage temporel.
C'est un design de base, extensible. Les mécanismes d'autorisation tels que la clé de session et l'ERC-7715 peuvent aider à équilibrer la commodité et la sécurité entre différentes applications. Une architecture de gardien plus complexe, avec plusieurs durées de verrouillage temporel sous différents seuils, peut aider à maximiser les chances de récupération réussie des comptes légitimes tout en minimisant les risques de vol.
Choix du tuteur
Pour les utilisateurs de crypto expérimentés, une option viable est la clé des amis et de la famille. Si chacun est invité à fournir une nouvelle adresse, personne n'a besoin de savoir qui ils sont - en fait, les gardiens n'ont même pas besoin de connaître l'identité des autres. S'ils ne communiquent pas, la possibilité de collusion est très faible. Cependant, pour la plupart des nouveaux utilisateurs, cette option n'est pas disponible.
La deuxième option est le gardien institutionnel : des entreprises qui offrent spécifiquement des services de signature de transactions uniquement sur demande d'informations de confirmation supplémentaires, comme un code de confirmation, ou des appels vidéo pour les utilisateurs de grande valeur. Cela fait longtemps que les gens essaient de créer cela, comme ma présentation de CryptoCorp en 2013. Cependant, jusqu'à présent, ces entreprises n'ont pas connu un grand succès.
La troisième option est plusieurs appareils personnels ( tels que des téléphones, des ordinateurs de bureau, des portefeuilles matériels ). Cela est faisable, mais la configuration et la gestion sont difficiles pour les utilisateurs inexpérimentés. Il existe également un risque de perte ou de vol simultané des appareils, surtout lorsqu'ils se trouvent au même endroit.
Récemment, nous avons commencé à voir davantage de solutions basées sur des clés universelles. Les clés peuvent être uniquement sauvegardées sur votre appareil, en faisant une solution pour appareil personnel, ou sauvegardées dans le cloud, rendant leur sécurité dépendante d'une combinaison complexe de sécurité par mot de passe, d'institutions et d'hypothèses matérielles de confiance. En réalité, les clés universelles représentent un précieux gain de sécurité pour les utilisateurs ordinaires, mais elles ne suffisent pas à elles seules à protéger les économies d'une vie des utilisateurs.
Heureusement, avec ZK-SNARK, nous avons une quatrième option : l'ID centralisé enveloppé dans ZK. Ce type inclut zk-email, Anon Aadhaar, Myna Wallet, etc. Fondamentalement, vous pouvez utiliser diverses formes d'ID centralisé d'une entreprise ou d'un gouvernement ( et les convertir en adresse Ethereum, et vous ne pouvez envoyer des transactions qu'en générant une preuve de possession de l'ID centralisé via ZK-SNARK.
Avec cet ajout, nous avons maintenant un large choix, les ID centralisés empaquetés en ZK ont une "facilité d'utilisation pour les débutants" unique.
Pour cela, il est nécessaire de réaliser une interface utilisateur simplifiée et intégrée : vous devriez pouvoir spécifier uniquement "example@gmail.com" comme tuteur, et cela devrait automatiquement générer l'adresse Ethereum zk-email correspondante. Les utilisateurs avancés devraient pouvoir saisir l'email ) ainsi que la valeur de sel de confidentialité potentiellement sauvegardée ( dans une application tierce open source et confirmer que l'adresse générée est correcte. Il en va de même pour tout autre type de tuteur pris en charge.
Il convient de noter qu'un défi réel auquel est confronté le zk-email est qu'il dépend de la signature DKIM, qui utilise des clés renouvelées tous les quelques mois, et ces clés ne sont elles-mêmes signées par aucune autre entité. Cela signifie que le zk-email actuel a un certain niveau d'exigence de confiance qui dépasse celui du fournisseur lui-même ; si le zk-email utilise la vérification TLSNotary pour mettre à jour les clés dans du matériel de confiance, cela pourrait réduire cette situation, mais ce n'est pas idéal. J'espère que les fournisseurs de services de messagerie commenceront à signer directement leurs clés DKIM. Actuellement, je recommande d'utiliser un gardien zk-email, mais je ne conseille pas à la plupart des gardiens de le faire : ne stockez pas de fonds dans un zk-email endommagé, ce qui signifie que les fonds ne peuvent pas être utilisés.
![Vitalik nouvel article : La vision du portefeuille idéal, une mise à niveau complète de l'expérience cross-chain à la protection de la vie privée])https://img-cdn.gateio.im/webp-social/moments-6e92b6b051653e68d5f93ed0d91891eb.webp(
Nouveaux utilisateurs et Portefeuille dans l'application
Les nouveaux utilisateurs ne souhaitent en réalité pas saisir un grand nombre de gardiens lors de leur première inscription. Par conséquent, le portefeuille devrait leur offrir une option très simple. Un moyen naturel est d'utiliser zk-email sur leur adresse e-mail, une clé stockée localement sur l'appareil de l'utilisateur ) qui pourrait être la clé universelle ( ainsi qu'une clé de sauvegarde détenue par le fournisseur, pour faire un choix 2 sur 3. À mesure que les utilisateurs deviennent plus expérimentés ou accumulent plus d'actifs, ils devraient être invités à un moment donné à ajouter plus de gardiens.
L'intégration du Portefeuille dans l'application est inévitable, car les applications cherchant à attirer des utilisateurs non cryptographiques ne souhaitent pas que les utilisateurs téléchargent simultanément deux nouvelles applications, ) et le Portefeuille Ethereum (, ce qui engendre une expérience utilisateur confuse. Cependant, de nombreux utilisateurs de portefeuilles intégrés devraient pouvoir lier tous les portefeuilles ensemble, de sorte qu'ils n'aient qu'à se soucier d'un "problème de contrôle d'accès". La méthode la plus simple consiste à adopter un schéma hiérarchique, avec un processus de "lien" rapide, permettant aux utilisateurs de définir le portefeuille principal comme le gardien de tous les portefeuilles intégrés. Le client Farcaster Warpcast a déjà pris en charge cela.
![Vitalik nouvel article : la vision d'un portefeuille idéal, une mise à niveau complète de l'expérience cross-chain à la protection de la vie privée])https://img-cdn.gateio.im/webp-social/moments-2439f49163d0212333ea4207f34cdbef.webp(
Protéger les utilisateurs contre la fraude et d'autres menaces externes
En plus de la sécurité des comptes, les portefeuilles d'aujourd'hui ont également beaucoup travaillé pour identifier les fausses adresses, le phishing, les escroqueries et d'autres menaces externes, et s'efforcent de protéger les utilisateurs. En même temps, de nombreuses contre-mesures restent assez rudimentaires : par exemple, exiger un clic pour envoyer de l'Éther ou d'autres jetons à toute nouvelle adresse, que ce soit 100 dollars ou 100 000 dollars. Il n'existe pas de solution miracle unique. Il s'agit d'une série de réparations et d'améliorations lentes et continues ciblant différentes catégories de menaces. Cependant, il est très précieux de continuer à travailler à l'amélioration.
![Vitalik nouvel article : la vision du portefeuille idéal, une mise à niveau complète de l'expérience cross-chain à la protection de la vie privée])https://img-cdn.gateio.im/webp-social/moments-9852b894445658cf6d25e8e105ea1445.webp(
Confidentialité
Il est maintenant temps de prendre plus au sérieux la confidentialité d'Ethereum. La technologie ZK-SNARK est très avancée, ne dépendant pas de portes dérobées pour réduire les risques de réglementation, et la technologie de confidentialité comme les pools de confidentialité ) devient de plus en plus mature. Des infrastructures de niveau secondaire, comme les mempools Waku et ERC-4337, se stabilisent également progressivement. Cependant, effectuer des transferts privés sur Ethereum nécessite actuellement que les utilisateurs téléchargent et utilisent explicitement un "portefeuille de confidentialité", tel que Railway ( ou Umbra ) pour les adresses invisibles. Cela augmente considérablement les inconvénients et réduit le nombre de personnes prêtes à effectuer des transferts privés. La solution consiste à intégrer directement les transferts privés dans le portefeuille.
Une implémentation simple est la suivante. Le portefeuille peut stocker une partie des actifs de l'utilisateur comme "solde privé" dans le pool de confidentialité. Lorsqu'un utilisateur effectue un transfert, il sort automatiquement du pool de confidentialité. Si l'utilisateur doit recevoir des fonds, le portefeuille peut générer automatiquement une adresse invisible.
De plus, le portefeuille peut générer automatiquement une nouvelle adresse ( pour chaque application à laquelle l'utilisateur participe, comme le protocole defi ). Les dépôts proviennent d'un pool de confidentialité, et les retraits vont directement dans le pool de confidentialité. Cela permet aux utilisateurs de dissocier leurs activités dans une application de celles dans d'autres applications.
Cette technologie est non seulement une voie naturelle pour le transfert d'actifs de confidentialité, mais aussi une voie naturelle pour la protection de l'identité privée. L'identité est sur la chaîne : toute application contrôlée par une preuve d'identité ( comme Gitcoin Grants ), tout chat contrôlé par des jetons, les protocoles conformes à Ethereum, etc. sont des identités sur la chaîne. Nous espérons que cet écosystème pourra également protéger la confidentialité. Cela signifie 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 le portefeuille de l'utilisateur devrait être la seule chose ayant une "vue globale".