#dusk $DUSK
这两天在翻 @Dusk 的 DuskEVM 文档，有个细节之前我确实忽略了：
交易在 DuskEVM 里打包，不代表这笔交易已经走完。
Dusk 现在这套架构里，DuskEVM 和 DuskDS 干的不是一件事。
Solidity 合约先在 DuskEVM 执行，交易进 sequencer，被打进 L2 block。后面 batcher 还要把交易数据提交到 DuskDS，状态通过 commitment、fault proof 这些机制继续往下确认。
最后负责 settlement 和 data availability 的，是 DuskDS。
所以我现在理解 DuskEVM，反而不会简单把它当成“Dusk 加了个 EVM”。
更准确一点应该是：
DuskEVM 管执行，DuskDS 管最后算不算数。
这也解释了为什么官方文档会专门区分 transaction inclusion 和 settlement。
包括目前 testnet 的 withdrawal 流程也能看到这种设计思路：先在 DuskEVM initiate，再到 Dusk L1 prove，最后 finalize，并不是 L2 那边显示成功就彻底结束。
这个区别对普通转账可能没那么性感，但放到金融场景里，我觉得反而重要。
证券、基金这些东西真要上链，大家最后关心的不只是“交易跑得快不快”，还有一个更实际的问题：
这笔状态到底在哪一层获得最终性？
所以接下来我看 DuskEVM mainnet，除了性能和 Solidity 兼容性，更想看这条从 execution 到 DuskDS settlement 的链路实际跑起来是什么表现。
至少现在架构上的分工，我算是看明白了。
这两天在翻 @Dusk 的 DuskEVM 文档，有个细节之前我确实忽略了：
交易在 DuskEVM 里打包，不代表这笔交易已经走完。
Dusk 现在这套架构里，DuskEVM 和 DuskDS 干的不是一件事。
Solidity 合约先在 DuskEVM 执行，交易进 sequencer，被打进 L2 block。后面 batcher 还要把交易数据提交到 DuskDS，状态通过 commitment、fault proof 这些机制继续往下确认。
最后负责 settlement 和 data availability 的，是 DuskDS。
所以我现在理解 DuskEVM，反而不会简单把它当成“Dusk 加了个 EVM”。
更准确一点应该是：
DuskEVM 管执行，DuskDS 管最后算不算数。
这也解释了为什么官方文档会专门区分 transaction inclusion 和 settlement。
包括目前 testnet 的 withdrawal 流程也能看到这种设计思路：先在 DuskEVM initiate，再到 Dusk L1 prove，最后 finalize，并不是 L2 那边显示成功就彻底结束。
这个区别对普通转账可能没那么性感，但放到金融场景里，我觉得反而重要。
证券、基金这些东西真要上链，大家最后关心的不只是“交易跑得快不快”，还有一个更实际的问题：
这笔状态到底在哪一层获得最终性？
所以接下来我看 DuskEVM mainnet，除了性能和 Solidity 兼容性，更想看这条从 execution 到 DuskDS settlement 的链路实际跑起来是什么表现。
至少现在架构上的分工，我算是看明白了。
