#dusk $DUSK @Dusk
Весь стек Dusk построен модульно. DuskDS — это слой расчетов и доступности данных: он запускает консенсус Succinct Attestation, обрабатывает стейкинг и хранит базовый актив DUSK. DuskEVM — отдельный слой исполнения, совместимый с Solidity, построенный на OP Stack (сиквенсер, работающий на op-geth, плюс батчер, который публикует данные транзакций обратно в DuskDS в виде BLOB-ов). При этом DuskEVM “оседает” обратно в DuskDS, а не полагается на собственную независимую безопасность. DuskVM — дальнейшая, еще развивающаяся нативная среда исполнения для контрактов Rust/WASM, предназначенная для приложений, которым нужна нативная приватность или интеграция на уровне протокола. Piecrust — это runtime для WASM (построенный на Wasmer), который изначально был встроен в DuskDS, а теперь извлекается в DuskVM. Сеть работает на Kadcast — это структурированный протокол широковещательной передачи в стиле Kademlia, а не случайный gossip.
Логика этой архитектуры в том, что “одна среда исполнения для всего” не работает для чейна, который пытается одновременно обслуживать как DeFi-компонуемость, так и регулируемый выпуск активов. Вместо того чтобы заставлять разработчиков Solidity переходить в нативную среду Rust/WASM или принуждать приложения с нативной приватностью к ограничениям EVM, расчеты и консенсус опираются на общий базовый слой, а среды исполнения специализируются поверх него. Kadcast соответствует той же логике: структурированная широковещательная рассылка дает более предсказуемую пропускную способность и задержки, что важнее для чейна, заявляющего детерминированную финальность, чем для того, который воспринимает финальность вероятностно.
Разделение исполнения и расчетов также означает, что гарантии DuskEVM столь сильны, насколько сильны мост и механизм батчинга, связывающие его обратно с DuskDS. По мере созревания DuskVM вместе с DuskEVM сеть в итоге будет выполнять три поверхности исполнения поверх одного слоя расчетов. Снижает ли такое разделение реально трение интеграции для разработчиков, или просто переносит сложность с вопроса “какую VM мне использовать” на вопрос “какой слой на самом деле хранит мою гарантию?”
Весь стек Dusk построен модульно. DuskDS — это слой расчетов и доступности данных: он запускает консенсус Succinct Attestation, обрабатывает стейкинг и хранит базовый актив DUSK. DuskEVM — отдельный слой исполнения, совместимый с Solidity, построенный на OP Stack (сиквенсер, работающий на op-geth, плюс батчер, который публикует данные транзакций обратно в DuskDS в виде BLOB-ов). При этом DuskEVM “оседает” обратно в DuskDS, а не полагается на собственную независимую безопасность. DuskVM — дальнейшая, еще развивающаяся нативная среда исполнения для контрактов Rust/WASM, предназначенная для приложений, которым нужна нативная приватность или интеграция на уровне протокола. Piecrust — это runtime для WASM (построенный на Wasmer), который изначально был встроен в DuskDS, а теперь извлекается в DuskVM. Сеть работает на Kadcast — это структурированный протокол широковещательной передачи в стиле Kademlia, а не случайный gossip.
Логика этой архитектуры в том, что “одна среда исполнения для всего” не работает для чейна, который пытается одновременно обслуживать как DeFi-компонуемость, так и регулируемый выпуск активов. Вместо того чтобы заставлять разработчиков Solidity переходить в нативную среду Rust/WASM или принуждать приложения с нативной приватностью к ограничениям EVM, расчеты и консенсус опираются на общий базовый слой, а среды исполнения специализируются поверх него. Kadcast соответствует той же логике: структурированная широковещательная рассылка дает более предсказуемую пропускную способность и задержки, что важнее для чейна, заявляющего детерминированную финальность, чем для того, который воспринимает финальность вероятностно.
Разделение исполнения и расчетов также означает, что гарантии DuskEVM столь сильны, насколько сильны мост и механизм батчинга, связывающие его обратно с DuskDS. По мере созревания DuskVM вместе с DuskEVM сеть в итоге будет выполнять три поверхности исполнения поверх одного слоя расчетов. Снижает ли такое разделение реально трение интеграции для разработчиков, или просто переносит сложность с вопроса “какую VM мне использовать” на вопрос “какой слой на самом деле хранит мою гарантию?”