Когда я читал white paper, этот вопрос постоянно крутился в голове. Главное повествование Dusk — «мы хотим и приватность, и соответствие требованиям», — но мой прошлый опыт подсказывает, что такие заявления обычно никому не нравятся. #dusk
Сначала посмотрим на обратную сторону медали. Zcash и Monero довели приватность до предела, но регуляторы не приняли это; биржи сняли их с листинга, и ликвидность начала падать. Ethereum и Bitcoin с точки зрения комплаенса проблем не имеют, но все операции прозрачны: когда крупная организация совершает сделку большого объёма, контрагент видит всё как на ладони. Dusk говорит, что нашёл третье решение — поначалу я сомневался. @Dusk
В white paper предлагается схема двойных транзакций плюс протокол Zedger. Moonlight используется для сценариев комплаенса, Phoenix — для сценариев приватности, а Zedger обеспечивает выполнение смарт‑контрактов в конфиденциальном состоянии, сохраняя при этом возможность аудита. Теоретически такая архитектура действительно может сработать.
Но когда я дочитал, я обнаружил ключевой пробел. В white paper говорится, что регуляторы могут получить доступ к необходимым данным, но не раскрывается, как именно они это делают: через какие механизмы выдается разрешение, кто хранит ключи, как отзываются права доступа. Самая сложная часть аудируемой системы приватности — не заставить регуляторов видеть данные, а гарантировать, что данные видит только тот, кому это разрешено, и только в течение авторизованного периода.
Я попробовал рассуждать с этой точки зрения. Если бы Dusk использовал доказательства наподобие zk‑SNARK, и у регулятора был бы определённый аудиторский ключ, то $DUSK мог бы проверять соблюдение комплаенса транзакций, не раскрывая приватность пользователя. Тогда такая схема была бы обоснована. Но если регуляторские полномочия будут злоупотреблены или ключи утекут, то «небоскрёб» защиты приватности рухнет.
Поэтому мой вывод такой: сосуществование приватности и комплаенса в принципе возможно, и в инженерном плане тоже может быть реализовано, но реальный эффект полностью зависит от тонкостей дизайна механизма контроля прав. А поскольку в white paper пока не представлены эти детали, мне остаётся ждать выхода дополнительных технических документов и только потом делать оценку. Ответ на этот вопрос — не в white paper, а в коде основной сети.
Сначала посмотрим на обратную сторону медали. Zcash и Monero довели приватность до предела, но регуляторы не приняли это; биржи сняли их с листинга, и ликвидность начала падать. Ethereum и Bitcoin с точки зрения комплаенса проблем не имеют, но все операции прозрачны: когда крупная организация совершает сделку большого объёма, контрагент видит всё как на ладони. Dusk говорит, что нашёл третье решение — поначалу я сомневался. @Dusk
В white paper предлагается схема двойных транзакций плюс протокол Zedger. Moonlight используется для сценариев комплаенса, Phoenix — для сценариев приватности, а Zedger обеспечивает выполнение смарт‑контрактов в конфиденциальном состоянии, сохраняя при этом возможность аудита. Теоретически такая архитектура действительно может сработать.
Но когда я дочитал, я обнаружил ключевой пробел. В white paper говорится, что регуляторы могут получить доступ к необходимым данным, но не раскрывается, как именно они это делают: через какие механизмы выдается разрешение, кто хранит ключи, как отзываются права доступа. Самая сложная часть аудируемой системы приватности — не заставить регуляторов видеть данные, а гарантировать, что данные видит только тот, кому это разрешено, и только в течение авторизованного периода.
Я попробовал рассуждать с этой точки зрения. Если бы Dusk использовал доказательства наподобие zk‑SNARK, и у регулятора был бы определённый аудиторский ключ, то $DUSK мог бы проверять соблюдение комплаенса транзакций, не раскрывая приватность пользователя. Тогда такая схема была бы обоснована. Но если регуляторские полномочия будут злоупотреблены или ключи утекут, то «небоскрёб» защиты приватности рухнет.
Поэтому мой вывод такой: сосуществование приватности и комплаенса в принципе возможно, и в инженерном плане тоже может быть реализовано, но реальный эффект полностью зависит от тонкостей дизайна механизма контроля прав. А поскольку в white paper пока не представлены эти детали, мне остаётся ждать выхода дополнительных технических документов и только потом делать оценку. Ответ на этот вопрос — не в white paper, а в коде основной сети.