La plupart des blockchains font un choix unique concernant la visibilité et obligent tout le monde à vivre avec. Dusk Network a fait quelque chose de moins carré et, je pense, plus honnête : il met en ligne deux modèles de transactions côte à côte et laisse le cas d’usage décider.
Moonlight est basé sur des comptes et public, proche de la façon dont se comporte un registre de blockchain classique : facile à auditer et simple à comprendre. Phoenix est basé sur des UTXO et protégé, masquant les montants et les participants grâce à des preuves de connaissance nulle, conçu pour les cas où la confidentialité est l’objectif principal plutôt qu’une simple option supplémentaire. Les deux vivent sur la même couche de base, DuskDS, et les deux peuvent déplacer le jeton DUSK ou payer le gas. Une troisième couche, Zedger, se place au-dessus des deux pour les titres réglementés : elle suit les soldes d’actifs conformes d’une manière conçue pour satisfaire des exigences de type MiFID II plutôt que des paiements généraux. Rien n’oblige un utilisateur ou un développeur à choisir une seule philosophie de la confidentialité et à s’y engager pour chaque interaction.
La décision de conception sur laquelle il vaut la peine de s’attarder tient au fait que Dusk n’a pas simplement tout définir par défaut en « shielded » et en rester là, comme le font beaucoup de projets axés sur la confidentialité. La confidentialité programmable, dans la formulation même de Dusk, signifie une confidentialité qui peut être orientée vers des règles spécifiques, plutôt que appliquée uniformément. Un transfert de titres réglementés pourrait nécessiter la confidentialité de Phoenix, plus une divulgation sélective à un auditeur. Une simple transaction de staking n’a peut-être pas besoin de masquage du tout, et l’imposer via un chemin de confidentialité plus lourd ne ferait qu’ajouter des coûts et de la complexité, sans réel bénéfice.
Ce que cela ne fait pas, en revanche, c’est rendre le choix trivial pour les concepteurs. Prendre en charge plusieurs modèles implique davantage de surface d’attaque à sécuriser, plus de documentation à rédiger et davantage de décisions confiées à des développeurs qui auraient peut-être préféré un choix par défaut évident. La flexibilité a un coût de maintenance, et Dusk Network continue de le payer.
#dusk $DUSK @Dusk
Moonlight est basé sur des comptes et public, proche de la façon dont se comporte un registre de blockchain classique : facile à auditer et simple à comprendre. Phoenix est basé sur des UTXO et protégé, masquant les montants et les participants grâce à des preuves de connaissance nulle, conçu pour les cas où la confidentialité est l’objectif principal plutôt qu’une simple option supplémentaire. Les deux vivent sur la même couche de base, DuskDS, et les deux peuvent déplacer le jeton DUSK ou payer le gas. Une troisième couche, Zedger, se place au-dessus des deux pour les titres réglementés : elle suit les soldes d’actifs conformes d’une manière conçue pour satisfaire des exigences de type MiFID II plutôt que des paiements généraux. Rien n’oblige un utilisateur ou un développeur à choisir une seule philosophie de la confidentialité et à s’y engager pour chaque interaction.
La décision de conception sur laquelle il vaut la peine de s’attarder tient au fait que Dusk n’a pas simplement tout définir par défaut en « shielded » et en rester là, comme le font beaucoup de projets axés sur la confidentialité. La confidentialité programmable, dans la formulation même de Dusk, signifie une confidentialité qui peut être orientée vers des règles spécifiques, plutôt que appliquée uniformément. Un transfert de titres réglementés pourrait nécessiter la confidentialité de Phoenix, plus une divulgation sélective à un auditeur. Une simple transaction de staking n’a peut-être pas besoin de masquage du tout, et l’imposer via un chemin de confidentialité plus lourd ne ferait qu’ajouter des coûts et de la complexité, sans réel bénéfice.
Ce que cela ne fait pas, en revanche, c’est rendre le choix trivial pour les concepteurs. Prendre en charge plusieurs modèles implique davantage de surface d’attaque à sécuriser, plus de documentation à rédiger et davantage de décisions confiées à des développeurs qui auraient peut-être préféré un choix par défaut évident. La flexibilité a un coût de maintenance, et Dusk Network continue de le payer.
#dusk $DUSK @Dusk
