追赶的两种模式
引导（bootstrapping）——从零走到当前版本——有两条根本不同的路子。 重放历史。从创世往前推，要么把每笔交易重新执行一遍，要么套用执行当年产出的输出。这样得到的节点持有完整历史：每个版本、每份证明、每笔交易。代价是慢，而且这条链每多跑一天就更慢。 下载当前状态。跳过历史，直接取最新版本上的状态键和值，对照已提交的根验一遍。节点花零头的时间就追上了当下，但对这条链怎么走到这一步一无所知。新节点
引导模式
重放历史从创世开始重新执行，或套用已存的输出慢，而且这条链每多跑一天就更慢
下载当前状态最新版本上的键与值，对照已提交的根验证花零头的时间就追上当下
当前版本此后持续同步
两条路并不等价下载当前状态的节点提供不了历史查询，也答不出某个仓位是怎么走到今天这一步的。给索引器或审计供数据的节点，恰恰需要它跳过的那段历史。
这是运维决定，不是可以不假思索就接受的默认值。下载当前状态的节点提供不了历史查询，也答不出某个仓位是怎么走到今天这一步的——它手上没有历史可读。给索引器或审计流程供数据的节点，恰恰需要它跳过的那段历史。
保持在当前版本
到了当前版本，节点靠消费陆续到达的已提交区块跟上进度——同样可以选执行交易或套用输出，验证强度和速度之间还是那套取舍。 和引导不同：这里的差距小而恒定，不像引导那样又大、又要慢慢追平。节点落后到一定程度就退回引导路径，不再逐块去补一个不知道多大的缺口。数据如何流动
同步不是一个节点向另一个节点要一段区块。它被拆成若干层，这样没有哪个对等节点会变成依赖，也没有哪个单点故障能让进度停下来。
有一个推论值得记住：正在同步的节点并不信任对等节点。每个数据块到达时都带着一份证明，对的是网络已提交的根；哪个对等节点给的数据对不上，就被拒掉，而不是被相信。挑对等节点是性能决定，不是信任决定。
验证
状态同步里，没有任何东西是凭发送方是谁就被接受的。 状态值对照已提交的状态根来验，交易和输出对照累加器来验。节点引导完成时，它的状态根和验证者法定人数签下的那个一致——快速路径之所以安全，靠的就是这一点：下载当前状态跳过的是历史，不是验证。后续阅读
存储与证明
使同步可验证的那些结构。
运行节点
节点角色，以及运营节点该找谁问。
网络拓扑
正在同步的对等节点在和哪一层节点通信。
索引器
历史能回答而当前状态无法回答的问题。