陈一晚风 2021-12-21 16:11

摘要:

当前的以太坊存储使用状态除了块之外还消耗了很多空间。

随着DeFi、GameFi等去中心化应用的蓬勃发展，以太坊节点的链数据规模不断增长，达到了约9T的存档，市场对于低Gas费用的高性能区块链的需求被大大增加。

以太坊全节点（存档）的链上数据  来源：etherscan

而众所周知，去中心化区块链的一个目标是允许商品PC运行节点，因此在商品PC上强制执行 9T+存储似乎是一项严格要求，而这也成为了构建高性能区块链的一个关键挑战。本文将就区块链存储爆炸的问题进行一系列分析，并对解决方案进行探讨。

来源：medium

作者：Qi Zhou

编译：陈一晚风

存储分析

下面我们就进一步来分析存储的使用情况，从以往的数据中我们可以发现，区块数据只需要约300G左右的数据（从区块高度0到13.6M），远小于9T。那么剩下的8.7T数据从何而来？

实际上，归档节点执行所有块并保留所有历史数据，包括块、状态、交易收据。其中state由 8.7TB的主要部分组成。所以有时，我们将存储爆炸称为“状态爆炸”。

什么是以太坊状态？

以太坊状态是一个默克尔帕特里卡树（MPT）。其中，叶子是地址 (0x…) => account的映射、帐户存储与地址相关的余额、随机数等；内部节点用来维护树结构，以便可以快速计算其哈希根。

MPT示图

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

存档节点存储成本图示

Geth的全节点

为了解决存档节点状态爆炸的问题，Geth的工程师创建了一种称为“pruned（修剪）”模式的新模式，该模式仅定期存储MPT。这里我们使用一个简化的例子，其中节点只为每3个块保存MPT。（注意，为了获得一个没有状态的区块的状态，节点必须获得该区块之前最近的状态，并重放交易）

通过定期存储MPT，状态的存储大小显着减少。据etherscan报道，目前Geth全节点的链上数据大小约为1TB。

Geth的全节点与快速同步

通过从起源重播所有事务来运行节点的一个问题是，重播所有事务的时间很长。一般来说，建立这样一个节点需要数周时间才能赶上网络从创世以来的最新状态。为了加快节点的引导阶段，Geth进一步提供了一种快速同步模式，可以下载最新稳定块（也称为枢轴块）的MPT，而无需重放和维护枢轴块之前的历史MPT。下载MPT后，它会像完整节点一样重放新块（具有定期状态存储）。

Geth的完整节点与快速同步示图

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

问题

以目前447GB的存储大小和15 TPS的以太坊为例，我们预计具有1TB SSD的商用PC应该能够运行节点相当长的时间（数年）。那么存储爆炸或状态爆炸真的存在吗？也许几年来它不适合以太坊，但如果我们可以将以太坊虚拟机（EVM）扩展到数百或数千TPS呢？

让我们将目光转向另一个基于EVM的链，币安智能链（BSC）。截至2021年12月8日，BSC已存储约984 GB链数据，块中约550 GB，状态中约400GB，共计完成2,066.23百万笔交易，100 TPS。

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

如果TPS为 100，即 ~3,153 M TPY

1 年后，总 TX ~5,219M，块 ~ 1.375 TB，状态 ~ 1.085TB

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

如果 TPS 为 150（观察到的峰值TPS），即 ~4,730 M TPY

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

3 年后，总 TX ~16,256M，块 ~4.327 TB，状态 ~3.414TB

综上所述，对于BSC来说，如果保持目前的速度甚至更高，很快就会达到以太坊存档节点相同的存储大小，这是普通PC几乎无法运行的。

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

如果我们对一个非常高的TPS区块链（就像QuarkChain能够做到的那样）做一个更大胆的假设，这个数字会变成多少？让我们考虑一个具有1000 TPS的区块链并分析块和状态大小将是：

假设tx大小约为100字节，每年块所需的存储量为1000 (TPS) * 100（每tx字节数）* 365 * 24 * 3600 = 2.86 TB

假设MPT有10个B账户（超过世界人口），我们预计状态大小将为150G（以太坊状态大小）/0.18B（以太坊唯一地址）* 10B = 8.3 TB

将它们放在一起，我们很容易提出大多数商品PC无法承受的要求。

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

状态存储优化

我们提出的第一个优化是使用flat KV而不是MPT。这将摆脱MPT中的所有内部节点，当MPT很大时，这可能代价高昂。假设每个账户的数据大约是50字节（20 个地址 + 2个随机数 + 12个余额 + 其他），我们可以用~ 10B * 50 + 100GB（代码）= 600 GB，大约是MPT版本的1/10！

虽然使用扁平KV带来了巨大的好处，但一个主要问题是我们无法在如此短的区块间隔内计算每个区块的状态后哈希，这意味着我们将失去以太坊的以下好处：

1、Fastsync：下载任何块的状态并通过重放剩余的块来赶上网络；

2、分叉检测（或拜占庭检测）：来自对等方的新创建的块是否会导致与本地执行的状态不同的状态。

为了启用快速同步，我们有一个周期性的快照块（快照间隔 = epoch = 例如，14 周）。一个快照块包含附加信息pre-state hash，即前一个快照块的post-state hash为非快照块不维护状态hash，相反，它有一个调用delta hash，其中包含块的所有事务的原始数据库操作（删除、更新）的散列。这使分叉检测成为可能。

我们不使用以太坊中区块的状态后哈希，而是使用状态前哈希。原因是节点不能立即计算状态后散列，但是使用状态前散列，节点可以使用整个纪元间隔来计算散列。例如，假设状态哈希计算每秒处理10M的状态数据，那么600 GB的整个状态将需要600 GB / 10 M ~ 16.67 小时（vs. epoch = 14 周）

计算状态前哈希的流程可以如下。

1.当一个快照块被接收并最终确定时，它的平面KV状态被快照，并创建一个后台线程来迭代所有 KV 条目（addr => account）并计算哈希。

2. 当下一个快照块被创建时，计算出的pre-state哈希值将存储在该块中。同样，节点将创建平面KV的另一个快照并在后台计算其哈希。

3.当下一个快照块被创建时，节点除了存储pre-state hash之外，现在可以释放快照块的KV快照，这意味着自快照块以来所有被删除/更新的数据将被自动通过 KV 存储进行 GC（例如，在 levelDB 中压缩）

因此，这意味着要存储状态，节点最多只需要两个KV快照（很可能是一个带增量的KV快照）。

块存储优化

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

1.周期性块的最新状态前快照，即（lastest — 1）快照块的后状态；

2.(latest — 1) 快照块之后的完整块。

我们可以对存储成本进行简单的数学计算：假设epoch持续时间为2周，则块重放大小为

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

此外，这里的数字不会随着时间的推移而增长。

依据前文的分析，我们得知了以太坊当前的存储使用情况：状态除了块之外还消耗了很多空间，

当TPS > 1000时，空间高得令人望而却步。

对此，我们建议可以对块和状态进行优化，将块大小从每年2.86 TB减少到224 GB，状态大小（~10B 帐户）从8.3 TB减少到600 GB，一台2TB的商用PC应该能够长时间运行节点。但是这样一来也会缺点，那就是轻节点无法验证状态中的条目（必须是全节点）。

欢迎加入鸵鸟区块链Telegram社群

中文社区 https://t.me/tuoniaox

英文社区 https://t.me/tuoniaoGroup

本文经「原本」原创认证，作者鸵鸟区块链，访问yuanben.io查询【40EGU9D1】获取授权信息。

声明： 鸵鸟区块链所有发布内容均为原创或授权发布，如需转载，请务必注明文章作者以及来源：鸵鸟区块链（微信公众号：MyTuoniao），任何不尊重原创的行为鸵鸟区块链都将进行责任追究！鸵鸟区块链报道和发布内容，不构成任何投资建议。