伦敦升级 Ropsten 测试网事故回顾_ETHE:ETHMAXY币

Ropsten共识问题

概述

2021年7月21日,OpenEthereum团队注意到他们在Ropsten上的节点卡在了区块?10679538?处。人们原以为这是OpenEthereum的问题。其实,问题真正出在go-ethereum实现检查1559交易发送方余额的方式上。一个无效交易被打包进了区块。由于Ropsten矿工运行的都是go-ethereum,这个区块随后又被其它go-ethereum矿工接受,但是被网络中的其它一些客户端拒绝了。具体来说,OpenEthereum和Besu拒绝了这个交易/区块,Nethermind、go-ethereum和Erigon接受了它。问题的根源已经找到,相关客户端已经在新的版本中修复了该问题:

go-ethereum:?v1.10.6,?fixPR;

以太坊客户端Besu发布v21.7.0,添加支持伦敦升级:官方消息,以太坊客户端Besu发布v21.7.0,添加支持伦敦升级。其它功能包括新的共识协议QBFT,使用Tessera的GoQuorum兼容隐私。[2021/7/20 1:05:12]

Erigon:?v2021.07.04-alpha,?fixPR;

Nethermind:?v1.10.79,?fixPR。

问题区块的信息

网络:Ropsten

区块编号:10679538

哈希值:0x1252a34c4f2b061adc609e909d958c02e1ac39043e2e60c0ec47e565e3f625f1

OpenEthereumdebug日志

以太坊客户端OpenEthereum新版本加入主网伦敦升级区块高度:以太坊客户端OpenEthereum发布OpenEthereumv3.3.0-rc.4版本,将主网的伦敦硬分叉升级的区块高度(12965000)写入,也就是8月4日左右。[2021/7/15 0:53:30]

eth_getBlock输出(go-ethereum)

测试网事故的时间线

2021年7月21日

18:39:Ropsten测试网上挖出区块10679537。

21:53:OpenEthereum开发者在EthereumR&Ddiscord的#1559-dev频道发帖称他们的节点卡在了区块10679538处。

以太坊测试网Rinkeby已于区块高度8897988处激活伦敦升级:以太坊测试网Rinkeby已于7月8日01:27:32在区块高度8897988处激活伦敦升级。本次升级包括了改变以太坊1.0Gas费用市场的的EIP-1559以及将难度炸弹推迟至2021年12月1日等更新,测试网Rinkeby激活伦敦升级的下一步将是在以太坊主网部署伦敦升级,主网升级的最终时间将在7月9日举行的以太坊核心开发人员会议上宣布。[2021/7/8 0:35:40]

21:58:@smixx?称他们的在Ropsten节点位于区块10680453。

22:36:Besu确认他们的节点也拒绝了区块10679538。

22:51:确认挖出区块10679538的矿工是go-ethereum节点。

以太坊伦敦升级在测试网上启动 一天内在Eth2上质押了10万以太坊:根据EIP-1559跟踪网站WatchtheBurn,自伦敦部署以来的一天内,Ropsten上已经烧毁了大约88,500个测试网ETH,名义价值1.776亿美元。加密数据聚合器CryptoQuant发现,大约在Eth2推出的同时,100,000以太币已存入Eth2的Staking合约,价值约2亿美元。CryptoQuant还指出,目前超过5%的ETH供应被锁定在价值约117.5亿美元的质押中。[2021/6/25 0:05:41]

22:55:确认go-ethereum矿工仍继续在区块10679538上面挖矿。

22:56:确认Nethermind也接受了区块10679538。

23:08:go-ethereum已确认问题的根本原因。

以太坊Ropsten测试网将首先激活伦敦升级:金色财经报道,以太坊开发者Tim Beiko今日发文宣布,以太坊伦敦升级现已准备好在测试网上部署。升级将首先在Ropsten测试网的区块10499401激活,预计将于2021年6月24日左右进行;Goerli测试网将在区块5062605激活升级,预计时间为6月30日;Rinkeby测试网将在区块8897988激活,预计时间为7月7日。Kovan测试网将在稍后升级,预计在主网区块通过之后。Tim Beiko还表示,截止目前,只有测试网(Ropsten、Goerli、Rinkeby)已安排了伦敦升级。在这些网络上成功激活升级后,将为以太坊主网设置一个升级区块。[2021/6/19 23:48:59]

23:43:go-ethereum开启?pull?request,提供候选修复方案。

23:46:Erigon开启pull?request,提供候选修复方案。

2021年7月22日

00:01:更新后的go-ethereum和Besu矿工在Ropsten上重启。

00:43:EthereumJS确认与go-ethereum、Erigon和Nethermind存在同样的问题。

01:57:Nethermind开启pull?request,提供候选修复方案。

10:22:修复后的版本挖出了区块?10680804。

22:54:go-ethereum发布了修复后版本?v1.10.6。

~23:00:Nethermind发布了修复后版本?v1.10.79。

2021年7月23日

~00:00:Erigon发布了修复后版本?v2021.07.04-alpha。

纠正措施建议

提高规范中断言的清晰度

该提交新增了关于EIP1559类型交易有效性的断言。具体来说,在第217行代码新增了以下断言:

另外还要注意的是,在前几行代码中,sender.balance?被修改成了减去交易量之后的部分。这个参数引发了混乱,因为一些客户端团队在检查第217行定义的断言时使用的是全部?sender.balance,而非更新后的值。

Go-Ethereum恢复

@holiman?关于go-ethereum恢复的说明:

节点同步时跟随错误的链

假设你正在运行?geth,并处于同步中。区块?X?上发生了分叉。你的节点跟随了总难度较高的错误的链。在区块?Z,你停止了节点并将其更新至修复后版本。

问题描述:节点依然在“错误”的链上。

解决方案:执行?debug.setHead{X-1)?回到分叉发生之前。这会将节点倒回区块?X?之前的某个状态,不一定是区块?X-1?的状态,因为?geth?不一定有区块?X-1?的完整状态,但是会有其它某个区块的完整状态。通常情况下,geth大约每隔1万个区块和/或宕机时会将状态刷到磁盘。如果geth在?gcmode=archive?下运行,就会将每个区块都刷到磁盘。

当错误的链总难度较高时进行同步

假设你正在同步一个?geth?节点,区块?X?上发生了分叉。由于分叉已经发生了,再加上错误的链总难度更高,你很可能会同步错误的链,pivot区块是?X+M。在这种情况下,由于你没有区块?X+M?之前的状态,无法执行?debug.setHead?来解决这个问题。

这种情况需要重新同步。但是,你需要防止geth同步错误的那条分叉链。这可以通过?whitelist?命令行参数实现。

因此,你需要执行?geth--whitelist123123=0x2342fafa9af9af9af9af9af9。

所谓的白名单,就是一个geth节点在与另一个对等节点连接时会向对方请求区块?123123?的数据。如果该geth节点收到的区块头中的哈希与白名单中的不符,就会与之断开连接。这就意味着,节点将排斥错误的链上的对等节点,只与较短链上的对等节点连接。

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

金智博客

[0:15ms0-6:588ms