#dusk $DUSK @Dusk
Je reviens sans cesse à la façon dont Dusk traite la question de la conformité, car elle n’est pas résolue comme je l’avais imaginé. La plupart des gens supposent que pitch est « privé par défaut », point final, et passent à autre chose. Mais quand je me suis réellement penché sur la documentation de Dusk, ce qui m’a frappé, c’est la séparation entre l’état confidentiel et l’état divulguable, intégrée au même modèle de transaction. Ce n’est pas une confidentialité « avec une couche de conformité » ajoutée plus tard : le mécanisme de divulgation sélective est natif de la façon dont une transaction est structurée dès le départ. Autrement dit, un émetteur ou un auditeur peut se voir remettre des clés de consultation sans que le protocole sous-jacent doive « bifurquer » sa logique pour un « mode réglementé » versus un « mode normal ». Ce que j’ai remarqué en fouillant l’activité sur le testnet, c’est que presque personne n’exploite réellement ce chemin de divulgation pour l’instant, car il n’y a pas de contrepartie réglementaire en temps réel qui le réclame. Du coup, le mécanisme est là, théoriquement solide, mais entièrement non testé par de vraies frictions. Ça me fait penser à construire une sortie de secours avant que l’immeuble ait des locataires. Je ne sais pas si c’est de la prévoyance ou juste une difficulté remise à plus tard. $DUSK Le vrai test n’est pas la description du livre blanc : c’est la première fois qu’un régulateur demande une divulgation sélective et que quelqu’un doit utiliser la fonctionnalité sous pression, plutôt que seulement dans la documentation
Je reviens sans cesse à la façon dont Dusk traite la question de la conformité, car elle n’est pas résolue comme je l’avais imaginé. La plupart des gens supposent que pitch est « privé par défaut », point final, et passent à autre chose. Mais quand je me suis réellement penché sur la documentation de Dusk, ce qui m’a frappé, c’est la séparation entre l’état confidentiel et l’état divulguable, intégrée au même modèle de transaction. Ce n’est pas une confidentialité « avec une couche de conformité » ajoutée plus tard : le mécanisme de divulgation sélective est natif de la façon dont une transaction est structurée dès le départ. Autrement dit, un émetteur ou un auditeur peut se voir remettre des clés de consultation sans que le protocole sous-jacent doive « bifurquer » sa logique pour un « mode réglementé » versus un « mode normal ». Ce que j’ai remarqué en fouillant l’activité sur le testnet, c’est que presque personne n’exploite réellement ce chemin de divulgation pour l’instant, car il n’y a pas de contrepartie réglementaire en temps réel qui le réclame. Du coup, le mécanisme est là, théoriquement solide, mais entièrement non testé par de vraies frictions. Ça me fait penser à construire une sortie de secours avant que l’immeuble ait des locataires. Je ne sais pas si c’est de la prévoyance ou juste une difficulté remise à plus tard. $DUSK Le vrai test n’est pas la description du livre blanc : c’est la première fois qu’un régulateur demande une divulgation sélective et que quelqu’un doit utiliser la fonctionnalité sous pression, plutôt que seulement dans la documentation
