这篇文章要讲的 bug 位于 Geth客户端的状态下载器内，它可以用来欺骗下载器，使之不能与主网正确同步。攻击者可以利用这个 bug 给以太坊区块链设置陷阱、任意触发硬分叉。
当你想运行一个以太坊节点的时候，首先必须同步上整个网络，即，下载和计算构建最新区块时刻的区块链状态所需的所有数据。根据用户自身的需要，同步方式可以在安全性和速度之间有所取舍，所以（在撰文之时） Geth 支持两种同步模式：完全同步和快速同步。
顾名思义，完全同步就是独立地执行完对以太坊区块链的整个同步过程。这就意味着，你的Geth 节点会下载和验证每个区块的工作量证明（PoW），此外，它还会计算区块内的每一条事务；由此，节点可以在本地生成区块链的最新状态，而无需信任其它节点。这种模式更安全，但速度上有很大牺牲。Geth 的完全同步可能要花几天乃至几周不等的时间
但是，有些用户可能不想等上几周。也许他们的时间很紧，又或者，他们并不觉得这种牺牲是值得的。因此，Geth 提供了一个模式：在近期的某个区块（称为 “pivot 区块”）之前的所有链数据，都用更快的方法来同步，只有 pivot 区块之后的区块链，才使用更慢的完全同步算法。在快速同步模式中，Geth 会下载区块，但仅随机选取一些区块来验证工作量证明，而不是每个区块都验证；而且，它也将不再自己执行事务，而是从网络中的其它节点处直接下载状态树，以此获得最终的区块链状态。
当然，Geth 也不会盲目相信其他节点发回的状态树数据，因为一个恶意的节点也可以声称某个账户只有一点点钱（但实际有很多）。要理解 Geth 如何能辨别收到的数据正确与否，我们先要理解默克尔帕特里夏树（Merkle-Patriciatrie）。
默克尔帕特里夏树（MPT）是 Geth客户端中的一种关键数据结构，它是默克尔树和帕特里夏树两者的结合。
简而言之，帕特里夏树会基于数据的前缀将数据存到一个树状结构中。相较于其它技术（如哈希表，hashmap）来说，帕特里夏树本身非常适合存储相似的数据，尽管在速度上可能有所牺牲。下面来看看，多个以 r 开头的单词是如何存到一棵帕特里夏树里的。
片
接着来说说默克尔树。在一棵默克尔树上，每个叶节点是数据的哈希值，每个非叶节点是它的两个子节点的哈希值。如果用户知道了默克尔树的默克尔根（即，顶端哈希值），并且想要确认某个数据是否存储在这棵树里，他只需要用到这棵树上的一条路径，这条路径所涉及的节点数量只跟叶节点数量的对数（注意不是叶节点数量）成正比。如下图所示，假设用户要证明 L2 存储在这棵树里，他只需提供 Hash 0-0 和 Hash 1。接着，验证者生成 Hash 0-1、Hash 0 和 Top Hash，再将Top Hash 与其所预期的默克尔根进行比较。
图片
默克尔帕特里夏树将帕特里夏树基于前缀的存储结构与默克尔树相结合，创造出了一种新的数据结构，不仅支持密码学验证方式，而且还能保持良好的运行时性能。
在默克尔帕特里树中，键和值都是任意的字节串。要想获得一个键的值，我们首先要将这个键转换成一个十六进制字符序列，即，将每个字节变成两个十六进制字符。然后，我们要先根据序列中的第一个字符，向根节点查询下一个节点是什么；得到此子节点后，再根据第二个字符向下查询节点，依次类推，直至找到最后一个节点，获得最后一个字符。
在下面这个例子中，我们可以看到默克尔帕特里夏树实际上包含三种不同的节点。扩展节点（在Geth 代码库中又被称为短节点）是经过优化的，负责存储一连串字符。在下图所示案例中，根节点存储了所有以 a7开头的键，无需使用两个不同的节点来代表 a 和 7。分支节点（或称 “完整节点”）包含每个可能字符的指针以及一个额外的空档来存储当前节点的值。最后，叶节点（又称值节点）的 key-end 字段必然与其所存储的 key 的后缀相匹配 1 。
图片
既然我们已经知道默克尔帕特里夏树是如何运作的了，我们可以开始探究什么是全局状态树。
区块链的绝大部分数据都存储在全局状态树中。虽然将状态树作为独一无二的实体包含在每个区块内这个设想看似便利，但实际上每个区块都要复制完整的状态树是极其低效的，因为每个区块之间的状态树只有细微差别。Geth 采用了不同的方案。你可以想象一下，Geth 维护了一个 MPT 节点池。每个区块的状态树只是整个池的子集。每当有新的区块被挖出或导入，就会有新的 MPT 节点被添加到池中。
要想识别节点池中的根节点，我们必须查询区块头。每个区块都包含一个指向stateRoot 的字段，该字段指向 MPT 的根节点（而该MPT存储以账户地址 2 作为键的账户数据）。这样一来，Geth就可以使用我们上文描述的算法查询账户信息，如任意地址的 nonce 或余额。
图片
请注意，如果是合约的话，账户状态将包含一个非空的 storageRoot 字段和 codeHash 字段。storageRoot 字段指向另一个根节点。但是，此时所涉及的 MPT 的用途是存储该合约的存储项数据；该 MPT 会将存储空档（storage slot）作为键，将原始数据作为值。
图片
为了将 MPT 存储在磁盘上，Geth选择使用 LevelDB 作为数据库。然而，LevelDB 是只支持字符串到字符串映射的键值数据库，MPT 不是字符串到字符串映射。为了解决这个问题，Geth 将每个节点编写成键值对，从而实现全局状态树的扁平化：将节点的哈希值作为键，将序列化的节点作为值。这样一来，Geth 就能查询任意区块的状态树，因为区块头中的 stateRoot 字段就是键，可以用来查找 LevelDB 中的序列化 MPT 节点（译者注：即一棵 MPT 的根节点）。
现在我们就大功告成了。当新的 Geth 节点使用快速同步加入网络时，它们会先请求 Exploit 合约，同步其状态子树及代码。当 Exploit 合约的代码被同步时，它会创建一个看起来与 Discrepancy 的状态根请求完全相同的原始条目请求，但它不会被当作子树请求处理。这意味着，该节点永远不会下载 Discrepancy 的状态 trie，因此未来读取 magic 的请求将返回 0 而非 1。
经过足够长的时间后，我们要做的就是调用Hardfork.hardfork(discrepancy)。每个正确同步整个网络的节点都会看到一个回滚交易，而每个使用快速同步加入网络的 Geth 节点都会看到一个成功的交易。这将导致一个区块产生两个不同的状态根，也就是说我们可以随心所欲地触发链分裂。
Geth 团队通过处理 PR#21039 中的树读取错误快速解决了该攻击，然后通过区分 PR #21080 中的代码部分和树部分完全修复了这个漏洞。
这是一个非常有趣的漏洞，它可以让攻击者在以太坊网络上设置一个 “炸弹”，并随时引爆，从而导致所有使用快速同步的 Geth 节点从主网中分叉。这个陷阱利用的是 Geth 的同步和数据存储代码中极其复杂的逻辑，这或许是它很长时间来都没有引起人们注意的原因。
