J’ai relu la documentation technique de Dusk hier soir et je suis reparti avec plus d’intérêt pour les questions de conception que pour les affirmations en première page.

La première chose qui me revenait sans cesse à l’esprit concernait la confidentialité et la réglementation. Dusk semble les traiter comme des objectifs complémentaires plutôt qu’opposés, mais comment cet équilibre fonctionne-t-il concrètement ? Phoenix peut conserver les détails des transactions privés grâce aux preuves à connaissance nulle (ZK), tandis que la conception globale tient compte de l’auditabilité. Cela soulève une question importante pour les marchés réglementés : qui a le droit de voir quoi, et dans quelles conditions ?

Ensuite, je me suis penché sur Kadcast. Au lieu de s’appuyer sur une propagation de type “commérage” conventionnelle, Dusk utilise une structure basée sur Kademlia pour réduire la transmission redondante des messages. Je comprends l’argument d’efficacité, mais je suis davantage curieux des compromis en matière de sécurité. L’optimisation du routage pourrait-elle créer de nouvelles façons d’influencer ou d’isoler des portions du réseau ?

Le design du consensus m’a aussi posé une question. Dusk utilise un PoS (preuve d’enjeu) basé sur des comités, avec extraction déterministe. L’enjeu (stake) influence la fréquence à laquelle les pourvoyeurs reçoivent des crédits et participent aux comités. Cela semble efficace, mais comment cela se comporte-t-il lorsque l’enjeu devient de plus en plus concentré ?

Plus je lisais, moins je pense que la question vraiment intéressante se résume à savoir si Dusk est “rapide” ou “privé”.

À quel point le système reste-t-il décentralisé à mesure que la participation institutionnelle augmente ? Et où se situent les limites réelles entre efficacité, confidentialité, gouvernance et sécurité ?

@Dusk
#dusk $DUSK