#dusk Last week, when I built a local DuskEVM node and test deployment scripts, my most core concern was actually the visibility of storage slot data. In the traditional Ethereum architecture, the global state trie is fully transparent and queryable. As long as the VM follows the standard EVM semantics, any so-called confidential attributes on-chain cannot automatically take effect; you have to rely on additional proof mechanisms to provide a fallback.
Dusk’s dual-track architecture splits the network into different layers: consensus and settlement are handled uniformly by the underlying DuskDS. The native DuskVM, based on the Phoenix protocol and the XSC specification, processes on-chain confidential assets, while the newly introduced DuskEVM is merely an execution tool that lowers the migration barrier. This modular approach saves the trouble of rewriting Rust code, but it also divides what used to be an integrated security logic into two separate systems.$DUSK
Technically, the core disagreement lies in how responsibility boundaries are defined. If, when developers write business logic in DuskEVM, they must manually call external modules like Citadel to assemble zero-knowledge proofs, then the burden of protecting privacy shifts from the protocol layer to the application-layer code. Once there is even a minor oversight in smart contract writing, the key transaction and holdings data will still be exposed in the public state.$BTC
From an engineering perspective, embracing Solidity can indeed quickly attract developers, but this also blurs the true data boundaries. For institutional-grade real asset business, unclear rules are the biggest taboo. Having two execution environments coexist only increases the audit cost and attack surface for cross-layer asset calls, meaning developers must assume compliance risk themselves.$ETH
I think while the official expands compatibility, it also needs to clarify as soon as possible the state mapping and privacy synchronization standards between the two layers. Purely technical compromises are hard to directly win over careful institutional capital. When you actually build a confidential application, do you care more about the pure privacy of native WASM, or do you prefer the developer convenience brought by the compatibility layer?@Dusk
Dusk’s dual-track architecture splits the network into different layers: consensus and settlement are handled uniformly by the underlying DuskDS. The native DuskVM, based on the Phoenix protocol and the XSC specification, processes on-chain confidential assets, while the newly introduced DuskEVM is merely an execution tool that lowers the migration barrier. This modular approach saves the trouble of rewriting Rust code, but it also divides what used to be an integrated security logic into two separate systems.$DUSK
Technically, the core disagreement lies in how responsibility boundaries are defined. If, when developers write business logic in DuskEVM, they must manually call external modules like Citadel to assemble zero-knowledge proofs, then the burden of protecting privacy shifts from the protocol layer to the application-layer code. Once there is even a minor oversight in smart contract writing, the key transaction and holdings data will still be exposed in the public state.$BTC
From an engineering perspective, embracing Solidity can indeed quickly attract developers, but this also blurs the true data boundaries. For institutional-grade real asset business, unclear rules are the biggest taboo. Having two execution environments coexist only increases the audit cost and attack surface for cross-layer asset calls, meaning developers must assume compliance risk themselves.$ETH
I think while the official expands compatibility, it also needs to clarify as soon as possible the state mapping and privacy synchronization standards between the two layers. Purely technical compromises are hard to directly win over careful institutional capital. When you actually build a confidential application, do you care more about the pure privacy of native WASM, or do you prefer the developer convenience brought by the compatibility layer?@Dusk