Когда существовал DuskEVM, Dusk Network могла бы сделать проще свою подачу: одна среда исполнения, Solidity для всех — и готово. Вместо этого документация прямо указывает, что нативная разработка Dusk, то есть контракты на Rust, компилируемые в WASM и исполняемые DuskVM, остается рекомендуемым путем всякий раз, когда приложению нужен контроль на уровне протокола, собственные модели транзакций или возможности нулевого знания, находящиеся совсем близко к базовому слою. Мне это решение кажется интересным для защиты, потому что поддерживать два пути исполнения обходится дороже и в разработке, и в объяснении, чем поддерживать один.
Логика, похоже, в том, что DuskEVM и DuskVM оптимизированы под разных клиентов, а не конкурируют за одну и ту же аудиторию. Команда, переносящая существующий Ethereum DeFi-протокол, хочет знакомые инструменты, уже проведенные аудиты и кошельки, которые уже работают — именно для этого и предназначен DuskEVM. А команда, создающая логику расчетов по ценным бумагам с ограниченными переводами, распределением дивидендов или правилами комплаенса, встроенными прямо в контракт, ближе к тому, на что изначально были рассчитаны Zedger и нативные контракты DuskVM: гибридная модель транзакций была создана специально для такого учета security-токенов, а не адаптирована постфактум из универсального шаблона.
Я не до конца уверен, что этот подход с двумя направлениями действительно предотвращает фрагментацию собственной базы разработчиков Dusk Network и усилий по документации между двумя аудиториями вместо того, чтобы сосредоточить их за одним фасадом. Две среды исполнения означают два набора инструментов для поддержки, две ментальные модели для новых участников и два ответа на простой вопрос о том, где в реальности должно быть построено новое приложение. Я понимаю ставку: если бы на этом раннем этапе сузились до одного пути, то тихо списали бы ту аудиторию, которой не достался бы выбор. Насколько Dusk Network останется достаточно большой, чтобы должным образом поддерживать оба пути в течение следующих нескольких лет, — за этим стоит понаблюдать.
#dusk $DUSK @Dusk
Логика, похоже, в том, что DuskEVM и DuskVM оптимизированы под разных клиентов, а не конкурируют за одну и ту же аудиторию. Команда, переносящая существующий Ethereum DeFi-протокол, хочет знакомые инструменты, уже проведенные аудиты и кошельки, которые уже работают — именно для этого и предназначен DuskEVM. А команда, создающая логику расчетов по ценным бумагам с ограниченными переводами, распределением дивидендов или правилами комплаенса, встроенными прямо в контракт, ближе к тому, на что изначально были рассчитаны Zedger и нативные контракты DuskVM: гибридная модель транзакций была создана специально для такого учета security-токенов, а не адаптирована постфактум из универсального шаблона.
Я не до конца уверен, что этот подход с двумя направлениями действительно предотвращает фрагментацию собственной базы разработчиков Dusk Network и усилий по документации между двумя аудиториями вместо того, чтобы сосредоточить их за одним фасадом. Две среды исполнения означают два набора инструментов для поддержки, две ментальные модели для новых участников и два ответа на простой вопрос о том, где в реальности должно быть построено новое приложение. Я понимаю ставку: если бы на этом раннем этапе сузились до одного пути, то тихо списали бы ту аудиторию, которой не достался бы выбор. Насколько Dusk Network останется достаточно большой, чтобы должным образом поддерживать оба пути в течение следующих нескольких лет, — за этим стоит понаблюдать.
#dusk $DUSK @Dusk
