比特币核心拟裁撤极低活跃度加密路由层，安全与维护博弈升温

尽管尚未做出最终决策，也未移除相关代码，但极低的节点采用率已促使贡献者重新评估在比特币主客户端中维持遗留覆盖网络所带来的实际安全风险与工程成本。

仅存七个健康节点暴露网络脆弱性

最新一次种子数据库核查仅识别出七个符合“良好”标准的CJDNS节点，凸显该网络的实际使用规模微乎其微。稀疏的节点分布严重削弱了抗攻击能力，使恶意实体更易实施隔离与操控，威胁仅依赖此路径的节点通信完整性。

基础设施健康度引发现有协议存续性讨论

这场技术辩论起源于一个公开的GitHub议题，质疑比特币核心是否应继续支持一个几乎无流量的加密传输层。虽然其初衷是构建多层冗余以应对审查或网络故障，但只有当底层存在足够活跃节点时，这种冗余才具备实际意义。

核心开发者Marco Falke报告称，其测试实例在任何时刻均无法建立超过三至四个有效连接。另一位贡献者对包含25个地址的公共种子列表进行探测，虽有22个响应基础握手，但仅有7个达到可被用于区块与交易传播的“稳定可靠”标准。

需指出的是，此次查询并非全面普查。未公开的私有节点或未索引节点仍可能存在于系统之外。然而，可访问目标不足十二个的事实表明，当前覆盖网络难以支撑生产级节点所需的弹性连接池。

解析加密网格：基于公钥的分布式路由机制

CJDNS是一种基于公钥密码学的加密IPv6覆盖网络，实现地址分配与分布式路由。自比特币核心23.0版本起，原生支持其作为多协议传输选项之一，允许节点通过CJDNS、IPv4、IPv6、Tor及I2P等路径进行对等通信。

官方文档指出，该协议提供端到端加密，增强流量分析抵御能力。但不同于Tor的匿名设计，中间路由器仍可见加密包的源与目标地址，不具备完全匿名性。

该功能仅影响节点发现与连接逻辑，不涉及区块验证、挖矿规则或共识机制，移除后不会改变比特币的基本运行规则。

日蚀攻击防护机制面临失效风险

在比特币网络架构中，对等节点选择与传输层可靠性直接决定数据完整性的保障程度。即便加密能隐藏内容，若可选节点池过小，仍无法防范虚假或延迟信息的注入。

日蚀攻击的核心在于控制目标节点的所有连接，使其脱离真实网络。攻击者可通过垄断全部出入连接，篡改区块传播时间、审查交易或发动双花攻击。

标准协议通过跨多个网络组建立多样化连接来缓解此类威胁。但在仅存在七个可信节点的CJDNS环境中，可用连接资源极为有限，攻击者只需少量资源即可实现完全包围，将原本的安全后备转化为关键单点故障。

维护负担与代码复杂性成为弃用动因

除安全缺陷外，部分开发者强调CJDNS集成带来的持续维护压力。其特殊格式的IPv6地址导致代码库需引入定制化处理逻辑、专用启动参数（如-cjdnsreachable）及异常处理分支。

这些非标准路径增加了漏洞引入风险，并干扰了网络栈的常规重构工作。多位核心贡献者已表达对移除该功能的“概念性认可”，即原则上认同其宏观目标，但尚未进入正式投票或合并流程。

紧急备用价值仍被部分开发者坚持

反对移除的声音认为，当前低使用率不应成为否定其潜在价值的唯一依据。开发者Jon Atack指出，自动化节点发现功能直至2025年初才上线，此前用户必须手动配置地址，显著提高部署门槛。

支持者主张，当前低迷反映的是认知不足与集成缺失，而非协议本身无效。一旦主流匿名网络遭遇大规模封锁或基础设施崩溃，CJDNS这类替代性网格协议或将成为维持节点连通的关键应急渠道。

Atack亦表示愿独立承担该模块的维护责任，以减轻团队负担。因此，核心团队面临抉择：是保留边缘场景下的安全冗余，还是为提升代码质量而清除低效组件。

移除方案对运营者的实际影响

若未来版本决定移除原生支持，比特币核心将不再主动管理CJDNS对等连接。此举不影响操作系统层面的外部运行，也不改变比特币整体网络行为。

对于绝大多数依赖标准协议的节点运营商而言，该变动将毫无感知。本次争论本质体现了比特币核心一贯的工程原则：每一行代码都必须经受住安全性与实用性的双重检验。