#dusk Я заново выстроил архитектурные документы @Dusk — в первую очередь меня задержало не доказательство с нулевым разглашением. Меня остановил сам факт: почему одна и та же сеть должна одновременно сохранять две схемы переводов — публичную и приватную. Многие проекты относятся к приватности как к переключателю: включил — ничего не видно, выключил — всё прозрачно. Но когда попадаешь в реальный финансовый сценарий, оказывается, что «либо одно, либо другое» недостаточно. Платёжная сторона хочет защитить остаток, эмитенту может понадобиться проверять соответствие, а аудитору нужно получать доказательства в заранее определённых пределах.
В основе Dusk делает Moonlight моделью публичных аккаунтов, а Phoenix — моделью приватного UTXO. Оба варианта умеют переводить $DUSK , платить Gas и выступать входом для выполнения контрактов. Сверху также выделяются DuskVM, которая напрямую запускает контракты на Rust/WASM, и DuskEVM, ориентированная на инструментарий Solidity. Самое интересное здесь не в том, что это «приватная цепочка». Интерес в том, что публичные расчёты, приватные переводы и совместимость с приложениями выполняют разные задачи — каждая на своём месте.
Однако то, что слои логично разнесены по ролям, не означает, что границы для пользователя автоматически становятся очевидными. Когда именно деньги переходят из публичного баланса в приватный, кто имеет право на выборочное раскрытие, какой путь использует приложение — DuskVM или DuskEVM, можно ли проверять состояние между слоями обычному человеку — всё это повышает сложность понимания. Особенно в отношении регулируемых активов: приватность — это не отказ раскрывать, а ограничение объекта, содержания и времени раскрытия. Любая расплывчатость в дизайне прав в итоге может превратиться в очередную «чёрную коробку».
Поэтому, когда я смотрю на Dusk, я не ограничиваюсь вопросом, может ли он скрыть один конкретный перевод. Мне важнее другое: когда нужно — сможет ли система предоставить достаточно доказательств; когда нужно скрывать — позволит ли она раскрывать минимум несвязанных данных; и сохраняется ли ясность после переключения между двумя путями. Направление архитектуры верное, но настоящая трудность — оставить сложность в протоколе, а не перекладывать её на пользователя.
$SNXXB $BTC
В основе Dusk делает Moonlight моделью публичных аккаунтов, а Phoenix — моделью приватного UTXO. Оба варианта умеют переводить $DUSK , платить Gas и выступать входом для выполнения контрактов. Сверху также выделяются DuskVM, которая напрямую запускает контракты на Rust/WASM, и DuskEVM, ориентированная на инструментарий Solidity. Самое интересное здесь не в том, что это «приватная цепочка». Интерес в том, что публичные расчёты, приватные переводы и совместимость с приложениями выполняют разные задачи — каждая на своём месте.
Однако то, что слои логично разнесены по ролям, не означает, что границы для пользователя автоматически становятся очевидными. Когда именно деньги переходят из публичного баланса в приватный, кто имеет право на выборочное раскрытие, какой путь использует приложение — DuskVM или DuskEVM, можно ли проверять состояние между слоями обычному человеку — всё это повышает сложность понимания. Особенно в отношении регулируемых активов: приватность — это не отказ раскрывать, а ограничение объекта, содержания и времени раскрытия. Любая расплывчатость в дизайне прав в итоге может превратиться в очередную «чёрную коробку».
Поэтому, когда я смотрю на Dusk, я не ограничиваюсь вопросом, может ли он скрыть один конкретный перевод. Мне важнее другое: когда нужно — сможет ли система предоставить достаточно доказательств; когда нужно скрывать — позволит ли она раскрывать минимум несвязанных данных; и сохраняется ли ясность после переключения между двумя путями. Направление архитектуры верное, но настоящая трудность — оставить сложность в протоколе, а не перекладывать её на пользователя.
$SNXXB $BTC
