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。
这笔交易在 1 分钟内得到确认......但这笔交易的交易费高达7,676 ETH（约2300 万美元）
https://etherscan.io/tx/0x2c9931793876db33b1a9aad123ad4921dfb9cd5e59dbb78ce78f28717595
为什么发生
EthereumJS库中的潜在问题，再加上在某些情况下和EIP-1559升级相关的gas费用变化，可能导致交易费用极高
又遇上Ledger硬件钱包有时可能以非人类可读的方式显示Gas费用，错失用户肉眼安全检查
只有ETH数量非常大的钱包才会受到影响，其他用户会看到交易失败
DeversiFi做了什么
到UTC+1下午12:30:00，DeversiFi团队意识到这个问题并开始了调查。
很快确定了两个主要关注点，开始积极测试，试图重现和解释错误交易是如何创建的。
与区块链社区分享了一个解释，注意到这个交易https://twitter.com/deversifi/status/1442487743922286594
到UTC + 1时间16:45，禁用Ledger用户存款
到晚上，找到gas费用函数中可能的罪魁祸首，并着手实施改进
增加了额外的安全和健全性检查，以确保与交易相关的gas费用不会超过不切实际的阈值，以防止用户错误、极端网络费用飙升，并作为防止任何未来编码错误的额外保护层
向EthereumJs维护者提交问题，描述了EthereumJs库中的缺陷
最后与Ledger团队就测试期间发现的异常情况进行了沟通，这些异常情况可能会混淆任何以太坊交易的异常高额费用
在28/09/21 15:30 之前推出了安全改进和重开存款
追回资金
不知名矿工在13307440区块打包的巨额Gas费，之后发现此矿工将挖到的ETH存入币安，DeversiFi立刻联系了币安。
币安同意将DeversiFi的电子邮件地址传递给矿工
UTC + 1时间20:36 ，收到矿工的电子邮件，达成安全返还资金的流程
一个小时内，矿工完成退款交易，共退款7626枚ETH
https://etherscan.io/tx/0x85294effd53126b3bfa9e7f655267e00ac1ae2ef76f4569644670bf5403637d6
背景知识
先回顾一下EIP-1559如何改变以太坊交易费用的处理方式。
EIP-1559交易由三部分组成：
基本费用 - 由网络决定并销毁
Max Fee Per Gas - 为获得区块打包而为每单位Gas支付的最大金额
Max Priority Fee - 用户可选的、直接支付给矿工的小费
EIP-1559 交易包括这些新字段，称为类型 2，而提供原始 Gas Price 字段的遗留交易仍受支持，称为类型 0。我们不讨论类型 1 发生了什么。
一个常见的误解是EIP-1559交易完全消除了用户为交易支付过高Gas费的可能性。但在优先费用和最高费用都设置得太高的情况下，无法防止意外多付。
详细调查
DeversiFi是以太坊上用于DeFi的第2层协议，其拥有一个前端，提供一个简单的界面来从各种钱包访问协议，包括Metamask和Ledger。大约一个月前，DeversiFi更新了前端，以利用伦敦硬分叉激活提供的EIP-1559交易，用最新版本的以太坊库并按照文档实现了新功能。
Metamask在生成消息和签名时执行了很多繁重的工作，但是对于Ledger等其他钱包，DeversiFi使用@ethereumjs/tx npm包（https://github.com/ethereumjs/ethereumjs-monorepo）自己生成交易。
具体来说，创建了一个EIP1559交易主体，在与Ledger钱包库接口之前生成消息注入参数和费用，以提示用户在他们的硬件设备上签名。
处理固定精度和扩展数值范围的库在以太坊生态系统中很重要，因为智能合约可以返回高达 256位的数字。JavaScript本身无法处理导致截断或浮点错误的精度。并非所有的大数字库都支持浮点值，不幸的是，ethereumjs库使用了BN (https://github.com/indutny/bn.js/)，而BN也不支持。看起来这有些道理，因为Solidity不直接支持除整数以外的任何内容，但它确实将责任推给了任何集成其库的人，也不使用十进制小数数值。
这是这个过程第一个出现问题的地方，特别是计算gas和优先费用然后转换成一个大数字对象时。由于利用最近几个区块用于预测优先费用，因此计算结果可能是十进制小数型数值（MyCrypto的Tay已经警告一段时间了）
当生成的gas值为整数时，底层的ethereumjs库代码完美运行，但是当gas值为十进制小数数值时变得奇怪。以太坊库代码使用的 BN库抛出一个错误，表明传递了一个无效值，但是由于该值首先被转换为缓冲区，因此没有触发错误处理。
例如，传递值33974230439.550003将得到一个整数35624562649959629，可能比预期高六个数量级。
当这种错误的数字解释发生时，它要么由于优先gas金额高于每个gas的最大费用而失败，要么因为用户在钱包中拥有的ETH数量几乎总是不可能足够高来支付这笔巨额的Gas费超支。
这意味着，除了遇到此问题的少数硬件钱包用户，几乎所有人都不会理解他们的交易失败的原因。
在Ledger上签署交易时，会向用户显示最高费用，以便他们验证将要授权的交易。让事情进一步恶化的因素是，当前Ledger将非常大的费用显示为十六进制值。
在尝试重现该问题时，DeversiFi遇到了如上所示的费用提示。在显示该问题的示例交易中，B526167CF91FECE4 的十六进制值等于 13053145295991336164，这相当于13053145295991.336164 Gwei或 13.05 ETH的天文费用?。
如果此交易被接受（并且钱包中存在用于支付它的资金），用户将签署最高216,564 ETH 的费用。
DeversiFi怀疑区块13307440是否可能就是这种情况，其中已支付的最高费用超过了授权的ETH费用2倍。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。