譬喻，这就是以十六叉树的形式暗示键与值对（170，v）的进程。在十六进制中，170 暗示为 0xaa，因此你只需要两层：个中之一用于第一个 a，另一层则用于第二个 a。

图 4: 在转换进程中，区块具有 2 个状态根（state Root）：一个是传统十六叉树的只读根，第二个是「包围」二叉树的根

你可以看到，这棵树要深得多，也窄得多。

而在同时，十六叉树正在靠山转换。此刻可以不消担忧插入，因为所有变动都存储在顶部树中。

图 3 区块头的 state root 字段指向十六叉树的根

归并进程会逐渐举办：每次生成新区块时，城市从叠加层中删除 n 个键，然后将其从头插入到基本树中。该进程将一连举办，直到从叠加层中删除所有键为止。在此阶段，包围状态根将从区块头中删除。

不幸的是，要将以太坊从十六叉树切换到二叉树，并不是一件容易的事。有很大都据需要转换，而且执行变动需要耗费高出 15 秒的区块时间。

这项提议得益于 Alexey Akhunov，Vitalik Buterin，Anna George，Sina Mahmoodi，Tomasz Stanczak 以及 Martin H. Swende 提供的名贵意见。

在这种要领中，确定在区块高度 H1 处，区块具有两个 stateRoots：一个用于「基本」十六叉树，一个用于「包围」二叉树。

当一笔生意业务读取或更新一个帐户时，系统首先搜索包围树。假如在哪里找不到帐户，系统将在旧的十六叉树中搜索该值。

除此之外，假如生意业务执行写入包围树中找到的键，则该键将从包围树中删除，并直接写入到基本树。

我们已经建设了一个 劈头的原型，以便预计完成转换所需的时间。我们相信，整个进程可以在公道的时间内（约莫几天）完成。跟着算法的改造，我将宣布更多的细节。

图 1: 这是一棵十六叉 trie 树示例，显示了值「v」如何存储在键 0xaa 处。此树只有 2 字节长的键，而且只沿 0xaa 键的子树被展开。为了简捷起见，不相关的子树被替换为「…」

原文标题：《以太坊焦点开拓者：MPT 十六叉树将被替换》

办理此问题的发起是设一个过渡期，在此期间，在十六叉树的顶部安排一棵包围二叉树，它的浸染是生存状态产生的所有变动，直到基树转换为二叉树。

这种过渡会分成三步举办：

影响以太坊的浩瀚问题之一是账户和合约数据的存储方法，以太坊今朝选择的布局称为默克尔帕特里夏树 (Merkle Patricia Tree，或简称 MPT）。尽量从理论上讲，它是很有意义的，但在实践中，它带来的问题要比其办理的问题要更多。多年来，焦点开拓人员一直在接头向二叉树（binary tree）的转换，在本文中，我将阐发我对这一问题的观点，然后给出一个办理它的要领。

以下是译文：

除此之外，想象一下，你正在翻译一本 5000 页的书籍，作者一直打电话汇报你他对故事做了调解，这会影响到你已经翻译过的页面……而这大概会一直一连下去。

图片来自：tuchong.com

图 5: 转换的第二个阶段，区块头将十六叉树基本根替换为其二叉树转换基本根，以向网络发送信号，奉告它们已筹备停当

问题就呈此刻这里了：通过对所有节点举办哈希运算来从头计较哈希根耗费的时间太长，因此，为了计较根节点，矿工将从数据库中检索同级哈希（sibling hash）。尽量从数据库中获取所有子叶并对整棵树举办哈希运算所需的时间不多，但此操纵仍然需要大量时间。这是因为必需要从数据库中获取每个哈希。

叩谢

「来自 Ballet 的重要研究基本，它会使以太坊无状态变得友好，同时缔造了一个时机，以大大简化该协议。等候在将来的几个月中，来自以太坊 1.x 开拓人员越发精彩的事情及成就。」

这就是今朝以太坊碰着的问题，因为用户可以更新已转换的地点，这意味着你必需从头开始转换进程。