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