Я думал, что DuskVM и DuskEVM — это по сути два способа построить одно и то же.
Потом я потратил немного времени на то, как разработка устроена на практике, и понял, что нет.
Если собирать через DuskVM, вы гораздо ближе к нативной стороне @Dusk . Контракты пишутся на Rust, компилируются в WASM и выполняются непосредственно на L1. Это даёт доступ к собственным моделям транзакций Dusk и более низкоуровневым возможностям приватности/ZK.
DuskEVM ощущается как обратная компромиссная сделка.
Вы получаете Solidity, Foundry, Hardhat, обычные EVM-кошельки.. по сути те инструменты, которые уже знают разработчики Ethereum. Но выполнение всё равно завершается через DuskDS.
Меня “щелкнуло”, что это не столько история про то, чтобы заставить билдеров выбирать лучший VM.
Это про то, в чём реально нуждается приложение.
Если мне нужен прямой контроль на L1, нативная логика приватности или выполнение на уровне протокола, тогда DuskVM имеет больше смысла.
Если у меня уже есть EVM-приложение и мне просто нужен привычный способ войти в стек Dusk, то требовать переписывание на Rust было бы лишним трением.
Так что да, поначалу мне действительно казалось, что два среды выполнения выглядят избыточно.
Теперь это больше похоже на то, что Dusk пытается не противопоставлять друг другу совместимость с разработчиками и нативный контроль.
Одна экосистема, очень разные точки входа.
Интересно, какую сторону билдеры на самом деле выберут, когда начнут двигаться ещё приложения.
$DUSK #dusk
Потом я потратил немного времени на то, как разработка устроена на практике, и понял, что нет.
Если собирать через DuskVM, вы гораздо ближе к нативной стороне @Dusk . Контракты пишутся на Rust, компилируются в WASM и выполняются непосредственно на L1. Это даёт доступ к собственным моделям транзакций Dusk и более низкоуровневым возможностям приватности/ZK.
DuskEVM ощущается как обратная компромиссная сделка.
Вы получаете Solidity, Foundry, Hardhat, обычные EVM-кошельки.. по сути те инструменты, которые уже знают разработчики Ethereum. Но выполнение всё равно завершается через DuskDS.
Меня “щелкнуло”, что это не столько история про то, чтобы заставить билдеров выбирать лучший VM.
Это про то, в чём реально нуждается приложение.
Если мне нужен прямой контроль на L1, нативная логика приватности или выполнение на уровне протокола, тогда DuskVM имеет больше смысла.
Если у меня уже есть EVM-приложение и мне просто нужен привычный способ войти в стек Dusk, то требовать переписывание на Rust было бы лишним трением.
Так что да, поначалу мне действительно казалось, что два среды выполнения выглядят избыточно.
Теперь это больше похоже на то, что Dusk пытается не противопоставлять друг другу совместимость с разработчиками и нативный контроль.
Одна экосистема, очень разные точки входа.
Интересно, какую сторону билдеры на самом деле выберут, когда начнут двигаться ещё приложения.
$DUSK #dusk