#dusk $DUSK @Dusk Dusk's конфиденциальная настройка на самом деле работает в двух отдельных треках. В DuskDS модель Phoenix представляет значение как ноты, зафиксированные в дереве Меркла — при расходовании ноты не указывается, какая именно нота расходуется. Вместо этого отправитель публикует нулевой нултификатор (nullifier) и доказательство с нулевым разглашением, показывающее, что расход корректен, что право собственности действительно, и что не было создано стоимости «из ничего», при этом не раскрывая лежащую в основе ноту. Параллельно с этим Moonlight работает как прозрачная, аккаунтная модель в той же цепочке.

Однако в DuskEVM конфиденциальность обеспечивается совершенно другим набором инструментов — модулем под названием Hedger, который сочетает гомоморфное шифрование на базе ElGamal с доказательствами с нулевым разглашением, а также использует гибридную структуру UTXO/аккаунт. Здесь пользователь взаимодействует с контрактами через стандартный адрес EVM, а отдельный адрес Hedger управляет зашифрованными балансами, при этом соответствие (комплаенс) обеспечивается через allowlisting.

Это не две версии одной и той же идеи. Phoenix — это нотная система доказательств; Hedger выполняет вычисления непосредственно над зашифрованными балансами, которые подтверждаются доказательствами с нулевым разглашением. Вероятная причина разделения в том, что нотная приватность не ложится естественным образом в аккаунтную структуру EVM, поэтому там потребовался другой подход.

Запуск двух независимых криптографических «стеков» приватности параллельно означает больший вектор атаки и более тяжелое бремя аудита. Также неясно, как сохраняется гарантия приватности при переносе стоимости между двумя уровнями.

Поддержание двух отдельных механизмов конфиденциальности пропорционально увеличивает бремя аудита, или же совместная опора на доказательства с нулевым разглашением означает, что дополнительные затраты второго механизма на самом деле ниже, чем кажется?