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；
Erigon:?v2021.07.04-alpha,?fixPR；
数据：伦敦升级后以太坊网络每小时消耗39.5万美元的 ETH:8月6日消息，伦敦硬分叉于本周四上线，迎来了调整gas费用的EIP-1559升级。该调整的一部分引入了一种机制，该机制会消耗部分收取的基本费用。根据通缉数据显示，自大约14小时前升级上线以来燃烧的ETH总量约为3,395ETH。Etherchain报告的平均燃烧率为每分钟2.36ETH。这相当于每分钟6,596美元，或以当前价格计算，每小时大约395000美元的ETH在隐喻中升值。
Ultrasound.money数器报告称，以目前ETH价格约为2,800美元计算，总共销毁了3,390ETH，价值高达950万美元。NFT市场OpenSea是最热门的ETH燃烧器，自升级启动以来销毁了374个ETH，或略高于100万美元。排在第二位的是Uniswap的第2版，它已经烧掉了263个ETH，即740,000美元。（cointelegraph）[2021/8/6 1:38:25]
Nethermind:?v1.10.79,?fixPR。
以太坊伦敦升级完成后已销毁500枚ETH:8月5日消息，今晚20时33分以太坊伦敦升级完成后，成功引入EIP-1559。据etherchain.org数据显示，截止目前，已经销毁超过500枚ETH。[2021/8/5 1:37:10]
问题区块的信息
网络：Ropsten
区块编号：10679538
哈希值：0x1252a34c4f2b061adc609e909d958c02e1ac39043e2e60c0ec47e565e3f625f1
OpenEthereumdebug日志
eth_getBlock输出(go-ethereum)
Pantera Capital创始人：伦敦升级将帮助以太坊赶超比特币:Pantera Capital创始人，同时也是被誉为加密投资大师的Dan Morehead在周一的路透社全球市场论坛中表示，即将到来的伦敦升级将帮助以太坊赶超比特币，使以太坊更像一种固定资产。“我们将看到人们的转变，他（她）们也将用ETH存储财富，而不仅仅是用比特币。”此外，Dan Morehead还表示，以太坊升级到2.0后将大幅降低挖矿能耗。以太坊DeFi的广泛采用也将使其的规模超越比特币。
尽管Dan Morehead认为以太坊的未来比比特币更光明，但是其对比特币未来的发展也表示乐观。其认为到2021年底，BTC价格能达到8-9万美元，1年后达到12万美元。（Cointelegraph）[2021/8/4 1:33:15]
测试网事故的时间线
。
以太坊JavaScript库Web3.js发布v1.5.0-rc.0，添加支持伦敦升级和EIP-1559支持:以太坊JavaScript库Web3.js发布v1.5.0-rc.0，添加支持伦敦升级和EIP-1559支持。
据悉，以太坊两个最常用JavaScript库是Ethers.js和Web3.js。
此前消息，以太坊JavaScript库Ethers.js发布v5.4.0，添加EIP-1559支持。[2021/7/22 1:09:41]
2021年7月21日
18:39：Ropsten测试网上挖出区块10679537。
21:53：OpenEthereum开发者在EthereumR&Ddiscord的#1559-dev频道发帖称他们的节点卡在了区块10679538处。
以太坊客户端Geth发布伦敦升级版v1.10.5:官方消息，以太坊客户端Geth发布v1.10.5版本，启用了以太坊主网的伦敦硬分叉，包含EIP1559用户体验。
此前消息，以太坊开发者Tim Beiko表示，其“提议伦敦硬分叉于区块高度12965000在主网激活”已合并，预计客户端本周末/下周初发布版本，并在下周初/中发布适当的公告。[2021/7/14 0:51:53]
21:58：@smixx?称他们的在Ropsten节点位于区块10680453。
22:36：Besu确认他们的节点也拒绝了区块10679538。
22:51：确认挖出区块10679538的矿工是go-ethereum节点。
22:55：确认go-ethereum矿工仍继续在区块10679538上面挖矿。
22:56：确认Nethermind也接受了区块10679538。
23:08：go-ethereum已确认问题的根本原因。
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节点收到的区块头中的哈希与白名单中的不符，就会与之断开连接。这就意味着，节点将排斥错误的链上的对等节点，只与较短链上的对等节点连接。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。