#dusk $DUSK
最近继续翻 @Dusk 的交易生命周期文档，我才发现自己以前把一件事想得太简单：
交易执行成功，不等于这笔状态已经可以被金融系统当成“事实”。
在 DuskDS 里，一笔交易先被接收、传播、执行，后面还要经历最终确认。
官方文档甚至专门提醒：
included、accepted、confirmed，都不能直接当成 payment finality。
原因也不复杂。
一笔交易进了 accepted block，这个 block 仍然可能被回滚。
真正到 finalized，才意味着状态进入 deterministic finality。
Dusk 的 Succinct Attestation 里，会继续经过：
Proposal
→ Validation
→ Ratification
到 Ratification 完成，block 才真正 final。
我觉得这个细节比“多少 TPS”更值得看。
因为交易所或者金融系统最怕的不是晚几秒看到一笔交易。
怕的是：
我已经根据这笔状态给用户入账了，结果底层状态后来又变了。
所以 Dusk 给交易所的 integration 文档也明确要求，不能因为 mempool、included event 或者 accepted-but-unfinalized block 就提前记账。
这其实把 finality 讲得很实际。
它不是一个性能词。
而是在回答：
系统到底从哪一刻开始，可以不再担心这笔状态被撤回？
Dusk 官网现在给出的 finality 指标大约是 10 秒。
我更关心的不是这个数字够不够漂亮。
而是主网真实负载起来以后，这个从 accepted 到 finalized 的边界能不能一直保持清楚、稳定。
金融系统真正依赖的，最后还是这个。
最近继续翻 @Dusk 的交易生命周期文档，我才发现自己以前把一件事想得太简单：
交易执行成功，不等于这笔状态已经可以被金融系统当成“事实”。
在 DuskDS 里，一笔交易先被接收、传播、执行，后面还要经历最终确认。
官方文档甚至专门提醒：
included、accepted、confirmed，都不能直接当成 payment finality。
原因也不复杂。
一笔交易进了 accepted block，这个 block 仍然可能被回滚。
真正到 finalized，才意味着状态进入 deterministic finality。
Dusk 的 Succinct Attestation 里，会继续经过：
Proposal
→ Validation
→ Ratification
到 Ratification 完成，block 才真正 final。
我觉得这个细节比“多少 TPS”更值得看。
因为交易所或者金融系统最怕的不是晚几秒看到一笔交易。
怕的是：
我已经根据这笔状态给用户入账了，结果底层状态后来又变了。
所以 Dusk 给交易所的 integration 文档也明确要求，不能因为 mempool、included event 或者 accepted-but-unfinalized block 就提前记账。
这其实把 finality 讲得很实际。
它不是一个性能词。
而是在回答：
系统到底从哪一刻开始，可以不再担心这笔状态被撤回？
Dusk 官网现在给出的 finality 指标大约是 10 秒。
我更关心的不是这个数字够不够漂亮。
而是主网真实负载起来以后，这个从 accepted 到 finalized 的边界能不能一直保持清楚、稳定。
金融系统真正依赖的，最后还是这个。