Broadchain

烤仔TVのCCW | Merkle 前缀树的优化

Conflux中文社区 2020-04-23 18:36 1982

在智能合约的执行过程中,每一次状态的读和写都对应着后台数据库大量的读写,极大地影响了系统的执行速度。


大家好,欢迎收看 CCW。


在上期视频中,我们为大家讲到在 Merkle 前缀树中,当读一个或写一个数据时,需要读取或修改这个节点到根节点这条路径上的每一个节点。


在智能合约的执行过程中,每一次状态的读和写都对应着后台数据库大量的读写,极大地影响了系统的执行速度。


那么 Conflux 是如何解决它的呢?答案尽在本期视频中。


划重点

以太坊优化方案:


1.路径压缩:当 Merkle 前缀树中的节点没有绑定值而且只有一个孩子节点,那么这个节点就可以和它的孩子节点压缩成一个节点。


2.Merkle 前缀树中有哪些键是由合约的开发者决定的,这些键所形成的 Merkle 前缀树可能不太平衡,如果给每一个键去算它的哈希值,那么由于计算出来的哈希值相对随机很多,再去生成 Merkle 前缀树也会平衡很多。


以太坊的优化方案可以支持大概 30 TPS 的吞吐率,但是当吞吐率提高到 1000 TPS 量级的时候,系统中的数据量剧增,执行速度要求也相应高很多,这个方案也不适用了。


 Conflux 优化方案:


维护两棵 Merkle 前缀树,其中一棵 Merkle 前缀树和以太坊一样存储所有的数据;另外维护一棵小的 Merkle 前缀树只记录最近几个区块的修改。


如果账本或者智能合约变量发生了修改,我们会把这个修改记录在小的 Merkle 前缀树中。因为这棵 Merkle 前缀树比较小,所以说它的层数小很多,访问时对后台数据库的读写压力也相应小很多。当一定时间过去以后,这棵记录修改状态的 Merkle 前缀树长得比较大了,我们就用一次操作,把这些更新全部更新回这棵大的 Merkle 前缀树里面,那么这棵小的 Merkle 前缀树就会被清空,然后以此往复。

声明:BroadChain Finance网站和App所发布的内容,均不构成任何投资建议。

Conflux中文社区

——

260 篇 作品
48.43W 总阅读量