Когда публичная сеть добавляет совместимость с EVM, я обычно предполагаю, что нативная среда исполнения постепенно теряет приоритет. Инструменты для EVM привлекают больше разработчиков, Solidity становится по умолчанию, а отдельный нативный рантайм начинает выглядеть как поддерживаемая «обуза», про которую незаметно забывают.
Но обновлённая архитектура @Dusk сознательно избегает такого шаблона.
Теперь DuskDS отвечает за расчёты (settlement) и доступность данных на базовом уровне, DuskEVM запускает приложения, совместимые с EVM, а DuskVM остаётся на L1 специально для контрактов на Rust и WASM, которым нужен прямой доступ к нативной приватности и функциям ZK.
Сначала я воспринял это как ненужное дублирование, но, кажется, это наоборот: это рассматривает онбординг разработчиков и возможности протокола как две разные задачи, которые не стоит силой сводить в одно место.
DuskEVM берёт на себя сторону онбординга. Solidity-контракты, существующие кошельки и инструменты Ethereum работают здесь без изменений. DuskVM занимается другим: когда приложению нужна нативная транзакционная модель Dusk, функции конфиденциальности или ZK-доказательства, ему не нужно всё переводить через EVM-совместимый код. Официальная документация позиционирует DuskVM как среду исполнения WASM, работающую нативно на Dusk L1.
Это помогло мне иначе посмотреть на то, что именно #dusk собирается строить.
Это не просто разделение сети на уровни. Это признание более конкретной вещи: EVM — эффективная точка входа для привлечения разработчиков, но, возможно, это не то место, где стоит нести возможности, предназначенные быть нативными для самого протокола.
За чем действительно стоит наблюдать, — не сможет ли $DUSK одновременно обслуживать две среды исполнения, а выберут ли разработчики на практике разные пути в зависимости от того, что им нужно.
Если основная разработка останется в EVM, DuskVM станет возможностью, которая существует, но почти не используется. Если приложения, ориентированные на приватность, и финансовые протоколы начнут маршрутизироваться через нативный путь исполнения, потому что EVM не справляется с этими требованиями, то сложность поддержки двух сред получит оправдание.
Но обновлённая архитектура @Dusk сознательно избегает такого шаблона.
Теперь DuskDS отвечает за расчёты (settlement) и доступность данных на базовом уровне, DuskEVM запускает приложения, совместимые с EVM, а DuskVM остаётся на L1 специально для контрактов на Rust и WASM, которым нужен прямой доступ к нативной приватности и функциям ZK.
Сначала я воспринял это как ненужное дублирование, но, кажется, это наоборот: это рассматривает онбординг разработчиков и возможности протокола как две разные задачи, которые не стоит силой сводить в одно место.
DuskEVM берёт на себя сторону онбординга. Solidity-контракты, существующие кошельки и инструменты Ethereum работают здесь без изменений. DuskVM занимается другим: когда приложению нужна нативная транзакционная модель Dusk, функции конфиденциальности или ZK-доказательства, ему не нужно всё переводить через EVM-совместимый код. Официальная документация позиционирует DuskVM как среду исполнения WASM, работающую нативно на Dusk L1.
Это помогло мне иначе посмотреть на то, что именно #dusk собирается строить.
Это не просто разделение сети на уровни. Это признание более конкретной вещи: EVM — эффективная точка входа для привлечения разработчиков, но, возможно, это не то место, где стоит нести возможности, предназначенные быть нативными для самого протокола.
За чем действительно стоит наблюдать, — не сможет ли $DUSK одновременно обслуживать две среды исполнения, а выберут ли разработчики на практике разные пути в зависимости от того, что им нужно.
Если основная разработка останется в EVM, DuskVM станет возможностью, которая существует, но почти не используется. Если приложения, ориентированные на приватность, и финансовые протоколы начнут маршрутизироваться через нативный путь исполнения, потому что EVM не справляется с этими требованиями, то сложность поддержки двух сред получит оправдание.
