J’ai passé une heure à parcourir la documentation de Dusk en m’attendant au pitch habituel « soucieux de la vie privée dès la conception », et la partie qui m’est vraiment restée en tête est plus petite que ça. $DUSK #dusk @Dusk se présentent comme s’inscrivant « dans la confidentialité par défaut, la possibilité d’audit lorsque c’est requis », ce qui ressemble à deux réglages qu’un utilisateur peut activer ou désactiver. En pratique, ce n’est pas symétrique. La confidentialité est un niveau protocolaire et automatique dès l’instant où vous effectuez une transaction. Le volet « auditabilité » n’est pas du tout quelque chose que la partie qui transige contrôle : il dépend de la personne (ou entité) qui détient les clés d’attestation cryptographique, ce qui signifie que la visibilité de la conformité est une relation entre le réseau et un régulateur ou une institution, et non une fonctionnalité avec laquelle un utilisateur interagit. Ainsi, le cadrage « défaut vs avancé » correspond en réalité à « votre défaut vs l’avancé de quelqu’un d’autre », et vous ne voyez jamais, côté utilisateur, dans quel mode vous opérez réellement. C’est un design cohérent pour des infrastructures institutionnelles, mais il déplace discrètement à qui l’interface est destinée. En le lisant en tant qu’utilisateur de détail, j’ai compris que la promesse de confidentialité et la promesse de conformité ne s’adressent même pas à la même personne. Et ça me fait me demander comment cette séparation apparaît dès que le volume réel d’actifs tokenisés (RWA) commence à circuler sur le système.