如果一笔交易从你手里发出去，真正的考验并不是本地机器多快，而是这条消息能不能有条理地到达需要它的节点。用户看不到这段路，但它会影响共识为什么会慢、为什么会出现重复处理。

把网络想成一座城市：最粗暴的方法是每个路口都把同一张通知抄给所有相邻路口。通知当然能传开，代价是大量重复。Kadcast 的思路不是让每个节点都喊一遍，而是利用 Kademlia 的距离组织和 XOR 距离，把消息放进结构化的转发关系里，减少无差别泛洪。

这里最重要的不是“Dusk 已经快到多少”，而是你终于有了一个更准确的问题：消息覆盖的成本在哪里？执行时间只回答节点处理事情的速度，传播路径还要回答消息怎样被送到其他节点。两笔账都没看全，就不能把一个局部结果当成整体性能。

当然，白皮书里的 Kadcast 是机制设计，不是当前主网基准报告。节点规模、网络波动和实际路径，都可能改变最后结果。看 @Dusk_Foundation ，我会先把这条路径画出来，再判断共识是否被重复广播拖住。$DUSK 是网络原生代币，不能替这张图作证；#dusk 的技术讨论也该从消息如何到达开始。

从普通使用角度看，一条确认消息不是凭空出现的，它要经过传播、接收和重复处理。我们当然不能凭白皮书直接给主网下结论，但可以先把问题问对：一个执行引擎如果消息覆盖方式仍然低效，用户看到的最终体验会被哪一层拖住？把路径纳入性能，正是这套机制值得观察的地方。

先看路径，再看数字，顺序不能反。别只看执行速度。