Я углубился в @Dusk и его два пути выполнения — DuskEVM для Solidity и DuskVM для нативных контрактов на Rust/WASM.

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

Я перестал смотреть только на документацию и начал думать о том, что разработчики реально будут выбирать.

DuskEVM знаком, с теми инструментами EVM, которые разработчики уже знают. DuskVM идет глубже в рантайм через Forge: он берет на себя шаблонный код, экспорт WASM и драйверы данных, а состояние контракта живет напрямую в линейной памяти и сериализуется с помощью rkyv.

Стоп — это создает интересное противоречие.

DuskVM может предложить более нативную и потенциально с меньшими накладными расходами среду выполнения, но DuskEVM все равно может оказаться очевидным выбором просто потому, что с ним проще собирать.

Именно этот разрыв мне кажется более интересным, чем сама по себе Rust/WASM-архитектура.

Я не говорю, что DuskVM здесь ошибочен. Нативная модель выполнения делает ровно то, для чего была задумана.

Главный вопрос в том, достаточно ли технического преимущества, чтобы изменить поведение разработчиков.

Это напоминает выбор между привычным инструментом, который делает работу, и более специализированным, который дает вам больший контроль — но при этом просит сначала освоить новый рабочий процесс.

Если разработчики продолжат выбирать DuskEVM, станет ли DuskVM технически мощной, но нишевой средой выполнения?

Или же нативное развертывание в итоге станет значимым сигналом о более глубокой сетевой полезности #Dusk ?
$DUSK $KII $AKE
#RedditToJoinSP500 #US30YBondAuctionYieldHighestSince2001 #GlobalStocksNearRecordHighs #ProCapFilesBitcoinTreasuryDiscountETF