#dusk $DUSK When I was reading the architecture document for @Dusk , I found a design choice that can easily be brushed over in a single sentence: DuskDS handles settlement and data availability, while DuskEVM handles execution. Separating settlement and execution isn’t something done casually—behind it is a whole set of trade-offs around "speed" and "security".
Putting this design in the context of OP Stack makes it clear. DuskEVM is the execution environment, with Solidity contracts running on the EVM side; the gas consumption and state changes from user interactions happen in this layer. But DuskDS is the real settlement layer—outputs from the EVM side need to be submitted to L1, then go through verification, waiting for proof maturity and the dispute-game window, before they become final in a protocol sense. Fast execution is handled by the EVM side, while ultimate security belongs to L1.
The cost of this architecture is also quite straightforward: cross-layer operations must wait. Exiting funds requires three steps—output proposal, proof submission, and finalization—each with its own time window, so it isn’t a one-click process. At the moment, this architecture is still running on the testnet and uses test tokens with no real-world value. Getting the test flow to work only proves that the protocol path is viable; it can’t tell us the mainnet launch date, nor does it demonstrate the stability of output proposals and finalization under high load.
So I remain cautious about the label "EVM compatibility." What’s truly worth validating isn’t just whether Solidity can run, but the actual latency of cross-layer exits, the recovery path after failures, and how this separation architecture performs under high load after the mainnet parameters are published. Separating the execution layer and settlement layer is said to be modular, but the user-experience "bill" ultimately has to be paid by the product. #dusk @Dusk