Dans le relais colis, le code de retrait change à chaque fois. Même si c’est encore le même destinataire, le système ne te dira pas : « Ces deux retraits ont été effectués par la même personne ».
Récemment, j’ai aidé un voisin à récupérer un colis et je me suis rendu compte que le système du point relais est assez particulier : une même personne a retiré deux fois, mais les codes de retrait étaient totalement différents. Quand le/la employé(e) scanne, il/elle ne voit que « pour qui est le retrait de cette fois ». Il/elle ne peut pas savoir si cette personne est déjà venue la dernière fois.
Plus tard, en fouillant le modèle de transaction de Dusk, Phoenix, j’ai compris : cette logique de « à chaque fois un nouveau code, et les personnes externes ne peuvent pas établir le lien » est aussi utilisée on-chain, et de façon encore plus poussée.
Côté Phoenix : pour chaque transaction, le destinataire ne reçoit pas une adresse fixe, mais une adresse temporaire, une « note public key » (notée npk). L’émetteur utilise la clé publique longue durée du receveur, plus un nombre aléatoire, pour calculer cette npk à usage unique. Le receveur, lui, se sert de sa view key pour vérifier transaction par transaction : s’il parvient à calculer l’npk, c’est que cette transaction lui était destinée.
Le point clé, c’est que — cette npk change à chaque fois. Même si une même personne reçoit dix paiements, quelqu’un qui scanne les données on-chain ne peut pas savoir si ces dix paiements ont le même bénéficiaire, parce qu’il n’existe tout simplement aucune adresse fixe répétée à laquelle se raccrocher.
Cette conception vise à résoudre l’« unlinkability » (l’absence de possibilité de rapprochement). Elle ne cherche pas seulement à empêcher que « le fait que tu as reçu de l’argent » soit visible ; elle empêche surtout qu’on puisse reconstituer la relation « ces dix paiements viennent tous du même destinataire ».
Et en plus, elle supporte la délégation : l’utilisateur peut donner la view key séparément à un tiers, pour que celui-ci aide à identifier quelles transactions sont les siennes, sans pour autant obtenir le droit de dépenser. Le découpage est très fin.
Une adresse jetable, ça a l’air très sûr, mais cela implique aussi que la détection et le calcul à chaque transaction coûtent plus cher qu’avec le modèle à adresse fixe. Une fois à grande échelle, est-ce que l’efficacité du scan pourra tenir ? Tout dépend des données réelles.
$DUSK
#dusk @Dusk
Récemment, j’ai aidé un voisin à récupérer un colis et je me suis rendu compte que le système du point relais est assez particulier : une même personne a retiré deux fois, mais les codes de retrait étaient totalement différents. Quand le/la employé(e) scanne, il/elle ne voit que « pour qui est le retrait de cette fois ». Il/elle ne peut pas savoir si cette personne est déjà venue la dernière fois.
Plus tard, en fouillant le modèle de transaction de Dusk, Phoenix, j’ai compris : cette logique de « à chaque fois un nouveau code, et les personnes externes ne peuvent pas établir le lien » est aussi utilisée on-chain, et de façon encore plus poussée.
Côté Phoenix : pour chaque transaction, le destinataire ne reçoit pas une adresse fixe, mais une adresse temporaire, une « note public key » (notée npk). L’émetteur utilise la clé publique longue durée du receveur, plus un nombre aléatoire, pour calculer cette npk à usage unique. Le receveur, lui, se sert de sa view key pour vérifier transaction par transaction : s’il parvient à calculer l’npk, c’est que cette transaction lui était destinée.
Le point clé, c’est que — cette npk change à chaque fois. Même si une même personne reçoit dix paiements, quelqu’un qui scanne les données on-chain ne peut pas savoir si ces dix paiements ont le même bénéficiaire, parce qu’il n’existe tout simplement aucune adresse fixe répétée à laquelle se raccrocher.
Cette conception vise à résoudre l’« unlinkability » (l’absence de possibilité de rapprochement). Elle ne cherche pas seulement à empêcher que « le fait que tu as reçu de l’argent » soit visible ; elle empêche surtout qu’on puisse reconstituer la relation « ces dix paiements viennent tous du même destinataire ».
Et en plus, elle supporte la délégation : l’utilisateur peut donner la view key séparément à un tiers, pour que celui-ci aide à identifier quelles transactions sont les siennes, sans pour autant obtenir le droit de dépenser. Le découpage est très fin.
Une adresse jetable, ça a l’air très sûr, mais cela implique aussi que la détection et le calcul à chaque transaction coûtent plus cher qu’avec le modèle à adresse fixe. Une fois à grande échelle, est-ce que l’efficacité du scan pourra tenir ? Tout dépend des données réelles.
$DUSK
#dusk @Dusk
