#dusk $DUSK 周末晚上在办公室翻 @Dusk 的技术文档，做分布式系统开发的老周发来一条消息：“DUSK 那个三层委员会共识你看了没？提议、验证、核准，每轮三拨人来回传消息，通信链路够复杂的。”
我点开文档，盯着 Succinct Attestation 的架构看了很久。DUSK 的 SA 共识每轮出块要经过 Proposal、Validation、Ratification 三个阶段，每个阶段由不同委员会处理，成员从质押至少 1000 DUSK 的节点中随机选出。任何写过 BFT 共识的人看到这套设计，都得承认它在安全性和终局性上确实有追求——“deterministic finality once a block is ratified”。
但顺着通信链路往下拆时，后背开始发凉。
三阶段委员会意味着每轮出块需要多次全网广播，这一切依赖 Kadcast——DUSK 自研的 UDP 结构化 P2P 广播协议。官方把它列为与共识并列的核心组件。但社区节点运营者反馈过实际问题：节点会卡在某个区块不动，只能靠快照重新同步；不同版本节点互相识别不了，日志里频繁蹦出网络不匹配的警告。2021 年的 Issue 也承认，Kadcast 节点一旦进入 OutSync 状态，就无法下载任何区块。
最让我不安的是 devnet 的实战记录：一次共识分叉事件中，同一轮产生了两个区块，30 个节点里只有 2 个成功执行了回退，其余节点继续在错误分支上运行。DUSK 确实设计了 Emergency Mode 作为兜底，但应急机制从未经历主网级实战检验。
三层委员会 + 自研广播协议 + 未经实战检验的应急兜底。关于 DUSK 的共识通信链路，你有没有不同的观点？
以上仅为个人看法，不构成投资建议。欢迎评论区聊一聊！
我点开文档，盯着 Succinct Attestation 的架构看了很久。DUSK 的 SA 共识每轮出块要经过 Proposal、Validation、Ratification 三个阶段，每个阶段由不同委员会处理，成员从质押至少 1000 DUSK 的节点中随机选出。任何写过 BFT 共识的人看到这套设计，都得承认它在安全性和终局性上确实有追求——“deterministic finality once a block is ratified”。
但顺着通信链路往下拆时，后背开始发凉。
三阶段委员会意味着每轮出块需要多次全网广播，这一切依赖 Kadcast——DUSK 自研的 UDP 结构化 P2P 广播协议。官方把它列为与共识并列的核心组件。但社区节点运营者反馈过实际问题：节点会卡在某个区块不动，只能靠快照重新同步；不同版本节点互相识别不了，日志里频繁蹦出网络不匹配的警告。2021 年的 Issue 也承认，Kadcast 节点一旦进入 OutSync 状态，就无法下载任何区块。
最让我不安的是 devnet 的实战记录：一次共识分叉事件中，同一轮产生了两个区块，30 个节点里只有 2 个成功执行了回退，其余节点继续在错误分支上运行。DUSK 确实设计了 Emergency Mode 作为兜底，但应急机制从未经历主网级实战检验。
三层委员会 + 自研广播协议 + 未经实战检验的应急兜底。关于 DUSK 的共识通信链路，你有没有不同的观点？
以上仅为个人看法，不构成投资建议。欢迎评论区聊一聊！