Le code source est la base de la confiance dans la blockchain, ainsi que la condition nécessaire pour créer un système sans confiance. Mais lorsque ce principe rencontre des blockchains privées axées sur la finance comme Dusk, le problème devient plus complexe.

Imaginez une grande institution financière envisageant d'utiliser une certaine blockchain pour traiter ses transactions d'actifs principaux. Que doivent-ils faire en premier ? Examiner le code source dans ses moindres détails. Bien que cela facilite l'audit, à quel prix ? — tous les détails techniques, toutes les vulnérabilités potentielles, toutes les idées de logique métier sont visibles pour les concurrents et les hackers malveillants.

Pour un projet qui prône "privacy + conformité", ce paradoxe est particulièrement douloureux. Votre avantage concurrentiel réside souvent dans la conception même du code. L'open source complet revient à donner ses atouts principaux à des imitateurs.

Une problématique plus concrète est que les institutions financières développent généralement leurs propres contrats intelligents propriétaires sur votre chaîne — ces contrats contiennent souvent leurs secrets commerciaux et leur avantage concurrentiel. Si le projet impose que tout doit être open source, ces institutions ne seront pas d’accord. Cela crée un cercle vicieux : pour attirer les géants de la finance, il faut leur offrir un espace privé ; mais faire cela semble aller à l’encontre des principes de la communauté open source.

La seule solution apparente est une stratégie en couches — l’infrastructure de base reste open source et transparente, pour gagner la confiance et assurer la sécurité de l’audit ; mais au niveau des applications et de la logique commerciale, laisser suffisamment d’autonomie. Ainsi, on évite à la fois de tomber dans des compromis commerciaux excessifs et de faire fuir les clients par idéalisme. La question est : comment tracer cette ligne, personne ne donne de réponse standard.