以太坊区块链的大小不会在短时间内超过1TB

编者按：许多人误解了区块数据和 Chaindata 数据，认为以太坊区块数据量将会很快超过1TB ，从而使一般用户同步不了。这片文章起到了正本清源的作用。

在深入这篇文章之前，请阅读有关我参与研究的两篇报告(1,2)和在本文底部的一篇关于数据准确性(3)的文章。

我每月至少一次会看到有人在r/ethereum上发布一张图表，预测以太坊的区块链体积将很快超过1 TB。我想利用这个机会在这篇文章中澄清有关以太坊-区块链大小的一些传闻，并试图解释为什么这张图表在技术上是正确的，但这并不代表全部。

我们先来看看这张图表。它显示了一个以太节点（红色）的完整数据目录大小（该图用的是一个Geth节点），以及一个比特币节点（蓝色）（可能是Bitcoin-Core节点），节点大小随着时间的推移的图示。比特币的走势以类似线性的趋势逐渐向上移动，而以太坊的走势却会让读者联想到一个指数增长的斜率。

关于区块、区块历史、状态和状态历史

指责以太坊区块链膨胀的用户，其实与他们自己的设想相差不远。但事实上，并不是链膨胀，而是以太坊状态膨胀。在继续阅读之前，我想给大家梳理一下白皮书中的一些术语。

区块。一组会在正确执行之后更新状态的交易。每个绑定交易的区块都会得到一个数字、存在一些困难、并且包含最近的状态。

状态。状态由所有经过初始化的以太坊账户组成。在我写这篇文章的时候，差不多已有1200万的已知账户和合约，它们大概以每天100k个新账户的速度增长。

区块历史（Block-History）。所有历史区块（从创世块到最新的最佳区块）的链，也被称为区块链。

状态历史（State-History）。每个历史区块的状态构成了状态历史。稍后我会详细讨论这个问题。

如果这让你觉得有点无聊，还请继续耐心读下去。

理解精简模式（Pruning-Modes）和同步模式（Sync-Modes）

2016年初，Go-Ethereum团队推出了一种所谓的快速同步模式。从那时起，运行 ，尤其是在同一年以太坊发生垃圾邮件攻击之后，完全同步模式让人非常头疼。我写这些模式的时候用了斜体，因为稍后我会回过头来帮大家厘清它们最本质的含义。那么现在就先记住它们吧。

2016年底，Parity团队（以前的Ethcore）对链上的垃圾邮件作出反击，他们提供了一种压缩同步模式（ warp synchronization），以消除新用户的完全链同步。与Geth-fast一样，对那些试图同步以太坊链的用户而言， 很快就成为了实际上的标准模式。到今天为止，以上选项在两种客户端中都是默认的。

但是，对Geth节点进行快速同步（fast-sync）/完全同步（full-sync），分别是指什么呢? 相比非压缩同步，对Parity节点进行压缩同步（warp-sync），又是指什么呢？

一个完全同步（full-sync）的Geth节点能处理整个区块链并重放所有曾经发生过的交易。一个快速同步（fast-sync）的Geth节点只下载与所有区块同步的全部交易收据，以及最新的状态数据库。一旦完成之后，它就会切换到完全同步模式。注意，这不仅产生快速同步，也会产生精简的状态数据库，因为历史状态对于高度比最新区块低1024的区块是不可用的。 这个影响不大，但在继续阅读之前，请记住，Geth同步模式也是精简模式。

看看Parity配置选项，就更加复杂了。除了前面提到的同步模式之外，Parity还提供了独立精简模式，即快速模式（fast）和存档模式（archive）。是的，Gethfast也是一种同步模式，而且我们了解到，Gethfast更加精简，然而Parityfast精简模式不会与同步模式重耦合。在这一点上，我不得不承认，术语让人很困惑，读到这里你可能已经不想继续读下去了。慢着，让我们用笔和纸画一些东西。

Geth的fast模式实现了更快的同步和数据库精简，而Gethfull禁用了这两种模式。然而，在Parity里，wrap模式可以被禁用，而无需同时禁用状态树的精简！这句话很重要，所以我特地加粗显示。我不是要在这里比较以太坊客户端，这至少并非我本意。我是想告诉你，用一个较小的数据库运行一个完整验证的以太坊节点是可行的。Parity只不过为它提供了概念验证（proof-of-concept）。

这是为什么呢？因为只要你在你的磁盘上保存了所有的历史区块，你就可以通过对整个链的再加工来计算任意历史状态。但在大多数的用例中，根本不需要历史状态！所以说，从状态历史中删除过时的条目从而将所需的磁盘空间减少95%是一种明智的做法。

所以，一个完整验证节点的最小体积是多少？

嗯，大概几十GB吧，如果只运行parity而不启用warp（no-warp）的话。今年初秋的时候，它的体积还不到20 GB，但状态的增长速度非常快。目前，包含区块和交易的原始历史区块数据的体积大约为12-15GB，而最新状态的体积大约为1-2GB。

但是，这是否能算作为一个完整的以太坊节点呢？当然：

它从运行着完整的区块链同步，从创世块开始。

它重放所有的交易并执行所有的合约。

它重新计算每个区块的状态。

它将所有历史区块保存在磁盘上。

它将最新的状态保存在磁盘上，并删除旧状态。

以太坊客户端永远不会删除旧的区块，这是比特币和以太坊之间最显著的区别，因为精简一个比特币节点只能连带删除旧的区块。联系上下文，就更容易理解为何用户经常会认为一个删减过的以太坊节点不算是一个完整的节点。但现在，亲爱的朋友，你已经知道其实反论才是 。:)

最重要的是，即使是一个经过压缩同步（warp-synced）的Parity节点，也会在初始化同步后下载区块的整个历史，这样就可以在完成旧区块同步之后，为网络提供完整的节点。

完整图景：9个Parity配置比较

以下是我“色彩缤纷”的电子表格截屏，这张表格试图区分Parity在不同操作模式下的节点安全性。

配置 到配置 都被认为是完整的节点。配置 是默认配置的warp节点，一旦旧区块下载完成后，它就可以被认为是完整的节点。然而，它不会重放所有的交易；它只检查历史区块的工作量证明。

配置 是用户经常要求的，但在生产使用中却是极不推荐的。这个设置与一个删减过的比特币节点有一定的相似性，因为历史区块部分不可用。这不再是一个完整的节点。请注意，我在这一段上面添加了一道分隔线。你懂的。

配置 是一个轻客户端，这就值得为它专门再写一篇文章。谢谢你耐心看到了这里，以下是给你的总结：默认情况下，以太坊的一个完整节点不需要超过20-30 GB的磁盘空间。:)

以下是一些值得注意的信息和重要的注解。

（1）我在Parity工作。我比较了不同的Parity配置，不仅因为我的确认识且了解它们，还因为Parity允许用户分别配置删除模式和同步模式。

（2）我持有一些比特币和以太币。我希望这不会对我在本文中概述的技术方面产生任何影响。对此，我也在努力避免过于政治化。

（3）为了收集数字，我花了6个多星期的时间，用36种不同的配置中运行Parity。这很消耗时间和资源，但仍然有一个问题，我不能保持所有配置同时运行，因此，本文中给出的数字准确性必须谨慎使用。我希望这些结果与运行相同配置的其他节点的差异能控制在±20%。我想你应该明白的：