#dusk $DUSK 翻 @Dusk 的架构文档时，我发现一个容易被一句话带过的设计选择：DuskDS做结算和数据可用性，DuskEVM做执行。结算和执行分家，不是随便拆的，背后是一整套关于"快"和"安全"的取舍。
把这个设计放到OP Stack的语境里就清楚了。DuskEVM是执行环境，Solidity合约在EVM侧运行，用户交互的Gas消耗、状态变化都在这一层发生。但DuskDS才是真正的结算层——EVM侧的输出需要提交到L1，经过验证、等待proof maturity和dispute-game窗口，最终才获得协议意义上的最终性。快速执行归EVM管，最终安全归L1管。
这套架构的代价也很直接：跨层操作需要等待。退出资金要经过输出提案、证明提交和finalize三步，每一步都有时间窗口，不是一键完成。目前这套架构还跑在测试网上，用的是没有现实价值的测试币。测试流程跑通只证明协议路径可行，推不出主网上线日期，也推不出高负载下输出提案和finalize的稳定性。
所以我对"EVM兼容"这个标签保持谨慎。真正值得验证的不是Solidity能不能跑，而是跨层退出的实际耗时、失败后的恢复路径、以及主网参数公开后这套分离架构在高负载下的表现。执行层和结算层分家，嘴上说是模块化，但用户体验上的账，最终要由产品来还。#dusk @Dusk