给以太坊做个大手术:MPT十六叉树转二叉树需要这三步_比特币:LTC

写在前面:

想象一下,你正在翻译一本5000页的书籍,作者一直打电话告诉你他对故事做了调整,这会影响到你已经翻译过的页面……而这可能会一直持续下去,这就是以太坊从当前使用的MPT十六叉树转变为二叉树结构中遇到的一个类似困境。对此,以太坊核心开发者GuillaumeBallet提出了一种方案,可以在大约几天的时间内,通过3个步骤完成这一转换手术。

(图片来自:tuchong.com)

以下是译文:

影响以太坊的众多问题之一是账户和合约数据的存储方式,以太坊目前选择的结构称为默克尔帕特里夏树(MerklePatriciaTree,或简称MPT)。尽管从理论上讲,它是很有意义的,但在实践中,它带来的问题要比其解决的问题要更多。多年来,核心开发人员一直在讨论向二叉树的转换,在本文中,我将介绍我对这一问题的看法,然后给出一个解决它的方法。

MakerDAO社区投票选出第一批孵化生态系统参与者:金色财经报道,MakerDAO社区民意投票根据新的Maker章程参数选出第一批四个孵化生态系统参与者:dewiz、Sidestream、Phoenix Labs和Viridian Protector Advisory Company。

dewiz预算分配为每月15万DAI与21枚MKR,目标包括以RWA为重点的Collateral Onboarding Technical工作与一般智能合约开发;

Sidestream预算分配为每月70,912.5枚DAI,目标为全栈智能合约与前端开发;

Phoenix Labs在民意投票通过后将立即分配347,100枚DAI,每月将为开发者关系一职分配1.7万枚DAI与10枚MKR,目标为交付Spark协议并维护12个月;

Viridian Protector Advisory Company在民意投票通过后将立即分配257,250枚DAI,每月分配85,750枚DAI,目标为提供Protector咨询工作。[2023/4/1 13:38:15]

提议的过程引入了一个过渡期,在此期间,两种树结构都会存在。这样做的好处是,在转换树结构时,主链可以保持运行,并且还可以确保将所有帐户转换为二叉树格式。

MakerDAO关于提高ETH-A和WBTC-A债务上限的执行投票已通过:据MakerDAO官方消息,关于提高ETH-A和WBTC-A债务上限的执行投票已通过。ETH-A债务上限从7.4亿DAI增加到10亿DAI,WBTC-A债务上限从1.6亿DAI增加到2.1亿DAI。[2021/1/20 16:33:51]

背景

目前,以太坊的账户是被存储到一棵十六叉树当中的。所谓十六叉,就表示一个节点有16个子节点,理论上这是很好的,因为这意味着你需要更少的"阶段"来存储你所有的数据。

例如,这就是以十六叉树的形式表示键与值对的过程。在十六进制中,170表示为0xaa,因此你只需要两层:其中之一用于第一个a,另一层则用于第二个a。

动态 | 以太坊DeFi应用发展迅速 Maker处于领先状态 ?:区块链投研机构TokenGazer发布ETH 3月月报:在DeFi应用排名里,绝大部分排名靠前的应用都是搭建在以太坊上。目前,在这些应用中被锁定的token价值约为$434MM,2019年4月10日,MakerDAO的用户已将市场上2.11%的ETH抵押在智能合约中以换取稳定币DAI,而MakerDAO中的ETH共计价值约为402MM美元,环比增长44%,占去中心化金融项目中锁定token总价值的 93%左右,处于领先状态。[2019/4/10]

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

注意,这棵树很浅,也很宽。然后将其与以下相同键与值对的二叉树表示法进行比较。在二进制中,

170表示为

10101010。

图2:和图1中相同的键值对,以二叉树形式进行存储。为了简洁起见,不相关的子树被表示为“…”。

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

在以太坊中,每个区块都包含一个stateRoot字段,它是MPT根的哈希值。总而言之,这个哈希,是通过对根的16个子项的哈希列表进行哈希运算而获得的。这些子哈希列中的每一个,又依次是其子哈希列表的哈希,依此类推。

每次生成一个新区块时,矿工都会更新帐户树并重新计算其根哈希值。哈希存储在新区块的stateRoot字段中,然后新区块被密封。

图3区块头的stateroot字段指向十六叉树的根。

问题就出现在这里了:通过对所有节点进行哈希运算来重新计算哈希根花费的时间太长,因此,为了计算根节点,矿工将从数据库中检索同级哈希。尽管从数据库中获取所有子叶并对整棵树进行哈希运算所需的时间不多,但此操作仍然需要大量时间。这是因为必须要从数据库中获取每个哈希。

在十六叉树中,通常每个阶段要获取15个同级哈希。在上面的示例中,这就是30个哈希。

即使更深入,二叉树每个阶段也只需要一个同级哈希。在上面的示例中,就只有8个哈希!这就是为什么在实践当中,二叉树实际上要更好的原因。

覆盖转化法

不幸的是,要将以太坊从十六叉树切换到二叉树,并不是一件容易的事。有很多数据需要转换,并且执行更改需要花费超过15秒的区块时间。

除此之外,想象一下,你正在翻译一本5000页的书籍,作者一直打电话告诉你他对故事做了调整,这会影响到你已经翻译过的页面……而这可能会一直持续下去。

这就是目前以太坊遇到的问题,因为用户可以更新已转换的地址,这意味着你必须重新开始转换过程。

解决此问题的建议是设一个过渡期,在此期间,在十六叉树的顶部放置一棵覆盖二叉树,它的作用是保存状态发生的所有更改,直到基树转换为二叉树。

这种过渡会分成三步进行:

第1步-转换

在这种方法中,确定在区块高度

H1处,区块具有两个

stateRoots:一个用于“基础”十六叉树,一个用于“覆盖”二叉树。

图4:在转换过程中,区块具有2个状态根:一个是传统十六叉树的只读根,第二个是“覆盖”二叉树的根。

十六叉树被认为是只读的,因此对状态的任何更新都将是对覆盖树的更新。

当一笔交易读取或更新一个帐户时,系统首先搜索覆盖树。如果在那里找不到帐户,系统将在旧的十六叉树中搜索该值。

而在同时,十六叉树正在后台转换。现在可以不用担心插入,因为所有更改都存储在顶部树中。

第2步-基转换

后台转换过程完成后,矿工将通过转换结果替换只读的十六叉树基础根来宣布他们已准备好进行切换。对状态的读写操作与步骤1相同。

图5:转换的第二个阶段,区块头将十六叉树基础根替换为其二叉树转换基础根,以向网络发送信号,告知它们已准备就绪。

当一个足够大的序列区块对转换后的基础根具有相同的值时,这意味着大多数矿工都完成了转换,并对转换后的树的外观达成了共识。接下开,就进入到合并过程。

第3步-合并两颗树

合并过程会逐渐进行:每次生成新区块时,都会从叠加层中删除n个键,然后将其重新插入到基础树中。该过程将持续进行,直到从叠加层中删除所有键为止。在此阶段,覆盖状态根将从区块头中删除。

除此之外,如果交易执行写入覆盖树中找到的键,则该键将从覆盖树中删除,并直接写入到基础树。

下一步

我们已经创建了一个初步的原型,以便估计完成转换所需的时间。我们相信,整个过程可以在合理的时间内完成。随着算法的改进,我将发布更多的细节。

致谢

这项提议得益于AlexeyAkhunov,VitalikButerin,AnnaGeorge,SinaMahmoodi,TomaszStanczak以及MartinH.Swende提供的宝贵意见。

相关讨论:https://ethresear.ch/t/overlay-method-for-hex-bin-tree-conversion/7104

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

金宝趣谈

[0:15ms0-5:787ms