Dusk : ce que Phoenix cache réellement
Je pensais autrefois que la confidentialité sur une blockchain signifiait de masquer une adresse et d’espérer que le reste du système resterait cohérent. Cette hypothèse me dérangeait, car la confidentialité financière est inutile si personne ne peut établir de façon indépendante que la transaction elle-même était valide.
C’est ce qui a rendu le modèle Phoenix de Dusk particulièrement intéressant à examiner plus attentivement. Il utilise des transferts protégés, basés sur des notes, dans lesquels des preuves à connaissance nulle établissent la validité de la transaction sans révéler les mêmes informations qu’un modèle de compte public. La documentation actuelle de Dusk indique que Phoenix masque le montant transféré, l’identité de l’expéditeur aux yeux des tiers, et les notes spécifiques impliquées, tandis que les clés de consultation peuvent fournir une divulgation sélective lorsque des preuves sont nécessaires.
La tension intéressante, c’est que la confidentialité ne supprime pas le besoin de vérification. Elle change simplement la forme que prend cette vérification. Les validateurs doivent toujours établir que la transaction est légitime, qu’il existe des fonds suffisants et que la même valeur n’a pas été dépensée deux fois, mais ils ne devraient pas avoir besoin des détails privés sous-jacents.
La conception Phoenix du livre blanc s’appuie sur des engagements, des nullifiants et des preuves à connaissance nulle pour dissocier ces deux exigences. Cela semble élégant, mais l’élégance sur le papier n’est pas la même chose que la capacité à prouver que le système reste pratique en conditions d’utilisation soutenue. La documentation actuelle de Dusk précise aussi que générer ces preuves exige suffisamment de calcul pour justifier une infrastructure dédiée de Prover.
Ce que Dusk doit démontrer, c’est que la garantie de confidentialité et le coût opérationnel demeurent compatibles à mesure que l’utilisation augmente.
S’acharner sur des détails sans comprendre réellement ce que Dusk cherche à résoudre est une façon rapide de mal interpréter le projet.
Si les détails des transactions restent privés, quel niveau de divulgation sélective est suffisant ?
La confidentialité compte surtout lorsque la validité peut rester vérifiée indépendamment.
@Dusk_Foundation $DUSK #dusk
Je pensais autrefois que la confidentialité sur une blockchain signifiait de masquer une adresse et d’espérer que le reste du système resterait cohérent. Cette hypothèse me dérangeait, car la confidentialité financière est inutile si personne ne peut établir de façon indépendante que la transaction elle-même était valide.
C’est ce qui a rendu le modèle Phoenix de Dusk particulièrement intéressant à examiner plus attentivement. Il utilise des transferts protégés, basés sur des notes, dans lesquels des preuves à connaissance nulle établissent la validité de la transaction sans révéler les mêmes informations qu’un modèle de compte public. La documentation actuelle de Dusk indique que Phoenix masque le montant transféré, l’identité de l’expéditeur aux yeux des tiers, et les notes spécifiques impliquées, tandis que les clés de consultation peuvent fournir une divulgation sélective lorsque des preuves sont nécessaires.
La tension intéressante, c’est que la confidentialité ne supprime pas le besoin de vérification. Elle change simplement la forme que prend cette vérification. Les validateurs doivent toujours établir que la transaction est légitime, qu’il existe des fonds suffisants et que la même valeur n’a pas été dépensée deux fois, mais ils ne devraient pas avoir besoin des détails privés sous-jacents.
La conception Phoenix du livre blanc s’appuie sur des engagements, des nullifiants et des preuves à connaissance nulle pour dissocier ces deux exigences. Cela semble élégant, mais l’élégance sur le papier n’est pas la même chose que la capacité à prouver que le système reste pratique en conditions d’utilisation soutenue. La documentation actuelle de Dusk précise aussi que générer ces preuves exige suffisamment de calcul pour justifier une infrastructure dédiée de Prover.
Ce que Dusk doit démontrer, c’est que la garantie de confidentialité et le coût opérationnel demeurent compatibles à mesure que l’utilisation augmente.
S’acharner sur des détails sans comprendre réellement ce que Dusk cherche à résoudre est une façon rapide de mal interpréter le projet.
Si les détails des transactions restent privés, quel niveau de divulgation sélective est suffisant ?
La confidentialité compte surtout lorsque la validité peut rester vérifiée indépendamment.
@Dusk_Foundation $DUSK #dusk