DuskVM против DuskEVM: Два пути для разработчиков

Нужна ли блокчейну необходимость принудительно загонять каждого разработчика в одну и ту же среду выполнения?

Dusk использует иной подход, предлагая два пути для смарт-контрактов — каждый из них рассчитан на разные модели разработки.

DuskVM — нативный путь. Разработчики пишут контракты на Rust, компилируют их в WASM и выполняют напрямую в Dusk L1. Это дает контрактам прямой доступ к модели выполнения Dusk L1, моделям транзакций, протоколу контрактов и возможностям, которые должны находиться близко к базовому уровню, включая приватность и функциональность, связанную с нулевыми знаниями.

DuskEVM выбирает маршрут, ориентированный на совместимость. Разработчики могут использовать Solidity или Vyper вместе с привычными кошельками, библиотеками и инструментами для EVM. Расчет и доступность данных обеспечиваются через DuskDS, а DUSK выступает в качестве нативного газового токена.

Следовательно, различие заключается не столько в выборе того, какая среда лучше, сколько в согласовании архитектуры с требованиями приложения. DuskVM поддерживает прямое выполнение в L1 и нативные возможности Dusk. DuskEVM снижает порог входа для разработчиков, которые уже работают в экосистеме Ethereum.

Для Dusk наличие обоих путей создает интересный баланс между нативной функциональностью и привычностью для разработчиков.

Может ли поддержка как нативного выполнения, так и совместимости с EVM быть более сильной стратегией для разработчиков, чем принуждение к одной универсальной среде?

$DUSK


#dusk @Dusk