Vision du Portefeuille Idéal : mise à niveau complète de l'expérience cross-chain à la protection de la vie privée
Une couche clé dans la pile d'infrastructure d'Ethereum est le Portefeuille, mais les chercheurs et développeurs principaux de L1 sous-estiment souvent son importance. Le Portefeuille est la fenêtre par laquelle les utilisateurs interagissent avec le monde d'Ethereum, et les utilisateurs ne peuvent réellement bénéficier des caractéristiques décentralisées, anti-censure, sécurisées et de confidentialité offertes par Ethereum et ses applications que si le Portefeuille lui-même possède les attributs correspondants.
Récemment, le portefeuille Ethereum a réalisé des progrès significatifs en matière d'expérience utilisateur, de sécurité et de fonctionnalités. Cet article vise à partager mes réflexions sur les caractéristiques qu'un portefeuille Ethereum idéal devrait avoir. Ce n'est pas une liste complète, elle reflète mes tendances de cyberpunk, mettant l'accent sur la sécurité et la confidentialité, ce qui pourrait manquer dans l'expérience utilisateur. Cependant, je pense qu'il est plus efficace d'optimiser l'expérience utilisateur en déployant et en itérant simplement en fonction des retours plutôt que de se concentrer sur une liste de souhaits, donc je considère que se concentrer sur les attributs de sécurité et de confidentialité est le plus précieux.
Expérience utilisateur des transactions cross-chain L2
Il existe actuellement une feuille de route de plus en plus complète pour améliorer l'expérience utilisateur cross-chain L2, comprenant des aspects à court et à long terme. Ici, nous discutons principalement 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 intégré cross-chain L2, ainsi que (ii) adresse spécifique à la chaîne et demande de paiement. Votre Portefeuille devrait être en mesure de vous fournir une adresse conforme au style de projet ERC.
Lorsque quelqu'un ( ou certaines applications ) vous fournissent une adresse dans ce format, vous devriez être en mesure de la coller dans le champ "destinataire" du portefeuille, puis de cliquer sur "envoyer". Le portefeuille devrait traiter automatiquement les données d'envoi de la manière la plus appropriée:
Si vous avez déjà suffisamment de jetons du type requis sur la chaîne cible, envoyez directement les jetons.
Si vous avez le type de jeton requis ( sur une autre chaîne ou plusieurs autres chaînes ), utiliser des protocoles tels que l'ERC-7683 ( est en réalité un DEX cross-chain ) pour envoyer des jetons.
Si vous avez différents types de jetons sur la même chaîne ou sur d'autres chaînes, utilisez une bourse décentralisée pour les convertir en monnaie du bon type sur la bonne chaîne et les envoyer. Cela devrait nécessiter le consentement explicite de l'utilisateur : l'utilisateur verra combien de frais il a payés et combien de frais le destinataire a reçus.
Le contenu ci-dessus s'applique au cas d'utilisation "Vous copiez et collez l'adresse ( ou ENS, comme vitalik.eth @ optimism.eth) quelqu'un vous paie". Si le dapp demande un dépôt, alors le processus idéal est d'étendre l'API web3 et de permettre au dapp d'émettre des demandes de paiement spécifiques à la chaîne. Ensuite, votre Portefeuille sera en mesure de répondre à cette demande de la manière nécessaire. 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 commodité des transferts.
Les demandes de paiement spécifiques à la chaîne peuvent également être intégrées dans un code QR, et le portefeuille mobile peut scanner le code QR. Dans les scénarios de paiement en personne ( ou en ligne ), le destinataire émettra un code QR ou un appel API web3, indiquant "Je souhaite X unités du jeton YZ sur la chaîne, avec l'ID de référence ou le rappel W", le portefeuille pourra satisfaire cette demande librement de toutes les manières. Une autre option est le protocole de lien de réclamation, où le portefeuille de l'utilisateur génère un code QR ou une URL contenant une autorisation de réclamation pour obtenir un certain montant de fonds de leur contrat sur la chaîne, le travail du destinataire est de déterminer comment transférer ces fonds vers leur propre portefeuille.
Un autre sujet pertinent est le paiement des gas. Si vous recevez des actifs sur un L2 sans avoir d'ETH, et que vous devez envoyer une transaction sur ce L2, le portefeuille devrait être capable d'utiliser automatiquement le protocole (, par exemple RIP-7755), pour payer le gas sur la chaîne là où vous avez de l'ETH. Si le portefeuille souhaite que vous effectuiez plus de transactions sur le L2 à l'avenir, il devrait également utiliser uniquement des DEX pour envoyer, par exemple, des ETH d'une valeur de plusieurs millions de gas, afin que les transactions futures puissent dépenser directement le gas ( là-bas, car c'est moins cher ).
Sécurité du compte
Une façon de conceptualiser le défi de la sécurité des comptes est qu'un bon Portefeuille devrait jouer un rôle à la fois dans deux domaines : (i) protéger les utilisateurs contre les attaques de pirates ou malveillantes des développeurs de Portefeuille, et (ii) protéger les utilisateurs contre les conséquences de leurs propres erreurs.
Ma solution préférée à ce sujet, depuis plus de dix ans, a été la récupération sociale et les Portefeuilles multi-signatures, avec un contrôle d'accès par niveau. Les comptes des utilisateurs ont deux niveaux de clés : une clé principale et N tuteurs ( par exemple N = 5). La clé principale est capable d'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, telles que l'envoi de la totalité de la valeur dans le compte, ou (ii) modifier 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 verrou temporel.
Ci-dessus est la conception de base, qui 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é de différentes applications. Des architectures de gardien plus complexes, telles que plusieurs durées de verrouillage temporel sous 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.
Qui ou quoi devrait être le tuteur ?
Pour les utilisateurs expérimentés de la communauté des crypto-monnaies, une option viable est la clé de vos amis et de votre famille. Si vous demandez à chacun de fournir une nouvelle adresse, alors personne n'a besoin de savoir qui ils sont - en fait, vos gardiens n'ont même pas besoin de savoir qui ils sont les uns par rapport aux autres. S'ils ne vous soufflent pas, il est peu probable qu'ils soient de mèche. Cependant, pour la plupart des nouveaux utilisateurs, cette option n'est pas disponible.
La deuxième option est un gardien institutionnel : des entreprises qui fournissent des services de signature de transactions uniquement après avoir reçu d'autres informations de confirmation à votre demande : par exemple, un code de confirmation, ou un appel vidéo pour les utilisateurs à valeur élevée. Les gens ont longtemps essayé de créer cela, par exemple, j'ai présenté CryptoCorp en 2013. Cependant, jusqu'à présent, ces entreprises n'ont pas encore connu beaucoup de succès.
La troisième option est plusieurs appareils personnels ( tels que des téléphones, des ordinateurs de bureau et des Portefeuilles matériels ). Cela peut fonctionner, mais il est également difficile à configurer et à gérer pour les utilisateurs sans expérience. Il existe également un risque de perte ou de vol simultané des appareils, en particulier lorsqu'ils sont situés au même endroit.
Récemment, nous avons commencé à voir davantage de solutions basées sur la clé universelle. La clé ne peut être sauvegardée que sur votre appareil, ce qui en fait une solution personnelle, mais elle peut également être sauvegardée dans le cloud, rendant sa 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é, la clé représente un gain de sécurité précieux pour l'utilisateur moyen, mais s'appuyer uniquement sur elle n'est pas suffisant pour protéger les économies de toute une vie de l'utilisateur.
Heureusement, grâce à ZK-SNARK, nous avons une quatrième option : l'ID centralisé enveloppé dans ZK. Ce type inclut zk-email, Anon Aadhaar, Myna Wallet, etc. En gros, vous pouvez adopter plusieurs formes de ( ID centralisé d'entreprise ou de gouvernement ), et les convertir en adresse Ethereum, vous ne pouvez envoyer des transactions que par la génération d'une preuve de possession de l'ID centralisé via ZK-SNARK.
Avec cet ajout, nous avons maintenant un large éventail de choix, et l'ID centralisé emballé en ZK possède une "facilité d'utilisation pour les débutants" unique.
Pour cela, il doit être réalisé via une interface utilisateur simplifiée et intégrée : vous devriez pouvoir spécifier simplement que vous souhaitez "example@gmail.com" comme gardien, et cela devrait automatiquement générer l'adresse zk-email Ethereum correspondante sous le capot. Les utilisateurs avancés devraient être en mesure d'entrer leur e-mail ( ainsi que les valeurs de sel de confidentialité qui pourraient être stockées dans cet e-mail ) dans des applications tierces open source et de confirmer que l'adresse générée est correcte. Cela devrait également s'appliquer à tout autre type de gardien pris en charge.
Veuillez noter qu'aujourd'hui, zk-email fait face à un défi pratique : il dépend de la signature DKIM, qui utilise des clés qui sont remplacées tous les quelques mois, et ces clés elles-mêmes ne sont signées par aucune autre entité. Cela signifie qu'aujourd'hui, zk-email a un certain degré d'exigence de confiance qui dépasse celle du fournisseur lui-même ; si zk-email utilise TLSNotary sur du matériel de confiance pour vérifier les clés mises à jour, cela pourrait réduire cette situation, mais ce n'est pas idéal. J'espère que les fournisseurs de messagerie commenceront à signer directement leurs clés DKIM. Aujourd'hui, je conseillerais à un gardien d'utiliser zk-email, mais je ne recommande pas à la plupart des gardiens de le faire : ne stockez pas de fonds dans zk-email, car une défaillance signifie que vous ne pouvez pas utiliser l'ensemble de vos fonds.
Nouveaux utilisateurs et Portefeuille intégré
Les nouveaux utilisateurs ne souhaitent en réalité pas entrer 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, la clé stockée localement sur l'appareil de l'utilisateur ( pourrait être la clé universelle ) et la clé de sauvegarde détenue par le fournisseur, pour effectuer un choix 2-of-3. À mesure que les utilisateurs deviennent plus expérimentés ou accumulent plus d'actifs, il devrait leur être suggéré à un moment donné d'ajouter plus de gardiens.
L'intégration du Portefeuille dans les applications est inévitable, car les applications qui tentent d'attirer des utilisateurs non-crypo ne souhaitent pas que les utilisateurs téléchargent simultanément deux nouvelles applications, ( l'application elle-même, ainsi qu'un Portefeuille Ethereum, ) ce qui entraîne une expérience utilisateur déroutante. Cependant, de nombreux utilisateurs de Portefeuille d'applications devraient être en mesure de relier tous leurs Portefeuilles ensemble, afin qu'ils n'aient à se soucier que d'un "problème de contrôle d'accès". La méthode la plus simple consiste à adopter un schéma hiérarchique, où il y a un processus de "lien" rapide qui permet aux utilisateurs de définir leur Portefeuille principal comme le gardien de tous les Portefeuilles intégrés dans l'application.
Protéger les utilisateurs contre les escroqueries et autres menaces externes
En plus de la sécurité des comptes, les portefeuilles d'aujourd'hui font beaucoup de travail pour identifier les fausses adresses, le phishing, les escroqueries et d'autres menaces externes, et s'efforcent de protéger les utilisateurs contre ces menaces. Pendant ce temps, de nombreuses mesures restent assez rudimentaires : par exemple, demander de cliquer pour envoyer de l'ETH ou d'autres jetons à toute nouvelle adresse, que vous envoyiez 100 dollars ou 100 000 dollars. Ici, il n'existe pas d'unique remède miracle. C'est une série de corrections et d'améliorations lentes et continues visant différentes catégories de menaces. Cependant, continuer à s'efforcer de s'améliorer ici a beaucoup de valeur.
Confidentialité
Il est temps de commencer à prendre l'Ethereum plus au sérieux.
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.
10 J'aime
Récompense
10
8
Reposter
Partager
Commentaire
0/400
HalfIsEmpty
· 07-20 04:01
La première fois que j'entends parler de l'importance du portefeuille.
Voir l'originalRépondre0
Layer2Arbitrageur
· 07-19 12:59
mdr imagine appeler ça "vie privée" quand tes données de transaction fuient comme une passoire
Voir l'originalRépondre0
BearMarketMonk
· 07-18 17:20
Chaque Portefeuille vante sa sécurité. Apprendre à bien gérer sa Clé privée est la véritable sécurité.
Voir l'originalRépondre0
LightningClicker
· 07-17 18:50
Le portefeuille décentralisé n'est-il pas trop dangereux ?
Voir l'originalRépondre0
MysteriousZhang
· 07-17 18:47
cross-chain sécurité yyds
Voir l'originalRépondre0
DataPickledFish
· 07-17 18:43
Portefeuille, sauvez les personnes atteintes de cécité spatiale !
Voir l'originalRépondre0
DefiPlaybook
· 07-17 18:38
Franchement, la sécurité de ces portefeuilles n'est pas encore au point, soyez prudents lorsque vous entrez dans une position.
Vision du portefeuille idéal : mise à niveau complète du cross-chain, de la sécurité et de la confidentialité
Vision du Portefeuille Idéal : mise à niveau complète de l'expérience cross-chain à la protection de la vie privée
Une couche clé dans la pile d'infrastructure d'Ethereum est le Portefeuille, mais les chercheurs et développeurs principaux de L1 sous-estiment souvent son importance. Le Portefeuille est la fenêtre par laquelle les utilisateurs interagissent avec le monde d'Ethereum, et les utilisateurs ne peuvent réellement bénéficier des caractéristiques décentralisées, anti-censure, sécurisées et de confidentialité offertes par Ethereum et ses applications que si le Portefeuille lui-même possède les attributs correspondants.
Récemment, le portefeuille Ethereum a réalisé des progrès significatifs en matière d'expérience utilisateur, de sécurité et de fonctionnalités. Cet article vise à partager mes réflexions sur les caractéristiques qu'un portefeuille Ethereum idéal devrait avoir. Ce n'est pas une liste complète, elle reflète mes tendances de cyberpunk, mettant l'accent sur la sécurité et la confidentialité, ce qui pourrait manquer dans l'expérience utilisateur. Cependant, je pense qu'il est plus efficace d'optimiser l'expérience utilisateur en déployant et en itérant simplement en fonction des retours plutôt que de se concentrer sur une liste de souhaits, donc je considère que se concentrer sur les attributs de sécurité et de confidentialité est le plus précieux.
Expérience utilisateur des transactions cross-chain L2
Il existe actuellement une feuille de route de plus en plus complète pour améliorer l'expérience utilisateur cross-chain L2, comprenant des aspects à court et à long terme. Ici, nous discutons principalement 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 intégré cross-chain L2, ainsi que (ii) adresse spécifique à la chaîne et demande de paiement. Votre Portefeuille devrait être en mesure de vous fournir une adresse conforme au style de projet ERC.
Lorsque quelqu'un ( ou certaines applications ) vous fournissent une adresse dans ce format, vous devriez être en mesure de la coller dans le champ "destinataire" du portefeuille, puis de cliquer sur "envoyer". Le portefeuille devrait traiter automatiquement les données d'envoi de la manière la plus appropriée:
Le contenu ci-dessus s'applique au cas d'utilisation "Vous copiez et collez l'adresse ( ou ENS, comme vitalik.eth @ optimism.eth) quelqu'un vous paie". Si le dapp demande un dépôt, alors le processus idéal est d'étendre l'API web3 et de permettre au dapp d'émettre des demandes de paiement spécifiques à la chaîne. Ensuite, votre Portefeuille sera en mesure de répondre à cette demande de la manière nécessaire. 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 commodité des transferts.
Les demandes de paiement spécifiques à la chaîne peuvent également être intégrées dans un code QR, et le portefeuille mobile peut scanner le code QR. Dans les scénarios de paiement en personne ( ou en ligne ), le destinataire émettra un code QR ou un appel API web3, indiquant "Je souhaite X unités du jeton YZ sur la chaîne, avec l'ID de référence ou le rappel W", le portefeuille pourra satisfaire cette demande librement de toutes les manières. Une autre option est le protocole de lien de réclamation, où le portefeuille de l'utilisateur génère un code QR ou une URL contenant une autorisation de réclamation pour obtenir un certain montant de fonds de leur contrat sur la chaîne, le travail du destinataire est de déterminer comment transférer ces fonds vers leur propre portefeuille.
Un autre sujet pertinent est le paiement des gas. Si vous recevez des actifs sur un L2 sans avoir d'ETH, et que vous devez envoyer une transaction sur ce L2, le portefeuille devrait être capable d'utiliser automatiquement le protocole (, par exemple RIP-7755), pour payer le gas sur la chaîne là où vous avez de l'ETH. Si le portefeuille souhaite que vous effectuiez plus de transactions sur le L2 à l'avenir, il devrait également utiliser uniquement des DEX pour envoyer, par exemple, des ETH d'une valeur de plusieurs millions de gas, afin que les transactions futures puissent dépenser directement le gas ( là-bas, car c'est moins cher ).
Sécurité du compte
Une façon de conceptualiser le défi de la sécurité des comptes est qu'un bon Portefeuille devrait jouer un rôle à la fois dans deux domaines : (i) protéger les utilisateurs contre les attaques de pirates ou malveillantes des développeurs de Portefeuille, et (ii) protéger les utilisateurs contre les conséquences de leurs propres erreurs.
Ma solution préférée à ce sujet, depuis plus de dix ans, a été la récupération sociale et les Portefeuilles multi-signatures, avec un contrôle d'accès par niveau. Les comptes des utilisateurs ont deux niveaux de clés : une clé principale et N tuteurs ( par exemple N = 5). La clé principale est capable d'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, telles que l'envoi de la totalité de la valeur dans le compte, ou (ii) modifier 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 verrou temporel.
Ci-dessus est la conception de base, qui 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é de différentes applications. Des architectures de gardien plus complexes, telles que plusieurs durées de verrouillage temporel sous 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.
Qui ou quoi devrait être le tuteur ?
Pour les utilisateurs expérimentés de la communauté des crypto-monnaies, une option viable est la clé de vos amis et de votre famille. Si vous demandez à chacun de fournir une nouvelle adresse, alors personne n'a besoin de savoir qui ils sont - en fait, vos gardiens n'ont même pas besoin de savoir qui ils sont les uns par rapport aux autres. S'ils ne vous soufflent pas, il est peu probable qu'ils soient de mèche. Cependant, pour la plupart des nouveaux utilisateurs, cette option n'est pas disponible.
La deuxième option est un gardien institutionnel : des entreprises qui fournissent des services de signature de transactions uniquement après avoir reçu d'autres informations de confirmation à votre demande : par exemple, un code de confirmation, ou un appel vidéo pour les utilisateurs à valeur élevée. Les gens ont longtemps essayé de créer cela, par exemple, j'ai présenté CryptoCorp en 2013. Cependant, jusqu'à présent, ces entreprises n'ont pas encore connu beaucoup de succès.
La troisième option est plusieurs appareils personnels ( tels que des téléphones, des ordinateurs de bureau et des Portefeuilles matériels ). Cela peut fonctionner, mais il est également difficile à configurer et à gérer pour les utilisateurs sans expérience. Il existe également un risque de perte ou de vol simultané des appareils, en particulier lorsqu'ils sont situés au même endroit.
Récemment, nous avons commencé à voir davantage de solutions basées sur la clé universelle. La clé ne peut être sauvegardée que sur votre appareil, ce qui en fait une solution personnelle, mais elle peut également être sauvegardée dans le cloud, rendant sa 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é, la clé représente un gain de sécurité précieux pour l'utilisateur moyen, mais s'appuyer uniquement sur elle n'est pas suffisant pour protéger les économies de toute une vie de l'utilisateur.
Heureusement, grâce à ZK-SNARK, nous avons une quatrième option : l'ID centralisé enveloppé dans ZK. Ce type inclut zk-email, Anon Aadhaar, Myna Wallet, etc. En gros, vous pouvez adopter plusieurs formes de ( ID centralisé d'entreprise ou de gouvernement ), et les convertir en adresse Ethereum, vous ne pouvez envoyer des transactions que par la génération d'une preuve de possession de l'ID centralisé via ZK-SNARK.
Avec cet ajout, nous avons maintenant un large éventail de choix, et l'ID centralisé emballé en ZK possède une "facilité d'utilisation pour les débutants" unique.
Pour cela, il doit être réalisé via une interface utilisateur simplifiée et intégrée : vous devriez pouvoir spécifier simplement que vous souhaitez "example@gmail.com" comme gardien, et cela devrait automatiquement générer l'adresse zk-email Ethereum correspondante sous le capot. Les utilisateurs avancés devraient être en mesure d'entrer leur e-mail ( ainsi que les valeurs de sel de confidentialité qui pourraient être stockées dans cet e-mail ) dans des applications tierces open source et de confirmer que l'adresse générée est correcte. Cela devrait également s'appliquer à tout autre type de gardien pris en charge.
Veuillez noter qu'aujourd'hui, zk-email fait face à un défi pratique : il dépend de la signature DKIM, qui utilise des clés qui sont remplacées tous les quelques mois, et ces clés elles-mêmes ne sont signées par aucune autre entité. Cela signifie qu'aujourd'hui, zk-email a un certain degré d'exigence de confiance qui dépasse celle du fournisseur lui-même ; si zk-email utilise TLSNotary sur du matériel de confiance pour vérifier les clés mises à jour, cela pourrait réduire cette situation, mais ce n'est pas idéal. J'espère que les fournisseurs de messagerie commenceront à signer directement leurs clés DKIM. Aujourd'hui, je conseillerais à un gardien d'utiliser zk-email, mais je ne recommande pas à la plupart des gardiens de le faire : ne stockez pas de fonds dans zk-email, car une défaillance signifie que vous ne pouvez pas utiliser l'ensemble de vos fonds.
Nouveaux utilisateurs et Portefeuille intégré
Les nouveaux utilisateurs ne souhaitent en réalité pas entrer 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, la clé stockée localement sur l'appareil de l'utilisateur ( pourrait être la clé universelle ) et la clé de sauvegarde détenue par le fournisseur, pour effectuer un choix 2-of-3. À mesure que les utilisateurs deviennent plus expérimentés ou accumulent plus d'actifs, il devrait leur être suggéré à un moment donné d'ajouter plus de gardiens.
L'intégration du Portefeuille dans les applications est inévitable, car les applications qui tentent d'attirer des utilisateurs non-crypo ne souhaitent pas que les utilisateurs téléchargent simultanément deux nouvelles applications, ( l'application elle-même, ainsi qu'un Portefeuille Ethereum, ) ce qui entraîne une expérience utilisateur déroutante. Cependant, de nombreux utilisateurs de Portefeuille d'applications devraient être en mesure de relier tous leurs Portefeuilles ensemble, afin qu'ils n'aient à se soucier que d'un "problème de contrôle d'accès". La méthode la plus simple consiste à adopter un schéma hiérarchique, où il y a un processus de "lien" rapide qui permet aux utilisateurs de définir leur Portefeuille principal comme le gardien de tous les Portefeuilles intégrés dans l'application.
Protéger les utilisateurs contre les escroqueries et autres menaces externes
En plus de la sécurité des comptes, les portefeuilles d'aujourd'hui font beaucoup de travail pour identifier les fausses adresses, le phishing, les escroqueries et d'autres menaces externes, et s'efforcent de protéger les utilisateurs contre ces menaces. Pendant ce temps, de nombreuses mesures restent assez rudimentaires : par exemple, demander de cliquer pour envoyer de l'ETH ou d'autres jetons à toute nouvelle adresse, que vous envoyiez 100 dollars ou 100 000 dollars. Ici, il n'existe pas d'unique remède miracle. C'est une série de corrections et d'améliorations lentes et continues visant différentes catégories de menaces. Cependant, continuer à s'efforcer de s'améliorer ici a beaucoup de valeur.
Confidentialité
Il est temps de commencer à prendre l'Ethereum plus au sérieux.