如果你也像我一样好奇,那就跟随这篇文章,我将向你展示如何在发送交易之前使用ether.js检查交易的有效性。
几个月前,我在试图确认以太坊交易时从Metamask收到了上述错误消息。Metamask当时刚刚添加了这个功能。
显然,我在测试与Uniswap智能合约的交互时,在我的dApp上输入了无效的输入变量。出于好奇,我还是发送了这个交易,看看它是否真的会失败——它确实失败了。
但是,Metamask是如何知道交易将会失败的呢?这个问题在我脑海里徘徊了好一会儿,直到我找到了答案。
如果你也像我一样好奇,那就跟随这篇文章,我将向你展示如何在发送交易之前使用ether.js检查交易的有效性。
区块链交易在默认情况下是不可变的,这意味着没有办法逆转已经被确认的交易。例如,如果将ETH发送到错误的以太坊地址,就没有办法恢复它。除非地址的主人好心地给你退回。
防止这种情况发生的一种方法是,在确认交易前仔细检查地址,或者使用易于读取的ENS名称。但是其他类型的交易(例如铸造NFT)呢?
根据Buycoins Research的Tubbycat NFT销售分析,大约776 ETH(当时约200万美元)花费在失败的交易费用上。这只是整个生态系统因交易失败而损失的一小部分。其中一些交易费用被销毁了,而另一些则归矿工所有。
尽管还有其他因素,比如可能导致未决交易最终失败的前端攻击,但可以通过事先检查其有效性来防止某些交易失败。
不执行交易的状态更改,而是要求节点假装调用没有状态更改并返回结果。
这实际上并不改变任何状态,而且是免费的。在某些情况下,这可用于确定交易是失败还是成功。
让我们考虑这个例子:
爱丽丝想从鲍勃的快餐店订一个汉堡,但必须开车去那里买。鲍勃做的汉堡是全县最好的,而且卖得很快。
如果爱丽丝在汉堡卖完后开车去餐厅,她会浪费时间、精力和汽油。因此,在她去餐厅之前,她需要知道是否还有汉堡。
鲍勃的餐厅有一个网站,他在那里更新销售情况,这样人们就能看到还剩下多少汉堡。如果爱丽丝查看网站,发现汉堡已经卖完了,她就不会浪费资源开车去那里。
否则,她会开车去餐厅吃她最喜欢的汉堡。此场景类似于进行静态调用以检查交易是否可能失败的方式。
在本节中,我们将对Uniswap V3合约进行静态调用,并尝试转移我们不拥有的流动性头寸。
在进入代码之前,请确保已经安装了ethers。如果没有,请使用以下命令安装:
npm install --save ethers
安装成功后,在Etherscan上打开Uniswap合约代码。向下滚动到合约ABI并将其复制到剪贴板。
Uniswap V3 ABI
const { ethers, providers } = require('ethers');
require('dotenv').config()
const abi = require('./abi.json')
const contractAddress = "0xC36442b4a4522E871399CD717aBDD847Ab11FE88"
const signer = new ethers.Wallet(
process.env.PRIVATE_KEY,
providers.getDefaultProvider('mainnet')
);
const contract = new ethers.Contract(contractAddress, abi, signer);
这个示例使用来自ethers的默认提供程序。然而,在创建应用时,请确保在Infura上注册自己的提供商,以提高请求率/限制,并获得呼叫指标。
const from = "0x66fe4806cD41BcD308c9d2f6815AEf6b2e38f9a3"
const to = "0xC41672E349C3F6dAdf8e4031b6D2d3d09De276f9"
const tokenId = 100
from地址既不是代币100的所有者,也不是代币100的批准发送者,因此不能将其转移到另一个地址。但是让我们试着用callStatic方法来传递它,看看结果。
const transaction = async () => {
const a = await contract.callStatic.transferFrom(from, to, tokenId) console.log(a)
}
transaction()
当尝试这样做时,我们应该会得到一个类似于下面的错误。
1 reason: 'ERC721: transfer caller is not owner nor approved', code: 'CALL_EXCEPTION', method: 'transferFrom(address,address,uint256)', errorArgs: [ 'ERC721: transfer caller is not owner nor approved' ], errorName: 'Error', errorSignature: 'Error(string)', address: '0xC36442b4a4522E871399CD717aBDD847Ab11FE88', args: [ '0x66fe4806cD41BcD308c9d2f6815AEf6b2e38f9a3', '0xC41672E349C3F6dAdf8e4031b6D2d3d09De276f9', 100 ], transaction: { data: '0x23b872dd00000000000000000000000066fe4806cd41bcd308c9d2f6815aef6b2e38f9a3000000000000000000000000c41672e349c3f6dadf8e4031b6d2d3d09de276f90000000000000000000000000000000000000000000000000000000000000064', to: '0xC36442b4a4522E871399CD717aBDD847Ab11FE88', from: '0xC41672E349C3F6dAdf8e4031b6D2d3d09De276f9' } }
我们可以看到reason: ‘ERC721: transfer caller is not owner nor approved’(原因:“ERC721:转移调用者既不是所有者也不是批准者”),这是该交易失败的原因。最重要的是,静态调用是一个只读函数,并且是无gas的。
通过在我们的dApp、bot等中集成静态调用,将节省大量的钱,而这些钱本可以用来支付失败的交易的gas费用。
如果已经成功地坚持到现在,那么你一定已经成功地向区块链发送了一个静态调用。
可以查看完整的代码如下:
const { ethers, providers } = require('ethers');
require('dotenv').config()
const abi = require('./abi.json')
const contractAddress = "0xC36442b4a4522E871399CD717aBDD847Ab11FE88"
const signer = new ethers.Wallet(
process.env.PRIVATE_KEY, providers.getDefault
Provider('mainnet'));
);
const contract = new ethers.Contract(contractAddress, abi, signer);
const from = "0x66fe4806cD41BcD308c9d2f6815AEf6b2e38f9a3"
const to = "0xC41672E349C3F6dAdf8e4031b6D2d3d09De276f9"
const tokenId = 100
const transaction = async () => {
const a = await contract.callStatic.transferFrom(from, to, tokenId)
console.log(a)
}
transaction()
ChinaDeFi - ChinaDeFi.com 是一个研究驱动的DeFi创新组织,同时我们也是区块链开发团队。每天从全球超过500个优质信息源的近900篇内容中,寻找思考更具深度、梳理更为系统的内容,以最快的速度同步到中国市场提供决策辅助材料。
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!