#dusk $DUSK @Dusk Je me souviens que mon petit frère Waqas m’a posé une question qui m’a fait repenser le design de la confidentialité de Dusk. Si les utilisateurs peuvent choisir la quantité d’informations à révéler, est-ce que cela ne rend pas le développement plus difficile ?

Honnêtement, j’ai été surpris par ce que cette question a mis en lumière. Le vrai problème n’est pas en soi l’existence de transactions masquées. Le problème, c’est que les développeurs ne peuvent pas considérer le registre public comme une source complète de l’état de l’application.

Cette hypothèse compte dès le niveau de l’infrastructure. Les portefeuilles, les indexeurs et les systèmes financiers doivent prendre en compte les cas où les informations qu’ils utilisent normalement pour la découverte, la récupération ou la comptabilité ne sont pas disponibles publiquement.

Ce qui m’a particulièrement interpellé, c’est ce qui se passe à un niveau supérieur. Les développeurs doivent distinguer les fonctions qui nécessitent réellement des détails au niveau des transactions de celles qui peuvent fonctionner sans.

Au lieu de construire en partant d’une visibilité maximale des données et d’ajouter ensuite la confidentialité, les applications doivent définir leurs dépendances en matière de données en tenant déjà compte de la confidentialité. C’est le compromis architectural qui, selon moi, est le plus intéressant dans Dusk. La confidentialité modifie ce que les logiciels financiers peuvent savoir par défaut, et donc la manière dont ces logiciels doivent être conçus.

Accepteriez-vous de sacrifier un peu de simplicité de développement pour un modèle d’application où la confidentialité est intégrée aux hypothèses sous-jacentes dès le premier jour ? 🤔