大家好，欢迎收看 CCW。

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

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

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

划重点

?以太坊优化方案：

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

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

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

?Conflux 优化方案：

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

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

END