Сеть начала «копать» в сторону «доступа аудитора», потому что это обычно самая туманная часть любого питча про приватные монеты. Хотел понять реальный механизм, а не просто фразу.
Dusk использует две модели транзакций параллельно: Moonlight (полностью публичная, как обычная модель аккаунта) и Phoenix (защищённая, конфиденциальные балансы/переводы). Вы выбираете для каждой транзакции. В этой части всё просто.
А вот чего я не ожидал: раскрытие аудитору — это не «аудитор получает мастер‑ключ ко всему». Согласно собственному описанию Dusk, пользователь шифрует полезную нагрузку транзакции пользовательским ключом, а затем шифрует этот пользовательский ключ ключом аудитора — так что расшифровать её может только конкретный аудитор. Затем нулевое доказательство (zero‑knowledge proof) подтверждает, что ключ аудитора действительно был использован корректно, не раскрывая полезную нагрузку никому, кто проверяет цепочку.
То есть это раскрытие по транзакциям и с привязкой к ключу, а не «бэкдор», сидящий на всей системе. Нет ключа аудитора — нет доступа, точка, даже для собственных валидаторов сети.
Пробел, который я не смог полностью закрыть: в документации это описано на уровне идентичности Citadel, но я не нашёл публичного случая, где регулятор реально вытягивал данные по этому процессу на мейннете. На бумаге всё выглядит убедительно, но «аудитор расшифровывает одну транзакцию с помощью доказуемого шифрования» и «реальный рабочий процесс регулятора во время живого аудита» — это разные проверки.
Кто-нибудь видел, чтобы это срабатывало в реальном сценарии комплаенса, а не только описано как возможность
#dusk $DUSK #dusk $DUSK
Dusk использует две модели транзакций параллельно: Moonlight (полностью публичная, как обычная модель аккаунта) и Phoenix (защищённая, конфиденциальные балансы/переводы). Вы выбираете для каждой транзакции. В этой части всё просто.
А вот чего я не ожидал: раскрытие аудитору — это не «аудитор получает мастер‑ключ ко всему». Согласно собственному описанию Dusk, пользователь шифрует полезную нагрузку транзакции пользовательским ключом, а затем шифрует этот пользовательский ключ ключом аудитора — так что расшифровать её может только конкретный аудитор. Затем нулевое доказательство (zero‑knowledge proof) подтверждает, что ключ аудитора действительно был использован корректно, не раскрывая полезную нагрузку никому, кто проверяет цепочку.
То есть это раскрытие по транзакциям и с привязкой к ключу, а не «бэкдор», сидящий на всей системе. Нет ключа аудитора — нет доступа, точка, даже для собственных валидаторов сети.
Пробел, который я не смог полностью закрыть: в документации это описано на уровне идентичности Citadel, но я не нашёл публичного случая, где регулятор реально вытягивал данные по этому процессу на мейннете. На бумаге всё выглядит убедительно, но «аудитор расшифровывает одну транзакцию с помощью доказуемого шифрования» и «реальный рабочий процесс регулятора во время живого аудита» — это разные проверки.
Кто-нибудь видел, чтобы это срабатывало в реальном сценарии комплаенса, а не только описано как возможность
#dusk $DUSK #dusk $DUSK