一文读懂7676枚 ETH 巨额矿工费惊情

9月27日，据Etherscan报道，Bitfinex交易所主要钱包以7676.62ETH的Gas资费转账10万美元USDT，最终受益人为2019年从Bitfinex分拆的非托管交易所DeversiFi。 这笔巨额的矿工费随后被不知名的矿工转移到货币贬值交易所。

9月28日，事情获得了圆满的结局。 经过Bitfinex与币安以及矿工的谈判，根据以太坊13307440，矿工归还了因昨晚错误操作Bitfinex钱包而支付的7626ETH Gas费用，DeversiFi感谢矿工50 ETH

9月29日，DeversiFi公布了该事件的完整报告。

事件回顾

发生了什么事

UTC 1小时11.10.08 AM，用户向DeversiFi存入10万USDT。

这笔交易在一分钟内得到确认……但是这笔交易的交易费达到了7，676 ETH (约2300万美元)。

359以太网. io/tx/0x2c 9931793876 DB 33 B1 A9 AAD 123 AD 4921 DFB 9C D5 E 59 DBB 78 CE 78 f 28717595

为什么会发生

除了EthereumJS库的潜在问题外，在某些情况下，与EIP-1559升级相关的gas费用的变化可能会导致交易费用非常高

另外，如果遇到Ledger硬件钱包，Gas费用会以非人能够读取的方式显示，有时会错过用户肉眼的安全检查

只有ETH数量非常多的钱包会受到影响，其他用户会看到交易失败

德沃夫I做了什么

在UTC 1下午12:30:00之前，DeversiFi团队注意到了这个问题并开始了调查。

为了立刻找出两个主要的兴趣点，再现并说明错误交易是如何产生的，我们开始了积极的测试。

与区块链社区共享了说明。 注意到这笔交易为https://推特.com /开发商sifi/status/14424874392286594

禁用总帐用户的存款，直至UTC 1小时16:45

到了晚上，在gas费用函数中找出可能的主谋，着手改善

增加了额外的安全性和运行状况检查，以确保与交易相关的gas费用不超过不切实际的阈值，从而作为防止用户错误、极端网络费用高涨和未来编码错误的附加保护层

向EthereumJs维护提出了问题，说明了EthereumJs库的缺陷

最后，我们就测试中发现的异常与Ledger团队进行了联系。 这些异常可能会混淆以太坊交易异常高昂的费用

28/09/21发布了15:30之前改善安全和重新开始存款的消息

回收资金

不知名矿工在13307440块打包的巨额Gas费用。 后来发现这个矿工把挖的ETH交给投币机保管，DeversiFi马上联系了投币机。

货币贬值同意将DeversiFi的电子邮件地址交给矿工

UTC 1小时20:36，完成接收矿工电子邮件，安全归还资金的程序；

一小时内矿工完成了退款交易，共退还了7626张ETH

359以太网. io/tx/0x 85294 EFFD 53126 B3 BFA 9e7f 655267 e 00 AE2EF 76f 456964670 BF 5403637 D 6

DeversiFi留给矿工50 ETH作为感谢费

到底发生了什么

背景知识

首先让我们回顾一下EIP-1559如何改变以太坊交易费用的处理方式。

EIP-1559交易由三部分组成。

基本费用由网络决定并销毁

maxfeepergas每单位gas支付的最大金额，用于检索块包

maxpriorityfee直接支付给矿工的芯片(可选)

虽然EIP-1559事务包含这些称为类型2的新字段，但是提供原始gas价格字段的传统事务得到了称为类型0的支持。 我们不讨论类型1发生了什么。

一个常见的误解是，EIP-1559交易完全消除了用户为交易支付过高的Gas费用的可能性。 但是，如果优先费用和最高费用定得太高，则无法防止意外多付。

详细调查

DeversiFi是以太网上DeFi的第2层协议，具有前端，提供了从元马克和雷德格等各种钱包访问协议的简单接口。 大约一个月前，DeversiFi更新了前端，以启用利用伦敦硬叉提供的EIP-1559交易，并使用最新版本的以太坊按照文档实现了新功能。

Metamask在生成消息和签名时执行了很多繁重的工作，但在其他钱包(如Ledger )中，DeversiFi支持@ethereumjs/tx npm包(https://Github.com/ethereree

具体来说，创建EIP1559交易主体，与Ledger钱包库接口之间生成消息注入参数和费用，督促用户在硬件设备上签名。

由于智能合约最多可以返回256位数字，因此处理固定精度和扩展数值范围的库在以太坊生态系统中非常重要。 JavaScript本身无法处理导致截断和浮点错误的精度。 并非所有的数据库都支持浮点值。 不幸的是，ethereumjs库正在使用bn (https://Github.com/Indu TNY/BN.JS/)，BN也不支持。 这似乎是有道理的，因为索尔斯克亚不直接支持整数以外的东西，但它将责任推给所有整合库的人，而不使用十进制小数的数值。

这是此过程中的第一个问题，特别是在计算gas和优先级费用并将其转换为大型数字对象时。 由于最近的几个区块用于优先费用预测，因此计算结果可能是十进制小数类型的数值。 (MyCrypto的Tay已经警告过一段时间了。 ）

如果生成的gas值是整数，则基础ethereumjs库代码可以完美地工作，但如果gas值是十进制小数，则很奇怪。 以太库代码中使用的BN库会抛出错误，指示传递了无效值，但不会触发错误处理，因为它首先转换为缓冲区。

例如，如果传递值33974230439.550003，则会得到整数35624562649959629，可能比预期高6位数。

发生这种错误的数字解释时，那是因为gas的金额优先于每个gas的最大费用而失败，或者用户钱包里的ETH数量不足以支付这笔巨额的gas费用超支。

这意味着除了少数面临这个问题的硬件钱包用户外，大部分人都不了解交易失败的原因。

在Ledger中签署交易后，会向用户显示最高的费用，以验证要批准的交易。 使事情更加恶化的主要原因是，当前的Ledger将非常大的费用表示为十六进制值。

在试图再现这个问题时，DeversiFi遇到了上述费用的提示。 在显示这个问题的示例交易中，B526167CF91FECE4的十六进制值为13053145295991336164，相当于13053145295991.336164 Gwei或13.05 ETH的天文费用。

如果这笔交易被接受，并且钱包里有资金支付它，用户将签署最高216，564 ETH的费用。

DeversiFi怀疑块13307440是否有可能是这种情况。 其中，已支付的最高费用超过了许可的ETH费用的两倍。