我給 @Dusk 测试网挂了几个节点，抓包后最大的感受是：很多主网运维还在用“CPU 红线+内存水位”这种上个时代的指标，却对节点间信令积压、重复报文、路由表抖动毫无察觉。比特币早期泛洪广播是现成反面教材：一笔交易到达节点后，无差别推给所有邻居，8 到 16 条对等连接同时转发，网络层带宽呈乘数级放大。早期比特币测试网统计里，单笔交易广播的冗余副本经常超过连接数的三倍。并发一上来，网卡中断先于区块同步打满。

Kadcast 没有走这条老路。它把 Kademlia 的 XOR 距离逻辑直接压进传播层：节点先算目标与本地 ID 的距离，按前缀长度把邻居塞进不同 k-bucket，同步时沿树状路由逐层多播。我实测压测下来，瞬时带宽峰值比泛洪低一截，外部探针也因多跳转发难以反推源 IP。设计上这是有依据的：Kadcast 在论文级模拟里把广播冗余从 Gossip 的线性级压到对数级，少一个数量级。

但我的质疑恰恰在这里。效率全押在路由表健康度上，等于把分布式系统的容错外包给了拓扑假设。一旦跨海光缆被挖断，或者攻击者用廉价 Sybil 身份污染特定 k-bucket，节点会频繁触发路由修复和备选路径切换。寻址延迟不是线性增长，而是抖动放大：路由表每丢失一个高前缀桶，查询跳数可能从对数级跳直接退化到穷举试探。我在压测里看到更反直觉的一幕：同样 2000 笔交易注入，泛洪节点网卡中断次数是 Kadcast 节点的四倍，但丢包率超过 3% 后 Kadcast 的区块同步时间反而超。这个成本足以吃掉前期省下的带宽红利。

公网不是实验室，TCP 重传、NAT 穿透、运营商 QoS 都会放大逻辑拓扑的脆弱性。评估这类底层网络，最怕的不是 CPU 飙高，而是路由表静默劣化：表面吞吐正常，实则信令重试和桶修复已把控制面打穿。#dusk $DUSK $BTC