比特币早期版本有一个叫”检查点”的机制：软件里预置若干块哈希和高度，新节点在初始同步到某个高度之前，只接受预置认可的链，以此降低历史时期的资源耗尽类攻击面。随着assumevalid这类更灵活的假设机制成熟，硬编码检查点变得多余，最终被移除。到了当前版本，如果你还在配置文件里写 -checkpoints，会看到一句明确的警告——参数还在，但它不再有任何作用。这段逻辑就在 src/init.cpp 里。
参数为什么还留着
源码在解析参数阶段专门处理这件事。它把 -checkpoints 注册成一个隐藏的、帮助文本为空的参数——也就是说它不出现在常规 -help 里，存在的唯一理由是：如果有人在旧配置里还留着它，程序能给出一个友好的提示，而不是报”未知参数”让人一头雾水。启动检查里还有一段：只要检测到用户设了 -checkpoints，就抛出一条初始化警告，说明”选项已设置但检查点已被移除，此项无效”。这是一次典型的”接口向后兼容、内部实现已掏空”的处理。
移除了什么、留下了什么
被移除的是节点在验证历史区块时”强制对齐到某预置链”的那套硬规则。保留的是两个更聪明的替代：一是 assumevalid 一族，让你对某个足够高的区块之后的历史签名验证做有边界的信任跳加速；二是节点仍会照常验证工作量、验证区块结构、验证交易合法性。也就是说，检查点的”历史信任被写死在二进制里”这件事被彻底放弃了，取而代之的是”可以假设但可配置、可撤销”的方式。旧配置里的 -checkpoints=0 或带值的写法，现在对同步行为没有任何影响，唯一效果是那条启动警告。
会不会影响安全
不必因为看到警告就担心安全退化。检查点当初要解决的问题——远古时期的算力不足以支撑从创世逐块盲验——早已被 assumevalid 加最小累计工作量下限等机制以更稳妥的形态覆盖。检查点本身还有个众所周知的顾虑：它把某段历史的”正确链”硬编码进软件，与比特币”运行中的节点自己按规则判定”的去中心化取向有张力。移除它，是把这类硬编码信任交还给可配置、可验证的机制，而不是取消验证。
运维该怎么处理这条警告
如果你在升级后日志里看到那条”检查点已移除、此项无效”的提示，正确动作是把配置文件里的 -checkpoints 行删掉，让日志安静下来——它只是提醒你有历史遗留配置在空转。不需要为它改同步方式、不需要额外操作。要确认节点行为没受影响，看同步是否正常完成、assumevalid 类设置是否符合你的加速预期即可。把它当作一次配置卫生清理，而不是安全事件。
代码里的两处落点
参数注册处写着”检查点已被移除，保留 -checkpoints 作为隐藏参数以便设置时给出更友好的提示”，帮助文本留空，因此 -help 与 -help-debug 都看不到它；能看见它的唯一途径就是设上它、触发警告。启动校验里另有专门一段检测用户是否设了该参数，命中就发出初始化警告”选项已设置但检查点已移除，此项无效果”。两条路径合起来就是升级后你能看到的全部痕迹：一次警告，仅此而已。历史上的检查点机制用内置的”高度到哈希”强制映射，让同步在到达指定高度前拒绝竞争分支，在远古算力薄弱期降低了历史重写与资源耗尽风险；assumevalid 一族成熟之后，这种信任改为可配置、可撤销的形式，硬编码序列遂被整体废弃。节点同时保留 assumevalid 加速参数与按累计工作量下限拒绝异常链的机制，共同接替旧职能。核对配置文件时顺手删掉 checkpoints= 行即可：日志归于安静，同步行为零变化。本文讨论软件演进与配置维护，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。