Le crépuscule faisait partie de ces projets que je croyais comprendre trop vite.
Je l’avais classé sous “chaîne de confidentialité”, ce qui est techniquement vrai, mais aussi trop superficiel. Plus j’y regardais, plus il me semblait que Dusk est en réalité centré sur le fait de donner à la confidentialité et à la transparence des rôles distincts au sein du même réseau.
La première composante, c’est Moonlight. C’est le modèle le plus familier : soldes visibles, activités visibles, et un flux de transactions qui ressemble davantage à ce que la plupart des utilisateurs de chaînes publiques connaissent déjà. C’est utile parce que toutes les interactions n’ont pas besoin d’être cachées, et parce que la transparence peut faciliter la conception et l’inspection de certaines applications.
Vient ensuite Phoenix, qui emprunte une autre voie. Au lieu de traiter les soldes comme des entrées de compte ouvertes, il utilise des notes chiffrées. Les preuves à connaissance nulle permettent au réseau de vérifier qu’une dépense est valide sans révéler les détails de la transaction.
Cette distinction a changé ma façon de voir le projet. Dusk ne fait pas qu’ajouter de la confidentialité comme une simple fonctionnalité. Il cherche à faire de la confidentialité un choix de conception natif.
Ce qui reste encore un peu flou pour moi, d’après les documents publics, c’est la manière dont les utilisateurs seront orientés entre Moonlight et Phoenix dans de vraies applications.
À long terme, Dusk gagnera ou perdra probablement sur la question de savoir si cela semble simple, sans compromettre l’architecture sous-jacente.
Selon vous, où le réglage par défaut devrait-il se placer : transparence d’abord, ou confidentialité d’abord ?
#dusk @Dusk $DUSK
Je l’avais classé sous “chaîne de confidentialité”, ce qui est techniquement vrai, mais aussi trop superficiel. Plus j’y regardais, plus il me semblait que Dusk est en réalité centré sur le fait de donner à la confidentialité et à la transparence des rôles distincts au sein du même réseau.
La première composante, c’est Moonlight. C’est le modèle le plus familier : soldes visibles, activités visibles, et un flux de transactions qui ressemble davantage à ce que la plupart des utilisateurs de chaînes publiques connaissent déjà. C’est utile parce que toutes les interactions n’ont pas besoin d’être cachées, et parce que la transparence peut faciliter la conception et l’inspection de certaines applications.
Vient ensuite Phoenix, qui emprunte une autre voie. Au lieu de traiter les soldes comme des entrées de compte ouvertes, il utilise des notes chiffrées. Les preuves à connaissance nulle permettent au réseau de vérifier qu’une dépense est valide sans révéler les détails de la transaction.
Cette distinction a changé ma façon de voir le projet. Dusk ne fait pas qu’ajouter de la confidentialité comme une simple fonctionnalité. Il cherche à faire de la confidentialité un choix de conception natif.
Ce qui reste encore un peu flou pour moi, d’après les documents publics, c’est la manière dont les utilisateurs seront orientés entre Moonlight et Phoenix dans de vraies applications.
À long terme, Dusk gagnera ou perdra probablement sur la question de savoir si cela semble simple, sans compromettre l’architecture sous-jacente.
Selon vous, où le réglage par défaut devrait-il se placer : transparence d’abord, ou confidentialité d’abord ?
#dusk @Dusk $DUSK