使用 Ethers.js 向智能合约发送静态调用

几个月前，我在试图确认以太坊交易时从Metamask收到了上述错误消息。Metamask当时刚刚添加了这个功能。

显然，我在测试与Uniswap智能合约的交互时，在我的dApp上输入了无效的输入变量。出于好奇，我还是发送了这个交易，看看它是否真的会失败——是的，它确实失败了。

但是，Metamask是如何知道交易将会失败的呢?这个问题在我脑海里徘徊了好一会儿，直到我找到了答案。

如果你也像我一样好奇，那就跟随这篇文章，我将向你展示如何在发送交易之前使用ether.js检查交易的有效性。

区块链交易

区块链交易在默认情况下是不可变的，这意味着没有办法逆转已经被确认的交易。例如，如果将ETH发送到错误的以太坊地址，就没有办法恢复它。除非地址的主人好心地给你退回。

防止这种情况发生的一种方法是，在确认交易前仔细检查地址，或者使用易于读取的ENS名称。但是其他类型的交易(例如铸造NFT）呢?

根据Buycoins Research的Tubbycat NFT销售分析，大约776 ETH(当时约200万美元)花费在失败的交易费用上。这只是整个生态系统因交易失败而损失的一小部分。其中一些交易费用被销毁了，而另一些则归矿工所有。

尽管还有其他因素，比如可能导致未决交易最终失败的前端攻击，但可以通过事先检查其有效性来防止某些交易失败。

静态调用

不执行交易的状态更改，而是要求节点假装调用没有状态更改并返回结果。

这实际上并不改变任何状态，而且是免费的。在某些情况下，这可用于确定交易是失败还是成功。

让我们考虑这个例子:

爱丽丝想从鲍勃的快餐店订一个汉堡，但必须开车去那里买。鲍勃做的汉堡是全县最好的，而且卖得很快。

如果爱丽丝在汉堡卖完后开车去餐厅，她会浪费时间、精力和汽油。因此，在她去餐厅之前，她需要知道是否还有汉堡。

鲍勃的餐厅有一个网站，他在那里更新销售情况，这样人们就能看到还剩下多少汉堡。如果爱丽丝查看网站，发现汉堡已经卖完了，她就不会浪费资源开车去那里。

否则，她会开车去餐厅吃她最喜欢的汉堡。此场景类似于进行静态调用以检查交易是否可能失败的方式。

使用NodeJS进行静态调用

在本节中，我们将对Uniswap V3合约进行静态调用，并尝试转移我们不拥有的流动性头寸。

在进入代码之前，请确保已经安装了ethers。如果没有，请使用以下命令安装：

npm install --save ethers

安装成功后，在Etherscan上打开Uniswap合约代码。向下滚动到合约ABI并将其复制到剪贴板。

​ Uniswap V3 ABI

• 创建一个abi.json文件，并将ABI粘贴到其中。
• 接下来，创建一个用于进行静态调用的新文件。
• 将ether库和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()

当尝试这样做时，我们应该会得到一个类似于下面的错误。

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.getDefaultProvider('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()

Source：https://medium.com/better-programming/sending-static-calls-to-a-smart-contract-with-ethers-js-e2b4ceccc9ab

关于

ChinaDeFi - ChinaDeFi.com 是一个研究驱动的DeFi创新组织，同时我们也是区块链开发团队。每天从全球超过500个优质信息源的近900篇内容中，寻找思考更具深度、梳理更为系统的内容，以最快的速度同步到中国市场提供决策辅助材料。

Layer 2道友 - 欢迎对Layer 2感兴趣的区块链技术爱好者、研究分析人与Gavin（微信: chinadefi）联系，共同探讨Layer 2带来的落地机遇。敬请关注我们的微信公众号 “去中心化金融社区”。