拆解以太坊状态(State)问题:一个鲜为人知的严重威胁_比特币:Ethereal直译

以太坊基金会今日发文披露了一个2019年首次发现的安全漏洞,在上个月的柏林升级之前,该漏洞的严重程度为发生攻击时可能使主网瘫痪。该漏洞的本质是触发随机Trie查询,以太坊开发人员曾试图用EIP-1884、EIP-2583、EIP-2929、以及快照功能来抵御该漏洞,最终在柏林升级之后该漏洞危险性降低。通过此博客文章,目的是正式披露以太坊平台所面临的一个严重威胁。在以太坊柏林硬分叉之前,这个威胁是切实存在的。

状态

让我们从以太坊和状态的背景知识开始。

以太坊状态由一种patricia-merkletrie组成。这篇文章将不做过多的详细介绍,随着状态的增长,这个树上的树枝变得越来越密。添加的每个帐户都是一片叶子。在树的根和叶本身之间,有许多“中间”节点。

为了在这棵巨大的树中查找给定的帐户或“叶子”,需要从根到中间节点来解析大约6-9个哈希的某个位置,以最终解析最后一个哈希hash,该哈希会指向我们正在寻找的数据。

简而言之:每执行一次Trie查找来查找帐户,就会执行8-9个解析操作。每个解析操作都是一次数据库查找,并且每词数据库查找可以是任意数量的真实磁盘操作。磁盘操作的次数很难估计,但是由于trie密钥是加密哈希,因此密钥是“随机的”,这对任何数据库来说都是最糟糕的情况。

随着以太坊的增长,有必要提高访问trie的操作的gas价格。这是在2016年10月区块高度2,463,000的TangerineWhistle中执行的,其中包括EIP150。EIP150在所谓的“上海攻击”之后大幅提高了某些操作的gas成本,并进行了一系列更改以防止DoS攻击。

另一项gas提升同样在伊斯坦布尔升级中被执行,即2019年12月区块高度9,069,000。在这次升级中,EIP1884被激活。

EIP1884引入了以下操作成本更改:

SLOAD从200提升到800gas,

BALANCE从400提升到700gas,

EXTCODEHASH从400提升到700gas。

问题

2019年3月,MartinSwende对EVM操作码性能进行了一些测量。这次调查之后促成创建了EIP-1884。在EIP-1884上线之前的几个月,《BrokenMeter》论文正式发表。

两位以太坊安全研究人员与该论文的一位作者DanielPerez合作“武器化”了一个漏洞,他们将漏洞提交给了以太坊赏金计划。这是在2019年10月4日。

我们建议您完整阅读那次提交的内容,这是一份精心撰写的报告。

在专门用于讨论跨客户端安全性的频道上,当天,来自Geth,Parity和Aleth的开发人员被告知了有关提交的信息。

该漏洞的本质是触发随机trie查询。一个非常简单的变体是:

在他们的报告中,研究人员通过eth_call对同步到主网的节点执行了此有效负载,这些是在使用10Mgas时执行的数量:

使用EXTCODEHASH?发动10Mgas攻击

Parity:?~90s

Geth:?~70s

使用EXTCODESIZE?发动10Mgas攻击

Parity:?~50s

Geth:?~38s

显而易见,EIP1884引入的更改确实在降低攻击方面产生了影响,但远远不够。

在大阪Devcon大会之前确实如此。在Devcon期间,主网客户端开发人员之间共享了该问题的知识。我们还与Hubert和Mathias以及GregMarkou进行了会面。ETC开发人员也收到了这份报告。

随着2019年临近尾声,我们知道我们遇到的问题比我们之前预期的要大,恶意交易可能导致区块时间间隔增加到分钟级。更糟的是,开发人员已经对EIP-1884感到不满意,因为EIP-1884中断了某些合约程序,而用户和矿工们都为提高gas限制而着急。

此外,仅两个月后的2019年12月,ParityEthereum宣布退出以太坊工作,而OpenEthereum接管了代码库的维护工作。

之后一个新的客户端协调频道被创建,在该频道中,Geth,Nethermind,OpenEthereum和Besu开发人员继续进行协调。

解决方案

我们意识到,我们必须采取两种方法来解决这些问题。一种方法是使用以太坊协议,并以某种方式在协议层解决该问题。最好不要违反合约,最好不要惩罚“良好”行为,但仍要设法防止攻击。

第二种方法是通过软件工程,通过更改客户端中的数据模型和结构。

协议层工作

如何处理这些类型的攻击的第一个迭代升级可以在这里查看。2020年2月,该解决方案以EIP2583的形式正式发布。其背后的想法是,每当一次Trie查找导致遗漏时,简单地增加一个罚款。

但是,Peter为这个想法找到了一种解决方法——“屏蔽中继”攻击——将这种惩罚的有效范围设定一个上限。

对于miss所导致的罚款的问题在于,首先需要进行查找,以确定必须施加罚款。但是,如果剩余的gas不足以进行罚款,则表明已执行了未付费用。即使确实导致抛出异常,也可以将这些状态读取包装到嵌套调用中。允许外部调用者继续重复攻击而无需支付罚款。

因此,这个EIP被弃置,而我们正在寻找更好的替代方案。

阿列克谢·阿克胡诺夫探索了Oil的概念,它是“gas”的第二种来源,但与gas本质上不同,因为执行层看不到它,并可能导致交易全局还原。

Martin在2020年5月提出了一个类似提案,关于Karma的。

在迭代这些计划时,VitalikButerin建议仅增加gas成本,并维持访问名单。2020年8月,Martin和Vitalik开始迭代,也就是后来的EIP-2929及EIP-2930。

EIP-2929有效地解决了许多以前的问题。

与EIP-1884相反,它仅针对尚未访问的内容增加成本。这导致净成本仅增加了不足百分之一。

此外,它与EIP-2930一样,不会破坏任何合约流

而且,可以通过提高gas成本来进一步调整它。

2021年4月15日,它们都随着柏林升级而上线。

开发工作

2019年10月,Peter尝试解决此问题的方法是进行动态状态快照。

快照是一种二级数据结构,用于以平面格式存储以太坊状态,在Geth节点的实时运行期间,可以完全在线构建。

照的好处在于,它充当状态访问的一种加速结构:

快照无需提供O磁盘读取来访问帐户/存储插槽,而是可以提供直接的O访问时间。

快照支持每项条目O复杂度的帐户和存储迭代,这使远程节点可以比以前便宜得多地检索顺序状态数据。

快照的存在还实现了更多奇特的用例,例如离线修剪状态Trie或迁移到其他数据格式。

快照的缺点是原始帐户和存储数据实际上是重复的。对于主网,这意味着要使用额外的25GBSSD空间。

动态快照的想法已经在2019年中期开始,主要目的是成为snap同步的推动者。当时,Geth团队正在开展许多“大项目”。

离线状态修剪

动态快照snap同步

通过分片状态进行的LES状态分布

但是,最后决定完全优先考虑快照,暂时将其他项目推迟。这些奠定了后来成为snap/1同步算法的基础。于2020年3月合并到主网。

随着“动态快照”功能的发布,我们有了一些喘息的空间。如果以太坊网络受到攻击,那将是痛苦的,是的,但是至少有可能通知用户有关启用快照的信息。整个快照生成将花费大量时间,并且尚无法同步快照,但是网络至少可以继续运行。

在2021年3月至4月,snap/1协议在geth中推出,从而可以使用基于快照的新算法进行同步。尽管仍然不是默认的同步模式,但这是使快照不仅可用作攻击防护,而且对于用户来说是一项重大改进。

在协议方面,柏林升级在2021年4月正式执行。

以下是在我们的AWS监控环境中制定的一些基准测试:

柏林升级前,无快照,25Mgas:14.3s

柏林升级前,有快照,25Mgas:1.5s

柏林升级后,无快照,25Mgas:~3.1s

柏林升级后,有快照,25Mgas:~0.3s

数字表示,柏林升级将攻击的效率降低了5倍,快照将攻击的效率降低了10倍,总共将攻击影响降低了50倍。

我们估计,目前在主网上,在没有快照的情况下,创建区块可能需要2.5-3s在一个geth节点上执行。随着状态的增长,该数字将继续恶化。

如果使用refund来增加一个区块内的有效gas使用量,则可以进一步提高2x倍。使用EIP1559,区块gas限制将具有更高的弹性,并允许在临时爆发中再增加2倍。

至于实施这种攻击的可行性;攻击者购买一个完整的区块所需的成本约为几个ETH。

为什么现在披露这个威胁?

长期以来,这种威胁一直是“公开秘密”,实际上至少有一次被无意间地公开披露,并且在ACD电话会议中多次被提及,但没有明确的细节。

由于柏林升级现在已经过去,并且默认情况下,geth节点正在使用快照,因此我们估计这个威胁的危险程度非常低,可以公开了,现在该对此前的开发者幕后工作进行全面披露。

至关重要的是,社区必须有机会了解对用户体验产生负面影响的变更背后的原因,例如增加gas成本和限制refund。

这篇文章是由马丁·霍尔斯特·斯文德和彼得·西拉吉2021-04-23撰写的。在2021-04-26与其他基于以太坊的项目共享,并在2021-05-18公开披露。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金宝趣谈

火币下载暴跌风暴后 反思币圈金融行为_DAO:KEN

近日币圈的爆炸性新闻不断,昨日全盘更是出现史诗级暴跌,但是人们对去中心化投资热情依旧,传统金融组织开始接受虚拟世界的一些组织模式和金融工具,大亨们也意图参与到去中心化投资的浪潮中.

[0:0ms0-6:37ms