Vision idéale du portefeuille Ethereum : une mise à niveau complète de l'expérience cross-chain à la protection de la vie privée
Une couche clé de la pile d'infrastructure d'Ethereum est le Portefeuille, mais il est souvent sous-estimé par les chercheurs et développeurs principaux de L1. Le Portefeuille est la fenêtre entre les utilisateurs et le monde d'Ethereum, et les utilisateurs ne peuvent bénéficier d'aucune des propriétés décentralisées, résistantes à la censure, sécurisées, privées ou autres offertes par Ethereum et ses applications, à condition que le Portefeuille lui-même possède également ces propriétés.
Récemment, le portefeuille Ethereum a fait de grands progrès en matière d'expérience utilisateur, de sécurité et de fonctionnalités. Le but de cet article est de donner un aperçu des caractéristiques qu'un portefeuille Ethereum idéal devrait posséder. Ce n'est pas une liste exhaustive ; elle reflète une tendance crypto-anarchiste, axée sur la sécurité et la vie privée, et il est presque certain qu'elle est incomplète en termes d'expérience utilisateur. Cependant, une liste de souhaits n'est pas aussi efficace pour optimiser l'expérience utilisateur que le déploiement et l'itération simples basés sur les retours d'expérience, c'est pourquoi se concentrer sur les attributs de sécurité et de vie privée est la chose la plus précieuse.
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, qui comprend des volets à court et à long terme. Nous allons parler de la partie à court terme : des idées qui peuvent encore être mises en œuvre théoriquement aujourd'hui.
La pensée centrale est (i) l'envoi intégré cross-chain L2, ainsi que (ii) une adresse spécifique à la chaîne et des demandes de paiement. Le portefeuille devrait être capable de fournir à l'utilisateur une adresse, suivant le style des projets ERC pertinents.
Lorsque quelqu'un ( ou certaines applications ) fournissent ce format d'adresse à l'utilisateur, l'utilisateur devrait être en mesure de le coller dans le champ "destinataire" du portefeuille, puis de cliquer sur "Envoyer". Le portefeuille devrait traiter automatiquement les données envoyées de la manière la plus efficace possible :
Si l'utilisateur a déjà suffisamment de jetons du type requis sur la chaîne cible, veuillez envoyer directement les jetons.
Si un utilisateur possède le type de jeton requis sur une autre chaîne ( ou plusieurs autres chaînes ), utiliser le protocole associé ( est en réalité un DEX cross-chain ) pour envoyer des jetons.
Si un utilisateur possède différents types de jetons sur la même chaîne ou sur d'autres chaînes, il doit utiliser un échange décentralisé pour les convertir en la monnaie correcte du bon type sur la bonne chaîne et les envoyer. Cela devrait nécessiter l'autorisation 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 "l'utilisateur copie et colle l'adresse ( ou ENS, par exemple, vitalik.eth @ optimism.eth) quelqu'un effectue un paiement à l'utilisateur". Si le dapp demande un dépôt, 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, le portefeuille sera en mesure de satisfaire cette demande de la manière requise. Pour garantir une bonne expérience utilisateur, il est également nécessaire de normaliser les demandes getAvailableBalance, et le portefeuille doit prendre en compte sérieusement sur quelles chaînes les actifs des utilisateurs seront stockés par défaut, 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, que le portefeuille mobile peut scanner. 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 X unités du jeton YZ sur la chaîne, avec un ID de référence ou un 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, dans lequel 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 de leur contrat sur la chaîne, le travail du destinataire est de comprendre comment transférer ces fonds vers leur propre portefeuille.
Un autre sujet connexe est le paiement des frais de gaz. Si un utilisateur reçoit des actifs sur un L2 sans avoir d'Éther, et qu'il doit envoyer une transaction sur ce L2, le portefeuille devrait être capable d'utiliser automatiquement le protocole pour payer les frais de gaz sur la chaîne là où les utilisateurs ont de l'Éther. Si le portefeuille souhaite que les utilisateurs effectuent plus de transactions à l'avenir sur le L2, il devrait également utiliser uniquement un DEX pour envoyer, par exemple, des ETH d'une valeur de plusieurs millions de frais de gaz, afin que les transactions futures puissent directement y utiliser les frais de gaz ( car cela 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 sur deux fronts : (i) protéger les utilisateurs des attaques malveillantes ou des piratages de la part des développeurs de portefeuilles, et (ii) protéger les utilisateurs des conséquences de leurs propres erreurs.
La solution préférée à cet égard, depuis plus de dix ans, a été la récupération sociale et le portefeuille multi-signatures, avec un contrôle d'accès hiérarchique. Les comptes des utilisateurs ont deux niveaux de clés : une clé principale et N gardiens ( par exemple N = 5). La clé principale est capable d'exécuter des opérations de faible valeur et non financières. La plupart des gardiens doivent exécuter (i) des opérations de haute valeur, comme envoyer toute la valeur dans le compte, ou (ii) changer la clé principale ou tout gardien. Si nécessaire, il peut être permis à la clé principale d'exécuter des opérations de haute valeur via un verrouillage temporel.
Ce qui précède est la conception de base, qui peut être étendue. Les clés de session et les mécanismes d'autorisation associés peuvent aider à soutenir l'équilibre entre la commodité et la sécurité des différentes applications. Des architectures de gardien plus complexes, par exemple 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.
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é des amis et de la famille de l'utilisateur. Si l'utilisateur demande à chacun de lui fournir une nouvelle adresse, alors personne n'a besoin de savoir qui ils sont - en fait, les gardiens de l'utilisateur n'ont même pas besoin de savoir qui ils sont. S'ils ne préviennent pas l'utilisateur, la probabilité qu'ils complotent ensemble 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 des services de signature de transactions uniquement à la réception d'autres informations de confirmation sur demande de l'utilisateur : par exemple, un code de confirmation, ou un appel vidéo pour les utilisateurs de grande valeur. Les gens ont longtemps essayé de créer cela, par exemple, l'introduction de 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, des portefeuilles matériels ). Cela peut fonctionner, mais il peut être é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, surtout lorsqu'ils se trouvent 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 l'appareil de l'utilisateur, en faisant une solution de dispositif personnel, mais elle peut également être sauvegardée dans le cloud, ce qui rend sa sécurité dépendante d'hypothèses complexes de sécurité par mot de passe hybride, d'institutions et de matériel de confiance. En réalité, la clé représente un gain de sécurité précieux pour l'utilisateur moyen, mais elle ne suffit pas à elle seule à protéger les économies de toute une vie de l'utilisateur.
Heureusement, avec ZK-SNARK, nous avons une quatrième option : l'identité centralisée enveloppée dans ZK. Ce type comprend zk-email, Anon Aadhaar, Myna Wallet, etc. Fondamentalement, les utilisateurs peuvent adopter diverses formes ( d'identité centralisée d'entreprise ou de gouvernement ) et les convertir en adresse Ethereum, les utilisateurs ne peuvent envoyer des transactions qu'en générant une preuve de possession d'une identité centralisée grâce à ZK-SNARK.
Avec ce complément, nous avons maintenant un large éventail de choix, et l'ID centralisé emballé en ZK possède une "convivialité pour les débutants" unique.
Pour ce faire, il doit être réalisé par une interface utilisateur simplifiée et intégrée : les utilisateurs devraient pouvoir spécifier uniquement "example@gmail.com" en tant que 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é éventuellement stockées dans cet e-mail ) dans une application tierce open source, et de confirmer que l'adresse générée est correcte. Cela devrait également être le cas pour tout autre type de gardien pris en charge.
Veuillez noter qu'un défi réel auquel zk-email est confronté aujourd'hui est qu'il repose sur la signature DKIM, qui utilise des clés renouvelées tous les quelques mois, et ces clés elles-mêmes ne sont pas signées par d'autres entités. Cela signifie qu'aujourd'hui, zk-email a un certain niveau d'exigence de confiance au-delà de celui du fournisseur lui-même ; si zk-email utilise TLSNotary pour vérifier les clés mises à jour dans du matériel de confiance, cela pourrait réduire cette situation, mais ce n'est pas idéal. Il est à espérer que les fournisseurs de messagerie commenceront à signer directement leurs clés DKIM. Aujourd'hui, il est conseillé à un tuteur d'utiliser zk-email, mais il n'est pas recommandé à la plupart des tuteurs d'utiliser : ne pas stocker des fonds dans zk-email endommagé signifie que les utilisateurs ne peuvent pas utiliser les fonds.
Nouveaux utilisateurs et Portefeuille intégré
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. Une voie naturelle consiste à utiliser zk-email sur leur adresse e-mail, la clé stockée localement sur l'appareil de l'utilisateur ( peut être la clé universelle ) et la clé de sauvegarde détenue par le fournisseur, pour effectuer un choix de 2 sur 3. Au fur et à 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 davantage de gardiens.
L'intégration des portefeuilles dans les applications est inévitable, car les applications qui tentent d'attirer des utilisateurs non cryptographiques 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 confuse. Cependant, de nombreux utilisateurs de portefeuilles d'applications devraient être en mesure de relier tous leurs portefeuilles ensemble, de sorte qu'ils n'aient à se soucier que d'un "problème de contrôle d'accès". La manière la plus simple est d'adopter un schéma hiérarchique, où il existe un processus de "lien" rapide, permettant aux utilisateurs de définir leur portefeuille principal comme le gardien de tous les portefeuilles intégrés à l'application. Certains clients prennent déjà en charge cela.
Par défaut, la récupération de certains comptes intégrés à l'application des utilisateurs peut être contrôlée par l'équipe de développement de l'application. Cependant, les utilisateurs peuvent "prendre le contrôle" de leur compte et modifier la récupération pour leur propre adresse.
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 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 de telles menaces. Dans le même temps, de nombreuses contre-mesures restent assez primitives : par exemple, demander de cliquer pour envoyer de l'Éther ou d'autres jetons à toute nouvelle adresse, que l'utilisateur envoie 100 dollars ou .
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.
13 J'aime
Récompense
13
6
Partager
Commentaire
0/400
HackerWhoCares
· 07-28 09:01
La sécurité et l'expérience doivent être prises en compte.
Voir l'originalRépondre0
BoredWatcher
· 07-28 08:33
Le portefeuille aurait dû être mis à jour depuis longtemps !
Voir l'originalRépondre0
TokenUnlocker
· 07-25 09:53
Le portefeuille est la première force de production !
Voir l'originalRépondre0
BottomMisser
· 07-25 09:53
Sécurité ? Mises à jour itératives ? Ne parlons pas du portefeuille tant qu'il n'a pas été volé.
Portefeuille Ethereum idéal : mise à niveau complète de l'expérience cross-chain, de la sécurité et de la confidentialité.
Vision idéale du portefeuille Ethereum : une mise à niveau complète de l'expérience cross-chain à la protection de la vie privée
Une couche clé de la pile d'infrastructure d'Ethereum est le Portefeuille, mais il est souvent sous-estimé par les chercheurs et développeurs principaux de L1. Le Portefeuille est la fenêtre entre les utilisateurs et le monde d'Ethereum, et les utilisateurs ne peuvent bénéficier d'aucune des propriétés décentralisées, résistantes à la censure, sécurisées, privées ou autres offertes par Ethereum et ses applications, à condition que le Portefeuille lui-même possède également ces propriétés.
Récemment, le portefeuille Ethereum a fait de grands progrès en matière d'expérience utilisateur, de sécurité et de fonctionnalités. Le but de cet article est de donner un aperçu des caractéristiques qu'un portefeuille Ethereum idéal devrait posséder. Ce n'est pas une liste exhaustive ; elle reflète une tendance crypto-anarchiste, axée sur la sécurité et la vie privée, et il est presque certain qu'elle est incomplète en termes d'expérience utilisateur. Cependant, une liste de souhaits n'est pas aussi efficace pour optimiser l'expérience utilisateur que le déploiement et l'itération simples basés sur les retours d'expérience, c'est pourquoi se concentrer sur les attributs de sécurité et de vie privée est la chose la plus précieuse.
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, qui comprend des volets à court et à long terme. Nous allons parler de la partie à court terme : des idées qui peuvent encore être mises en œuvre théoriquement aujourd'hui.
La pensée centrale est (i) l'envoi intégré cross-chain L2, ainsi que (ii) une adresse spécifique à la chaîne et des demandes de paiement. Le portefeuille devrait être capable de fournir à l'utilisateur une adresse, suivant le style des projets ERC pertinents.
Lorsque quelqu'un ( ou certaines applications ) fournissent ce format d'adresse à l'utilisateur, l'utilisateur devrait être en mesure de le coller dans le champ "destinataire" du portefeuille, puis de cliquer sur "Envoyer". Le portefeuille devrait traiter automatiquement les données envoyées de la manière la plus efficace possible :
Le contenu ci-dessus s'applique au cas d'utilisation "l'utilisateur copie et colle l'adresse ( ou ENS, par exemple, vitalik.eth @ optimism.eth) quelqu'un effectue un paiement à l'utilisateur". Si le dapp demande un dépôt, 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, le portefeuille sera en mesure de satisfaire cette demande de la manière requise. Pour garantir une bonne expérience utilisateur, il est également nécessaire de normaliser les demandes getAvailableBalance, et le portefeuille doit prendre en compte sérieusement sur quelles chaînes les actifs des utilisateurs seront stockés par défaut, 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, que le portefeuille mobile peut scanner. 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 X unités du jeton YZ sur la chaîne, avec un ID de référence ou un 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, dans lequel 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 de leur contrat sur la chaîne, le travail du destinataire est de comprendre comment transférer ces fonds vers leur propre portefeuille.
Un autre sujet connexe est le paiement des frais de gaz. Si un utilisateur reçoit des actifs sur un L2 sans avoir d'Éther, et qu'il doit envoyer une transaction sur ce L2, le portefeuille devrait être capable d'utiliser automatiquement le protocole pour payer les frais de gaz sur la chaîne là où les utilisateurs ont de l'Éther. Si le portefeuille souhaite que les utilisateurs effectuent plus de transactions à l'avenir sur le L2, il devrait également utiliser uniquement un DEX pour envoyer, par exemple, des ETH d'une valeur de plusieurs millions de frais de gaz, afin que les transactions futures puissent directement y utiliser les frais de gaz ( car cela 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 sur deux fronts : (i) protéger les utilisateurs des attaques malveillantes ou des piratages de la part des développeurs de portefeuilles, et (ii) protéger les utilisateurs des conséquences de leurs propres erreurs.
La solution préférée à cet égard, depuis plus de dix ans, a été la récupération sociale et le portefeuille multi-signatures, avec un contrôle d'accès hiérarchique. Les comptes des utilisateurs ont deux niveaux de clés : une clé principale et N gardiens ( par exemple N = 5). La clé principale est capable d'exécuter des opérations de faible valeur et non financières. La plupart des gardiens doivent exécuter (i) des opérations de haute valeur, comme envoyer toute la valeur dans le compte, ou (ii) changer la clé principale ou tout gardien. Si nécessaire, il peut être permis à la clé principale d'exécuter des opérations de haute valeur via un verrouillage temporel.
Ce qui précède est la conception de base, qui peut être étendue. Les clés de session et les mécanismes d'autorisation associés peuvent aider à soutenir l'équilibre entre la commodité et la sécurité des différentes applications. Des architectures de gardien plus complexes, par exemple 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.
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é des amis et de la famille de l'utilisateur. Si l'utilisateur demande à chacun de lui fournir une nouvelle adresse, alors personne n'a besoin de savoir qui ils sont - en fait, les gardiens de l'utilisateur n'ont même pas besoin de savoir qui ils sont. S'ils ne préviennent pas l'utilisateur, la probabilité qu'ils complotent ensemble 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 des services de signature de transactions uniquement à la réception d'autres informations de confirmation sur demande de l'utilisateur : par exemple, un code de confirmation, ou un appel vidéo pour les utilisateurs de grande valeur. Les gens ont longtemps essayé de créer cela, par exemple, l'introduction de 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, des portefeuilles matériels ). Cela peut fonctionner, mais il peut être é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, surtout lorsqu'ils se trouvent 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 l'appareil de l'utilisateur, en faisant une solution de dispositif personnel, mais elle peut également être sauvegardée dans le cloud, ce qui rend sa sécurité dépendante d'hypothèses complexes de sécurité par mot de passe hybride, d'institutions et de matériel de confiance. En réalité, la clé représente un gain de sécurité précieux pour l'utilisateur moyen, mais elle ne suffit pas à elle seule à protéger les économies de toute une vie de l'utilisateur.
Heureusement, avec ZK-SNARK, nous avons une quatrième option : l'identité centralisée enveloppée dans ZK. Ce type comprend zk-email, Anon Aadhaar, Myna Wallet, etc. Fondamentalement, les utilisateurs peuvent adopter diverses formes ( d'identité centralisée d'entreprise ou de gouvernement ) et les convertir en adresse Ethereum, les utilisateurs ne peuvent envoyer des transactions qu'en générant une preuve de possession d'une identité centralisée grâce à ZK-SNARK.
Avec ce complément, nous avons maintenant un large éventail de choix, et l'ID centralisé emballé en ZK possède une "convivialité pour les débutants" unique.
Pour ce faire, il doit être réalisé par une interface utilisateur simplifiée et intégrée : les utilisateurs devraient pouvoir spécifier uniquement "example@gmail.com" en tant que 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é éventuellement stockées dans cet e-mail ) dans une application tierce open source, et de confirmer que l'adresse générée est correcte. Cela devrait également être le cas pour tout autre type de gardien pris en charge.
Veuillez noter qu'un défi réel auquel zk-email est confronté aujourd'hui est qu'il repose sur la signature DKIM, qui utilise des clés renouvelées tous les quelques mois, et ces clés elles-mêmes ne sont pas signées par d'autres entités. Cela signifie qu'aujourd'hui, zk-email a un certain niveau d'exigence de confiance au-delà de celui du fournisseur lui-même ; si zk-email utilise TLSNotary pour vérifier les clés mises à jour dans du matériel de confiance, cela pourrait réduire cette situation, mais ce n'est pas idéal. Il est à espérer que les fournisseurs de messagerie commenceront à signer directement leurs clés DKIM. Aujourd'hui, il est conseillé à un tuteur d'utiliser zk-email, mais il n'est pas recommandé à la plupart des tuteurs d'utiliser : ne pas stocker des fonds dans zk-email endommagé signifie que les utilisateurs ne peuvent pas utiliser les fonds.
Nouveaux utilisateurs et Portefeuille intégré
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. Une voie naturelle consiste à utiliser zk-email sur leur adresse e-mail, la clé stockée localement sur l'appareil de l'utilisateur ( peut être la clé universelle ) et la clé de sauvegarde détenue par le fournisseur, pour effectuer un choix de 2 sur 3. Au fur et à 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 davantage de gardiens.
L'intégration des portefeuilles dans les applications est inévitable, car les applications qui tentent d'attirer des utilisateurs non cryptographiques 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 confuse. Cependant, de nombreux utilisateurs de portefeuilles d'applications devraient être en mesure de relier tous leurs portefeuilles ensemble, de sorte qu'ils n'aient à se soucier que d'un "problème de contrôle d'accès". La manière la plus simple est d'adopter un schéma hiérarchique, où il existe un processus de "lien" rapide, permettant aux utilisateurs de définir leur portefeuille principal comme le gardien de tous les portefeuilles intégrés à l'application. Certains clients prennent déjà en charge cela.
Par défaut, la récupération de certains comptes intégrés à l'application des utilisateurs peut être contrôlée par l'équipe de développement de l'application. Cependant, les utilisateurs peuvent "prendre le contrôle" de leur compte et modifier la récupération pour leur propre adresse.
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 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 de telles menaces. Dans le même temps, de nombreuses contre-mesures restent assez primitives : par exemple, demander de cliquer pour envoyer de l'Éther ou d'autres jetons à toute nouvelle adresse, que l'utilisateur envoie 100 dollars ou .