Раньше я думал: если одна публичная цепочка разместит несколько сред выполнения, максимум — это даст разработчикам больше вариантов. Но после того как я разобрал архитектуру @Dusk , стало понятно, что связь между DuskVM и DuskEVM не такая простая: они больше похожи на два входа, ориентированные на разные потребности.$DUSK
DuskVM напрямую работает в Dusk L1, использует Rust/WASM — подходит для вызова нативных активов, функций конфиденциальности и ZK-возможностей; DuskEVM же больше напоминает мост для миграции, позволяя разработчикам на Solidity продолжать пользоваться привычными кошельками, фреймворками и тестовыми инструментами. В итоге результаты с обеих сторон передаются в DuskDS для расчетов.#dusk
Это означает, что роль DuskEVM заключается не только в снижении порога миграции. Например, обычному финансовому приложению, чтобы сначала подключить зрелую экосистему EVM-инструментов, можно начать с DuskEVM; но если речь о конфиденциальных ценных бумагах, передаче контролируемых активов или если нужно вызывать нативные секретные возможности Dusk, то останавливаться только на уровне EVM нельзя — многие сценарии всё равно нужно реализовывать через DuskVM.
Отсюда и вопросы. Допустим, приложению нужно и взаимодействовать с Solidity-контрактами, и обрабатывать нативные конфиденциальные активы Dusk — где тогда хранится ключевое состояние? Как синхронизировать данные между двумя средами? Кто будет проверять вызовы между слоями? Если что-то пойдёт не так, разработчику придётся разбираться: это проблема контракта, среды выполнения или расчётного слоя?$BTC
Поэтому сейчас я смотрю на многосредовость Dusk не только как на преимущество совместимости. С одной стороны, это даёт возможность зайти большему числу разработчиков, а с другой — переносит на команду разработки сложные задачи системного проектирования. На самом деле важно не то, сколько Dusk предлагает способов выполнения, а смогут ли эти среды сформировать чёткие границы, чтобы разработчикам не приходилось делать бессмысленные компромиссы, и чтобы из‑за желания одновременно задействовать разные возможности приложение не превращалось в всё более сложный конструктор.$ETH
DuskVM напрямую работает в Dusk L1, использует Rust/WASM — подходит для вызова нативных активов, функций конфиденциальности и ZK-возможностей; DuskEVM же больше напоминает мост для миграции, позволяя разработчикам на Solidity продолжать пользоваться привычными кошельками, фреймворками и тестовыми инструментами. В итоге результаты с обеих сторон передаются в DuskDS для расчетов.#dusk
Это означает, что роль DuskEVM заключается не только в снижении порога миграции. Например, обычному финансовому приложению, чтобы сначала подключить зрелую экосистему EVM-инструментов, можно начать с DuskEVM; но если речь о конфиденциальных ценных бумагах, передаче контролируемых активов или если нужно вызывать нативные секретные возможности Dusk, то останавливаться только на уровне EVM нельзя — многие сценарии всё равно нужно реализовывать через DuskVM.
Отсюда и вопросы. Допустим, приложению нужно и взаимодействовать с Solidity-контрактами, и обрабатывать нативные конфиденциальные активы Dusk — где тогда хранится ключевое состояние? Как синхронизировать данные между двумя средами? Кто будет проверять вызовы между слоями? Если что-то пойдёт не так, разработчику придётся разбираться: это проблема контракта, среды выполнения или расчётного слоя?$BTC
Поэтому сейчас я смотрю на многосредовость Dusk не только как на преимущество совместимости. С одной стороны, это даёт возможность зайти большему числу разработчиков, а с другой — переносит на команду разработки сложные задачи системного проектирования. На самом деле важно не то, сколько Dusk предлагает способов выполнения, а смогут ли эти среды сформировать чёткие границы, чтобы разработчикам не приходилось делать бессмысленные компромиссы, и чтобы из‑за желания одновременно задействовать разные возможности приложение не превращалось в всё более сложный конструктор.$ETH