8BTCCI: 14048.09 8BTCVI: 10024.12 24H成交额: ¥5633.80亿 总市值: ¥17689.95亿
以太坊真全节点不足100个,欺诈证明如何弥补网络的安全性?

以太坊真全节点不足100个,欺诈证明如何弥补网络的安全性?

洒脱喜 发布在 竞争币 独家 105526

关于比特币和以太坊的节点对比,社区最常用的方法,是使用节点统计网站的数据,例如,当前bitnodes.earn.com统计的比特币节点数是10459个,而ethernodes.org统计的以太坊节点数则是8580个。乍看之下,两大区块链网络似乎平分秋色。

p2

(比特币节点数)

p4

(以太坊节点统计数)

实则不是这样。

我们首先需要了解的背景是,当前,完整的比特币区块链交易数据大小约为200 GB,而完整的以太坊区块链数据则达到了比特币的10倍,接近2TB

以太坊的状态爆炸,使得用户要完整存储数据变得不现实,也因此,当前以太坊的8000多个节点,绝大多数是修剪过的全验证节点,当然,为了好听一些,以太坊官方还是将这类全验证节点简称为全节点,而把完整存储历史状态数据的节点称为档案节点(Archive Node),而在今天,以太坊全网的档案节点已不足100个了。

而比特币的全节点,其实就相当于以太坊的“档案节点”,当然,比特币也有类似的修剪节点,这是在Bitcoin Core 0.12.0 版本客户端之后提供的一种功能。

而这种修剪节点,同样可独立完成比特币转账确认,但是它并没把整个区块链都保存到本地,也就无法提供完整的区块链给其它节点。

可以说,无论是比特币的全节点,还是以太坊的档案节点,它们都是各自网络的主心骨,如果网络完全失去了它们,网络的安全性将大大降低,而这类节点数越多,就代表着网络的抵抗性越强。

下面分享一个关于真以太坊全节点(来自BlockCypher CEO )的悲剧故事:

“由于君士坦丁堡硬分叉,BlockCypher的以太坊API几乎被淘汰了一个月。本文会解释发生了什么,我们吸取了什么教训,以及我们正在做什么,以防止将来发生这种类型的停机事故。

为君士坦丁堡硬分叉提前做准备

以太坊团队在2018年12月份中旬宣布,以太坊将在19年1月份进行君士坦丁堡硬分叉。开发者称即将到来的分叉,将是以太坊历史上最不重要的分叉。对此,我们不同意,这次硬分叉影响了数百个源文件。按照以太坊官方概述的协议,我们主动开始遵循他们的指示,这也涉及到修改我们的备份存储。我们团队在圣诞节期间加班,并在2019年1月份的第一周完成了这项工作。

我们以为已经准备好了。

到了1月8日,发生了大问题

1月8日晚上,我们意识到我们的以太坊状态出现了问题,但我们不知道发生了什么,我们只知道一些小数据丢失了。以太坊状态是不可解读的,所有数据都经哈希存入树结构当中,这使得我们不可能找出到底发生了什么问题。

我们尝试了多个恢复过程,但都没有成功。我们一直遭遇丢失数据错误(一个Trie节点)。

由于多次尝试后仍未能发现和恢复丢失的数据,我们开始了“快速”同步过程:完成“快速”同步需要2天多的时间。不幸的是,它没有帮助我们恢复丢失的数据,也没有恢复我们的状态。

你们可能会问:

为什么快速同步不起作用?因为它只包含整个区块链数据的一小部分为了可靠地提供和操作我们的API,我们需要所有的数据

为什么我们不在君士坦丁堡更新之前备份我们的状态?我们做了,但它因还原而部分损坏了。另外,以太坊状态不是一个可以简单备份和修补的数据库。它不能在以太坊节点在线的情况下完成,也不能以增量的方式完成(远超过1 TB)。

(经验教训1:以太坊状态与其他区块链非常不同。它不能使用任何传统的备份方法进行恢复。)

漫长的完全同步游行开始了

作为最后的手段,我们在1月12日开始对超过2 TB的以太坊状态进行“完全”同步。由于知道了我们必须应对的规模,我们升级到了最大的可用机器,试图让同步工作更快,但帮助并不大。

我们无能为力地等待和检查。

1月14日,君士坦丁堡硬分叉计划在生效前一天被推迟了,显然,安全审计发现了一个漏洞,允许潜在攻击者从智能合约中窃取加密货币。最后一分钟的取消,令我们非常沮丧。如果我们等到君士坦丁堡生效后才开始实施,我们就可以节省大量的工作、焦虑和开支……而且我们的ETH API将一直工作。

(经验教训2:不要提前计划以太坊升级,先等他们发生。)

两周后,我们了解到“完全”同步实际上不是完全状态修复。

两个多星期后,我们的以太坊状态恢复了,但这并不是我们灾难的结束。结果,完全同步默认为不包括完整的Trie状态。如果你正在进行完全同步,为什么默认设置不包括所有内容?这违背了逻辑,我们的下一个挑战是如何将Trie状态添加到“完整”状态。

Vitalik,请帮忙!

在研究了我们能想到的,将Trie状态添加到以太坊状态的所有方法之后,我们请求Vitalik提供帮助。他给我们的第一个回复是:“哦,你们是少数几个运行那些大的、可怕节点的运营者之一。” 我们问他是否知道有其他人运行一个“大的、可怕的节点”,看看我们是否可能与他们同步,但Vitalik不知道任何人,尽管以太坊基金会也保留了以太坊区块链的完整存档副本。我们无奈之下再次开始完全同步,这次包括Trie状态。

(经验教训3:如果进行链重组,我们可能是唯一了解以太坊交易历史的公司)

……

而另一种只下载区块头交易或状态数据的节点,我们称之为简化支付验证(SPV)节点,又称轻节点,而比特币和以太坊,都拥有此类节点。(目前,研究者们又提出了简化版SPV节点,又称超轻节点,例如FlyClient

在正常情况下,SPV轻节点的运行是良好的,但当多数全节点出现不诚实行为的情况下,轻节点的安全保障就会变得较弱。例如,尽管在比特币或以太坊网络中的多数非诚实节点,目前只能审查、反转或重排序交易,如果所有的客户端都使用的是轻节点,多数共识将能够相互勾结,产生包含凭空创造货币的交易区块,而轻节点将无法检测到这一点。另一方面,全节点将立即拒绝掉那些无效区块。

而由于以太坊的数据太过庞大,其会遇到的挑战也就越大,为此,以太坊创始人等研究者就提出了欺诈证明方案和数据可用性证明系统(论文:欺诈证明:通过多数非诚实节点,实现最大化轻客户端安全性并扩展区块链)。

简单说,如果以太坊网络有一个诚实的全节点,它愿意生成在最大网络延迟的情况下传播的欺诈证明,然后轻客户端就能够接收和验证来自全节点的无效区块欺诈证明,而数据可用性证明系统,则负责让轻客户端能够保证全节点生成欺诈证明所需的区块数据是可用的。

通过这种方式,使得以太坊轻客户端的安全程度能够向全节点靠近,当然,这只是在理论上的。

总的来说,就目前的情况而言,比特币的节点健康度是要好于以太坊的,而后者想要解决这个问题,就需要付出更多的努力。

评论(14)
登录 账号发表你的看法,还没有账号?立即免费 注册
  • 神币 2019-03-14
    BTM比原链才是真正的比特币
  • 莱特币爱好者 2019-03-14
    快玩完了,它的数据增长速度还在不断地提高。
  • 洒脱喜 2019-03-14
    据说不到10个了
  • 北极之雪 2019-03-14
    比原链的全节点数量49个,我懂了,比原链原来能跟以太坊平分秋色
  • 洒脱喜 2019-03-14
    写这篇文章不是说以太坊不安全,相比大多数公链而言,以太坊还是足够安全的,只是它没有比特币安全这是事实。同样的,比特币也会遇到这样的问题,我们需要探讨的是解决方案。
    • Viral.: 2019-03-15
      以太坊并不需要存档节点来维护安全性,全节点就可以。实际上存档节点是全节点的一种模式,full node with archive setting,如果需要历史的状态数据,自己回去重新跑一遍区块链就行。
    • 洒脱喜: 2019-03-18
      回复Viral. :所谓的以太坊全节点是权衡的一种考虑,实际并非真正意义上的全节点,当然,这对安全的影响不大,但是考虑过没有,一旦没人去运行存档节点会意味着什么(这也是以太坊基金会为什么要去运行几个存档节点的原因)。
    • 洒脱喜: 2019-03-18
      回复Viral. : 实际上是全节点是存档节点的修剪模式,而不是反过来
  • 尒溤6467367346 2019-03-14
    懂了,买
  • lansea90 2019-03-14
    以太坊碰到真问题了,可能是他最困难的时候吧。
  • SX_LLH_906 2019-03-17
    麻烦做点功课再发帖行不?存档节点对安全性好无影响,全节点就够了,存档节点只是为了查询历史某一block高度上的实时状态。不懂瞎几把写
    • 洒脱喜: 2019-03-26
      请先看懂我写的意思,存档节点一般是浏览器才需要去做的,如果丢失了状态,浏览器就不可完全信任了,这无疑是带来了风险,不要说对安全性无影响,这是自欺欺人的话
    • 洒脱喜: 2019-03-26
      您所说的话是来自以太坊官方说法的翻译,一个全数据和不全数据的账本,安全性当然会有差异,即便以太坊的全节点本身安全性已经足够