Beam Sync：同步以太坊节点的新方法

为什么要改善节点同步体验？

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

我们的团队希望尽自己的力量扭转这一趋势。我们的使命是尽可能增加网络上的节点数量，特别是那些由爱好者、研究人员和开发人员运行的节点。当我们问起他们为何不运行自己节点时，答案不外乎是：“我安装了客户端软件，也尝试了同步区块链，但好像总是同步不上。于是我就停下来了，因为我还有别的事要做。”

所以，如果我们想让更多的人来运行节点，就得让节点同步更快一些，并且在同步过程中能够反馈进度信息。许多团队都在这个领域耕耘。专用硬件或许是一条重要途径。但在这篇文章里，我们想讲的是 “Beam Sync” 同步方法如何能够大幅提升同步速度。

现有的同步方法

为了更好地理解 Beam Sync 的原理，我们先来看看现有的几种同步方法。

Full Sync（完全同步方法）

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

Fast Sync（快速同步方法）

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

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

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

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

其他方法

其他的快速同步方法包括 Warp Sync 以及一些目前尚未得到验证的同步方法。抽象一些来看，它们都属于快速同步方法的不同形式。另外，即使了解这些其它同步方法的原理，也无助于理解 Beam 同步策略，所以这些同步原理不是我们这篇文章的重点，我以后再讲。

快速同步方法有多快？

快速同步方法在目前的主网运行环境下面临一些挑战，因为同步需要下载很多数据，甚至超过 100GB 的数据，所以，可能在上图所示的第二步 “Get All State（获得所有的状态）” 就要卡住很长时间。

更糟糕的是，（在快速同步模式下）对等节点不会逐块给你提供状态数据，只会提供启动块前一段时间内的状态，比如启动块前 100 个区块（即开始同步前 30 分钟）的状态数据。Geth 客户端的默认设置是前 120 个区块。

如果你不能在 30 分钟内下载完所有的状态数据（剧透警告：你真的下不完），你就需要做切换（pivot），就是换一个新的启动块，重新开始同步，虽然不是从 0 开始，但是也增加了下载和验证区块的时间。

Geth 客户端在提高同步速度上取得了非凡的成绩，快速同步和完全同步模式都有巨大进步，而且 Geth 客户端的每一次更新都会有所推进，但即使你有非常完美的电脑硬件，同步过程依然需要持续至少 4 小时。对于第一次同步来说，这样的过程确实略显艰难。

那么，我们团队正在开发一个用 Python 语言编写的客户端，叫 “Trinity”。Python 在速度性能上不会比 Go 语言更快。如果以性能为中心的 Geth 代码不能像我们希望的那样快速同步，Trinity 客户端又有什么机会呢？完全有理由预计 Trinity 客户端执行一次快速同步需要几个星期。但是如果客户端不能同步主网，那么它就没意义，同样，花费几周时间去同步也没有意义。出于这种需要，我们构思了一种新的同步策略，我们现在称之为：Beam 同步方法。

Beam 同步方法

概述

Beam 同步方法是直接改进快速同步方法的结果，这两种同步方法的区别是 Beam 同步方法是一开始就直接执行启动块，并且只请求本地数据库中缺少的状态数据，并把输入状态和输出状态保存在本地。执行完一个块后就同步到下一个块并重复该过程，按需请求缺少的数据。

随着时间的推移，缺少的数据会越来越少。注意，如果某个状态从未被访问过，那么客户端将永远不会请求它（因此永远也不会获得这部分状态数据），因此我们在后台运行另一个进程来填补这些空白。通过该回填过程，Beam 同步最终会取得所有状态数据并保存在本地，然后节点就可以切换到完全同步状态。

我们将执行每个块所需的数据集称为 “区块见证数据”（block witness）。得益于默克尔树的结构，我们不用完整地下载某个状态，就可以证明见证数据真的是从这个状态中取出来的（译者注：就是所谓的 “默克尔证明”）。

区块见证数据大小

为了简单起见，我们用 “区块见证数据大小” 来指称执行区块所需的数据元素数量。这类数据元素可能是在主要账户状态树上的一个节点，或者是合约存储树上的一个节点，或者是某个合约的完整字节码（译者注：此处说的 “状态树”、“存储树” 都是默克尔树结构的数据）。

分析区块见证数据大小是理解 Beam 同步方法性能的关键。快速同步方法必须在执行第一个区块（即启动块）之前下载全部状态数据，而 Beam 同步仅需要下载一个区块的见证数据，如果所下载的区块见证数据包含完整状态的三分之一，那么 Beam 同步的运行效率将大约是快速同步的三倍。

所以，显然，下一个步骤是看主网的见证数据实际是多大。可能直接下结论还为时尚早，但是早期试验结果表明 3000 个状态树节点的数据量是一个合理的估计（90% 置信度）。而主网的全部状态信息有超过 3 亿个树节点。

Beam 同步的速度提升

让我们新定义一个标准：“从启动到执行” 的时间。这是从用空数据库启动节点到完成最近一个区块的完全导入所需的时间。

如果 Beam 仅需要下载 3000 个状态树节点，而快速同步需要下载 3 亿个树节点，那么我们就可以确定 Beam Sync 方法的速度上限：在同步主网时，可在 “从启动到执行” 时间上获得最多 10 万倍的提升！

但是，Beam Sync 方法往往无法真正做到 10 万倍提升。理由包括但不限于：

1. 状态数据的下载并不是建立全节点的所有工作，例如，我们还要下载区块头来验证我们所同步的区块链是最长链
2. 区块见证数据是按需确定的，这就意味着我们无法提前预知需要哪些状态数据（收到一个数据，才能确定下一个需要的数据是什么）。所以我们向对等节点请求数据时，一次只能请求一个状态数据。相反，快速同步一次最多可请求 384 个树节点，这使得 Beam 同步对对等节点的网络延迟更敏感。
3. 寻找高质量，低延迟的同步节点需要花些时间。说实在的，会遇上什么样的对等节点，那是真·随机事件。

与快速同步方法不同，Beam 同步方法会持续下载启动块之后的区块状态，这样也会拖慢区块导入时间。如果你对这一点有一些直观认识，那么你可能会注意到，如果收集区块见证的平均时间比区块生产的平均时间还要长，那问题会更加严重。

Beam 同步滞后性

获得第一份区块见证数据所需的时间必定长于网络产生一个区块的时间（约 15 秒）。同样，我们也可以预见，见证数据要几个区块的时间才能送达，我们把这种情况称为“滞后”，大约是最新一个导入区块和链顶端区块之间的时间间隔。

区块见证数据的收集延迟问题可能会逐渐加重，然后你会发现你的 Beam 同步节点延迟了 5 分钟。这就是说，你本地拥有的最新区块其实是整个网络 5 分钟之前产生的区块，这意味着当 RPC 调用你现在节点账户余额的时候，你的节点会反馈五分钟之前的余额。

在坊间的测试中，很常见的一个现象是滞后时间变化很大，从 1 分钟到 20 分钟不等。幸运的是，我们有一些技巧可以使得区块同步从滞后的情况中恢复，事实上，一般来说，落后越多反而恢复得越好，这就导致了滞后时间的极大波动：先是不断落后，然后是迅速追赶，循环往复。

我们可以在区块落后的情况下更快地赶上的一个原因是，我们可以提前、同时为多个区块生成见证数据。毕竟，只有落后时，你才能利用这些未来的区块。当然，如果收集所需区块数据的时间总是超过区块产生时间，那么毫无疑问你将会越来越落后于区块链的增长，我们希望这种情况永远不会发生，但我们需要为此做好计划。

Beam Sync Pivot

就像快速同步一样，如果你落后太多，对等节点可能就不愿意为你提供你需要的数据了。切换（pivoting）机制是解决这个问题的关键。

Beam 同步里的 pivoting 机制就像快速同步里的一样，你的节点选择一系列要跳过的块，并在链顶端附近选择一个新的区块块区块头，然后，Beam 同步再一次开始，节点并没有完全从头开始同步，它仍然拥有来自上一次同步的所有数据。

无论你是采用 Beam 同步或者快速同步，只要使用切换机制你就需要付出相应的成本，切换机制意味着需要下载更多数据，这些数据中还会有一些你的节点并没有亲自验证过其执行的区块。好消息是：如果你不是落后超过 30 分钟，Beam 同步方法就不需要激活切换机制，相反，使用快速同步方法时，你非得切换几次不可。

好了，让我们看看真实的情况是什么样。

Trinity 客户端上的 Beam 同步

原型公布

一个新的阿尔法版本的 Trinity 客户端上周公布，这个版本包括一个可在高端硬件上运行的 Beam 同步方法原型。

我们一直在测试针对主网的同步过程。通常可在第一个小时内执行第一个区块，多数时候都能在 5 分钟之内搞定！这里不包括下载区块头的时间和偶尔因为缺少好的对等节点所耽误的时间。

注释：把区块 Gas Limit 从 8M 提升到 10M 似乎会增加平均滞后时间，伊斯坦布尔升级后可能会减少滞后时间，因为提高了在区块链上写入状态数据所需的 gas 耗费量。

目前 Trinity 还是阿尔法版本，最新的版本依然有很多问题，比如同步可能会在一两天后突然中止，即使没有中止，也会落后很多导致激活切换机制。安装 Trinity 客户端需要额外的工作，命令行输出更是一团糟。所以，Trinity 目前只准备好了给那些既好奇、又不介意实际操作一下的开发者和研究人员使用。

悬而未决的问题基本上都会在日常开发中暴露出来，所以这些问题都是 “后台日志上的 bug”。在这一点上，可以说，没有人担心 Beam Sync 会不会是一个难以企及的梦想。这种对 Beam 同步的信心是崭新的。但我们也认为未来有可能有突发的未知问题亟待解决，就像一个月前一样！

剩下的工作

除了基础的调试和实现工作，我们依然还有许多其它工作要做。Trinity 还没有实现状态的回填机制（即下载启动块之前的旧事件、事务和数据）。目前激活切换机制的唯一方法是重新启动 Trinity，而且尚不清楚 Beam 同步方法所需的最低硬件配置（我们欢迎大家帮我们搜集相关数据）。

以上所有问题都处于积极的研发攻克之中，并且这只是 Trinity 上许多工作之一，感谢以太坊基金会对这些工作的赞助和支持。

Beam Sync 的创新之处在哪里？

Beam 同步方法，和其他的理论一样，都是建立在之前的研究工作之上的。通过下载最新状态、跳过旧区块执行来加速同步的方法（快速同步方法），并不是我们发明的。依靠见证数据而不是完整状态来执行区块，从而加速执行的方法，也不是我们发明的，详细情况可以看无状态客户端。

真正的进展是我们综合了这两者：首先使用引导式快速同步来模拟无状态客户端，然后逐渐过渡到完全同步模式。我们丢掉了无状态客户端的一个优点，即低硬盘开销，但是我们保留了快速执行最近一个块的优点。通过在本地保存状态输入和状态输出数据，我们减轻了关于无状态客户端的一个重要隐忧，即被大量见证数据 DOS 攻击的风险，Beam 同步方法执行的时间越长，被 DOS 攻击的风险越小。

在我们运行以太坊本地客户端的时候，Beam 同步模式可以提供更好的反馈和更快的执行结果，我们觉得这对于用户愉快地运行本地节点来说是重要的一步。