每当我想起目前还有多少人仍在使用 Infura(通过 Metamask、Gnosis-Safe 等)与链上应用程序交互时，我就感到有点难受。Infura 的服务很棒，但如果大部分用户都不自己运行节点，显然也不太对头。即使是非常有能力且积极性非常高的开发人员，也不能完全摆脱对 Infura 的依赖。从这点看来，我们仍未完成以太坊的 “自主验证” 愿景中的重要部分。

Full Sync(完全同步方法)

完全同步方法是执行自创世区块以来的每一个区块。创世区块标志着一个起始创世状态(状态的内容包括帐户余额、合约字节码、合约存储内容等)。所谓 “执行区块” 就是，每下载到一个区块，就读取前一个状态并(根据区块内容)产生新状态，并以该新状态来验证区块头中的状态根(以验证该区块是不是一个有效的区块)。在以太坊主网上完全同步的速度非常慢，而且随着网络的老化，使用完全同步方法来同步到最新区块的时间也会越来越长。所以人们开发出了 “快速同步” 方法。

Fast Sync(快速同步方法)

快速同步方法就是下载过去所有的区块和区块头，并选择最近的区块作为 “启动块”。启动块以前的区块都跳过执行，到了启动块再开始执行区块。这种方法假设了从创世块到启动块都正确地遵循了所有 EVM 规则。这个假设是合理的，因为矿工有动力遵循诚信不作恶原则，生产正常区块，拒绝可能具有攻击性的区块。

在快速同步可以执行启动块之前，需要的区块状态包括：合约字节码、帐户和合约存储内容。执行交易时可能需要读取所有这些值中的任何一个。因此，快速同步方法要求从其他对等节点处获得启动块之前的状态快照。快照是用状态根哈希值来标记的;所谓状态根哈希值，就是所有状态内容的哈希默克尔树根值。节点使用该状态根哈希来验证从其他对等节点处下载的状态数据是否与矿工在该区块中声明的状态相匹配。

快速同步方法下载完所需的所有状态后，等于节点已经有了执行交易所需的一切数据。那么这时候开始，节点就可以切换成完全同步模式了，从启动块开始可以逐个逐个执行区块了，就跟完成了启动块以前的完全同步过程的节点一样。

简化之后的过程就像下面这张动图所显示的：

其他方法

其他的快速同步方法包括 Warp Sync 以及一些目前尚未得到验证的同步方法。抽象一些来看，它们都属于快速同步方法的不同形式。