#dusk $DUSK Переведення_Примечание: репозитории GitHub DUSK оказались куда интереснее, чем чтение «белой книги». С апреля по июнь 2026 года в репозитории rusk появился часто встречающийся ключевой термин: revocation. В трёх подряд версиях minor release снова и снова дополнялись пограничные кейсы, связанные с отзываемыми (revocation) Citadel-учётными данными: как поступать с токенами «квалифицированного инвестора», выданными после банкротства организации; как синхронизировать списки отзыва между юрисдикциями; нужно ли аннулировать ZK-доказательства, которые были уже сгенерированы после отзыва.
Это как раз та уязвимость DUSK, которую проще всего упустить из виду. Все смотрят на приватность Phoenix (privacy UTXO) и на выборочное раскрытие Hedger, и кажется, что модель «по умолчанию скрыто + авторизация с возможностью проверки» уже примирила противоречие между комплаенсом и приватностью. Но якорь доверия в identity-слое Citadel — это не ZK-схемы, а сам эмитент: если эмитент обанкротится или у него отзовут лицензию, все credential, которые он исторически выдал, в юридическом смысле сразу превращаются в бумажки, а вот доказательства, которые уже на цепочке были построены с использованием этих credential, автоматически недействительными не становятся.
Отсюда — старый вопрос: «я соответствовал условиям тогда» и «я всё ещё соответствую условиям» — это разные утверждения. Второе требует проверки отзыва в реальном времени, а проверка в реальном времени либо идёт on-chain (дорого по gas), либо через oracle (ухудшение модели доверия). В документации DUSK почти не раскрыты ключевые параметры управления: окно задержки отзыва, страховая ответственность эмитента, маппинг credential между юрисдикциями. А ведь именно эти параметры в первую очередь спрашивают лицензированные финансовые организации при due diligence.
Код может помочь с «как доказать», но не решает «кто решает». Если DUSK в ближайший год не пропишет governance-фреймворк Citadel в юридически обязательных дополнительных соглашениях и не заставит NPEX или 21X (и подобных) лицензированных участников брать на себя эмиссионную ответственность в форме контрактов, то в глазах институциональных клиентов это так и останется «технологическим прототипом», а не доверенной (custodied) финансовой инфраструктурой.
#dusk @Dusk
Это как раз та уязвимость DUSK, которую проще всего упустить из виду. Все смотрят на приватность Phoenix (privacy UTXO) и на выборочное раскрытие Hedger, и кажется, что модель «по умолчанию скрыто + авторизация с возможностью проверки» уже примирила противоречие между комплаенсом и приватностью. Но якорь доверия в identity-слое Citadel — это не ZK-схемы, а сам эмитент: если эмитент обанкротится или у него отзовут лицензию, все credential, которые он исторически выдал, в юридическом смысле сразу превращаются в бумажки, а вот доказательства, которые уже на цепочке были построены с использованием этих credential, автоматически недействительными не становятся.
Отсюда — старый вопрос: «я соответствовал условиям тогда» и «я всё ещё соответствую условиям» — это разные утверждения. Второе требует проверки отзыва в реальном времени, а проверка в реальном времени либо идёт on-chain (дорого по gas), либо через oracle (ухудшение модели доверия). В документации DUSK почти не раскрыты ключевые параметры управления: окно задержки отзыва, страховая ответственность эмитента, маппинг credential между юрисдикциями. А ведь именно эти параметры в первую очередь спрашивают лицензированные финансовые организации при due diligence.
Код может помочь с «как доказать», но не решает «кто решает». Если DUSK в ближайший год не пропишет governance-фреймворк Citadel в юридически обязательных дополнительных соглашениях и не заставит NPEX или 21X (и подобных) лицензированных участников брать на себя эмиссионную ответственность в форме контрактов, то в глазах институциональных клиентов это так и останется «технологическим прототипом», а не доверенной (custodied) финансовой инфраструктурой.
#dusk @Dusk
Citadel的凭证吊销到底多难解决
0%
ZK证明的"时间差"风险有多大?
100%
签发方倒闭后链上凭证怎么办?
0%
1 проголосовали • Голосование закрыто