首页 > 矿场 > 以太坊真全节点不足100个?这背后的故事鲜为人知
路安  

以太坊真全节点不足100个?这背后的故事鲜为人知

摘要:星际比特免责声明:本文不构成任何投资建议。小编:记得文章来源: 巴比特资讯关于比特币和以太坊的节点对比,社区最常用的方法,是使用节点统计网站的数据,例如,当前bitnodes.earn.com统计的比特币节点数是10459个,而ethernodes.org统计的以太坊节点数则是8580个。乍看之下,
以太坊真全节点不足100个?这背后的故事鲜为人知

免责声明:本文不构成任何投资建议。

小编:记得

文章来源: 巴比特资讯

以太坊真全节点不足100个?这背后的故事鲜为人知

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

以太坊真全节点不足100个?这背后的故事鲜为人知

(比特币节点数)

以太坊真全节点不足100个?这背后的故事鲜为人知

(以太坊节点统计数)

实则不是这样。

我们首先需要了解的背景是,当前,完整的比特币区块链交易数据大小约为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轻节点的运行是良好的,但当多数全节点出现不诚实行为的情况下,轻节点的安全保障就会变得较弱。例如,尽管在比特币或以太坊网络中的多数非诚实节点,目前只能审查、反转或重排序交易,如果所有的客户端都使用的是轻节点,多数共识将能够相互勾结,产生包含凭空创造货币的交易区块,而轻节点将无法检测到这一点。另一方面,全节点将立即拒绝掉那些无效区块。

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

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

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

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

免责声明
世链财经作为开放的信息发布平台,所有资讯仅代表作者个人观点,与世链财经无关。如文章、图片、音频或视频出现侵权、违规及其他不当言论,请提供相关材料,发送到:2785592653@qq.com。
风险提示:本站所提供的资讯不代表任何投资暗示。投资有风险,入市须谨慎。
世链粉丝群:提供最新热点新闻,空投糖果、红包等福利,微信:juu3644。