尽管尚未触发任何代码删除动作，也未作出最终裁决，但极低的节点活跃度已促使比特币核心团队深入审视在主客户端中维持遗留加密路由层所带来的实际安全代价与工程负担。
最近一次种子数据库扫描仅识别出七个符合“可靠”标准的CJDNS节点，揭示该加密传输层的实际部署规模已陷入严重萎缩。稀疏的节点分布大幅削弱了网络弹性，使恶意实体更易实施定向隔离与流量操控。当前讨论聚焦于保留备用通信路径的必要性，与持续维护高复杂度代码所带来潜在漏洞之间的权衡。
一场公开的GitHub议题引发对现有传输架构的深度审查，质疑比特币核心是否应继续为几乎无实际流量的加密路由层提供支持。其初衷是构建多层级容灾机制，以防单一网络层崩溃或遭遇审查。然而，该冗余设计的前提是底层存在足够数量的活跃节点，否则将形同虚设。
核心开发者Marco Falke报告称，其测试实例在任意时刻均难以建立超过三至四个独立连接。另一项调查针对一个包含25个已知地址的种子列表，虽有22个响应基础握手，但仅有7个满足用于区块传播和交易分发的技术合规标准。
需指出的是，此次采样非全面普查；私有节点与未被索引的实例仍可能存在于公共清单之外。但即便如此，可访问目标少于十二个的事实表明，该覆盖网络无法支撑生产环境所需的冗余能力。
CJDNS是一种基于公钥密码学的加密IPv6覆盖网络，实现分布式地址分配与动态路由。自2022年23.0版本起，比特币核心正式集成对CJDNS的支持，允许节点通过该通道与其他主流网络（如IPv4、IPv6、Tor、I2P）并行通信。
官方文档强调，其端到端加密特性提升了流量分析与过滤的难度。然而，它并非真正意义上的匿名网络——中间路由器虽无法解密内容，但仍能观察到加密源与目标地址，存在元数据泄露风险。
此功能仅影响节点发现与连接逻辑，不涉及区块验证、挖矿规则或共识机制。即使移除，比特币核心仍将执行完全相同的共识流程。
在比特币节点安全体系中，对等连接的质量直接决定抗干扰能力。加密可防止第三方窥探数据内容，但若可用连接池过小，则无法抵御虚假信息或延迟投递攻击。
日蚀攻击的核心在于完全控制目标节点的所有通信路径。攻击者通过垄断其进出连接，将节点从全球网络中孤立，进而操纵其接收到的区块信息、审查特定交易，甚至尝试双花未确认交易。
常规网络通过跨多个异构子网建立分散连接来防御此类攻击。但在仅依赖七节点的CJDNS环境中，可用连接总量严重不足，攻击者只需少量资源即可实现全包围，致使原本的安全后备沦为致命单点故障。
除了使用率低迷带来的安全隐忧，开发者还指出CJDNS集成对整体代码库造成的长期维护负担。
不同于标准化协议处理模块，CJDNS并未与标准IPv6逻辑充分解耦。因其采用特殊格式的IPv6地址，系统必须引入定制化处理流程、专用启动参数（如-cjdnsreachable），以及大量边缘场景修复逻辑。这些额外分支显著增加了代码复杂度，也提高了未来重构与漏洞修复的难度。
多位核心贡献者已表达对废除该功能的“概念性认可”。在开源社区语境中，这代表对宏观方向的认同，而非立即行动的承诺，也不构成最终决策。
反对移除的声音认为，当前低使用率不应成为否定其战略意义的唯一依据。开发者Jon Atack指出，自动化节点发现功能直至2025年初才完成集成，此前用户需手动配置地址，相比一键式部署的Tor或I2P，门槛极高。
支持者主张，低采纳源于认知盲区及主流节点软件缺乏整合，而非协议本身失效。一旦主要匿名网络遭受国家级封锁、基础设施瘫痪或大规模审查，像CJDNS这样的替代网格便可能成为关键的应急通信通道。
Atack已自愿承担代码维护责任，以缓解团队负担。当前争议本质是：究竟应为罕见极端情况保留备份路径，还是以精简代码为由彻底清除低效组件。
若未来版本中正式取消原生支持，比特币核心将停止对CJDNS连接的内部管理。这一变更不会禁止用户在操作系统层面独立运行该网络，也不会改变整个比特币网络的数据处理方式。
对于绝大多数依赖标准协议的节点运营商而言，该调整将毫无感知。此次讨论再次凸显比特币核心坚持的工程哲学：每一行代码都必须经得起安全性与实用性的双重检验。
声明：文章不代表币圈网立场和观点，不构成本站任何投资建议。内容仅供参考！
免责声明:本站所有内容仅供用户学习和研究,不构成任何投资建议.不对任何信息而导致的任何损失负责.谨慎使用相关数据和内容,并自行承担所带来的一切风险.