В понедельник вечером я изучал $DUSK разработческую документацию и заметил: две линии входов идут рядом — EVM-путь и нативный ZK-путь. Сначала мне это не показалось чем-то особенным. Тогда я думал: чем это отличается от того, что другие блокчейны делают совместимость? В EVM-цепи добавляют модуль приватности, в ZK-цепи — EVM-совместимость: разве это не один и тот же шаблон?
Но потом я обратил внимание на одну деталь: обе эти линии используют один и тот же слой расчётов DuskDS. Пакетное состояние DuskEVM «анкорится» в DuskDS, а контракты DuskVM напрямую исполняются в Dusk L1; в итоге обе системы сходятся в одном консенсусе и слое доступности. Это значит, что разработчик может начать с EVM-пути: на Solidity и на привычном инструментальном стеке развернуть приложение. А дальше — при необходимости включить приватность через Hedger и шаг за шагом дойти до нативного ZK-пути, не нужно менять сеть.
Hedger использует гомоморфное шифрование и ZK-доказательства — он специально спроектирован для EVM-среды, и это отличается от пути, который идёт Zedger с его UTXO-моделью. Разработчики сначала прогоняют бизнес-логику на EVM-пути. Когда потребуется более глубокий контроль приватности, они переходят через Hedger, а затем мигрируют на нативные ZK-контракты DuskVM. Весь процесс не требует покидать экосистему Dusk.
Этот момент заставил меня пересмотреть всё ещё раз. У других блокчейнов «двойные пути» обычно — это две независимые сети: активы перетекают туда-сюда, и выбрав один вариант, разработчику трудно вернуться обратно. Когда же @Dusk DuskDS связывает оба пути в едином слое расчётов, активы могут свободно перемещаться между двумя средами. Миграция разработчика с EVM на нативный ZK становится похожей скорее на апгрейд, а не на переезд в другую сеть. Я вернулся назад и перечитал фразу на сайте: «активы могут свободно переключаться между двумя средами» — и только тогда понял, что это действительно и есть главное.
Я продолжу следить за данными после запуска DuskEVM mainnet — сколько разработчиков на Solidity сделают шаг через Hedger. Если этот сценарий подтвердится, #dusk может стать первой цепью, где разработчики «скользят» с EVM в нативный ZK без необходимости менять сеть на полпути.
Но потом я обратил внимание на одну деталь: обе эти линии используют один и тот же слой расчётов DuskDS. Пакетное состояние DuskEVM «анкорится» в DuskDS, а контракты DuskVM напрямую исполняются в Dusk L1; в итоге обе системы сходятся в одном консенсусе и слое доступности. Это значит, что разработчик может начать с EVM-пути: на Solidity и на привычном инструментальном стеке развернуть приложение. А дальше — при необходимости включить приватность через Hedger и шаг за шагом дойти до нативного ZK-пути, не нужно менять сеть.
Hedger использует гомоморфное шифрование и ZK-доказательства — он специально спроектирован для EVM-среды, и это отличается от пути, который идёт Zedger с его UTXO-моделью. Разработчики сначала прогоняют бизнес-логику на EVM-пути. Когда потребуется более глубокий контроль приватности, они переходят через Hedger, а затем мигрируют на нативные ZK-контракты DuskVM. Весь процесс не требует покидать экосистему Dusk.
Этот момент заставил меня пересмотреть всё ещё раз. У других блокчейнов «двойные пути» обычно — это две независимые сети: активы перетекают туда-сюда, и выбрав один вариант, разработчику трудно вернуться обратно. Когда же @Dusk DuskDS связывает оба пути в едином слое расчётов, активы могут свободно перемещаться между двумя средами. Миграция разработчика с EVM на нативный ZK становится похожей скорее на апгрейд, а не на переезд в другую сеть. Я вернулся назад и перечитал фразу на сайте: «активы могут свободно переключаться между двумя средами» — и только тогда понял, что это действительно и есть главное.
Я продолжу следить за данными после запуска DuskEVM mainnet — сколько разработчиков на Solidity сделают шаг через Hedger. Если этот сценарий подтвердится, #dusk может стать первой цепью, где разработчики «скользят» с EVM в нативный ZK без необходимости менять сеть на полпути.
