Hier, je n’ai pas dormi une nuit entière en étudiant le livre blanc $DUSK . Je suis resté longtemps à regarder un passage de la note de Phoenix.
Le champ chiffré de la note, « enc », est chiffré avec la view key du destinataire. Le livre blanc dit que la view key permet à un utilisateur de déléguer à un tiers le droit de rechercher des transactions sur le réseau via le scan, mais que le tiers n’obtient pas la secret key complète, donc il ne peut pas dépenser.
Au début, je n’ai pas trop prêté attention à ce détail. Puis j’ai compris : c’est en fait le cœur cryptographique d’une divulgation sélective. Pour une même transaction, des clés différentes contrôlent des droits d’accès différents.
Dans le livre blanc, la définition de la view key est (a, B), tandis que la secret key est (a, b). En manquant une composante de clé privée, b, on ajoute une couche supplémentaire de sécurité. Les données chiffrées de la note peuvent être déchiffrées et consultées, mais elles ne permettent pas de générer le nullifier correspondant pour dépenser. Le principe général de ce mécanisme, c’est qu’on peut dissocier le pouvoir de contrôle du pouvoir d’utilisation.
Pour le public, les transactions sont chiffrées ; les preuves ZK ne vérifient que la validité sans exposer les données. Pour les régulateurs, une partie autorisée qui reçoit la view key peut déchiffrer le contenu précis de la note, vérifier le solde, le contrepartiste et la conformité, mais ne peut pas utiliser les fonds. Le site officiel @Dusk dit que cela s’appelle « controlled visibility for audit, supervision, and regulated disclosure ». Plus je le lis, plus je trouve cette formulation exacte.
Un jeu de clés cryptographiques, et il répond simultanément à deux besoins apparemment contradictoires : la confidentialité et la conformité. Le public ne voit pas, le régulateur voit clairement, et l’utilisateur reste maître de la situation.
#dusk
Mais pour être honnête, je n’ai pas encore tout compris comment aligner, dans l’environnement EVM de Hedger, cette mécanique de view key. La view key du livre blanc est conçue pour le modèle natif UTXO de Phoenix ; Hedger utilise un modèle hybride UTXO/compte. Est-ce que les systèmes de clés des deux peuvent être mappés de façon transparente ? Je n’ai pas encore trouvé de réponse claire.
Le champ chiffré de la note, « enc », est chiffré avec la view key du destinataire. Le livre blanc dit que la view key permet à un utilisateur de déléguer à un tiers le droit de rechercher des transactions sur le réseau via le scan, mais que le tiers n’obtient pas la secret key complète, donc il ne peut pas dépenser.
Au début, je n’ai pas trop prêté attention à ce détail. Puis j’ai compris : c’est en fait le cœur cryptographique d’une divulgation sélective. Pour une même transaction, des clés différentes contrôlent des droits d’accès différents.
Dans le livre blanc, la définition de la view key est (a, B), tandis que la secret key est (a, b). En manquant une composante de clé privée, b, on ajoute une couche supplémentaire de sécurité. Les données chiffrées de la note peuvent être déchiffrées et consultées, mais elles ne permettent pas de générer le nullifier correspondant pour dépenser. Le principe général de ce mécanisme, c’est qu’on peut dissocier le pouvoir de contrôle du pouvoir d’utilisation.
Pour le public, les transactions sont chiffrées ; les preuves ZK ne vérifient que la validité sans exposer les données. Pour les régulateurs, une partie autorisée qui reçoit la view key peut déchiffrer le contenu précis de la note, vérifier le solde, le contrepartiste et la conformité, mais ne peut pas utiliser les fonds. Le site officiel @Dusk dit que cela s’appelle « controlled visibility for audit, supervision, and regulated disclosure ». Plus je le lis, plus je trouve cette formulation exacte.
Un jeu de clés cryptographiques, et il répond simultanément à deux besoins apparemment contradictoires : la confidentialité et la conformité. Le public ne voit pas, le régulateur voit clairement, et l’utilisateur reste maître de la situation.
#dusk
Mais pour être honnête, je n’ai pas encore tout compris comment aligner, dans l’environnement EVM de Hedger, cette mécanique de view key. La view key du livre blanc est conçue pour le modèle natif UTXO de Phoenix ; Hedger utilise un modèle hybride UTXO/compte. Est-ce que les systèmes de clés des deux peuvent être mappés de façon transparente ? Je n’ai pas encore trouvé de réponse claire.