Bonjour,
Il commence a y avoir pas mal de posts qui parlent de dérivation de portefeuille comme si le concept était évident, mais je n’en comprends pas du tout le principe et ne trouve aucune explication sur le sujet.
Quelqu’un pourrait-il expliquer succintement :
Merci par avance.
Je vais tenter de synthétiser rapidement ce que Elois ma appris l’année dernière à ce sujet:
/, soft), soit en dérivant la clé privé (//, hard). Parmi les dérivations par clé privé, nous avons nommé 2 formes de dérivations:
//0/1, //0/2, ect …).Pour résumer, dériver un mnemonic de manière hard et transparente permet d’avoir 10^21 wallets différents à partir d’une seule seed. Notre convention (qu’on invente pas) qui consiste à incrémenter des nombres entier permet entre autre de retrouver facilement ces wallets en scannant par exemple les dérivations //0 à //30 lors de l’import, si balance non null, wallet existe.
Les comptes Alice Bob et compagnies des blockchains de tests substrate par defaut sont des dérivations //Alice, //Bob, à partir d’un mnemonic de test inscrit en dur dans le code de substrate, ce qui est pratique.
Je ne sais pas si c’est claire.
Si je dis des bêtises d’autres corrigerons.
Je tente à mon tour
Qu’est ce c’est ?
La dérivation est un mécanisme qui permet de générer plusieurs paires de clés à partir d’un même secret. Les clés générées paraissent indépendantes du point de vue de la blockchain et sont gérées comme telles. En revanche, du point de vue de l’utilisateur, il suffit d’un seul secret maître pour générer toutes les clés dérivés.
À quoi ça sert ?
Il y a plusieurs applications à la dérivation comme détaillé par poka ci-dessus. Le principal cas d’usage qu’on envisage pour l’instant est de permettre à un utilisateur d’avoir plusieurs portefeuilles différents mais un seul secret à retenir. Par exemple, si je veux créer une caisse temporaire sans que son historique se mélange aux transactions de mon compte membre et sans avoir à stocker un mot de passe supplémentaire, je peux créer une dérivation.
Comment ça marche ?
Là ça devient technique et je ne saurais pas le vulgariser mais ça repose sur une fonction de dérivation qui permet de reproduire de manière déterministe des clés à partir d’une autre. On pourrait faire une analogie avec les identifiants Cesium. Si tu utilises Abcde / Fghij comme couple d’identifiants membre, tu pourrais choisir Abcde_portefeuille / Fghij pour ton compte portefeuille et Abcde_gchange / Fghij pour ton compte gchange. Mais la dérivation permet par exemple de partager le code de ton compte gchange avec quelqu’un sans qu’il puisse remonter à ton compte membre pour autant.
Ça vaudrait le coup de creuser le sujet pour mieux l’expliquer.
N’est-ce pas plutôt qu’elle ne doit recevoir qu’une seule transaction ? Sans avoir la clé privée on ne peut pas deviner qu’une clé dérivée opaque en est une. Donc on ne peut pas vérifier publiquement que le compte n’a été utilisé qu’une fois, c’est de la responsabilité de son propriétaire (donc du client/wallet).
Je n’ai pas lu en détail le document et je n’ai pas les bases en courbes elliptiques, mais d’après ce que j’ai compris (de ce paragraphe), pour dériver une clé enfant (publique ou privée) à partir d’une clé parent (respectivement publique ou privée) étendue (càd à laquelle on a ajouté le numéro de dérivation), on lui applique une fonction donnée.
Pour créer un compte dérivé transparent, on obtient sa clé privée à partir de la clé privée parent et du numéro de dérivation. La clé publique correspondante est obtenue à partir de la clé publique parent et du numéro de dérivation. La magie des maths fait que les clés coincident. N’importe qui peut alors, en connaissant la clé publique parent, vérifier que la clé publique dérivée en est bien dérivée.
Pour créer un compte dérivé opaque, c’est pareil, sauf qu’il n’existe pas de fonction pour déterminer la clé publique dérivée à partir de la clé publique parent et du numéro de dérivation. Donc le seul moyen de trouver la clé publique dérivée est à partir de la clé privée dérivée, donc de l’extérieur on ne peut pas savoir que les deux comptes appartiennent à la même personne.
Pour ce usecase précis, il me semble qu’il s’agirait de dérivation soft, par clé publique uniquement (/) (si j’ai bien compris), pas encore essayé de mon côté, mais très prometteur pour nos besoins je pense.
Mais concernant les comptes membres spécifiquement, il y aura d’autre mécanisme a pousser pour les protégés, comme par exemple attribuer des droit délégataire a un simple portefeuille dérivé, uniquement en émission de transaction par exemple, soit pouvoir certifier.
Tant qu’on ne peut pas déduire la clé privée parent de la clé privée dérivée, ça devrait être possible, que ce soit en opaque ou transparent. Il faut juste ne partager que la clé privée dérivée, plutôt que le chemin de dérivation complet.
Je parle ici de soft/hard, et non de hard transparente / hard opaque.
… Ca deviens compliqué la discutions avec tous ces termes 