通告 | Geth v1.10.0

编者注：这篇文章是 Geth 团队撰写的 Geth 1.10.0 大版本更新公告。文章很长，有 9000 多字，但是值得每一个关心以太坊的长期前景的人细细阅读。从中我们可以看到，一个为整个以太坊生态开发最基础的基础设施的工程师，如何理解自己的工程目标、如何发现瓶颈，以及如何理解自身在整个生态中的角色。

Geth v1.9.0 发布已一年半有余。在这期间，我们确实发布过 26 个版本（大约 3 周一次），但是主要版本发布总是更特殊一些。我的心情很微妙：一方面，新功能上线令我兴奋不已，另一方面，我又担心会出现重大失误。无论如何，以太坊正在发展，我们需要突破极限，跟上它的步伐。

言归正传，让我们欢迎 Geth v1.10.0 加入以太坊大家族。

风险提示

在详细介绍最新版本之前，我们有必要强调一下：任何新功能的推出总伴随着新的风险。为了满足风险状况不同的用户和项目的需求，许多重要功能（暂时）可以单独开启或关闭。无论你想要阅读这篇文章的所有内容，还是只阅读你感兴趣的部分，请不要略过文末的 “兼容性” 一节。

接下来，就让我们来看看 Geth v1.10.0 究竟有哪些特性！

柏林硬分叉

首先要声明一点。Geth v1.10.0 尚不可用于柏林硬分叉，因为 Solidity 团队担心 EIP 2315 最后会出现变数。由于v1.10.0 是大版本，我们不想让发布时间太接近柏林分叉。我们很快就会发布 v1.10.1，加入最终的 EIP 及相关区块编号的名单。

快照

我们一直在说快照加速（中文译本），说了很久了，现在终于出现在新发布版本中，我们心中也五味杂陈。本文不会涉及太多细节（见上面的超链接），快照（snapshot）是基于以太坊状态的加速数据结构，可大大加快读取 账户和合约存储项的速度。

具体来说，快照功能可以将访问账户的成本从 O(logN) 降低至 O(1)。乍看之下，这可能不是很多，但是在实际情况下，假设主网上有 1.4 亿个账户，快照可以为每次账户读取节省大约 8 次数据库查询。这几乎将磁盘查询量减少了一个数量级，确保其成为与状态大小无关的常量。

哇偶，这是不是说我们可以将 gas limit 提高 10 倍？很遗憾的是，不能。虽然快照确实能将读取性能提高 10 倍，但是 EVM 执行还需要写入 数据。数据写入需要经过默克尔验证。考虑到默克尔证明，磁盘写入的成本必须是 O(logN)。

既然如此，这又有什么意义呢？！虽然加快账户和合约存储的读取速度并不足以提高 gas limit，但它确实解决了一些棘手的问题：

• DoS。在 2016 年，以太坊遭受了有史以来最严重的 DoS 攻击（“上海” 攻击），持续了大约 2 至 3 个月。这次攻击通过以太坊状态膨胀以及滥用各种gas 定价过低的操作码来导致以太坊网络瘫痪。经过无数次客户端优化和硬分叉再定价之后，这次危机才得以平息。但是问题的根源依然存在：状态访问操作码有着固定的 EVM gas消耗量 O(1)，但是执行成本 O(logN) 是缓慢增加的。我们已经通过 “橘子口哨”（Tangerine Whistle）、“伊斯坦布尔”（Istanbul）以及即将到来的 “柏林”（Berlin）分叉状态操作码的 gas 消耗量，让 EVM 成本（名义开销）与运行时成本更加一致，但这些都只是权宜之计。快照可以将状态读取的执行成本降低至O(1)（使之与 EVM 成本更加一致），从而长期解决基于状态读取的 DoS 问题（请勿在他处引用这句话）。
• 调用。检查以太坊上智能合约的状态需要一次微 EVM 执行。一方面是运行字节码，另一方面是从磁盘中读取状态插槽。如果你运行了一个只供自己使用的以太坊节点，当前的状态访问速度应该绰绰有余。如果你运行一个供多名用户使用的以太坊节点，快照所带来的 10 倍性能提升可以让你以同样的成本完成 10 倍数量的查询。
• 同步。同步以太坊节点的方法主要有两种。你可以下载区块并执行区块中的所有交易。或者，你可以下载区块，验证其 PoW 证明，并下载与最新区块相关的状态。后者要快得多，但是需要通过其它节点获取最新状态的副本。在当前的 Merkle-Patricia 状态模型中，这些节点需要从磁盘上读取 16TB 的数据，才能满足节点同步需求。有了快照之后，这些节点只需从磁盘中读取 96GB 的数据，就能让新的节点加入网络。欲知更多详细信息，请阅读快照同步 部分。

• 快照就是 Merkle Patricia trie 的叶节点中已经包含的原始以太坊状态的冗余副本。目前，快照在主网上额外需要大约 20 至 25 GB 的磁盘成本。好在，快照有望让我们进一步实现状态存储优化，并降低当前 Merkle trie 的磁盘成本。
• 由于目前还没有人在网络中构建快照，节点最初需要自行承担迭代状态 trie 以及创建初始快照的开销。根据你的节点的负载，这可能需要耗时一天至一周，但是（一切顺利的话）每个节点在整个生命周期内只需完成一次。快照创建是在后台运行的，与其它节点操作同时执行。我们的计划是，当全网节点都可获得快照时，就不再要求节点迭代状态 trie 并创建初始快照。预知详情，请阅读快照同步 部分。

快照同步