目前尚未删除任何代码，也没有做出最终决定，但持续低迷的使用数据促使 Bitcoin Core 贡献者重新审视在比特币主客户端内维护传统覆盖网络的实际安全与工程权衡——这场讨论的焦点如今集中在加密路由网络 CJDNS 是否仍有理由留在参考实现之中。

七个“好”节点引发更广泛的基础设施审查

这场技术讨论始于一个公开的 GitHub issue，开发者在其中质疑 Bitcoin Core 是否应继续支持一个几乎没有任何有记录的真实流量的加密路由层。为比特币添加替代网络传输层的核心目标是冗余性：防止任何单一的网络层故障点或审查。然而，只有当活跃的对等节点网状网络参与底层网络时，冗余路由才能发挥作用。

在对仅使用 CJDNS 的节点设置进行自动化测试期间，Core 开发者 Marco Falke 报告称，他的实例在任何时候都无法与超过三到四个不同的对等节点建立连接。针对这一发现，另一位贡献者查询了一个成熟的网络种子节点数据库——即为新启动的节点提供首批对等节点地址的引导服务——其中包含 25 个已知的 CJDNS 地址。在测试的 25 个地址中，有 22 个响应了基本握手，但只有 7 个满足被归类为可靠“好”对等节点所需的技术标准，可用于活跃的区块和交易传播。

单次种子节点查询并不代表对整个 CJDNS 生态系统中所有运行节点的绝对普查；私有的、未公开广播的节点以及未被索引的对等节点可能仍存在于公共种子节点列表之外。即便如此，这些数字也凸显了一个严峻的现实：一个可访问路由目标少于十二个的覆盖网络，无法提供弹性生产节点所需的运行冗余。作为参照，长期运行的公共爬取统计到的 Tor 广播可达比特币节点数以千计，而 CJDNS 种子节点中仅持有 25 个地址。

理解 CJDNS：加密 IPv6 路由与共识规则

CJDNS 是一个加密的 IPv6 网状网络覆盖层，使用公钥密码学进行地址分配和分布式路由。在比特币之外，该协议最为人熟知的身份是志愿者运营的社区网状网络 Hyperboria 的路由层。Bitcoin Core 于 2022 年在版本 23.0 中添加了原生 CJDNS 支持，使节点运营者可以在 IPv4、IPv6、Tor 和 I2P 之外，通过 CJDNS 路由对等流量。

根据 Bitcoin Core 的文档，CJDNS 会对流量进行端到端加密，并可使流量分析和过滤变得更加困难。然而，它并不是与 Tor 意义相同的匿名网络：中间的 CJDNS 路由器仍然可以看到它们所转发的数据包的加密源地址和目标地址。

该提案仅涉及 Bitcoin Core 如何发现并连接对等节点。移除 CJDNS 支持不会改变区块验证、挖矿、脚本规则或交易格式；节点将继续执行相同的比特币共识规则。

日蚀攻击的安全机制

在比特币节点安全中，网络传输和对等节点选择与数据完整性直接相关。加密可以向第三方隐藏数据包内容，但如果节点的对等节点选择过于受限，它并不能保护节点免于被喂送虚假或延迟的信息。稀薄的对等节点池会削弱安全性，使恶意行为者隔离和操纵仅使用 CJDNS 的节点变得容易得多。

孤立节点面临的主要威胁是日蚀攻击（eclipse attack）。在日蚀攻击中，攻击者会攻陷或控制目标节点建立的所有对等连接。通过完全包围目标节点，攻击者实际上将其与合法的全球比特币网络隔离开来。从这个位置出发，攻击者可以通过延迟区块广播、审查特定的传入交易，或对未确认交易尝试双花攻击，来操纵受害者的区块链视图。

在标准的 IPv4、IPv6 或 Tor 路由下，Bitcoin Core 通过在不同网络组和网络范围内建立多个独立连接来缓解日蚀攻击；默认情况下，该软件同时保持八个出站全转发连接。而当一个节点仅在只有 7 个可靠对等节点的网络上运行时——少于这些默认的出站槽位——可用连接的总池就太小了：攻击者只需极少的资源就能垄断仅使用 CJDNS 的节点的所有传入和传出连接，使原本的安全后备方案变成严重的单点故障。

代码复杂性与弃用的理由

除了使用率低和安全方面的担忧之外，支持移除的开发者还强调 CJDNS 代码给整个 Bitcoin Core 软件仓库带来的持续维护负担。

与标准协议处理器不同，CJDNS 集成并未与标准 IPv6 连接逻辑完全隔离。由于 CJDNS 使用特殊格式的 IPv6 地址，代码库需要自定义处理逻辑、专门的启动参数（如 -cjdnsreachable）以及针对边缘情况的特殊变通方案。随着时间的推移，开发者注意到这些自定义逻辑路径会引入缺陷风险，并使网络栈的日常重构变得复杂。传输层也在积极开发之中，BIP 324 加密 v2 传输已作为选项在版本 26.0 中发布，并在版本 27.0 中默认启用——在 CJDNS 等传统路径被重新评估的同时，新的连接代码不断到来。

几位 Core 贡献者已对弃用该协议表示“Concept ACK”。在开源 Bitcoin Core 开发术语中，“Concept ACK”表示贡献者赞同提案的总体目标；它并不构成最终投票、代码合并或立即移除该功能的承诺。

长期紧急备用方案的理由

在争论的另一端，主张谨慎的开发者认为，节点的实用性不应仅凭当前的流量指标来判断。贡献者 Jon Atack 指出，自动化 CJDNS 对等节点发现直到 2025 年初才集成到 Core 中。在该更新之前，节点运营者必须手动配置对等节点地址——与 Tor 或 I2P 提供的一键式设置相比，这一过程造成了显著的准入门槛。

支持者认为，CJDNS 使用率低源于用户认知不足以及在流行的即装即用节点软件发行版中的集成有限，而非其缺乏内在价值。如果 Tor 或 I2P 等主要公共匿名网络遭遇集中式封锁、基础设施中断或国家级过滤，CJDNS 等替代网状协议可以提供一条维持对等连接的重要紧急备用通道。

Atack 还主动提出亲自维护 CJDNS 集成代码，以解决关于开发者负担的担忧。Core 贡献者现在必须决定，是为边缘情况的紧急状况保留一条替代传输路由，还是通过移除低使用率的网络逻辑来精简代码库。

潜在移除对节点运营者意味着什么

如果 Bitcoin Core 最终在未来的版本中移除原生 CJDNS 集成，该软件将只是停止在应用层内部管理 CJDNS 对等连接。这一变化不会阻止运营者在操作系统层面外部运行 CJDNS，也不会改变更广泛的比特币网络处理交易的方式。

Bitcoin Core 的移除操作通常遵循缓慢且有据可查的轨迹——弃用会在发行说明中被标记，代码只会在稍后的主要版本中删除，遵循该项目大约六个月的发布节奏——因此值得关注的标志包括 GitHub 讨论串、任何正式的弃用拉取请求，以及 2025 年添加的自动化对等节点发现在维护者做出决定之前是否会改变使用数据。

对于依赖标准 IPv4、IPv6、Tor 或 I2P 连接的绝大多数节点运营者而言，CJDNS 的移除将完全不会被察觉。这场持续进行的讨论体现了 Bitcoin Core 严谨的工程理念：每一行代码都必须通过经过验证的安全性和活跃的实用性来证明其存在的合理性。

本文仅供参考，不构成投资建议。

来源：Coindoo