La confidentialité programmable est une expression qui semble déjà aboutie dès qu’on la lit, comme une fonctionnalité qu’on peut simplement activer. Dusk Network utilise un langage proche de celui-ci pour décrire ce que son architecture apporte aux marchés réglementés, et je voulais vérifier ce qui se cache réellement derrière cette formule avant de la répéter à mon tour.
Sur le papier, la confidentialité programmable signifie qu’un développeur peut définir exactement quelles parties d’une transaction restent cachées et lesquelles restent visibles, puis faire appliquer automatiquement cette règle à chaque exécution de la transaction. La version de Dusk repose sur la divulgation sélective : un élément d’une couche de base qui inclut aussi la transparence et le règlement déterministe, combiné à Hedger, le module de confidentialité qui effectue le travail cryptographique réel sur le prochain mainnet DuskEVM. Hedger doit conserver confidentiels les soldes et les montants transférés tout en permettant au réseau de vérifier qu’une transaction est valide : un problème de calcul plus difficile que celui que doivent résoudre des systèmes entièrement privés ou entièrement publics.
L’écart entre la théorie et la réalité apparaît dans les détails que les régulateurs demandent effectivement. Une règle qui fonctionne sans problème pour un type d’instrument — une obligation avec un ensemble fixe d’exigences de divulgation — peut ne pas s’étendre automatiquement à un autre instrument, soumis à des règles de reporting différentes dans une autre juridiction. « Programmable » suggère une flexibilité qui doit être conçue et testée au cas par cas, et non supposée uniquement à partir de l’architecture.
Je prends au sérieux la cryptographie sous-jacente. La confidentialité de type homomorphe combinée à des systèmes de preuve est un terrain réel, éprouvé en recherche, et non un mirage. Ce que j’aimerais voir avant d’affirmer que la confidentialité programmable est bel et bien livrée — plutôt que seulement promise —, c’est une deuxième et une troisième règle de divulgation conçues pour un instrument réglementé réellement différent, et pas simplement la première qui a été mise en ligne.
@Dusk $DUSK #dusk
Sur le papier, la confidentialité programmable signifie qu’un développeur peut définir exactement quelles parties d’une transaction restent cachées et lesquelles restent visibles, puis faire appliquer automatiquement cette règle à chaque exécution de la transaction. La version de Dusk repose sur la divulgation sélective : un élément d’une couche de base qui inclut aussi la transparence et le règlement déterministe, combiné à Hedger, le module de confidentialité qui effectue le travail cryptographique réel sur le prochain mainnet DuskEVM. Hedger doit conserver confidentiels les soldes et les montants transférés tout en permettant au réseau de vérifier qu’une transaction est valide : un problème de calcul plus difficile que celui que doivent résoudre des systèmes entièrement privés ou entièrement publics.
L’écart entre la théorie et la réalité apparaît dans les détails que les régulateurs demandent effectivement. Une règle qui fonctionne sans problème pour un type d’instrument — une obligation avec un ensemble fixe d’exigences de divulgation — peut ne pas s’étendre automatiquement à un autre instrument, soumis à des règles de reporting différentes dans une autre juridiction. « Programmable » suggère une flexibilité qui doit être conçue et testée au cas par cas, et non supposée uniquement à partir de l’architecture.
Je prends au sérieux la cryptographie sous-jacente. La confidentialité de type homomorphe combinée à des systèmes de preuve est un terrain réel, éprouvé en recherche, et non un mirage. Ce que j’aimerais voir avant d’affirmer que la confidentialité programmable est bel et bien livrée — plutôt que seulement promise —, c’est une deuxième et une troisième règle de divulgation conçues pour un instrument réglementé réellement différent, et pas simplement la première qui a été mise en ligne.
@Dusk $DUSK #dusk
