Vision du portefeuille idéal Ethereum : une mise à niveau complète de l'expérience cross-chain à la protection de la vie privée.
Dans la pile d'infrastructure d'Ethereum, le portefeuille est une couche clé, mais souvent sous-estimée par les chercheurs et développeurs L1. Le portefeuille est la fenêtre par laquelle les utilisateurs communiquent avec le monde d'Ethereum, et les utilisateurs ne peuvent bénéficier des caractéristiques décentralisées, anti-censure, sécurisées et de confidentialité fournies par Ethereum et ses applications que lorsque le portefeuille possède les attributs appropriés.
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 des opinions sur les caractéristiques qu'un portefeuille Ethereum idéal devrait posséder. Ce n'est pas une liste complète, elle reflète l'inclination du cryptopunk de l'auteur, mettant l'accent sur la sécurité et la vie privée, ce qui peut ne pas être suffisamment complet en matière d'expérience utilisateur. Cependant, l'auteur estime qu'optimiser l'expérience utilisateur en déployant et en itérant simplement en fonction des retours d'expérience est plus efficace qu'une liste de souhaits, c'est pourquoi il considère que se concentrer sur les attributs de sécurité et de vie privée est le plus précieux.
expérience utilisateur des transactions cross-chain L2
Il existe maintenant une feuille de route de plus en plus détaillée pour améliorer l'expérience utilisateur cross-chain L2, comprenant des parties à court et à long terme. Ici, nous discutons de la partie à court terme : des idées qui peuvent théoriquement être mises en œuvre dès maintenant.
L'idée centrale est : (i) envoi cross-chain intégré L2, ainsi que (ii) adresses spécifiques à la chaîne et demandes de paiement. Le portefeuille devrait être en mesure de fournir à l'utilisateur une adresse conforme au style de projet ERC.
Lorsque l'utilisateur reçoit une adresse dans ce format, il doit pouvoir la coller dans le champ "Destinataire" du portefeuille et cliquer sur "Envoyer". Le portefeuille doit traiter automatiquement les données d'envoi :
Si vous disposez de suffisamment de jetons requis sur la chaîne cible, envoyez-les directement.
Si vous avez besoin de tokens de type similaire sur d'autres chaînes, utilisez un protocole similaire à ERC-7683 pour envoyer.
Si vous avez différents types de jetons, utilisez le DEX pour les convertir au bon type et les envoyer.
Cela s'applique au scénario de "paiement par adresse de copier-coller". Dans le cas où l'application demande un dépôt, le processus idéal consiste à étendre l'API web3 et à permettre à l'application d'émettre des demandes de paiement spécifiques à la chaîne. Le portefeuille peut répondre à cette demande de la manière nécessaire. Pour garantir une bonne expérience utilisateur, il est également nécessaire de standardiser la demande getAvailableBalance, et le portefeuille doit sérieusement envisager sur quelles chaînes stocker par défaut les actifs des utilisateurs afin de maximiser la sécurité et la commodité 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 des scénarios de paiement en face à face ou en ligne, le bénéficiaire émettra un code QR ou un appel API web3, indiquant "Je souhaite obtenir Y unités de l'élément Z sur la chaîne X, avec l'ID de référence ou le rappel W", le portefeuille peut librement 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, le bénéficiaire est responsable de transférer les fonds vers son propre portefeuille.
Un autre sujet connexe est le paiement des gas. Si des actifs sont reçus sur un L2 sans ETH et qu'il est nécessaire d'envoyer une transaction, le portefeuille doit pouvoir utiliser automatiquement le protocole ( comme RIP-7755) pour payer les gas à partir d'une chaîne avec de l'ETH. Si le portefeuille prévoit que l'utilisateur effectuera plus de transactions sur le L2 à l'avenir, il doit également utiliser uniquement le DEX pour envoyer une quantité suffisante d'ETH, afin que les transactions futures puissent directement payer les gas ( car c'est moins cher ).
sécurité du compte
La conceptualisation des défis en matière de sécurité des comptes est la suivante : un bon portefeuille doit jouer un rôle dans deux domaines : (i) protéger les utilisateurs contre les attaques de hackers ou les comportements malveillants des développeurs de portefeuilles, (ii) protéger les utilisateurs contre les conséquences de leurs propres erreurs.
La solution préférée est la récupération sociale et le portefeuille multi-signatures, avec 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 effectuer des opérations de faible valeur et non financières. La plupart des tuteurs doivent exécuter (i) des opérations de haute valeur, comme envoyer la valeur totale du compte, ou (ii) modifier la clé principale ou tout tuteur. Si nécessaire, la clé principale peut être autorisée à exécuter des opérations de haute valeur par le biais d'un verrouillage temporel.
La conception de base peut être étendue. Les clés de session et les mécanismes d'autorisation tels que l'ERC-7715 peuvent aider à soutenir l'équilibre entre la commodité et la sécurité des différentes applications. Des architectures de gardiennage plus complexes, comme celles avec plusieurs durées de verrouillage temporel à différents seuils, peuvent aider à maximiser les chances de récupération réussie des comptes légitimes tout en minimisant le risque de vol.
Choix du gardien
Pour les utilisateurs de cryptomonnaie expérimentés, une option viable est d'utiliser les clés de leurs amis et de leur famille. Si chaque personne est amenée à fournir une nouvelle adresse, personne n'a besoin de connaître l'identité des autres, et la possibilité de collusion est très faible. Mais pour la plupart des nouveaux utilisateurs, cette option n'est pas disponible.
La deuxième option est le gardien institutionnel : un service qui ne signe les transactions que lorsque d'autres informations de confirmation sont reçues. Les gens ont longtemps essayé de créer ce type de service, mais jusqu'à présent, cela a été peu réussi.
La troisième option est plusieurs appareils personnels ( tels que des téléphones, des ordinateurs, et des portefeuilles matériels ). Cela est viable mais difficile à configurer et à gérer pour les débutants. Il existe un risque de perte ou de vol simultané des appareils, surtout lorsqu'ils se trouvent au même endroit.
Récemment, de plus en plus de solutions basées sur des clés universelles sont apparues. Les clés peuvent être sauvegardées sur un appareil ou dans le cloud, la sécurité dépend d'une combinaison complexe de sécurité par mot de passe, d'organisations et d'hypothèses de matériel de confiance. Pour les utilisateurs ordinaires, cela représente un précieux gain de sécurité, mais cela ne suffit pas à protéger les économies de toute une vie des utilisateurs.
Heureusement, avec ZK-SNARK, nous avons une quatrième option : l'ID centralisé emballé dans ZK. Ces solutions incluent zk-email, Anon Aadhaar, Myna Wallet, etc. En gros, il est possible d'utiliser plusieurs formes d'ID centralisé d'entreprise ou de gouvernement ( et de les convertir en adresse Ethereum, les transactions ne pouvant être envoyées qu'en générant une preuve de possession de l'ID centralisé via ZK-SNARK.
Avec ce complément, nous avons maintenant un large choix, les ID centralisés emballés en ZK ont une "accessibilité pour les débutants" unique.
Pour cela, il est nécessaire de réaliser une interface utilisateur simplifiée et intégrée : elle doit permettre de spécifier uniquement "example@gmail.com" comme tuteur, générant automatiquement l'adresse zk-email Éther correspondante. Les utilisateurs avancés doivent pouvoir entrer l'email ) et éventuellement la valeur de sel de confidentialité ( dans des applications tierces open source, pour confirmer que l'adresse générée est correcte. Il en va de même pour d'autres types de tuteurs pris en charge.
Notez que le défi réel auquel zk-email est confronté aujourd'hui est la dépendance à la signature DKIM, en utilisant des clés qui sont renouvelées tous les quelques mois, ces clés n'étant pas signées par d'autres entités. Cela signifie que le zk-email actuel a une certaine exigence de confiance qui dépasse celle du fournisseur lui-même ; par exemple, l'utilisation de TLSNotary pour vérifier les clés mises à jour dans du matériel de confiance peut réduire ce problème, mais ce n'est pas idéal. Nous espérons que les fournisseurs de messagerie commenceront à signer directement les clés DKIM. Il est actuellement recommandé d'utiliser un gardien pour adopter zk-email, mais la plupart des gardiens ne sont pas conseillés : ne pas stocker de fonds dans zk-email signifie que les fonds ne pourront pas être utilisés en cas de défaillance.
![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 en application
Les nouveaux utilisateurs ne souhaitent en réalité pas saisir une grande quantité de gardiens lors de leur première inscription. Par conséquent, le portefeuille devrait offrir des options très simples. Une approche naturelle consiste à utiliser zk-email sur l'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 une option de 2 sur 3. À mesure que les utilisateurs deviennent plus expérimentés ou accumulent plus d'actifs, il devrait y avoir un moment donné pour les inciter à ajouter davantage de gardiens.
L'intégration des portefeuilles dans les applications est inévitable, car les applications tentant d'attirer des utilisateurs non cryptographiques ne souhaitent pas que les utilisateurs téléchargent deux nouvelles applications en même temps, ce qui créerait une expérience utilisateur confuse. Cependant, de nombreux utilisateurs de portefeuilles d'applications devraient pouvoir lier tous les portefeuilles ensemble, de sorte qu'ils n'aient qu'à se concentrer sur 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 dans l'application. Le client Farcaster Warpcast a déjà pris en charge cela.
![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-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 fait beaucoup de travail pour identifier les adresses fausses, le phishing, les escroqueries et d'autres menaces externes, et ils 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 tokens à toute nouvelle adresse, que l'on envoie 100 dollars ou 100 000 dollars. Il n'existe pas de remède miracle unique, mais une série d'améliorations continues visant différentes catégories de menaces. Il est très précieux de continuer à travailler sur cette question.
![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(
) vie privée
Il est maintenant temps de prendre la confidentialité d'Ethereum plus au sérieux. La technologie ZK-SNARK est déjà très avancée, ne s'appuyant pas sur des portes dérobées pour réduire les risques de réglementation. Les technologies de confidentialité comme les pools de confidentialité ### deviennent de plus en plus matures, et les infrastructures de niveau secondaire telles que les mempools Waku et ERC-4337 deviennent également plus stables. Cependant, pour le moment, effectuer des transferts privés sur Ethereum nécessite que les utilisateurs téléchargent et utilisent explicitement un "Portefeuille" de confidentialité. Cela introduit un grand inconvénient 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.
La mise en œuvre simple est la suivante : le Portefeuille peut stocker une partie des actifs de l'utilisateur en tant que "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 les utilisateurs participent. Les dépôts proviennent du 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 un moyen naturel de protéger le transfert d'actifs privés, mais aussi un moyen naturel de protéger l'identité privée. L'identité a eu lieu sur la chaîne : toute application utilisant une preuve d'identité contrôlée par un accès, comme Gitcoin Grants(, les chats contrôlés 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 vie privée. 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" permettant de voir toutes les preuves en même temps. Un écosystème natif où chaque utilisateur possède plusieurs comptes aide à atteindre cet objectif, tout comme les protocoles de preuve hors chaîne tels que EAS et Zupass.
Cela représente une vision pragmatique de la confidentialité d'Ethereum à moyen terme. Bien que certaines fonctionnalités puissent être introduites sur L1 et L2 pour rendre les transmissions protégées plus efficaces et fiables, cela est réalisable dès maintenant. Certains défenseurs de la confidentialité estiment que la seule chose acceptable est la confidentialité totale de tout : chiffrer l'ensemble de l'EVM. Cela pourrait être le résultat idéal à long terme, mais cela nécessite une réévaluation plus fondamentale du modèle de programmation, qui n'est pas encore à un niveau de maturité prêt à être déployé sur Ethereum. Nous avons effectivement besoin d'une confidentialité par défaut pour obtenir un ensemble d'anonymat suffisamment grand. Cependant, se concentrer d'abord sur les transferts entre comptes )i(, ainsi que sur l'identité et les cas d'utilisation associés à l'identité ) tels que les preuves privées ( est un premier pas pragmatique, plus facile à réaliser, et les portefeuilles peuvent déjà commencer à l'utiliser.
![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-ab5913a80a4549d9fec805c19442956b.webp(
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.
11 J'aime
Récompense
11
8
Reposter
Partager
Commentaire
0/400
GateUser-ccc36bc5
· 07-08 14:33
Peut-on résoudre le problème de lenteur du portefeuille ?
Voir l'originalRépondre0
OnChainArchaeologist
· 07-08 03:57
Devinez aveuglément, une autre bataille se profile : qui est le plus important, la vie privée ou l'expérience ?
Voir l'originalRépondre0
AirDropMissed
· 07-08 00:39
Le portefeuille cross-chain est juste un piège.
Voir l'originalRépondre0
BasementAlchemist
· 07-05 21:17
La confidentialité est la plus importante, allons-y!
Voir l'originalRépondre0
BlockchainTalker
· 07-05 21:17
en fait, c'est plutôt cool, pas mentir... la vie privée est le véritable MVP ici
Voir l'originalRépondre0
RektRecorder
· 07-05 21:17
Clé privée ne protégée, c'est comme courir à poil.
Voir l'originalRépondre0
PanicSeller
· 07-05 21:16
Emprunter de l'argent pour lever des fonds n'est pas aussi bon que de prendre des médicaments traditionnels.
Voir l'originalRépondre0
NFTArchaeologist
· 07-05 21:10
La chose la plus importante dans le cross-chain est la vitesse.
Vision idéale du portefeuille Ethereum : expérience cross-chain, protection de la vie privée et amélioration de la sécurité
Vision du portefeuille idéal Ethereum : une mise à niveau complète de l'expérience cross-chain à la protection de la vie privée.
Dans la pile d'infrastructure d'Ethereum, le portefeuille est une couche clé, mais souvent sous-estimée par les chercheurs et développeurs L1. Le portefeuille est la fenêtre par laquelle les utilisateurs communiquent avec le monde d'Ethereum, et les utilisateurs ne peuvent bénéficier des caractéristiques décentralisées, anti-censure, sécurisées et de confidentialité fournies par Ethereum et ses applications que lorsque le portefeuille possède les attributs appropriés.
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 des opinions sur les caractéristiques qu'un portefeuille Ethereum idéal devrait posséder. Ce n'est pas une liste complète, elle reflète l'inclination du cryptopunk de l'auteur, mettant l'accent sur la sécurité et la vie privée, ce qui peut ne pas être suffisamment complet en matière d'expérience utilisateur. Cependant, l'auteur estime qu'optimiser l'expérience utilisateur en déployant et en itérant simplement en fonction des retours d'expérience est plus efficace qu'une liste de souhaits, c'est pourquoi il considère que se concentrer sur les attributs de sécurité et de vie privée est le plus précieux.
expérience utilisateur des transactions cross-chain L2
Il existe maintenant une feuille de route de plus en plus détaillée pour améliorer l'expérience utilisateur cross-chain L2, comprenant des parties à court et à long terme. Ici, nous discutons de la partie à court terme : des idées qui peuvent théoriquement être mises en œuvre dès maintenant.
L'idée centrale est : (i) envoi cross-chain intégré L2, ainsi que (ii) adresses spécifiques à la chaîne et demandes de paiement. Le portefeuille devrait être en mesure de fournir à l'utilisateur une adresse conforme au style de projet ERC.
Lorsque l'utilisateur reçoit une adresse dans ce format, il doit pouvoir la coller dans le champ "Destinataire" du portefeuille et cliquer sur "Envoyer". Le portefeuille doit traiter automatiquement les données d'envoi :
Cela s'applique au scénario de "paiement par adresse de copier-coller". Dans le cas où l'application demande un dépôt, le processus idéal consiste à étendre l'API web3 et à permettre à l'application d'émettre des demandes de paiement spécifiques à la chaîne. Le portefeuille peut répondre à cette demande de la manière nécessaire. Pour garantir une bonne expérience utilisateur, il est également nécessaire de standardiser la demande getAvailableBalance, et le portefeuille doit sérieusement envisager sur quelles chaînes stocker par défaut les actifs des utilisateurs afin de maximiser la sécurité et la commodité 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 des scénarios de paiement en face à face ou en ligne, le bénéficiaire émettra un code QR ou un appel API web3, indiquant "Je souhaite obtenir Y unités de l'élément Z sur la chaîne X, avec l'ID de référence ou le rappel W", le portefeuille peut librement 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, le bénéficiaire est responsable de transférer les fonds vers son propre portefeuille.
Un autre sujet connexe est le paiement des gas. Si des actifs sont reçus sur un L2 sans ETH et qu'il est nécessaire d'envoyer une transaction, le portefeuille doit pouvoir utiliser automatiquement le protocole ( comme RIP-7755) pour payer les gas à partir d'une chaîne avec de l'ETH. Si le portefeuille prévoit que l'utilisateur effectuera plus de transactions sur le L2 à l'avenir, il doit également utiliser uniquement le DEX pour envoyer une quantité suffisante d'ETH, afin que les transactions futures puissent directement payer les gas ( car c'est moins cher ).
sécurité du compte
La conceptualisation des défis en matière de sécurité des comptes est la suivante : un bon portefeuille doit jouer un rôle dans deux domaines : (i) protéger les utilisateurs contre les attaques de hackers ou les comportements malveillants des développeurs de portefeuilles, (ii) protéger les utilisateurs contre les conséquences de leurs propres erreurs.
La solution préférée est la récupération sociale et le portefeuille multi-signatures, avec 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 effectuer des opérations de faible valeur et non financières. La plupart des tuteurs doivent exécuter (i) des opérations de haute valeur, comme envoyer la valeur totale du compte, ou (ii) modifier la clé principale ou tout tuteur. Si nécessaire, la clé principale peut être autorisée à exécuter des opérations de haute valeur par le biais d'un verrouillage temporel.
La conception de base peut être étendue. Les clés de session et les mécanismes d'autorisation tels que l'ERC-7715 peuvent aider à soutenir l'équilibre entre la commodité et la sécurité des différentes applications. Des architectures de gardiennage plus complexes, comme celles avec plusieurs durées de verrouillage temporel à différents seuils, peuvent aider à maximiser les chances de récupération réussie des comptes légitimes tout en minimisant le risque de vol.
Choix du gardien
Pour les utilisateurs de cryptomonnaie expérimentés, une option viable est d'utiliser les clés de leurs amis et de leur famille. Si chaque personne est amenée à fournir une nouvelle adresse, personne n'a besoin de connaître l'identité des autres, et la possibilité de collusion est très faible. Mais pour la plupart des nouveaux utilisateurs, cette option n'est pas disponible.
La deuxième option est le gardien institutionnel : un service qui ne signe les transactions que lorsque d'autres informations de confirmation sont reçues. Les gens ont longtemps essayé de créer ce type de service, mais jusqu'à présent, cela a été peu réussi.
La troisième option est plusieurs appareils personnels ( tels que des téléphones, des ordinateurs, et des portefeuilles matériels ). Cela est viable mais difficile à configurer et à gérer pour les débutants. Il existe un risque de perte ou de vol simultané des appareils, surtout lorsqu'ils se trouvent au même endroit.
Récemment, de plus en plus de solutions basées sur des clés universelles sont apparues. Les clés peuvent être sauvegardées sur un appareil ou dans le cloud, la sécurité dépend d'une combinaison complexe de sécurité par mot de passe, d'organisations et d'hypothèses de matériel de confiance. Pour les utilisateurs ordinaires, cela représente un précieux gain de sécurité, mais cela ne suffit pas à protéger les économies de toute une vie des utilisateurs.
Heureusement, avec ZK-SNARK, nous avons une quatrième option : l'ID centralisé emballé dans ZK. Ces solutions incluent zk-email, Anon Aadhaar, Myna Wallet, etc. En gros, il est possible d'utiliser plusieurs formes d'ID centralisé d'entreprise ou de gouvernement ( et de les convertir en adresse Ethereum, les transactions ne pouvant être envoyées qu'en générant une preuve de possession de l'ID centralisé via ZK-SNARK.
Avec ce complément, nous avons maintenant un large choix, les ID centralisés emballés en ZK ont une "accessibilité pour les débutants" unique.
Pour cela, il est nécessaire de réaliser une interface utilisateur simplifiée et intégrée : elle doit permettre de spécifier uniquement "example@gmail.com" comme tuteur, générant automatiquement l'adresse zk-email Éther correspondante. Les utilisateurs avancés doivent pouvoir entrer l'email ) et éventuellement la valeur de sel de confidentialité ( dans des applications tierces open source, pour confirmer que l'adresse générée est correcte. Il en va de même pour d'autres types de tuteurs pris en charge.
Notez que le défi réel auquel zk-email est confronté aujourd'hui est la dépendance à la signature DKIM, en utilisant des clés qui sont renouvelées tous les quelques mois, ces clés n'étant pas signées par d'autres entités. Cela signifie que le zk-email actuel a une certaine exigence de confiance qui dépasse celle du fournisseur lui-même ; par exemple, l'utilisation de TLSNotary pour vérifier les clés mises à jour dans du matériel de confiance peut réduire ce problème, mais ce n'est pas idéal. Nous espérons que les fournisseurs de messagerie commenceront à signer directement les clés DKIM. Il est actuellement recommandé d'utiliser un gardien pour adopter zk-email, mais la plupart des gardiens ne sont pas conseillés : ne pas stocker de fonds dans zk-email signifie que les fonds ne pourront pas être utilisés en cas de défaillance.
![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 en application
Les nouveaux utilisateurs ne souhaitent en réalité pas saisir une grande quantité de gardiens lors de leur première inscription. Par conséquent, le portefeuille devrait offrir des options très simples. Une approche naturelle consiste à utiliser zk-email sur l'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 une option de 2 sur 3. À mesure que les utilisateurs deviennent plus expérimentés ou accumulent plus d'actifs, il devrait y avoir un moment donné pour les inciter à ajouter davantage de gardiens.
L'intégration des portefeuilles dans les applications est inévitable, car les applications tentant d'attirer des utilisateurs non cryptographiques ne souhaitent pas que les utilisateurs téléchargent deux nouvelles applications en même temps, ce qui créerait une expérience utilisateur confuse. Cependant, de nombreux utilisateurs de portefeuilles d'applications devraient pouvoir lier tous les portefeuilles ensemble, de sorte qu'ils n'aient qu'à se concentrer sur 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 dans l'application. Le client Farcaster Warpcast a déjà pris en charge cela.
![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-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 fait beaucoup de travail pour identifier les adresses fausses, le phishing, les escroqueries et d'autres menaces externes, et ils 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 tokens à toute nouvelle adresse, que l'on envoie 100 dollars ou 100 000 dollars. Il n'existe pas de remède miracle unique, mais une série d'améliorations continues visant différentes catégories de menaces. Il est très précieux de continuer à travailler sur cette question.
![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(
) vie privée
Il est maintenant temps de prendre la confidentialité d'Ethereum plus au sérieux. La technologie ZK-SNARK est déjà très avancée, ne s'appuyant pas sur des portes dérobées pour réduire les risques de réglementation. Les technologies de confidentialité comme les pools de confidentialité ### deviennent de plus en plus matures, et les infrastructures de niveau secondaire telles que les mempools Waku et ERC-4337 deviennent également plus stables. Cependant, pour le moment, effectuer des transferts privés sur Ethereum nécessite que les utilisateurs téléchargent et utilisent explicitement un "Portefeuille" de confidentialité. Cela introduit un grand inconvénient 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.
La mise en œuvre simple est la suivante : le Portefeuille peut stocker une partie des actifs de l'utilisateur en tant que "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 les utilisateurs participent. Les dépôts proviennent du 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 un moyen naturel de protéger le transfert d'actifs privés, mais aussi un moyen naturel de protéger l'identité privée. L'identité a eu lieu sur la chaîne : toute application utilisant une preuve d'identité contrôlée par un accès, comme Gitcoin Grants(, les chats contrôlés 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 vie privée. 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" permettant de voir toutes les preuves en même temps. Un écosystème natif où chaque utilisateur possède plusieurs comptes aide à atteindre cet objectif, tout comme les protocoles de preuve hors chaîne tels que EAS et Zupass.
Cela représente une vision pragmatique de la confidentialité d'Ethereum à moyen terme. Bien que certaines fonctionnalités puissent être introduites sur L1 et L2 pour rendre les transmissions protégées plus efficaces et fiables, cela est réalisable dès maintenant. Certains défenseurs de la confidentialité estiment que la seule chose acceptable est la confidentialité totale de tout : chiffrer l'ensemble de l'EVM. Cela pourrait être le résultat idéal à long terme, mais cela nécessite une réévaluation plus fondamentale du modèle de programmation, qui n'est pas encore à un niveau de maturité prêt à être déployé sur Ethereum. Nous avons effectivement besoin d'une confidentialité par défaut pour obtenir un ensemble d'anonymat suffisamment grand. Cependant, se concentrer d'abord sur les transferts entre comptes )i(, ainsi que sur l'identité et les cas d'utilisation associés à l'identité ) tels que les preuves privées ( est un premier pas pragmatique, plus facile à réaliser, et les portefeuilles peuvent déjà commencer à l'utiliser.
![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-ab5913a80a4549d9fec805c19442956b.webp(
) Éther