以太坊全节点到底是2TB还是180GB?

区块链爱好者副船长发布在 ETH/以太坊
 7221  10

作者:LocalPartitionFromImage
转自微博:https://weibo.com/5166192059/HmyVodJAp



前一阵子撕逼的问题“以太坊全节点到底是2TB还是180GB”,我个人的理解大致如下,欢迎挑错:

1.以太坊的区块链和比特币是不一样的。
比特币的区块链只登记了“交易历史”。以太坊的区块链同时登记了“交易历史”和“余额状态”两种数据。
比特币开发者也曾经考虑过进行协议升级、让比特币区块链也登记上“余额状态”,也就是UTXO commitment,但是考虑到种种问题,一直都没有实现。

2.以太的180GB确实可以叫全节点,它也是有保留完整交易历史的,而且只要对接算力就有独立出块能力。
删掉的只是历史状态数据,它相当于“余额”,是可以从交易历史里重新算出来的。
统计图表:http://t.cn/EJVbtgP

3.所谓“2TB的全节点”,应该叫做“存档节点”而不是“全节点”(虽然也算是全节点),人家以太坊社区本来也都是这么叫的。
“存档节点”比一般的“全节点”多出来的数据,即使删掉,也是可以重算出来的,只不过重算的过程非常费时费力而已。
统计图表:http://t.cn/EJVbtgG
如果我没理解错,以太的存档节点,不仅要重放交易历史,还要把历史上的每一个时刻拍照记录下来。
我搜到了一个技术团队的测试结果,他们用配置非常非常高的机器,也跑了好几个星期,才跟上最新的区块:http://t.cn/EMlMFmC

4.以太的第一个可疑点/喷点:新节点同步时如果要把历史上所有的交易都完整验证(重放)一遍,完成“自证清白”的过程,计算负担就太重。
所以,一般同步以太全节点的时候,用的选项都是“fast”,节点只会直接下载近期的状态,直接从近期的状态开始完整验证。
也就是说,对于历史交易,相当于只是简单“过目”了一遍,并没有真正去执行验证。
如果不用这种偷懒的手段,而是老实地执行完整的重放验证,可能用高配的机器也得跑上好几天甚至几个星期——具体要多久,我也不知道,谁有数据希望分享一下。

5.作为对比,Bitcoin Core(最主流的的比特币全节点软件)如果要完成一次完整校验历史交易的同步,在2018年12月,高配的机器大概只需要5小时:http://t.cn/ELs5qMs
有一点要注意:Bitcoin Core默认并不会完整验证所有交易历史,因为assumevalid默认是开启的,由开发者写入了一个区块哈希值,相当于信任开发者已经代用户完成了这个区块之前的完整(数字签名)验证。
需要改一下配置,设置assumevalid=0,才是真正的完整验证。上面那个测试就是设置了assumevalid=0的。
另外,即使比特币的全节点启用了修剪,也就是简单粗暴地删掉了老区块,也仍然可以算作一个全节点。但是历史区块删掉了是没办法重算出来的,所以这种启用修剪的全节点不能帮助新的全节点从头同步,不能向别人“自证清白”。

至于中本聪白皮书里提到的裁剪,它其实从来就没被实现过。可能是因为回溯扫描老区块数据的工作模式效率比较低吧——很早以前,比特币全节点软件就已经完成了区块数据和UTXO数据的分离管理,这样验证交易的效率才不至于太差。

6.以太的第二个可疑点/喷点:以太节点的light模式,相当于比特币的SPV。这种“节点”硬件要求极低、同步极快,因为它是啥也不验证,直接跟着算力走的。
不知道以太统计“全节点”的时候,是不是也把这种light模式的“伪节点”也统计进去了……

7.作为对比,比特币最主流的全节点软件Bitcoin Core并没有加入SPV客户端功能。

8.其实,对于网络上出现的一个节点,它到底是不是“真节点”,外人是没办法准确区分的,因为节点完全可以“滥竽充数”,从别人那里把数据拉过来,当“二道贩子”,无论比特币还是以太坊都是这样。

PS:同步比特币全节点时,最常见的性能瓶颈在磁盘读写上,因为chainstate目录里保存的UTXO集合(相当于所有比特币地址的余额状态)被非常频繁地查询、更新,会产生大量零碎的读写操作,对机械硬盘来说压力山大。如果用固态硬盘就会好很多。
就现在来说,如果能拿出大约6GB以上的内存分给数据库缓存,就可以完全避免频繁读写磁盘带来的性能瓶颈,但是以后UTXO集合大小说不定会再创新高,那个时候就需要更多的内存,或者需要高性能SSD来缓解这个问题了。
  • 正序
  • 最新
只看帖主楼层直达
  • 区块链爱好者 副船长 2019-03-26 14:14:19 只看该作者沙发
    原评论
    狗狗币:关于全节点的定义,我觉得应该是有从诞生至今全部主链数据的节点。全部“数据”是关键。至于是否能挖矿,是否包括加工后的数据,甚至版本如何,是否能被其它节点直接发现连接,能否发币等,都关系不大。要明白全节点是总账本,信息若有缺失不能完全对账的不算是全节点。
    比特派钱包:你说的是对的
    比太钱包:你说的是对的
    朗豫-fred:都是一样的。 比特币也用了很多cache来缓存utxo,stxo. 全节点不能只说包含压缩的纯区块数据啊,要能实用必须展开。 Bitcoin core 没用spv,但是用prune了啊。
    潘志彪kevin:比特币的UTXO集合,目前采用LevelDB实现,磁盘文件大约3GB,dbcache=3000就足够了
  • visionhigh 船员 2019-03-26 14:15:25 只看该作者板凳
    终于有明白人了。
  • visionhigh 船员 2019-03-26 14:16:43 只看该作者地板
    最近看到不少傻逼因为自己的低理解能力喷以太坊, 真是可怜
  • 洒脱喜 副船长 2019-03-26 15:27:02 只看该作者5楼
    这个问题很难去界定啊,180GB的的确是修剪过的节点,以太坊因比BTC多了状态数据,叫它全验证节点(或简称全节点)是可以的,但终究是删掉了状态数据,尽管从理论上来看,我们可通过全节点计算出被删掉的状态数据,但这是一个非常费时费力的过程,你可能会说,以太坊的全节点安全性足够了啊,不需要存档节点来提供安全性!这个你可以了解一下BlockCypher的例子,这个存档节点因为找不到对等的存档节点,被迫花费了更多的时间和精力去恢复丢失的一点状态数据,导致BlockCypher的以太坊API几乎被淘汰了一个月的时间,这就是安全影响。

    从比特币的角度来看,180GB的节点不能被称为全节点,存档节点才是真的全节点
  • 莱特币爱好者 副船长 2019-03-26 16:28:45 来自App只看该作者6楼
    偷换概念,无耻之徒,穷途末路。
  • Aitlas 副船长 2019-03-27 09:25:59 只看该作者7楼
    原作者在本站ID是 @BurntCoins

    另外,真正要命的其实是验证问题,撑爆的是低配电脑的CPU、内存和网络带宽,硬盘空间倒是次要的,参见缪永权去年的文章。
  • fjh2013 队长 2019-03-27 09:36:32 只看该作者8楼
    其实矛盾的焦点还是存储问题 + 带宽问题,运算不是问题。
    5G 网络不是秒下G 级别数据吗,到时带宽问题是否能解决呢。
    存储问题好办,淘汰机械硬盘吧。
  • 一套拳法 队长 2019-04-01 13:19:12 只看该作者9楼
    @委拉斯凯兹:

    关于以太坊和比特币的全节点的问题讨论很热烈,我个人的几点看法:

    1)首先需以太坊的智能合约和BTC的脚本是有区别的。BTC的脚本执行过程可以看作一个原子操作,不存在中间状态。而以太坊的智能合约实际上是一个允许多人修改的状态机,每个区块包含对状态机进行修改的交易,所以智能合约有大量中间状态。交易保存在底层的levelDB中即区块中;而中间状态是一个巨大的state tie,保存在stateDB中。

    2)以太坊的一个新的fast node对当前区块之前的交易是不执行的,而是从其他节点得到一个state snapshot,在这个基础上再开始执行。然后每隔一定的区块(1024个)把老的状态信息都丢掉,只保留最新状态。

    那么fast node到底算不算全节点呢?我觉得不能算

    1)去中心化的精髓就是“Don't trust,Verify”。fast node的信任不是完全来自于公开的区块链,而是来自于其他节点,也就是存在大量没有verify的数据。

    2)fast node无法回到任意历史状态,而全节点可以。fast node丢掉了1024个区块之前的状态信息,而一旦区块链因为算力竞争从1024个区块之前开始重组,fast node等同于失效了。

    3)state tie是一个巨大的随机访问树,受到磁盘IO限制,重构需要大量时间。不是说想重构就可以重构的,大量fast node如果要重新生成state tie就根本不可能跟上当前的区块更新速度。也就是说永远不能变成全节点。

    我们甚至还可以进一步假设极端情况,如果以太坊都由fast node组成,那么以太坊的区块链就是没有任何人完整校验过的,虽然还可以正常工作,但是这是不可接收的。

    原文:https://weibo.com/2046927503/HmGzE3nhQ
  • BurntCoins 副船长 2019-04-02 20:30:51 只看该作者10楼
    洒脱喜发表于2019-03-26 15:27:02这个问题很难去界定啊,180GB的的确是修剪过的节点,以太坊因比BTC多了状态数据,叫它全验证节点(或简称全节点)是可以的,但终究是删掉了状态数据,尽管从理论上来看,我们可通过全节点计算出被删掉的状态数据,但这是一个非常费时费力的过程,你可能会说,以太坊的全节点安全性足够了啊,不需要存档节点来提供安全性!这个你可以了解一下BlockCypher的例子,这个存档节点因为找不到对等的存档节点,被迫花费了更多的时间和精力去恢复丢失的一点状态数据,导致BlockCypher的以太坊API几乎被淘汰了一个月的时间,这就是安全影响。

    从比特币的角度来看,180GB的节点不能被称为全节点,存档节点才是真的全节点
    但是比特币全节点压根就没保存老状态啊……如果出了数据损坏之类问题,也只能从头reindex吧。不过,数据损坏只是多种可能的情况之一,另一种情况是链重组/回滚。对于比特币来说,回滚是通过读取revXXXXX.dat一个一个打补丁来完成的;以太就不知道是什么状况了。
    楼层直达
  • BurntCoins 副船长 2019-04-02 20:31:47 只看该作者11楼
    洒脱喜发表于2019-03-26 15:27:02这个问题很难去界定啊,180GB的的确是修剪过的节点,以太坊因比BTC多了状态数据,叫它全验证节点(或简称全节点)是可以的,但终究是删掉了状态数据,尽管从理论上来看,我们可通过全节点计算出被删掉的状态数据,但这是一个非常费时费力的过程,你可能会说,以太坊的全节点安全性足够了啊,不需要存档节点来提供安全性!这个你可以了解一下BlockCypher的例子,这个存档节点因为找不到对等的存档节点,被迫花费了更多的时间和精力去恢复丢失的一点状态数据,导致BlockCypher的以太坊API几乎被淘汰了一个月的时间,这就是安全影响。

    从比特币的角度来看,180GB的节点不能被称为全节点,存档节点才是真的全节点
    还有,比特币这边,即使是启用了prune(直接删掉老区块数据,删掉后除了找别人重新下载之外无法恢复)的节点,也仍然可以叫做全节点的。
    楼层直达
登录 账号发表你的看法,还没有账号?立即免费 注册