En étudiant Dusk, j’ai longtemps poursuivi une question : la *viewing key* de Phoenix, qui en contrôle réellement l’usage ?
Avant, en analysant les blockchains axées sur la confidentialité, j’avais l’habitude de regarder d’abord le TPS et l’écosystème. En reprenant l’étude de Dusk, j’ai commencé à me concentrer sur autre chose : qui détient les droits de divulgation sélective, et donc pour qui cette chaîne est réellement plus adaptée.
Le design de Phoenix m’a fait m’arrêter et réfléchir pendant longtemps.
Les transactions chiffrées utilisent des preuves ZK pour valider la conformité et masquer le montant ainsi que les parties impliquées. La *viewing key* permet ensuite aux utilisateurs d’autoriser de façon sélective un tiers à consulter les détails d’une transaction.
Cette direction de conception est la bonne.
Mais j’ai parcouru en détail la logique de contrôle de la *viewing key*, et je suis resté bloqué sur une question que personne ne semble aborder clairement.
Une *viewing key*, une fois transmise, peut-elle être retirée ?
Si elle ne peut pas être retirée, que se passe-t-il si l’utilisateur a autorisé aujourd’hui un régulateur à consulter des transactions, puis veut révoquer cette autorisation demain ?
Si elle peut être retirée, comment traiter l’historique déjà consulté ? Cette confidentialité n’existerait déjà plus.
Moonlight correspond au modèle *account-based* public. Phoenix correspond au modèle de confidentialité. Les deux modèles partagent la couche de règlement de DuskDS, mais la gestion du cycle de vie de la *viewing key* : dans la documentation, je ne l’ai pas trouvée expliquée clairement.
DuskVM est encore dans un état *forthcoming*, tandis que DuskEVM vient d’être lancé. NPEX a achevé la tokenisation de titres pour 300 millions d’euros, avec une mise en fonctionnement sur le mainnet qui dure depuis plus d’un an. La capitalisation de DUSK est d’environ 26,63 millions de dollars, soit une baisse de plus de 90 % par rapport à son plus haut historique.
Cette architecture a besoin de temps pour être validée — mais le mécanisme de révocation de la *viewing key* est une question dont je veux la réponse avant même d’attendre sa validation.
Parce que la confidentialité, ce n’est pas seulement la capacité de divulguer : c’est aussi la capacité de retirer réellement.
Je surveille un seul signal : est-ce que Dusk dispose d’un mécanisme complet et public de gestion du cycle de vie des *viewing keys*, incluant la gestion des autorisations, leur révocation et le traitement des droits de consultation de l’historique ?
Oui : la divulgation sélective de Phoenix est un outil de confidentialité contrôlé réellement par l’utilisateur.
Non : une fois la *viewing key* donnée, ce qui se passe ensuite — l’utilisateur ne le sait pas.
A : la *viewing key* est générée et détenue par l’utilisateur, et le droit de révocation lui revient donc naturellement.
B : aucune information publique sur un mécanisme de révocation ; la contrôlabilité de la *viewing key* repose sur des hypothèses plutôt que sur un processus vérifié.
De quel côté vous vous placez ?
Ceci ne constitue pas un conseil en investissement : les transactions comportent des risques. DYOR. $BTC
@Dusk $DUSK #dusk #BinanceSquare $ETH
Avant, en analysant les blockchains axées sur la confidentialité, j’avais l’habitude de regarder d’abord le TPS et l’écosystème. En reprenant l’étude de Dusk, j’ai commencé à me concentrer sur autre chose : qui détient les droits de divulgation sélective, et donc pour qui cette chaîne est réellement plus adaptée.
Le design de Phoenix m’a fait m’arrêter et réfléchir pendant longtemps.
Les transactions chiffrées utilisent des preuves ZK pour valider la conformité et masquer le montant ainsi que les parties impliquées. La *viewing key* permet ensuite aux utilisateurs d’autoriser de façon sélective un tiers à consulter les détails d’une transaction.
Cette direction de conception est la bonne.
Mais j’ai parcouru en détail la logique de contrôle de la *viewing key*, et je suis resté bloqué sur une question que personne ne semble aborder clairement.
Une *viewing key*, une fois transmise, peut-elle être retirée ?
Si elle ne peut pas être retirée, que se passe-t-il si l’utilisateur a autorisé aujourd’hui un régulateur à consulter des transactions, puis veut révoquer cette autorisation demain ?
Si elle peut être retirée, comment traiter l’historique déjà consulté ? Cette confidentialité n’existerait déjà plus.
Moonlight correspond au modèle *account-based* public. Phoenix correspond au modèle de confidentialité. Les deux modèles partagent la couche de règlement de DuskDS, mais la gestion du cycle de vie de la *viewing key* : dans la documentation, je ne l’ai pas trouvée expliquée clairement.
DuskVM est encore dans un état *forthcoming*, tandis que DuskEVM vient d’être lancé. NPEX a achevé la tokenisation de titres pour 300 millions d’euros, avec une mise en fonctionnement sur le mainnet qui dure depuis plus d’un an. La capitalisation de DUSK est d’environ 26,63 millions de dollars, soit une baisse de plus de 90 % par rapport à son plus haut historique.
Cette architecture a besoin de temps pour être validée — mais le mécanisme de révocation de la *viewing key* est une question dont je veux la réponse avant même d’attendre sa validation.
Parce que la confidentialité, ce n’est pas seulement la capacité de divulguer : c’est aussi la capacité de retirer réellement.
Je surveille un seul signal : est-ce que Dusk dispose d’un mécanisme complet et public de gestion du cycle de vie des *viewing keys*, incluant la gestion des autorisations, leur révocation et le traitement des droits de consultation de l’historique ?
Oui : la divulgation sélective de Phoenix est un outil de confidentialité contrôlé réellement par l’utilisateur.
Non : une fois la *viewing key* donnée, ce qui se passe ensuite — l’utilisateur ne le sait pas.
A : la *viewing key* est générée et détenue par l’utilisateur, et le droit de révocation lui revient donc naturellement.
B : aucune information publique sur un mécanisme de révocation ; la contrôlabilité de la *viewing key* repose sur des hypothèses plutôt que sur un processus vérifié.
De quel côté vous vous placez ?
Ceci ne constitue pas un conseil en investissement : les transactions comportent des risques. DYOR. $BTC
@Dusk $DUSK #dusk #BinanceSquare $ETH
