问题在于：假如要对所有节点做哈希，从头计较根哈希的时间就太长了，因此，为了计较根节点的哈希，矿工将从数据库中检索 同层节点的兄弟哈希值（sibling hashes） 。固然后者（矿工从数据库检索兄弟哈希值）耗费的时间没有前者（矿工从数据库库获得所有的叶子节点并做哈希）那么多，这个操纵照旧很耗时。因为每个哈希都必需从数据库中取出。
今朝，以太坊的状态树是十六叉制的。十六叉制暗示每个节点有 16 个孩子节点。理论上讲，这种方法挺好的，因为孩子节点多意味着只需要更少的 “层” （即树高）便可存储所有数据。

账户和合约存储数据的方法是影响的浩瀚问题之一。以太坊协议选用了 Merkle Patricia Tree（MPT，默克尔帕特里夏树）来组织账户及合约数据。尽量这种数据布局在理论上结果很好，但在实际应用中，它带来的问题却比它可以或许办理的问题多。焦点开拓者们已经接头多年，想要把这种数据布局换为二叉树，我将在这篇文章中叙述我对这个问题的观点以及如何实现这种转变。
整个步调的焦点只有一个：假如生意业务执行时要写的键存在于包围树上，这个键就会从包围树上删除，写操纵直接在二叉下层树长举办。
在这种要领下，区块高度为 H1 时必定会有 两个 状态根：一个是 “下层” 十六叉树状态根，一个是 “包围层” 二叉树状态根。

譬喻，下图是用十六叉树暗示的键值对 (170, v)。十六进制中，170 记作 0xaa，因此你只需要两层：第一层记录第一个 a，，第二层记录第二个 a。

十六叉树被配置为只读，因此对状态的任何更新都将在包围树长举办。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。