Потратил немного времени сегодня, разбираясь, как доступ к аудиту на самом деле должен работать в Dusk, а не просто повторяя всем известный слоган про «приватность». Заходил с ожиданием, что будет какой-то админский оверрайд — бэкдор, который регуляторы могли бы просто включить. Но нет, дело не в этом.

Вместо этого Dusk использует что-то ближе к механизму view-key: транзакция по умолчанию остаётся скрытой (shielded), но отправитель может сгенерировать ключ, который позволяет конкретному аудитору расшифровать детали именно этой транзакции, не раскрывая при этом остальную историю кошелька. Небольшая разница, но она меняет всю модель — раскрытие становится тем, что пользователь разрешает для каждой транзакции, а не тем, что «вшито» в стандартную видимость цепочки.

Вот к чему я постоянно возвращаюсь. Это работает только если аудитор, получающий этот ключ, доверенный и умеет обращаться с ним правильно. Цепочка обеспечивает криптографию, но не то, что происходит с данными после того, как их расшифровывают вне цепочки. Поэтому тезис «приватность И соответствие требованиям» действительно правдив на уровне протокола, но «последняя миля» всё равно опирается на институциональное доверие — так же, как это устроено в традиционных финансах.

Похоже, Dusk Network сузила проблему «приватность против прозрачности», а не решила её полностью — и, честно говоря, это звучит гораздо правдоподобнее, чем проект, который заявляет, что полностью «раскусил» её. Для контекста: текущие $DUSK находятся в диапазоне низких однозначных центов.

@Dusk вся эта теоретическая конструкция держится на том, что такой компромисс работает на практике.

Если доверие к аудиту всё ещё зависит от того, как аудитор ведёт себя, то $DUSK действительно решил проблему приватности и соответствия, или просто перенёс место, где должно сидеть это доверие?

#DUSK