Phoenix et Moonlight coexistent : une chaîne de confidentialité laisse une échappatoire qui n’est pas vraiment privée. Je trouve ça plutôt lucide.
Les personnes qui travaillent sur des projets de confidentialité ont tendance à aller jusqu’à l’extrême : soit tout cacher, en prétendant à une confidentialité absolue ; soit, par facilité, abandonner la confidentialité pour gagner en efficacité. Ces deux dernières années, j’ai vu pas mal de projets qui se présentaient comme « axés confidentialité » mourir à cause de ce choix binaire : soit l’audit et la régulation ne peuvent pas vraiment les toucher, soit la fonction de confidentialité n’est finalement qu’une façade. En parcourant la documentation liée à $DUSK , j’ai constaté qu’ils n’ont pas choisi l’extrême. Phoenix est basé sur un modèle UTXO : pour effectuer des paiements masqués, il dissimule à la fois le solde et les relations de transactions. Moonlight, lui, repose sur un modèle de compte : il suit un chemin public, et le solde comme les transferts sont affichés au grand jour. Deux voies existent donc en parallèle : toutes deux permettent de transférer des DUSK, de payer des frais (gas), et de servir de points d’entrée pour l’exécution des contrats. Qui utilise quelle voie relève du choix.
Au début, je pensais que c’était un compromis. Puis je me suis rendu compte que c’était en fait une stratégie de repli. Les institutions doivent être conformes et pouvoir faire l’objet d’audits et de retracer : il est impossible que tous les flux de fonds soient intégralement “boîtes noires”. Dans un bac à sable de régulation, la première chose à vérifier est évidemment où va l’argent. Les utilisateurs ordinaires, eux, veulent de la confidentialité : ils ne veulent pas que chaque transfert se retrouve décortiqué jusqu’au moindre détail. Forcer une seule approche à satisfaire deux demandes contraires a de fortes chances de décevoir tout le monde. C’est comme construire une maison avec une entrée principale et une entrée de service : l’entrée principale sert à ceux qui viennent vérifier l’identité, l’entrée de service à ceux qui ne veulent pas être surveillés par les voisins. C’est le même bâtiment ; personne ne trouve une des portes inutile.
Mon avis sur une conception comme celle de @Dusk est : elle admet que l’on ne peut pas répondre à toutes les demandes, et elle est finalement plus honnête que de bricoler un “plan universel” censé convenir à tout. Dans la tech, au final, on ne se bat pas tant pour la pureté des idéaux de chacun que pour la capacité de quelqu’un à commencer par mâcher les réalités les plus dures. #dusk
Les personnes qui travaillent sur des projets de confidentialité ont tendance à aller jusqu’à l’extrême : soit tout cacher, en prétendant à une confidentialité absolue ; soit, par facilité, abandonner la confidentialité pour gagner en efficacité. Ces deux dernières années, j’ai vu pas mal de projets qui se présentaient comme « axés confidentialité » mourir à cause de ce choix binaire : soit l’audit et la régulation ne peuvent pas vraiment les toucher, soit la fonction de confidentialité n’est finalement qu’une façade. En parcourant la documentation liée à $DUSK , j’ai constaté qu’ils n’ont pas choisi l’extrême. Phoenix est basé sur un modèle UTXO : pour effectuer des paiements masqués, il dissimule à la fois le solde et les relations de transactions. Moonlight, lui, repose sur un modèle de compte : il suit un chemin public, et le solde comme les transferts sont affichés au grand jour. Deux voies existent donc en parallèle : toutes deux permettent de transférer des DUSK, de payer des frais (gas), et de servir de points d’entrée pour l’exécution des contrats. Qui utilise quelle voie relève du choix.
Au début, je pensais que c’était un compromis. Puis je me suis rendu compte que c’était en fait une stratégie de repli. Les institutions doivent être conformes et pouvoir faire l’objet d’audits et de retracer : il est impossible que tous les flux de fonds soient intégralement “boîtes noires”. Dans un bac à sable de régulation, la première chose à vérifier est évidemment où va l’argent. Les utilisateurs ordinaires, eux, veulent de la confidentialité : ils ne veulent pas que chaque transfert se retrouve décortiqué jusqu’au moindre détail. Forcer une seule approche à satisfaire deux demandes contraires a de fortes chances de décevoir tout le monde. C’est comme construire une maison avec une entrée principale et une entrée de service : l’entrée principale sert à ceux qui viennent vérifier l’identité, l’entrée de service à ceux qui ne veulent pas être surveillés par les voisins. C’est le même bâtiment ; personne ne trouve une des portes inutile.
Mon avis sur une conception comme celle de @Dusk est : elle admet que l’on ne peut pas répondre à toutes les demandes, et elle est finalement plus honnête que de bricoler un “plan universel” censé convenir à tout. Dans la tech, au final, on ne se bat pas tant pour la pureté des idéaux de chacun que pour la capacité de quelqu’un à commencer par mâcher les réalités les plus dures. #dusk