After reading through the architecture documents for @Dusk last night, one contradiction always comes up: do we have two execution paths coexisting to please both sides, or is the division of labor clearly defined?
The official documentation is very clear on its positioning. As the settlement and data availability layer, DuskDS sits beneath everything else. On top of it, Dusk provides two smart-contract execution paths: DuskVM (formerly known as Piecrust) runs Rust/WASM contracts and executes directly on Dusk L1; DuskEVM, on the other hand, is an EVM-equivalent execution environment based on OP Stack, with settlement and data availability handled by DuskDS.
The division of responsibilities between these two systems is not duplicated development.
DuskVM targets protocol-level business logic. It carries the privacy settlement logic for two transaction models, Phoenix and Moonlight. Contracts are compiled to WASM rather than EVM bytecode, making it naturally compatible with zero-knowledge proof systems. When you need to call underlying privacy capabilities, you go through DuskVM.
DuskEVM is the “compatibility layer.” Developers who are used to Solidity do not need to refactor their code: they can use familiar tools like Hardhat and Foundry, and MetaMask wallets can integrate seamlessly. After execution, the transaction data is submitted to DuskDS in the end as final attestations via the batcher in blob form.
This division of labor is reasonable by itself—privacy and compliance logic run in the native environment, while the upper EVM compatibility layer serves as the traffic entry point. They each do their own job. But “reasonable” doesn’t mean it has been validated.
The key question is: how many applications are deployed in each environment? Based on publicly available information, on the testnet DuskEVM already has 17 DeFi projects deployed. However, the number, share, and types of applications in the native DuskVM environment—at least for now—don’t show any clear statistics. Without application distribution data, “a reasonable division of labor” remains at the architecture design level. We can infer the architecture logic, but the ecosystem’s real impact can only be answered by data.
#dusk $DUSK
The official documentation is very clear on its positioning. As the settlement and data availability layer, DuskDS sits beneath everything else. On top of it, Dusk provides two smart-contract execution paths: DuskVM (formerly known as Piecrust) runs Rust/WASM contracts and executes directly on Dusk L1; DuskEVM, on the other hand, is an EVM-equivalent execution environment based on OP Stack, with settlement and data availability handled by DuskDS.
The division of responsibilities between these two systems is not duplicated development.
DuskVM targets protocol-level business logic. It carries the privacy settlement logic for two transaction models, Phoenix and Moonlight. Contracts are compiled to WASM rather than EVM bytecode, making it naturally compatible with zero-knowledge proof systems. When you need to call underlying privacy capabilities, you go through DuskVM.
DuskEVM is the “compatibility layer.” Developers who are used to Solidity do not need to refactor their code: they can use familiar tools like Hardhat and Foundry, and MetaMask wallets can integrate seamlessly. After execution, the transaction data is submitted to DuskDS in the end as final attestations via the batcher in blob form.
This division of labor is reasonable by itself—privacy and compliance logic run in the native environment, while the upper EVM compatibility layer serves as the traffic entry point. They each do their own job. But “reasonable” doesn’t mean it has been validated.
The key question is: how many applications are deployed in each environment? Based on publicly available information, on the testnet DuskEVM already has 17 DeFi projects deployed. However, the number, share, and types of applications in the native DuskVM environment—at least for now—don’t show any clear statistics. Without application distribution data, “a reasonable division of labor” remains at the architecture design level. We can infer the architecture logic, but the ecosystem’s real impact can only be answered by data.
#dusk $DUSK
