Et si le vrai problème de la transparence de la blockchain n’était pas qu’il manque trop peu d’informations, mais qu’il en est au contraire exposé beaucoup trop ?
J’ai commencé à me pencher sur DUSK en explorant des projets construits autour d’une infrastructure financière, et un choix de conception ne cessait de me ramener : il ne traite pas chaque transaction comme ayant besoin du même niveau de visibilité.
DUSK sépare les flux de transactions publiques et ceux protégés, tout en permettant de divulguer l’information de manière sélective lorsqu’une partie donnée a besoin de preuves.
Cela ressemble à une décision d’architecture relativement mineure jusqu’à ce qu’on réfléchisse à la manière dont fonctionnent réellement les marchés financiers.
Une entreprise peut avoir besoin de prouver qu’un transfert est légitime sans révéler l’intégralité de sa position. Un investisseur peut devoir satisfaire une règle d’éligibilité sans publier chaque détail de son identité. Un régulateur peut avoir besoin d’une piste d’audit sans transformer chaque relation commerciale en données publiques.
Ce qui m’intéresse, c’est l’hypothèse de fond remise en question : la vérification ne nécessite pas forcément de la visibilité.
En recherchant DUSK, je me suis surpris à me demander à quelle fréquence les systèmes blockchain confondent « n’importe qui peut inspecter ceci » avec « ceci peut être vérifié indépendamment ». Ces idées se recoupent, mais elles ne sont pas identiques.
La question de conception la plus utile n’est peut-être pas de savoir si un réseau doit être transparent ou privé. Elle consiste plutôt à déterminer si la visibilité peut devenir conditionnelle, intentionnelle et réversible selon la personne qui a réellement besoin de l’information.
Cette distinction me paraît de plus en plus importante à mesure que la blockchain se rapproche de systèmes financiers où la confidentialité n’est plus une option.
@Dusk #dusk $DUSK
J’ai commencé à me pencher sur DUSK en explorant des projets construits autour d’une infrastructure financière, et un choix de conception ne cessait de me ramener : il ne traite pas chaque transaction comme ayant besoin du même niveau de visibilité.
DUSK sépare les flux de transactions publiques et ceux protégés, tout en permettant de divulguer l’information de manière sélective lorsqu’une partie donnée a besoin de preuves.
Cela ressemble à une décision d’architecture relativement mineure jusqu’à ce qu’on réfléchisse à la manière dont fonctionnent réellement les marchés financiers.
Une entreprise peut avoir besoin de prouver qu’un transfert est légitime sans révéler l’intégralité de sa position. Un investisseur peut devoir satisfaire une règle d’éligibilité sans publier chaque détail de son identité. Un régulateur peut avoir besoin d’une piste d’audit sans transformer chaque relation commerciale en données publiques.
Ce qui m’intéresse, c’est l’hypothèse de fond remise en question : la vérification ne nécessite pas forcément de la visibilité.
En recherchant DUSK, je me suis surpris à me demander à quelle fréquence les systèmes blockchain confondent « n’importe qui peut inspecter ceci » avec « ceci peut être vérifié indépendamment ». Ces idées se recoupent, mais elles ne sont pas identiques.
La question de conception la plus utile n’est peut-être pas de savoir si un réseau doit être transparent ou privé. Elle consiste plutôt à déterminer si la visibilité peut devenir conditionnelle, intentionnelle et réversible selon la personne qui a réellement besoin de l’information.
Cette distinction me paraît de plus en plus importante à mesure que la blockchain se rapproche de systèmes financiers où la confidentialité n’est plus une option.
@Dusk #dusk $DUSK
