При чтении официальной документации Dusk я поймал себя на том, что перечитал одну фразу дважды, прежде чем дошло: исполнительный слой DuskEVM построен на OP Stack — sequencer запускает op-geth для выполнения EVM-транзакций, batcher публикует данные транзакций как blob в DuskDS, а proposer затем публикует обещание по состоянию, ссылаясь на эти уже выполненные батчи. Проще говоря, DuskEVM по сути является Layer 2, а DuskDS (собственный L1-слой Dusk) — это его основа доступности данных и финального расчёта.
Этот архитектурный выбор довольно умный.
Родная среда смарт-контрактов Dusk — это DuskVM, которая работает на наборе Piecrust, виртуальной машине WASM, написанной на Rust: она ориентирована на разработчиков, которые хотят напрямую использовать Rust/WASM и задействовать протокольные активы и возможности ZK. А DuskEVM рассчитан на команды, которым удобнее пользоваться готовой экосистемой инструментов Solidity и не хочется учиться чему-то новому. Две ноги вместо того, чтобы заставлять всех менять язык.
В последних версиях Piecrust также продолжают добавлять поддержку memory64 и заменили базовый рантайм с wasmer на wasmtime — всё это делается ради более масштабируемого состояния контрактов и производительности выполнения.
По-настоящему стоит задуматься о структуре комиссий: в DuskEVM за транзакцию нужно заплатить дважды — первая плата в стиле EIP-1559 за L2-выполнение, а вторая — комиссия за доступность данных, когда батчевые данные публикуются в DuskDS. Это означает, что реальная пропускная способность и стоимость DuskEVM в конечном счёте всё равно упираются в «горлышко» доступности данных у DuskDS как у L1: даже если L2-исполнение будет быстрым, если базовый слой расчёта заблокирован, выше всё равно не подняться. Это почти не отличается по сути от большинства публичных сетей L2, где DA делается через Ethereum — просто вместо Ethereum используется собственный L1 Dusk.
Для разработчиков, которые планируют деплой контрактов в DuskEVM, эти архитектурные детали — не просто фоновая теория: они напрямую определяют, станет ли DA-часть в вашей модели затрат большей статьёй расходов, чем плата за выполнение, особенно в высокочастотных финансовых приложениях с большими объёмами данных.
@Dusk $DUSK #dusk
Этот архитектурный выбор довольно умный.
Родная среда смарт-контрактов Dusk — это DuskVM, которая работает на наборе Piecrust, виртуальной машине WASM, написанной на Rust: она ориентирована на разработчиков, которые хотят напрямую использовать Rust/WASM и задействовать протокольные активы и возможности ZK. А DuskEVM рассчитан на команды, которым удобнее пользоваться готовой экосистемой инструментов Solidity и не хочется учиться чему-то новому. Две ноги вместо того, чтобы заставлять всех менять язык.
В последних версиях Piecrust также продолжают добавлять поддержку memory64 и заменили базовый рантайм с wasmer на wasmtime — всё это делается ради более масштабируемого состояния контрактов и производительности выполнения.
По-настоящему стоит задуматься о структуре комиссий: в DuskEVM за транзакцию нужно заплатить дважды — первая плата в стиле EIP-1559 за L2-выполнение, а вторая — комиссия за доступность данных, когда батчевые данные публикуются в DuskDS. Это означает, что реальная пропускная способность и стоимость DuskEVM в конечном счёте всё равно упираются в «горлышко» доступности данных у DuskDS как у L1: даже если L2-исполнение будет быстрым, если базовый слой расчёта заблокирован, выше всё равно не подняться. Это почти не отличается по сути от большинства публичных сетей L2, где DA делается через Ethereum — просто вместо Ethereum используется собственный L1 Dusk.
Для разработчиков, которые планируют деплой контрактов в DuskEVM, эти архитектурные детали — не просто фоновая теория: они напрямую определяют, станет ли DA-часть в вашей модели затрат большей статьёй расходов, чем плата за выполнение, особенно в высокочастотных финансовых приложениях с большими объёмами данных.
@Dusk $DUSK #dusk