1.以太坊的区块链和比特币是不一样的。 比特币的区块链只登记了“交易历史”。以太坊的区块链同时登记了“交易历史”和“余额状态”两种数据。 比特币开发者也曾经考虑过进行协议升级、让比特币区块链也登记上“余额状态”，也就是UTXO commitment，但是考虑到种种问题，一直都没有实现。
2.以太的180GB确实可以叫全节点，它也是有保留完整交易历史的，而且只要对接算力就有独立出块能力。 删掉的只是历史状态数据，它相当于“余额”，是可以从交易历史里重新算出来的。 统计图表：
https://etherscan.io/chartsync/chaindefault
3.所谓“2TB的全节点”，应该叫做“存档节点”而不是“全节点”（虽然也算是全节点），人家以太坊社区本来也都是这么叫的。 “存档节点”比一般的“全节点”多出来的数据，即使删掉，也是可以重算出来的，只不过重算的过程非常费时费力而已。 统计图表：
https://etherscan.io/chartsync/chainarchive
如果我没理解错，以太的存档节点，不仅要重放交易历史，还要把历史上的每一个时刻拍照记录下来。 我搜到了一个技术团队的测试结果，他们用配置非常非常高的机器，也跑了好几个星期，才跟上最新的区块：
https://blog.slock.it/how-to-not-run-an-ethereum-archive-node-a-journey-d038b4da398b?gi=91dda8b571f
4.以太的第一个可疑点/喷点：新节点同步时如果要把历史上所有的交易都完整验证（重放）一遍，完成“自证清白”的过程，计算负担就太重。 所以，一般同步以太全节点的时候，用的选项都是“fast”，节点只会直接下载近期的状态，直接从近期的状态开始完整验证。 也就是说，对于历史交易，相当于只是简单“过目”了一遍，并没有真正去执行验证。 如果不用这种偷懒的手段，而是老实地执行完整的重放验证，可能用高配的机器也得跑上好几天甚至几个星期——具体要多久，我也不知道，谁有数据希望分享一下。
5.作为对比，Bitcoin Core（最主流的的比特币全节点软件）如果要完成一次完整校验历史交易的同步，在2018年12月，高配的机器大概只需要5小时：
https://medium.com/casa/bitcoin-full-validation-sync-performance-d842260cf353
有一点要注意：Bitcoin Core默认并不会完整验证所有交易历史，因为assumevalid默认是开启的，由开发者写入了一个区块哈希值，相当于信任开发者已经代用户完成了这个区块之前的完整（数字签名）验证。 需要改一下配置，设置assumevalid=0，才是真正的完整验证。上面那个测试就是设置了assumevalid=0的。 另外，即使比特币的全节点启用了修剪，也就是简单粗暴地删掉了老区块，也仍然可以算作一个全节点。但是历史区块删掉了是没办法重算出来的，所以这种启用修剪的全节点不能帮助新的全节点从头同步，不能向别人“自证清白”。
至于中本聪白皮书里提到的裁剪，它其实从来就没被实现过。可能是因为回溯扫描老区块数据的工作模式效率比较低吧——很早以前，比特币全节点软件就已经完成了区块数据和UTXO数据的分离管理，这样验证交易的效率才不至于太差。
6.以太的第二个可疑点/喷点：以太节点的light模式，相当于比特币的SPV。这种“节点”硬件要求极低、同步极快，因为它是啥也不验证，直接跟着算力走的。 不知道以太统计“全节点”的时候，是不是也把这种light模式的“伪节点”也统计进去了……
7.作为对比，比特币最主流的全节点软件Bitcoin Core并没有加入SPV客户端功能。
8.其实，对于网络上出现的一个节点，它到底是不是“真节点”，外人是没办法准确区分的，因为节点完全可以“滥竽充数”，从别人那里把数据拉过来，当“二道贩子”，无论比特币还是以太坊都是这样。
PS：同步比特币全节点时，最常见的性能瓶颈在磁盘读写上，因为chainstate目录里保存的UTXO集合（相当于所有比特币地址的余额状态）被非常频繁地查询、更新，会产生大量零碎的读写操作，对机械硬盘来说压力山大。如果用固态硬盘就会好很多。 就现在来说，如果能拿出大约6GB以上的内存分给数据库缓存，就可以完全避免频繁读写磁盘带来的性能瓶颈，但是以后UTXO集合大小说不定会再创新高，那个时候就需要更多的内存，或者需要高性能SSD来缓解这个问题了。
本文来源：微博
