Відкритий код є основою віри у блокчейн і необхідною умовою створення системи без довіри. Але коли ці принципи стикаються з приватними блокчейнами, орієнтованими на фінансову сферу, наприклад Dusk, виникають ускладнення.

Уявімо велику фінансову установу, яка розглядає можливість використання певного блокчейну для обробки ключових активів. Що вони спершу зроблять? Вивернуть вихідний код навиворіт. Це дійсно полегшує аудит, але за якою ціною? — усі технічні деталі реалізації, всі можливі вразливості, всі бізнес-логіки — будуть чітко видні конкурентам і зловмисним хакерам.

Для проектів, що проголошують "приватність + відповідність", ця дилема особливо болюча. Ваша ключова конкурентна перевага часто прихована саме у дизайні коду. Відкритий код означає, що ви даруєте свої основні карти імітаторам.

Більш реальна проблема полягає в тому, що фінансові установи зазвичай розробляють на вашому ланцюзі власні приватні смарт-контракти — ці контракти часто містять їхні комерційні таємниці та конкурентні переваги. Якщо проектна команда наполягає, щоб усе було відкритим, ці установи навряд чи погодяться. Це породжує замкнене коло: щоб залучити фінансових гігантів, потрібно надати їм приватний простір; але таке рішення, здається, суперечить ідеї відкритого співтовариства.

Здається, єдиний вихід — це багаторівнева стратегія: основна інфраструктура залишається відкритою та прозорою для отримання довіри та безпеки аудиту; але на рівні додатків і бізнес-логіки залишаються достатньо автономії. Це дозволяє уникнути повної комерційної компромісу і не відлякує клієнтів через ідеалізм. Проблема в тому, як пройти цю тонку лінію — ніхто не дає стандартної відповіді.