区块链神吐槽前一阵子撕逼的问题“以太坊全节点到底是2TB还是180GB”，我个人的理解大致如下，欢迎挑错：
以太坊的区块链和比特币是不一样的。
比特币的区块链只登记了“交易历史”。以太坊的区块链同时登记了“交易历史”和“余额状态”两种数据。
比特币开发者也曾经考虑过进行协议升级、让比特币区块链也登记上“余额状态”，也就是UTXO commitment，但是考虑到种种问题，一直都没有实现。
以太的180GB确实可以叫全节点，它也是有保留完整交易历史的，而且只要对接算力就有独立出块能力。
删掉的只是历史状态数据，它相当于“余额”，是可以从交易历史里重新算出来的。
所谓“2TB的全节点”，应该叫做“存档节点”而不是“全节点”（虽然也算是全节点），人家以太坊社区本来也都是这么叫的。
“存档节点”比一般的“全节点”多出来的数据，即使删掉，也是可以重算出来的，只不过重算的过程非常费时费力而已。
如果我没理解错，以太的存档节点，不仅要重放交易历史，还要把历史上的每一个时刻拍照记录下来。
我搜到了一个技术团队的测试结果，他们用配置非常非常高的机器，也跑了好几个星期，才跟上最新的区块。
以太的第一个可疑点/喷点：新节点同步时如果要把历史上所有的交易都完整验证（重放）一遍，完成“自证清白”的过程，计算负担就太重。
所以，一般同步以太全节点的时候，用的选项都是“fast”，节点只会直接下载近期的状态，直接从近期的状态开始完整验证。
也就是说，对于历史交易，相当于只是简单“过目”了一遍，并没有真正去执行验证。
如果不用这种偷懒的手段，而是老实地执行完整的重放验证，可能用高配的机器也得跑上好几天甚至几个星期——具体要多久，我也不知道，谁有数据希望分享一下。
作为对比，Bitcoin Core（最主流的的比特币全节点软件）如果要完成一次完整校验历史交易的同步，在2018年12月，高配的机器大概只需要5小时。
有一点要注意：Bitcoin Core默认并不会完整验证所有交易历史，因为assumevalid默认是开启的，由开发者写入了一个区块哈希值，相当于信任开发者已经代用户完成了这个区块之前的完整（数字签名）验证。
需要改一下配置，设置assumevalid=0，才是真正的完整验证。上面那个测试就是设置了assumevalid=0的。
另外，即使比特币的全节点启用了修剪，也就是简单粗暴地删掉了老区块，也仍然可以算作一个全节点。但是历史区块删掉了是没办法重算出来的，所以这种启用修剪的全节点不能帮助新的全节点从头同步，不能向别人“自证清白”。
至于中本聪白皮书里提到的裁剪，它其实从来就没被实现过。可能是因为回溯扫描老区块数据的工作模式效率比较低吧——很早以前，比特币全节点软件就已经完成了区块数据和UTXO数据的分离管理，这样验证交易的效率才不至于太差。
作为对比，比特币最主流的全节点软件Bitcoin Core并没有加入SPV客户端功能。
以太的第二个可疑点/喷点：以太节点的light模式，相当于比特币的SPV。
这种“节点”硬件要求极低、同步极快，因为它是啥也不验证，直接跟着算力走的。不知道以太统计“全节点”的时候，是不是也把这种light模式的“伪节点”也统计进去了……
其实，对于网络上出现的一个节点，它到底是不是“真节点”，外人是没办法准确区分的
因为节点完全可以“滥竽充数”，从别人那里把数据拉过来，当“二道贩子”，无论比特币还是以太坊都是这样。
PS：同步比特币全节点时，最常见的性能瓶颈在磁盘读写上，因为chainstate目录里保存的UTXO集合（相当于所有比特币地址的余额状态）被非常频繁地查询、更新，会产生大量零碎的读写操作，对机械硬盘来说压力山大。如果用固态硬盘就会好很多。
就现在来说，如果能拿出大约6GB以上的内存分给数据库缓存，就可以完全避免频繁读写磁盘带来的性能瓶颈，但是以后UTXO集合大小说不定会再创新高，那个时候就需要更多的内存，或者需要高性能SSD来缓解这个问题了。
原文链接：微博@LocalPartitionFromImage
狗狗币：区块链关于全节点的定义，我觉得应该是有从诞生至今全部主链数据的节点。全部“数据”是关键。至于是否能挖矿，是否包括加工后的数据，甚至版本如何，是否能被其它节点直接发现连接，能否发币等，都关系不大。要明白全节点是总账本，信息若有缺失不能完全对账的不算是全节点。
以太坊全节点VS比特币全节点
Ethereum在 2015-07-30诞生，经过4年的发展到现在的740w高度，从https://etherscan.io/chartsync/chainarchive 数据来看，完完整整的区块链数据已经膨胀到2231.5 GB，也就是2.2 TB，同步时间要花几个月时间，而且每天以 3～4 GB的速度在增长。在过几年5TB的硬盘可能也装不下了，这也是为什么ethereum技术社区对的分片呼声这么高的原因。
Bitcoin在2009-01-03诞生，经过10年的发展，完完整整的区块链数据基本也就200多GB，同步时间基本在24~36小时。
从保持去中心化，保有全量数据的角度来说，Bitcoin 在这两方面平衡的相当好。而Ethereum归档节点的机器成本已经很高了，个人没有太多动力去维护。
之前我曾抱怨Bitcoin技术推动太墨迹，丧失了很多机会，现在我感觉Ethereum面临的技术挑战相当严峻。从最近的君士坦丁堡硬分叉出现的问题来看，这2个最知名的区块链技术团队的行事风格差异也挺大的。
Bitcoin是伟大的创举，Ethereum是天才的设计，前者是从0到1跨时代的发明，后者带来了智能合约，深刻影响着传统的经济观念。
总之，都祝好吧。
关于以太坊和比特币的全节点的问题讨论很热烈，我个人的几点看法：
首先需以太坊的智能合约和BTC的脚本是有区别的。
BTC的脚本执行过程可以看作一个原子操作，不存在中间状态。而以太坊的智能合约实际上是一个允许多人修改的状态机，每个区块包含对状态机进行修改的交易，所以智能合约有大量中间状态。交易保存在底层的levelDB中即区块中；而中间状态是一个巨大的state tie，保存在stateDB中。
以太坊的一个新的fast node对当前区块之前的交易是不执行的，而是从其他节点得到一个state snapshot，在这个基础上再开始执行。
然后每隔一定的区块（1024个）把老的状态信息都丢掉，只保留最新状态。
那么fast node到底算不算全节点呢？我觉得不能算
- 去中心化的精髓就是“Don't trust，Verify”。fast node的信任不是完全来自于公开的区块链，而是来自于其他节点，也就是存在大量没有verify的数据。
- fast node无法回到任意历史状态，而全节点可以。fast node丢掉了1024个区块之前的状态信息，而一旦区块链因为算力竞争从1024个区块之前开始重组，fast node等同于失效了。
- state tie是一个巨大的随机访问树，受到磁盘IO限制，重构需要大量时间。不是说想重构就可以重构的，大量fast node如果要重新生成state tie就根本不可能跟上当前的区块更新速度。也就是说永远不能变成全节点。
我们甚至还可以进一步假设极端情况，如果以太坊都由fast node组成，那么以太坊的区块链就是没有任何人完整校验过的，虽然还可以正常工作，但是这是不可接收的。
微博评论：
LocalPartitionFromImage：1. Bitcoin Core默认也没有完整验证，因为有assumevalid，比特币和以太的不同仅仅在于比特币没有直接跟随算力，而是引入对开发者的信任; 2.长回滚破坏性很大，也极少发生。如果经常发生长回滚，那这条链也不安全了; 3.只有新区块产生速率持续超过一般机器的验证消化速率，才会导致“无法追上”的情况。
LocalPartitionFromImage：回复@委拉斯凯兹:1.其他全节点实现往往也有类似的机制，比如checkpoint，assumevalid也是源自于checkpoint的。2.所以我才问fast node是不是真的完全无法处理长回滚，一旦碰到就瞎了。3.网络对archival node的依赖到底体现在哪些方面呢？
委拉斯凯兹：回复@LocalPartitionFromImage:1）assumevalid直接在参数中可以设置，btcpay就没有使用这个特性，Jameson Lopp测试的5个小时同步所有区块也没有使用，btc的很多其他实现也不支持assumevalid。2）长回滚是黑天鹅，小概率不代表不会发生。3）普通机器已经无法同步archive node了
LocalPartitionFromImage：历史区块如果出现“验证速率慢过记账出块”这种情况，可能也是个喷点/疑点，但是山丘迟早可以翻过去，硬骨头迟早还是能啃完的。
LocalPartitionFromImage：还有，Bitcoin Core其实压根就没有保存“旧状态”，更遑论“丢弃”。为了应对回滚，Bitcoin Core保存了revXXXXX.dat文件。不知道以太是怎么做的，我了解不多，但凭直觉的话，不应该像你说的一样“fast node碰到超长回滚会直接失效”。
推荐阅读：
《为什么要运行比特币全节点_私钥决定比特币所有权，全节点捍卫比特币规则_囤比特币@ahr999》
