Когда я впервые увидел архитектурную схему DUSK, у меня возник вопрос: зачем нужны два виртуальных машины? DuskVM запускает нативные смарт-контракты, а DuskEVM — контракты, совместимые с Ethereum. Разве это не добавляет сложности? Но после более глубокого исследования я понял, что такая конструкция на самом деле предназначена для решения вполне реальной проблемы: выбора между безопасностью и производительностью.
DuskVM — нативная виртуальная машина DUSK. Она напрямую работает поверх консенсусного слоя и может обращаться ко всем базовым возможностям, например к zk-доказательствам, приватным транзакциям и протоколу Phoenix. А DuskEVM построена на OP Stack: она выполняет смарт-контракты Ethereum, но финальное расчёты выполняет DuskDS. Ключевое различие в том, что в DuskVM контракты привязаны к консенсусной безопасности DUSK, а в DuskEVM контракты зависят от внешнего слоя-«моста».
Отсюда интересное разделение ролей: чувствительные активы (например, токены RWA, регулируемые активы) следует размещать в DuskVM, потому что им нужно напрямую использовать приватность и механизмы соответствия DUSK; а обычные DeFi-приложения (например, децентрализованные биржи и кредитные протоколы) можно разместить в DuskEVM, так как разработчикам достаточно перенести существующий код Ethereum — не нужно переписывать контракты с нуля.
Я посмотрел отзывы разработчиков: при развёртывании клона Uniswap V2 в DuskEVM нужно изменить примерно 20 строк кода (в основном — адаптировать параметры сети). Но если разрабатывать с нуля в DuskVM, понадобится сотни строк кода. При этом транзакции в DuskVM быстрее (в среднем 1,5 секунды на блок) и не требуется платить комиссию за мост. По сути, это выбор между «эффективностью разработки» и «производительностью».
Ещё один важный момент — изоляция безопасности. Данные DuskVM и DuskEVM физически разделены: контракты DuskEVM не могут напрямую получить доступ к приватному состоянию DuskVM. Это предотвращает сценарии вроде «flash loan attack» через уязвимости межслойного доступа. В официальном отчёте по безопасности DUSK за сентябрь 2025 года уделили особое внимание тестированию вызовов между VM: выяснилось, что все вызовы должны проходить через «песочничный шлюз», который проверяет права и тип вызывающего — чтобы не допустить проникновения вредоносного кода.$BTC
Но, на мой взгляд, у такой двухархитектурности есть и потенциальные риски: если в логике мостов между двумя VM появится уязвимость, её могут использовать. Например, злоумышленник может подделать вызов контракта DuskEVM, чтобы истощить ресурсы DuskVM.
#dusk @Dusk $DUSK