Я никак не могу разобраться: если и суммы сделок, и участники скрыты, как тогда производится аудит регулируемых активов? А если всё раскрывается в рамках соответствия, что тогда вообще остаётся от приватности?
Я поначалу думал, что Dusk — это просто «добавить слой ZK‑доказательства к переводу». Пока не наткнулся на Moonlight и Phoenix в официальной документации: оказалось, что они прокладывают две нативные ветки в одном и том же расчётном слое.
Moonlight — это модель публичных аккаунтов: отправитель, получатель и сумма видимы. Phoenix же использует зашифрованные векселя для фиксации средств: с помощью ZK‑доказательств подтверждается отсутствие двойной траты и достаточность баланса, но не раскрываются детали транзакции. В итоге оба варианта завершаются в DuskDS, где Transfer Contract отдельно их проверяет.
Это похоже на обычную линию и приватную линию того же вокзала: первая показывает информацию о платформах, вторая закрывает шторы. Но при аудите через viewing key можно адресно открыть окно для проверки. Citadel 2 расширяет подход на уровень идентичности: пользователи доказывают, что у них есть подходящие действительные атрибуты, не публикуя личные характеристики или конкретные предъявляемые документы.
Поэтому я считаю, что Dusk решает не задачу «как уйти от регулирования», а вопрос, для кого финансовые данные должны быть прозрачными. И риски здесь тоже: документы выдаются License Provider, а Service Provider всё равно должен решить, кому доверять; хранение и выдача viewing key тоже формируют новые границы управления. Смогут ли полномочия на раскрытие быть предметом аудита, отзыва и надлежащего управления — вот что мне интересно наблюдать дальше.
#dusk $DUSK @Dusk
Я поначалу думал, что Dusk — это просто «добавить слой ZK‑доказательства к переводу». Пока не наткнулся на Moonlight и Phoenix в официальной документации: оказалось, что они прокладывают две нативные ветки в одном и том же расчётном слое.
Moonlight — это модель публичных аккаунтов: отправитель, получатель и сумма видимы. Phoenix же использует зашифрованные векселя для фиксации средств: с помощью ZK‑доказательств подтверждается отсутствие двойной траты и достаточность баланса, но не раскрываются детали транзакции. В итоге оба варианта завершаются в DuskDS, где Transfer Contract отдельно их проверяет.
Это похоже на обычную линию и приватную линию того же вокзала: первая показывает информацию о платформах, вторая закрывает шторы. Но при аудите через viewing key можно адресно открыть окно для проверки. Citadel 2 расширяет подход на уровень идентичности: пользователи доказывают, что у них есть подходящие действительные атрибуты, не публикуя личные характеристики или конкретные предъявляемые документы.
Поэтому я считаю, что Dusk решает не задачу «как уйти от регулирования», а вопрос, для кого финансовые данные должны быть прозрачными. И риски здесь тоже: документы выдаются License Provider, а Service Provider всё равно должен решить, кому доверять; хранение и выдача viewing key тоже формируют новые границы управления. Смогут ли полномочия на раскрытие быть предметом аудита, отзыва и надлежащего управления — вот что мне интересно наблюдать дальше.
#dusk $DUSK @Dusk