新装一个 Geth 节点，最常见的疑问是”为什么头几天那么快、后面突然变慢”。答案通常藏在同步模式里：主流的 snap 模式先把状态本身搬进来，历史交易只在接近链尖时才逐块执行；而它的前身 full 模式要从创世块一路重放到今天。同一个节点、同一份硬盘，两种路径的时间差可以拉到几周量级。本文拆这笔账怎么算、快照为什么必须预先造好，以及卡住时的排查顺序。
两条路径在耗时上差在哪
full 模式的逻辑最直白：把每一块的交易依次执行一遍，状态是执行的副产品。好处是自带审计——每个中间状态都被重算过一次；代价是执行历史交易时的那些账户与存储节点散落各处，读盘几乎全是随机访问，历史越久越像拿锤子砸硬盘。
snap 模式换了思路：把”状态现在长什么样”当成一个可以直接下载的对象。节点先取区块头并选出规范链，随后向网络分段索取账户与存储的实际叶子值——注意是连续的可用数据段，而不是沿途的默克尔中间节点——拿到之后在本地自己把那棵哈希树重建出来。少下载的是海量的中间节点，省下的是等量的随机读。官方发布说明把这条路径描述为”下载连续一段段的有用状态数据、然后在本地重建默克尔 trie”，并说明快照来自一次性生成的动态快照结构。等状态追到离链尖不远的位置，节点再切回逐块执行，把最后那段历史交易真正跑一遍。
快不是白来的
快照同步把成本挪了三个地方，都要算回去。第一处是快照得有人造：它不是网络自带的基础设施，而是由提供该服务的节点先行生成并持续维护；一个刚出厂的节点若找不到愿意供给快照的对端，就只能退回逐块执行。官方在 v1.10.0 发布说明里就明确写过，快照同步随版本发布但当时尚未默认启用，原因正是担心默认切换后用户找不到合适的对端而反复回退。第二处是重建 trie 的开销：叶子值到位不等于状态就绪，本地要把整棵树算出来，这段时间磁盘写与哈希计算都会顶上去，进度条看起来像停住。第三处是审计边界的改变——大量历史状态是被”接受下载并验证到根哈希”而非重新执行，这属于信任模型上的取舍，安全性靠状态根一致性与链尖执行兜住，不是靠全网重放。
默认值与怎么确认自己在哪档
go-ethereum 的 syncmode 标志接受 snap 与 full 两个取值，其默认值取自配置的默认同步模式，当前默认为快照模式；仓库里 ethconfig 的 Defaults 也是 SnapSync。想确认现场状态，看日志里的同步阶段描述最直接：报账户与存储分段下载的是快照阶段，报导入区块与执行交易的是逐块阶段。运维上常见的误解是把中间那截”看起来没进度”的时段当成死机——多数时候是状态树重建在写盘。
卡住时的三步排查
第一步看阶段：如果是逐块执行慢，瓶颈通常是执行与随机读，考虑数据库与缓存配置，而不是网络。第二步看阶段切换条件：若长期停在快照阶段不动，先确认是否有可用对端在提供快照数据，这类停滞多半是候选池里没有合适的供给方。第三步看磁盘与容量：状态重建与快照落盘都是写密集操作，空间不足或写入延迟过高都会把进度压成阶梯状。三步的顺序不能反——阶段判断错了，后面每一步的处方都会开错。
快速问答
问：快照同步比逐块执行安全吗？ 答：两者最终都要与链尖状态一致，差别在于历史部分是被下载验证还是重新执行，属于信任边界不同而非对错。
问：老节点能用快照方式补齐吗？ 答：快照同步面向的是新装节点的首次追赶；已经带完整历史数据的实例走的是各自既有的同步与维护路径。
问：中途能改模式吗？ 答：模式在启动时决定，改动需重启；已经开始的同步不会静默切换到另一条路径。
风险提示：本文解释节点实现与同步机制，不构成投资建议。生产部署前请在独立实例完整跑一遍同步与查询验证。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。