为什么要提高节点实时体验？每当我回想目前还有多少人仍在用于 Infura（通过 Metamask、Gnosis-Safe 等）与链上应用程序交互时，我就深感有点难过。Infura 的服务有趣，但如果大部分用户都不自己运营节点，似乎也不过于对头。即使是十分有能力且积极性十分低的开发人员，也无法几乎挣脱对 Infura 的倚赖。

从这点显然，我们仍未完成以太坊的 “自律检验” 愿景中的最重要部分。我们的团队期望尽自己的力量挽回这一趋势。我们的愿景是尽量减少网络上的节点数量，尤其是那些由爱好者、研究人员和开发人员运营的节点。当我们问道他们为何不运营自己节点时，答案不外乎是：“我加装了客户端软件，也尝试了实时区块链，但样子总是实时不上。

于是我就停下了，因为我还有别的事要做到。”所以，如果我们想要让更加多的人来运营节点，就得让节点实时更加慢一些，并且在实时过程中需要对系统工程进度信息。

许多团队都在这个领域深耕。专用硬件也许是一条重要途径。但在这篇文章里，我们想讲的是 “Beam Sync” 实时方法如何需要大幅度提高实时速度。

现有的实时方法为了更佳地解读 Beam Sync 的原理，我们再行来想到现有的几种实时方法。Full Sync（几乎实时方法）几乎实时方法是继续执行自创世纪区块以来的每一个区块。

创世纪区块标志着一个接续创世纪状态（状态的内容还包括帐户余额、合约字节码、合约存储内容等）。所谓 “继续执行区块” 就是，每iTunes到一个区块，就加载前一个状态并（根据区块内容）产生新的状态，并以该新的状态来检验区块头中的状态根（以检验该区块是不是一个有效地的区块）。在以太坊主网上几乎实时的速度十分快，而且随着网络的老化，用于几乎实时方法来实时到近期区块的时间也不会更加宽。

所以人们研发出有了 “较慢实时” 方法。Fast Sync（较慢实时方法）较慢实时方法就是iTunes过去所有的区块和区块头，并自由选择最近的区块作为 “启动块”。启动块以前的区块都跳过继续执行，到了启动块再行开始继续执行区块。这种方法假设了从创世纪块到启动块都正确地遵循了所有 EVM 规则。

这个假设是合理的，因为矿工有动力遵循诚信不害人原则，生产长时间区块，拒绝接受有可能具备攻击性的区块。在较慢实时可以继续执行启动块之前，必须的区块状态还包括：合约字节码、帐户和合约存储内容。继续执行交易时有可能必须加载所有这些值中的任何一个。

因此，较慢实时方法拒绝从其他对等节点处取得启动块之前的状态快照。快照是用状态根哈希值来标记的；所谓状态根哈希值，就是所有状态内容的哈希默克尔树根值。

节点用于该状态根哈希来检验从其他对等节点处iTunes的状态数据否与矿工在该区块中声明的状态相匹配。较慢实时方法iTunes完所须要的所有状态后，相等节点早已有了继续执行交易所须要的一切数据。

那么这时候开始，节点就可以转换成几乎实时模式了，从启动块开始可以逐一逐一继续执行区块了，就跟已完成了启动块以前的几乎实时过程的节点一样。修改之后的过程就像下面这张动图所表明的：其他方法其他的较慢实时方法还包括 Warp Sync 以及一些目前仍未获得检验的实时方法。抽象化一些来看，它们都归属于较慢实时方法的有所不同形式。

另外，即使理解这些其它实时方法的原理，也急于解读 Beam 实时策略，所以这些实时原理不是我们这篇文章的重点，我以后再行谈。较慢实时方法有多慢？较慢实时方法在目前的主网运营环境下面对一些挑战，因为实时必须iTunes很多数据，甚至多达 100GB 的数据，所以，有可能在上图右图的第二步 “Get All State（取得所有的状态）” 就要卡住很长时间。更加差劲的是，（在较慢实时模式下）对等节点会逐块给你获取状态数据，只不会获取启动块前一段时间内的状态，比如启动块前 100 个区块（即开始实时前 30 分钟）的状态数据。

Geth 客户端的默认设置是前 120 个区块。如果你无法在 30 分钟内iTunes完了所有的状态数据（剧透警告：你知道下不完了），你就必须做到转换（pivot），就是换一个新的启动块，新的开始实时，虽然不是从 0 开始，但是也减少了iTunes和检验区块的时间。

Geth 客户端在提升实时速度上获得了非凡的成绩，较慢实时和几乎实时模式都有巨大进步，而且 Geth 客户端的每一次改版都会有所前进，但即使你有十分极致的电脑硬件，实时过程仍然必须持续最少 4 小时。对于第一次实时来说，这样的过程显然显得艰苦。

那么，我们团队正在研发一个用 Python 语言撰写的客户端，叫 “Trinity”。Python 在速度性能上会比 Go 语言更加慢。

如果以性能为中心的 Geth 代码无法像我们期望的那样较慢实时，Trinity 客户端又有什么机会呢？几乎有理由预计 Trinity 客户端继续执行一次较慢实时必须几个星期。但是如果客户端无法实时主网，那么它就没有意义，某种程度，花费几周时间去实时也没意义。

出于这种必须，我们构想了一种新的实时策略，我们现在称作：Beam 实时方法。

本文来源：PG电子·游戏官方网站-www.szydbw.com