聊区块链性能，十个人里有九个第一反应是TPS。剩下那个可能在看延迟。但Dusk这个项目吧，你把它的白皮书翻出来仔细捋一遍，会发现有个东西比交易速度更值得盯着——就是节点之间怎么“说话”。
大饼还好吧，BTC跌没多少！
我这么说不是因为TPS不重要，而是因为“算得快”和“传得快”压根是两码事。你执行层再猛，共识设计再精巧，消息在节点网络里卡住了——提案传不到验证者、验证结果回不到 ratification 委员会——那整个三阶段流程就得干等着。区块晚到几秒，轻则体验打折，重则不同节点看到不同候选块，stale block 率蹭蹭往上涨。
Dusk 选了 Kadcast 这条路。它不是 Gossip 那种“见人就转发”的广播模式，而是基于 Kademlia DHT 搭了一套结构化覆盖网络，节点 ID 之间的 XOR 距离决定路由，消息像树一样逐层展开。听着学术对吧？但核心逻辑其实就一句话：每条消息只走该走的路，不走冤枉路。
白皮书引用研究说，Kadcast 相对 Gossip 能省 25% 到 50% 的带宽。比如原来消耗100份带宽，现在大概 50 到 75 份——但这数字不能直接被翻译成“节点成本打对折”。机器配置没变、证明计算没变、存储开销没变，变的只是网络层那一块的传输成本。不过话说回来，对跑节点的人来说，带宽少一半意味着什么？意味着同样带宽条件下能接入更多节点，或者同样节点规模下不容易被带宽费用卡脖子。
有个细节挺能说明问题。节点文档里 9000/udp 被标记为 Kadcast 必需端口，Provisioner 要参与共识必须让这条通道可达；8080/tcp 反而是可选的，只有需要查询接口才开。换句话说，Kadcast 不是架构图上的装饰品——它直接卡着节点能不能参与共识的门槛。
熟悉 BTC 点对点广播的人知道，消息怎么穿过节点网络从来不是小事。 @Dusk $DUSK #dusk
大饼还好吧，BTC跌没多少！
我这么说不是因为TPS不重要，而是因为“算得快”和“传得快”压根是两码事。你执行层再猛，共识设计再精巧，消息在节点网络里卡住了——提案传不到验证者、验证结果回不到 ratification 委员会——那整个三阶段流程就得干等着。区块晚到几秒，轻则体验打折，重则不同节点看到不同候选块，stale block 率蹭蹭往上涨。
Dusk 选了 Kadcast 这条路。它不是 Gossip 那种“见人就转发”的广播模式，而是基于 Kademlia DHT 搭了一套结构化覆盖网络，节点 ID 之间的 XOR 距离决定路由，消息像树一样逐层展开。听着学术对吧？但核心逻辑其实就一句话：每条消息只走该走的路，不走冤枉路。
白皮书引用研究说，Kadcast 相对 Gossip 能省 25% 到 50% 的带宽。比如原来消耗100份带宽，现在大概 50 到 75 份——但这数字不能直接被翻译成“节点成本打对折”。机器配置没变、证明计算没变、存储开销没变，变的只是网络层那一块的传输成本。不过话说回来，对跑节点的人来说，带宽少一半意味着什么？意味着同样带宽条件下能接入更多节点，或者同样节点规模下不容易被带宽费用卡脖子。
有个细节挺能说明问题。节点文档里 9000/udp 被标记为 Kadcast 必需端口，Provisioner 要参与共识必须让这条通道可达；8080/tcp 反而是可选的，只有需要查询接口才开。换句话说，Kadcast 不是架构图上的装饰品——它直接卡着节点能不能参与共识的门槛。
熟悉 BTC 点对点广播的人知道，消息怎么穿过节点网络从来不是小事。 @Dusk $DUSK #dusk