#dusk $DUSK
Я снова за последние пару дней перечитал архитектурную документацию @Dusk , и теперь у меня появился вопрос: раньше я, по сути, слишком упростил.
В итоге DuskEVM тоже вернётся к settlement в DuskDS — так зачем тогда отдельно сохранять DuskVM?
Сначала я думал, что всё дело в различии языков разработки: один — Solidity, другой — Rust/WASM.
Но если продолжить читать дальше, различие на самом деле в исполняемом пути (execution path).
DuskVM напрямую запускается на L1.
А DuskEVM — нет. Транзакция сначала идёт через sequencer, затем исполняется на уровне EVM; дальше есть batch, state commitment, и только потом она снова подключается обратно к DuskDS.
Поэтому даже если в итоге всё приходит к одному и тому же settlement layer, то то, что происходит в середине, совершенно не одинаково.
И я думаю, что это различие действительно важно.
Если уже есть готовый продукт на Solidity и хочется перенести его с минимальными правками, то DuskEVM выглядит вполне разумно: инструменты и привычки разработки в основном уже знакомы.
Но если само приложение изначально должно напрямую работать с L1, или нужно использовать Dusk native-исполнительные возможности и протокольную логику, то «жёстко обходить» EVM-слой, возможно, и не обязательно.
Поэтому сейчас я уже не слишком переживаю о том, что “выше” — DuskEVM или DuskVM.
Скорее это две разные дороги.
Одна — чтобы облегчить вход разработчикам EVM.
Другая — для тех, кто изначально хотел использовать возможности Dusk-native напрямую.
В итоге обе они могут подключаться к DuskDS, но execution path — совсем разный.
Вот почему, по моему мнению, архитектура Dusk заслуживает изучения больше, чем «ещё один L1, совместимый с EVM».
Я снова за последние пару дней перечитал архитектурную документацию @Dusk , и теперь у меня появился вопрос: раньше я, по сути, слишком упростил.
В итоге DuskEVM тоже вернётся к settlement в DuskDS — так зачем тогда отдельно сохранять DuskVM?
Сначала я думал, что всё дело в различии языков разработки: один — Solidity, другой — Rust/WASM.
Но если продолжить читать дальше, различие на самом деле в исполняемом пути (execution path).
DuskVM напрямую запускается на L1.
А DuskEVM — нет. Транзакция сначала идёт через sequencer, затем исполняется на уровне EVM; дальше есть batch, state commitment, и только потом она снова подключается обратно к DuskDS.
Поэтому даже если в итоге всё приходит к одному и тому же settlement layer, то то, что происходит в середине, совершенно не одинаково.
И я думаю, что это различие действительно важно.
Если уже есть готовый продукт на Solidity и хочется перенести его с минимальными правками, то DuskEVM выглядит вполне разумно: инструменты и привычки разработки в основном уже знакомы.
Но если само приложение изначально должно напрямую работать с L1, или нужно использовать Dusk native-исполнительные возможности и протокольную логику, то «жёстко обходить» EVM-слой, возможно, и не обязательно.
Поэтому сейчас я уже не слишком переживаю о том, что “выше” — DuskEVM или DuskVM.
Скорее это две разные дороги.
Одна — чтобы облегчить вход разработчикам EVM.
Другая — для тех, кто изначально хотел использовать возможности Dusk-native напрямую.
В итоге обе они могут подключаться к DuskDS, но execution path — совсем разный.
Вот почему, по моему мнению, архитектура Dusk заслуживает изучения больше, чем «ещё один L1, совместимый с EVM».