概述
2021年 7 月 21 日，OpenEthereum 团队注意到他们在 Ropsten 上的节点卡在了区块 10679538 处。人们原以为这是 OpenEthereum 的问题。其实，问题真正出在 go-ethereum 实现检查 1559 交易发送方余额的方式上。一个无效交易（发送方余额只够支付交易实际使用的 gas，而非交易指定的 maxFeePerGas 总额）被打包进了区块。由于 Ropsten 矿工运行的都是 go-ethereum，这个区块随后又被其它 go-ethereum 矿工接受，但是被网络中的其它一些客户端拒绝了。具体来说，OpenEthereum 和 Besu 拒绝了这个交易/区块，Nethermind、go-ethereum 和 Erigon（这些客户端实现的部分代码来自 go-ethereum 代码）接受了它。问题的根源已经找到，相关客户端已经在新的版本中修复了该问题：
V神发布伦敦升级后链容量增加约9%的三个原因:V神（Vitalik Buterin）发文《链容量为什么在伦敦升级之后增加了约9%？》。V神表示有3个原因：
1. 冰河时代延迟
当伦敦分叉开始时，冰河时代才刚刚开始生效。伦敦之前的平均区块时间约为13.5秒，伦敦之后的平均区块时间回落到其长期正常水平约13.1秒。这是区块速度约3%的差异，这解释了链上gas使用量增加9%中的3%。
2. 目标值1500万与最大1500万
在伦敦升级之前，区块最低gas使用量为1500万，并非所有区块都使用了整个1500万，即使是功能最完善的区块生产者也会留下0-20999未使用的gas，因为剩余空间太少，无法容纳单笔交易，除此之外，总会有偶尔的区块生产者制造空块。4月份的一项分析表明，大约2%的区块是空的。假设在伦敦之前有大约2-3%的未使用空间。然而，在伦敦之后，1500万不是最大值，而是目标值。这意味着，如果使用的平均gas（包括空块）低于1500万，则基本费用将减少，直到平均值回到1500万。所以这又占了大约2-3%。
3. basefee调整中的数学缺陷
EIP1559公式在目标为50%时并不完美。从最近观察到的时间跨度中获取数据，51.5%是完整区块（full block）（因此，比预期的50%高约3%）。[2021/8/15 22:15:37]
go-ethereum: v1.10.6, fix PR；
ETH完成伦敦升级后 当前已销毁35.18个ETH:据ultrasound数据显示，以太坊伦敦升级完成后，截止区块#12,965,095，以太坊网络一共销毁35.18个ETH。
最近10个区块每个区块销毁ETH数量在0.09-0.9之间。[2021/8/5 1:36:53]
Erigon: v2021.07.04-alpha, fix PR；
Nethermind: v1.10.79, fix PR。
问题区块的信息
网络：Ropsten
区块编号：10679538
哈希值：0x1252a34c4f2b061adc609e909d958c02e1ac39043e2e60c0ec47e565e3f625f1
OpenEthereum debug 日志
eth_getBlock 输出 (go-ethereum)
以太坊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 开发者在 Ethereum R&D discord 的 #1559-dev 频道发帖称他们的节点卡在了区块 10679538 处。
Ethermine矿池宣布将在伦敦升级后变更支付政策，100%而不是80%的MEV奖励将转发给矿工:官方消息，Ethermine矿池宣布，在区块高度12,965,000进行伦敦升级后，将变更支付政策：100%而不是80%的MEV奖励将转发给矿工；现在也可以通过IP验证启动手动支付和更改阈值；最低支付门槛将降至0.01 ETH且无每月自动支付；矿工为所有以太坊主网支付交易支付的支付交易费，矿工可以设置他们愿意支付的最高gas价格。[2021/7/19 1:02:57]
21 : 58：/img/202281274105/1.jpg">
另外还要注意的是，在前几行代码（第 207 行）中，sender.balance 被修改成了减去交易量之后的部分（sender.balance -= transaction.amount）。这个参数引发了混乱，因为一些客户端团队在检查第 217 行定义的断言时使用的是全部 sender.balance（即，没有减去transactiion.amount 的发送者地址余额），而非更新后的值。
/img/202281274105/2.jpg">
因此，你需要执行 geth --whitelist 123123=0x2342fafa9af9af9af9af9af9。
所谓的白名单，就是一个 geth 节点在与另一个对等节点连接时会向对方请求区块 123123 的数据。如果该 geth 节点收到的区块头中的哈希与白名单中的不符，就会与之断开连接。这就意味着，节点将排斥错误的链上的对等节点，只与较短（但是正确的）链上的对等节点连接。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。