Ethereum中所有的开销管理都被统一到gas计费模型之下，交易的大小需要消耗对应的gas ，而每一条EVM指令消耗的gas，不仅考虑了计算开销，也将存储开销考虑在内。通过每个区块的gaslimit，间接限制了历史和状态的增长速度。

　　ps. 常见的一个误解是，Ethereum的「区块链大小」已经超过1T了。从上面的分析我们可以看到，「区块链大小」是一个非常模糊的定义，如果把历史状态算进去，确实超过了，但对于全节点来说，把历史状态删掉没有任何问题，因为只要有Genesis和交易历史，任意时刻的历史状态都可以重新被计算出来（不考虑计算需要的时间）。

　　真正有意义的数据，是全节点必须的数据的大小，Bitcoin是200G，Ethereum是170G，两者是基本相同的，而且在平均配置的云主机都能装下，因此人们观察到的Ethereum全节点减少并不是由于存储增加导致的（根本原因是同步时的计算开销）。

　　考虑到Ethereum的历史长度（当前区块的timestamp减去genesis的timestamp）不到Bitcoin的一半，可以看出Ethereum的历史和状态大小增长更快。

　　05

　　The Tragedy of (Storage) Commons：区块链版本的公地悲剧

　　公地悲剧所指指的是这样一种情况，有限的共享资源在不受任何限制的使用下被人们过度消耗。区块链节点为保存历史和状态付出的存储，正是这样一种共享资源。

　　区块链节点为处理交易所花费的资源有三种，CPU，存储和网络带宽。CPU和带宽都是每个区块会刷新的资源，我们可以认为每个区块间隔内都用同样多的CPU和带宽可供使用，上个区块消耗掉的CPU和带宽不会让下个区块可用的CPU和带宽变少。对于可刷新的资源，我们可以通过一次性支付的交易手续费来补偿节点（手续费与计算复杂度和交易大小的相关性可参考RFC0015Appendix）。

　　与CPU和带宽不同，存储是一种占用资源，在一个区块中被占用了的存储，除非使用者主动释放，否则无法在后面的区块中被其它使用者使用。节点需要为存储持续的付出成本，而使用者却不需要为存储持续的支付手续费（记住交易手续费只需要支付一次）。

　　使用者只需要在往区块链写数据的时候支付一点点手续费，就可以永久使用一个可用性超过Amazon S3的存储，其无限大的永久存储成本需要区块链网络中的所有全节点来承担。

　　Ethereum上由于各种DApp的存在，The Tragedy of (Storage) Commons相对更加严重。例如，在区块5700001（May 30, 2018）的时候，使用状态最多的5个合约是：

　　EtherDelta, 5.09%

　　IDEX, 4.17%

　　CryptoKitties, 3.05%

　　ENS, 1.92%

　　EOS Sale, 1.73%

　　比较有趣的是最后一个，EOS Sale。虽然EOS的众筹已经完成，EOS代币已经在EOS链上流转，EOS众筹的记录却永远留在了Ethereum的节点上，消耗Ethereum全节点的存储资源。

　　可以看到，在缺乏管理的情况下，区块链的存储资源会被有意或者无意的滥用。

　　在一个设计合理的经济模型中，使用者必须承担存储占用的成本，这个成本不仅仅与占用存储空间的大小成正比，还与占用时间的长度成正比。

　　06

　　状态爆炸

　　公地悲剧所指的无论是历史还是状态数据都会占用存储资源。通过上面对Bitcoin和Ethereum的分析（其他区块链的状态模型基本都可以归纳为二者之一）可以看到，虽然它们对历史和状态的增长进行了管理，但是对历史和状态的总大小却没有任何控制，这些数据会持续的无休止的累积下去，使得运行全节点需要的存储资源越来越大，提高全节点的运行门槛，使网络的去中心化程度越来越低，这是我们不愿意看到的。

　　你也许会说，有没有可能硬件平均水平的提高会超过历史和状态的积累速度？我的回答是可能性很低：

　　从这张图中我们可以看到，随着Ethereum网络的发展，状态数据累积的数量呈指数式的增长。Bitcoin的状态数据从0积累到3G，用了10年；Ethereum的状态数据从0积累到10G，用了4年；而这是在我们还没有解决Scalability问题，区块链仍然是小众技术的情况下的增长速度。

继续阅读：

此文由 比特币官网 编辑，未经允许不得转载！：首页 > 比特币行情 » 区块链的状态爆炸困境 |硬核系列