依赖风险审计备忘：go-libp2p-kad-dht DHT 发现机制的 Sybil/审查风险

[liujuanjuan1984]

背景

在依赖升级与 govulncheck 审计过程中，当前项目因直接依赖 github.com/libp2p/go-libp2p-kad-dht 被命中 GO-2024-3218。该记录关联 GHSA-mqr9-hjr8-2m9w / CVE-2023-26248，风险来自开放式 Kademlia DHT 在 peer/content discovery 场景下可能受到 Sybil / eclipse / content-censorship 攻击。

这不是当前项目自有实现中的普通 bug。本项目使用 libp2p DHT 作为自动/动态 peer discovery 的主要机制之一，风险来源主要在依赖与发现架构层。

当前项目中的适用面

当前项目中，full node / producer node 初始化 libp2p host 时启用 go-libp2p-kad-dht/dual，并通过 RoutingDiscovery 执行 rendezvous advertise 与 periodic peer discovery。

现有其它机制包括：

• bootstrap peers：启动时显式连接配置的 peer；
• pubsub peer exchange：已有 mesh 内辅助传播 peer；
• 手动 AddPeers API；
• skip peers / blacklist 类过滤。

但 DHT 基本仍是当前唯一的自动、动态 peer discovery 机制；项目没有全局的可信 peer allowlist / signed peer registry / 链上成员驱动的发现机制。

风险影响

该风险不等价于“可直接伪造区块”或“破解 libp2p 加密”。更准确的影响是发现层与连通性层：

• 节点可能发现不到真实 peer，启动或重连困难；
• 节点可能被引导连接到大量攻击者控制的 peer，形成 eclipse 风险；
• 共识网络若依赖 DHT 自动发现生产者/验证者，可能出现网络分区、延迟增大、出块不稳定；
• 对联盟链/许可链场景而言，把共识关键 peer discovery 交给无准入、低身份成本的开放式 DHT，是架构层风险。

为什么容易误解

公开漏洞数据库的版本口径不完全一致：

• GitHub Advisory / NVD 的描述中提到影响 go-libp2p-kad-dht <= 0.20.0、IPFS <= 0.18.1；
• Go vuln DB / govulncheck 仍将 github.com/libp2p/go-libp2p-kad-dht 标为 all versions / no known fixed；
• 因此即使升级到当前较新的 go-libp2p-kad-dht v0.40.0，审计工具仍可能继续报告该风险。

这容易造成两个误判：

1. 误以为当前项目独有地引入了一个新漏洞；
2. 误以为只要 bump 到最新版本就一定能消除审计风险。

更合理的理解是：该风险是开放 DHT 发现机制的结构性风险，版本升级可能降低已知实现问题，但无法单独证明共识网络发现层已经安全。

为什么难以彻底解决

Kademlia DHT 的核心机制是按 keyspace 距离寻找“最近”的 peer。在开放网络里，攻击者可以低成本批量生成 peer ID，并筛选靠近目标 key 的身份。只要网络允许任意节点加入，且发现结果主要由距离度量决定，就天然存在 Sybil / eclipse / content-censorship 空间。

可行缓解通常需要引入 DHT 之外的信任或成本机制，例如：

• peer 身份准入；
• allowlist / trusted peer set；
• signed peer record；
• 链上成员列表驱动的 producer / validator peer discovery；
• trusted bootstrap/discovery nodes；
• 查询结果多样性过滤；
• 将 DHT 降级为非关键 fallback 或默认关闭。

建议方向

建议不要把 DHT 作为共识关键 peer discovery 的权威来源。更可靠的升级方向是：

1. 保留 libp2p transport / connection / pubsub 能力；
2. 将 discovery 层抽象出来，支持 static、bootstrap、hybrid、dht 等模式；
3. 默认使用可信 bootstrap + 显式 allowlist / 链上成员列表 + signed peer record；
4. DHT 仅作为非关键 fallback，或在生产/共识网络中默认关闭；
5. 若最终目标是消除 govulncheck 命中，需要让生产构建不再导入 go-libp2p-kad-dht。

本 issue 仅作为依赖风险 audit 备忘，不作为普通 bug 报告。

[liujuanjuan1984]

追加一条本地联调观察，作为依赖/发现机制 audit 背景备忘的一部分（不是 bug 报告）：

• 在 1 个 bootstrap/address-book 节点 + 2 个 fullnode 的本地拓扑下，两个 fullnode 初始都能连接到 bootstrap，并在 kad/meshsub 层看到 bootstrap。
• 创建 group、第二个 fullnode 通过 seed join 后，owner fullnode 可以接收内容交易并出块；实际观察到 block 1 包含提交的交易。
• 第二个 fullnode 初始没有自动发现 owner fullnode，group peer 列表为空或未包含 owner，因此 rex 同步请求曾发送到 bootstrap 节点。
• bootstrap 节点不提供 /rex/2.0.0 协议，rex 请求因此出现协议协商失败；这说明“bootstrap/DHT 发现到的 peer”与“可作为 group block/data provider 的 peer”之间目前缺少足够明确的角色过滤或可用性校验。
• 通过现有 peer API 将两个 fullnode 显式互连后，第二个 fullnode 在后续 rex retry 中成功同步到 owner 的 block 1，并能通过内容接口读取同一笔交易。

这个现象进一步支持前述 audit 判断：风险点不只是 DHT 依赖本身，也包括当前自动发现结果未按节点角色、group membership、rex 协议能力和数据提供能力做足够筛选。较稳妥的改进方向应包括：

1. bootstrap/address-book 节点继续保持轻职责，不默认承担 block/data sync provider；
2. fullnode 发现链路需要明确筛选可用的 group peers，而不是把任意已连接 peer 都作为 rex 同步候选；
3. peer metadata 或握手阶段应暴露节点角色、支持协议、group membership/data availability；
4. syncer 在选择 provider 时应跳过不支持 rex 或不属于目标 group 的节点，并优先选择 owner/producer/已声明可提供数据的 fullnode；
5. DHT 之外应保留或增强可信 bootstrap peers、显式 allowlist、pubsub peer exchange 等机制，降低对单一自动发现机制的依赖。

[liujuanjuan1984]

追加基于 ii-commons 的论文审查结论和落地优先级修订。

检索口径：ii-commons arXiv 截止日期为 2026-06-19。相关论文整体支持本 issue 的判断：这不是单一版本依赖 bug，而是开放式 / 低身份成本 DHT discovery 在 Sybil / eclipse / content-censorship 场景下的结构性风险。

关键证据：

• arXiv:2307.12212 / NDSS 2024: Content Censorship in the InterPlanetary File System
  • 直接对应 CVE-2023-26248 / GO-2024-3218。
  • 论文说明攻击者可以生成靠近目标 content ID 的 Sybil peers，劫持 provider record 解析，使内容不可发现。
  • 论文提出 KL-divergence 检测和 region-based DHT 查询作为缓解，但这仍是 DHT 层面的缓解，不等价于把共识关键 discovery 安全化。
• arXiv:2505.01139 / Computer Networks 2026: Active Sybil attack and efficient defense strategy in IPFS DHT
  • 进一步说明旧的检测 + 扩大发布缓解仍可被主动 Sybil 攻击绕过。
  • 论文提出 SR-DHT-Store，并强调需要系统性 region-based queries、可与 S/Kademlia 等机制组合。
  • 对本项目的含义是：即使上游 DHT 实现继续优化，也不应把 DHT 作为 quorum / group / producer discovery 的权威来源。
• arXiv:1908.10141: Eclipsing Ethereum Peers with False Friends
  • 区块链网络层案例表明 Kademlia-inspired peer discovery 可被低成本身份和节点选择逻辑操控。
  • 论文建议长期减少对 ID-based peer selection 的依赖，高价值目标应使用静态可信 peers。
• arXiv:2402.16201: Honeybee: Byzantine Tolerant Decentralized Peer Sampling
  • 明确指出 Kademlia 与 GossipSub address exchange 在 Sybil 场景下不能提供安全随机采样。
  • 支持本 issue 中“不应依赖单一自动发现机制”的判断。
• arXiv:2603.23793: AetherWeave: Sybil-Resistant Robust Peer Discovery with Stake
  • 解决方向是给 peer discovery 引入 stake / slashing 等外部成本和惩罚机制。
  • 对许可链/联盟链场景，可类比为成员准入、签名 peer registry、链上成员列表等外部信任/成本机制。

结合论文结论，建议把当前方案落地优先级修订为：

P0：先保护共识关键路径，DHT 不作为权威 discovery

1. 增加 discovery mode 配置，例如：static / bootstrap / hybrid / dht。
2. 生产或共识网络默认不要依赖 DHT 发现 producer / validator / group data provider。
3. 对 quorum / group / producer 相关 peer，优先使用：
   • 显式 bootstrap peers；
   • 静态 trusted peers；
   • allowlist；
   • 链上 group member / producer 列表；
   • 签名 peer record / signed provider metadata。
4. DHT 仅作为非关键 fallback 或显式 opt-in 模式，而不是默认 authority。

P1：把“发现 peer”和“可用 group data provider”解耦

本地联调现象已经说明 bootstrap/DHT 发现到的 peer 不一定支持 /rex/2.0.0，也不一定属于目标 group 或持有目标 block/data。建议优先补齐 provider 选择前的能力校验：

1. peer metadata / handshake 暴露：
   • node role: bootstrap / fullnode / producer / relay；
   • supported protocols: rex、meshsub 等；
   • group membership；
   • data availability / latest block height；
   • record signature + expiry。
2. Rex syncer 选择 provider 时跳过：
   • 不支持 rex 协议的 peer；
   • bootstrap/address-book-only peer；
   • 不属于目标 group 的 peer；
   • 未声明或无法证明持有目标数据的 peer。
3. provider selection 应优先：owner / producer / 已验证 fullnode / 最近成功 provider。

P2：保留 DHT 时增强防御，但不要把它当作充分修复

如果仍保留 DHT fallback，可考虑：

1. 查询结果多样性过滤：IP subnet / ASN / peer ID 距离分布 / connection history。
2. 对 DHT 结果做 signed peer record 校验。
3. 对异常集中靠近某 target key 的 peer 做检测或降权。
4. 对 discovered peer 先做协议能力探测，再进入 group/Rex provider candidate set。
5. 将 DHT 连接结果和 group provider candidate set 分开维护。

这些措施可以降低风险，但根据 2024/2026 IPFS DHT 论文，不应视为彻底修复。

P3：依赖升级与 govulncheck 处理

1. 继续保持 go-libp2p-kad-dht 在较新版本，用于获得上游已有 hardening。
2. 但不要把 version bump 作为关闭本 issue 的充分条件。
3. GO-2024-3218 当前在 Go vuln DB 中仍标为 all versions, no known fixed，因此即使使用 v0.40.0 仍可能被 govulncheck 命中。
4. 如果最终目标是消除生产构建的审计命中，需要让生产 build path 不再导入 github.com/libp2p/go-libp2p-kad-dht，仅运行时关闭 DHT 通常不够。

修订后的判断：

• 短期可先做 P0/P1，把共识和 Rex 同步路径从开放 DHT 结果中隔离出来。
• 中期做 discovery abstraction，让 DHT 成为可替换、可关闭的 discovery backend。
• 长期如果需要保留开放网络能力，再研究 Honeybee / stake-backed discovery / signed registry / 链上成员发现等更强模型。
• issue 的关闭条件不应是“依赖升级完成”，而应至少包括“生产/共识关键 discovery 不再以开放 DHT 作为权威来源”。