检查点同步是什么？以太坊节点为什么不从创世块开始追链

一句话理解

检查点同步是新节点的一条上线捷径：不再从创世块逐块重放全部历史，而是从一个近期被全网公认定稿的状态快照出发，先向链头快进，再回头慢慢补历史区块。一个被最终性确认的检查点状态充当信任锚，把「这条链是不是真的」这个问题，压缩成「这个检查点是否可信」这一个问题。

为什么会有这条路

以太坊节点分执行层与共识层，从创世逐块验证全部历史，需要的数据量与时间对多数运维场景没有必要。检查点同步的做法是从一个已同步好的远端信标节点拉取一个近期最终化检查点的区块与状态，核对无误后把它当作起点向链头同步。Lighthouse 的公开文档对这条路径给了两个理由：更快，显著快于从创世同步且功能相同；更安全，因为它能防住创世同步防不住的长程攻击。第二个理由听起来反直觉，得从权益证明的一个特性说起。

弱主观性：锚点从哪来

权益证明链的安全依赖当前活跃验证者的投票权重，历史区块本身不再自带安全预算。一个掌握大量早期质押记录的攻击者，理论上可以从很久以前伪造一条规则上自洽的分叉；完全没有近期状态做参照的节点，很难从协议规则内部分辨新旧分支。这就是文档所称的弱主观性。检查点状态的作用，是给出一个各方都承认网络已经定稿的时刻：从那里向前，按现行规则正常验证；向回看，只承认哈希衔接而不必逐块复算。Lighthouse 文档进一步说明，自 v4.2.0 起，回填默认只回补到弱主观期附近，其中按该文档当时说明约五个月，需要一直补到创世得显式加参数；这个数字是该客户端对实现边界的说明，不是全网统一的精确常量。

操作层面发生了什么

Lighthouse 文档写明，自 v4.6.0 起检查点同步是默认路径，不提供检查点来源就不会从创世追链。操作要点有两条：准备一个可访问的已同步信标节点的 HTTP 地址，作为检查点同步参数传入；节点启动后会打印加载的检查点的状态根、区块根与槽位。文档特别建议把这些数字与可信来源交叉核对——朋友的节点、区块浏览器，或社区维护的公共端点列表。随后节点向前同步到链头，再开始回填历史区块；为保护验证性能，回填自 v4.1.0 起带限速，默认速度明显低于快进阶段，磁盘与网络预算要按此规划。历史区块在回填阶段只做哈希衔接与提议者签名的轻量校验，不重算状态转换，文档同时说明这不影响验证者职责。

哪些场合仍然要完整历史

做分析服务的人需要历史状态，检查点同步的节点默认缺这段账。Lighthouse 提供归档模式，让节点在同步完成后重算并重建历史状态，数据库用三个标记记录哪段历史与状态可查。如果只是跑验证者或普通读接口，这段账不必还。还需要分清两个不是一回事的概念：这是以太坊权益证明语境下的检查点同步，与比特币节点用假设高度提前跳过旧区块校验的做法解决的问题不同；弱主观期也不是一个精确的全网常量，不同实现给出的长度不同，看到具体数字先确认出处。

风险边界与核验顺序

检查点同步没有消除信任，只是把信任集中到一个近期锚点上。来源不可用或被篡改，节点可能接受错误的起点，所以配置后的第一件事是交叉核对打印出的区块根与槽位。它也不提供对当前链头之争的特殊保护，当下的分叉判断仍依赖验证者投票与最终性规则。本文描述客户端公开文档中的机制，不构成任何投资建议。