前面一篇文章（分析之三）中提到了以太坊的数据存储越来越大，有个数据“瘦身”的问题，本文中具体讨论下。
以太坊是一个去中心化的区块链系统，数据不是存放在中心服务器上，而是存在客户端的硬盘上。目前以太坊发展遇到一个现实问题：安装过以太坊客户端，挖过矿的同学想必都知道安装完后同步要好几天，数据高达几十G，在个人电脑上安装全客户端已经有点勉强了，更不要说是手机等轻客户端。这种情况发展下去，比如出现中心化，也就是只有一部分企业级用户会安装全客户端，个人客户对数据的验证只能依赖代理的企业，这个和区块链去中心化的理念背道而驰。幸亏现在有了快速同步的技术，让“臃肿”的以太坊数据成功“瘦身”。
以去年我下载的旧版本的geth为例，数据同步到2/3已经有40G了，因为体积太大网络较慢硬盘不够用一直同步不了；今年这个月，我用了新版本的geth，开启了快速同步特性（geth --fast），大概15个G一个晚上就完成了同步，处在可以挖矿的模式了。原因就是快速同步时不需要将所有历史交易全部重新回放一遍，减少了CPU的工作量，加快了速度（原先慢不是因为网络下载区块链数据带宽的问题，而是需要CPU验算时间）。
以太坊创始人Vitalik谈到以太坊瘦身，第一个特性就是fast syncing和state tree pruning的概念； fast syncing的意思是一个新的节点不需要下载和验证整个区块链，反而只需要下载每个交易的收据（receipt），然后可以用梅克尔树的模式下载和验证最新的状态。这样同步的时间更快。也就是说快速同步只关心交易结果，并不会把历史交易全部重新做一遍来验证。state tree pruning的意思是自动删除不再有效梅克尔树的树枝； 这样应该可以减少存储的需求5-10倍。为什么快速同步模式不仅快，数据库体积还小？因为LevelDB是种层级存储的模式，其实旧状态也保存着，只不过在比较深的level，读取时读取不到，Get时读取的是浅层level的最新状态，这种历史数据在快速同步时是没有同步过来的，大部分情况下也不需要关心（我安装了快速节点，部分交易历史无法显示了，但是账户余额绝对是正确的），从而有效减少了存储体积。
也就是说，以太坊数据大，是因为交易历史明细多，之前的交易历史明细如果不再关心了，可以用fast模式不同步下来（Trie树就少了），对个人用户而言是足够了。不过对交易所而言，要保存所有的历史记录，所以这样就不够了。我有个在交易所工作的前同事，透露交易所的以太坊节点，保存了所有Trie树，体积超过一个TB！
所以，到底需要保存多少数据，也是看需求。