Вчера ночью, просматривая документы Dusk, я наконец понял, что все это время слишком упрощенно трактовал фразу «поддержка EVM». Dusk не просто «складывает» весь контракт в одну виртуальную машину: знакомые приложения на Solidity и Foundry могут идти через DuskEVM. Газ оплачивается с помощью @Dusk DUSK, а пакетные данные и подтверждения состояний передаются на DuskDS для последующего расчета; если нужны нативная приватность и возможности нулевого знания или смарт‑контракты с управлением активами на уровне протокола, то они запускаются напрямую на DuskVM с помощью Rust/WASM.

Я понял это как два операционных пульта от одной и той же расчетной организации. Один оставляет привычные кнопки — миграция проходит быстрее; другой ближе к базовому «казначейству» и позволяет вызывать более нативные правила. В итоге все возвращается к одному и тому же расчетному основанию, где подтверждается книга. Такой компромисс важнее, чем просто «совместимость с EVM», потому что он разделяет эффективность разработки и нативные возможности.

Но наличие двух путей также добавляет сложности мостов и взаимодействия между слоями, и нужно точно определять состояние. В официальной документации прямо указано: быстрый пакетинг в DuskEVM не означает, что расчет уже завершен в DuskDS. Я не буду считать, что все окончательно сделано, лишь по тому, что на странице показан «успех». Дальше нужно посмотреть, насколько гладким будет кросс‑слойный опыт, насколько зрелы инструменты и растет ли объем реально развернутых контрактов. Архитектура дает выбор — а решение даст ответ.

#dusk $DUSK