#dusk $DUSK @Dusk
Ces derniers temps, j’observe Dusk sous un angle différent.
Plutôt que de commencer par « à quel point Dusk est-il privé ? », je m’intéresse davantage à ce qui se passe réellement sous cette couche de confidentialité.
Dusk est conçu autour de cas d’usage financiers, avec XSC permettant une logique de contrat intelligent confidentielle. Mais cela soulève un ensemble de questions bien plus difficiles :
→ Que peuvent réellement observer les validateurs ?
→ Qu’est-ce qui reste caché pendant l’exécution ?
→ Quelles garanties proviennent de la cryptographie, et lesquelles dépendent d’hypothèses réseau ou de l’implémentation ?
→ Comment les garanties de confidentialité sont-elles préservées à mesure que le protocole évolue ?
La gouvernance m’intéresse particulièrement. Un protocole conçu pour la finance réglementée ne peut pas considérer les mises à niveau comme de simples sorties de fonctionnalités. Des changements touchant l’exécution, la confidentialité ou la vérification pourraient directement affecter le modèle de confiance sur lequel reposent les applications.
Ainsi, plutôt que d’affirmer que j’ai déjà les réponses, je m’attaque d’abord à l’architecture.
Si vous aviez à réviser Dusk sous l’angle de la sécurité, quelle couche auditeriez-vous en premier, avant tout le reste ?
$DUSK #dusk
Ces derniers temps, j’observe Dusk sous un angle différent.
Plutôt que de commencer par « à quel point Dusk est-il privé ? », je m’intéresse davantage à ce qui se passe réellement sous cette couche de confidentialité.
Dusk est conçu autour de cas d’usage financiers, avec XSC permettant une logique de contrat intelligent confidentielle. Mais cela soulève un ensemble de questions bien plus difficiles :
→ Que peuvent réellement observer les validateurs ?
→ Qu’est-ce qui reste caché pendant l’exécution ?
→ Quelles garanties proviennent de la cryptographie, et lesquelles dépendent d’hypothèses réseau ou de l’implémentation ?
→ Comment les garanties de confidentialité sont-elles préservées à mesure que le protocole évolue ?
La gouvernance m’intéresse particulièrement. Un protocole conçu pour la finance réglementée ne peut pas considérer les mises à niveau comme de simples sorties de fonctionnalités. Des changements touchant l’exécution, la confidentialité ou la vérification pourraient directement affecter le modèle de confiance sur lequel reposent les applications.
Ainsi, plutôt que d’affirmer que j’ai déjà les réponses, je m’attaque d’abord à l’architecture.
Si vous aviez à réviser Dusk sous l’angle de la sécurité, quelle couche auditeriez-vous en premier, avant tout le reste ?
$DUSK #dusk