以太坊存储爆炸问题的分析与优化

Bitget下载

注册下载Bitget下载，邀请好友，即有机会赢取 3,000 USDT

APP下载   官网注册

编辑'；s注：本文是QuarkChain创始人兼CEO周博士撰写的一篇技术文章，并基于这篇文章在Learning举办了一场技术分享讲座。背景

Defi和GameFi等去中心化应用的蓬勃发展，极大地增加了对低交易成本的高性能区块链的需求。然而，构建高性能区块链的一个关键挑战是存储爆炸。下图是取自Etherscan的图。，它说明了以太坊完整节点(归档)的区块链数据大小。

从图中我们可以看到，节点的链数据规模稳步增长，目前已经达到~9TB。因为分散区块链的一个目标是允许通常配置的计算机运行节点。因此，很难在具有通用配置的计算机上实施9TB存储。

分解存储开销

如果我们进一步分析存储使用情况，我们可以发现，块数据只占300GB左右的数据(从块高0到13.6M)，远远小于9TB。那么剩下的8.7TB数据从何而来？

实际上，归档节点执行所有数据块并保留所有历史数据，包括：

Block

Status

交易回执

其中，Status是这个8.7TB的主要组成部分，所以有时候，我们称之为存储爆炸"国家爆炸"。但是国家为什么这么大？

以太坊状态是什么？

以太坊状态是MerklePatrica树(MPT)，其中

叶节点是地址(0x.)=

账户。其中账户存储与地址、随机数等相关联的余额。

内部节点维护树形结构，这样可以快速计算出整棵树的哈希根

因为存档节点会保留所有块的所有历史状态。这意味着MPT中的任何更新都将创建O(log(N))个内部节点，旧的内部节点不会被删除。

GETH的所有节点

为了解决归档节点的状态爆炸问题，Geth的天才工程师创造了一种新模式，叫做"修剪"模式，该模式仅定期存储MPT。这里我们给出一个简化的例子，其中节点只保存每3个块的MPT。(注意，为了获得不包含任何状态块的状态。节点必须获得阻塞前的最新状态，并重放下一个事务)。

通过定期存储MPT，状态的存储大小显著减小。根据Etherscan数据，目前Geth所有节点的区块链数据大小约为1TB。

Geth'；s快速同步完整节点

通过重放来自Genesis块的所有事务来运行节点的一个问题是，重放所有事务需要很长时间。一般而言建立这样一个节点需要几个星期才能从创建块赶上网络的最新状态。为了加快节点的启动过程，Geth进一步提供了快速同步模式，可以下载最新的稳定MPT，无需重播和维护块前的历史MPT。。下载MPT后，它会像整个节点一样重放新块(带有周期性状态存储)。

不存储历史MPT(有时甚至是历史块主体)一个Geth节点的存储大小可以进一步减少到447G(截至2021年12月6日)。通过减去300GB的块数据，我们推断状态大小约为150GB。

问题

以以太坊目前447GB的存储大小和15TPS的存储容量，我们预计一台1TBSSD的普通配置电脑应该可以长时间(比如几年)运行以太坊节点。那么存储爆炸或者状态爆炸真的存在吗？？也许在未来几年内不会，但如果我们可以将邰方的虚拟机(EVM)扩展到数百或数千个TPS会怎么样？

Let'；让我们把注意力转向另一家总部设在EVM的连锁店BSC。。截至2021年12月8日，BSC在链上拥有：

约984GB的数据，其中块约占550GB，状态约占400GB。

20.6623亿笔100TPS

如果进一步用交易数来预测数据大小，可以得到：

如果TPS为100，即一年后约3153mtpy

，总TX约5,219M。，块~1.375TB，态~1.085tb

三年后，总TX~11,525M，块~3.025TB，态~2.387TB

如果TPS为150(观测峰值TPS)，即~4730mtpy

后1年，总TX为~6,796m，块为~1.809TB，状态为~1.427TB

3年后总TX~16,256M，block~4.327TB，state~3.414TB

综上所述，对于BSC来说，如果保持现在的速度，会更高。，很快就会达到以太坊存档节点一样的存储大小，普通电脑几乎不可能运行。

具有极高TPS区块链的存储爆炸问题

如果我们对一个TPS极高的区块链做一个更大胆的假设(比如夸克链可以做到的)，这个数字会变成多少？让'；让我们考虑一个具有1000TPS的区块链，并分析它的块和状态大小。，就会是：

假设tx的大小在100字节左右，那么块每年需要的存储就是1000(TPS)*100(每tx字节)*365*24*3600=2.86TB

假设MPT有100亿个账户(比世界人口还多！)，我们预计状态大小为150G(以太网的状态大小)/0.18B(以太网的唯一地址)*10B=8.3TB

把这些数字放在一起。我们很容易得出一个结论，这是大多数普通电脑都不会承受的要求！

优化

为了优化存储成本，我们必须放宽限制，兼容EVM，而不是兼容以太坊。也就是我们必须建立/运行另一个支持EVM的链，而不是一个高度优化的以太坊客户端。

状态存储优化

我们提出的第一个优化是用普通KV代替MPT。当MPT很大的时候。MPT的所有内部节点都可能非常昂贵。我们的优化将删除MPT的所有内部节点。假设每个账户的数据约为50字节(20个地址，2个随机数，12个账户和其他)。，我们可以保存100亿的账户数据：

~10B*50100GB(代码)=600GB，大约是MPT版的1/10！

虽然用普通KV会带来很大的好处。但主要问题是，我们能'；t在这么短的块间隔内计算每个块的后状态hash，意味着我们将失去以太坊的以下好处：

快速同步：下载任意块的状态，通过回放剩余块快速同步网络

分叉检测(或拜占庭检测):来自对等体的新创建的块是否会导致与本地执行块不同的状态。

为了实现快速同步，我们有一个定期快照块(快照间隔=epoch=例如，14周)。。一个快照块包含了前一个状态哈希的附加信息，即前一个快照块的后一个状态哈希(执行事务后的状态哈希):

非快照块不维护状态哈希，但是有增量哈希。它包含该块中所有事务的原始数据库操作(删除、更新)的哈希。这使得分叉检测成为可能！

我们在以太坊中使用的是交易前的状态哈希，而不是交易后的状态哈希。。原因是节点不能立即计算事务后状态散列，但是通过使用事务前状态散列，节点可以使用整个历元间隔来计算散列。例如，假设状态哈希计算每秒处理10M个状态数据。，则需要600GB/10M~16.67小时(vs.epoch=14周)计算600GB的整个状态

计算前状态hash的过程如下：

1。当快照块被接收并完成时，其KV状态为snapshot，并且创建一个后台线程来迭代所有KV条目(地址=

帐户)并计算散列。

2。创建下一个快照块时。计算的预先状态散列值将被存储在这个块中。类似地，节点将创建KV的另一个快照，并在后台计算它的散列。

3。当创建下一个快照块时，节点存储状态之前的散列。，节点现在可以释放快照块的KV快照，这意味着来自快照块的所有删除/更新的数据将被自动垃圾收集(例如，在levelDB)

中压缩)。结果，状态将被存储。，节点最多只需要两个KV快照(可能一个带增量，一个KV快照)。

块存储优化

使用快照块，我们可以通过仅存储以下数据来进一步减少节点中所需的块数据：

事务执行前的最新快照块的快照，即事务执行后的(latest-1)快照块

(latest-1)快照块

我们可以简单计算一下存储成本：假设历元时长为2周，块回放大小为

2*14(天)*24(小时)*3600(秒)*100*1000(TPS)=224GB！

而且，这里的数字不会随着时间的推移而增加！

摘要

我们分析了以太坊目前的存储使用情况：

不仅是块，状态存储也要消耗大量的空间

当TPS

1000时，存储空间的使用是禁止性的

我们建议优化块和状态：

块大小从2.86TB减少到224GB

状态大小(~10B帐户)从8.3TB减少到600GB

一台2TB一般配置的电脑应该可以满足节点长时间运行的要求

缺点：一个轻型节点无法验证状态下的一条数据(必须是所有节点)

感谢

相关内容

标签： 节点 状态 存储