普及 ethers.js中的wait 方法的设计语义

[baiwfg2]

针对以下代码，在cursor中问了以下三个问题：

const fundTx = await fundme.fund({value: ethers.parseEther("0.01")})
await fundTx.wait()

Q1

这个wait方法是哪个包里的函数？为何在await fund之后还要调用wait ?

wait() 方法是 ethers.js 库中的一个函数，它用于等待交易被确认（即被打包进区块）。让我解释一下为什么需要它：

1. 当您调用 fund() 或其他发送交易的方法时，会立即返回一个交易对象（Transaction Response），这个对象包含了交易的基本信息，但此时交易还没有被确认。

2. wait() 方法会等待交易被确认，并返回交易收据（Transaction Receipt），这个收据包含了交易的完整信息，包括：

   • 交易是否成功
   • 交易使用的 gas
   • 交易所在的区块号
   • 交易产生的日志（events）
   • 等等

在您的代码中：

await fundMe.fund({value: ethers.parseEther("0.01")})
await helpers.time.increase(200)
await helpers.mine()  

这里不需要显式调用 wait()，因为：

1. fund() 方法本身已经返回了一个 Promise
2. 在测试环境中，helpers.time.increase() 和 helpers.mine() 会自动等待之前的交易被确认

但在部署脚本中：

await fundTx.wait()

这行代码是必要的，因为：

1. 部署脚本需要确保合约部署交易被确认
2. 后续的操作（如调用合约方法）需要等待合约部署完成
3. 在真实网络中，交易确认可能需要一些时间

所以总结一下：

• 在测试环境中，通常不需要显式调用 wait()，因为测试框架会自动处理交易确认
• 在部署脚本或实际应用中，建议使用 wait() 来确保交易被确认，这样可以避免在交易未确认时进行后续操作

Q2

为什么还要写成 await fundTx.wait() ？ wait已经将异步操作同步化了，wait本身为何还要做成异步接口？

这是一个很好的问题！wait() 方法被设计成异步接口是因为：

1. 网络延迟和确认时间：

   • 在区块链上，交易从发送到被确认需要一定时间
   • 在以太坊主网上，一个区块的确认时间大约是 12-15 秒
   • 在测试网络或本地网络，虽然确认时间较短，但仍然需要等待

2. 非阻塞操作：

   • 如果 wait() 是同步的，它会阻塞整个 JavaScript 执行线程
   • 这意味着在等待交易确认期间，程序无法执行其他操作
   • 通过使用异步接口，程序可以在等待期间继续执行其他任务

3. 实际工作流程：

// 发送交易
const fundTx = await fundMe.fund({value: ethers.parseEther("0.01")})
// 此时可以执行其他操作，比如更新UI或准备下一个操作
console.log("Transaction sent:", fundTx.hash)

// 等待交易确认
const receipt = await fundTx.wait()
// 交易确认后继续执行
console.log("Transaction confirmed in block:", receipt.blockNumber)

4. 错误处理：
   • 异步接口允许使用 try/catch 来处理交易失败的情况
   • 如果交易失败（比如 gas 不足），wait() 会抛出异常

try {
    const receipt = await fundTx.wait()
    console.log("Transaction successful")
} catch (error) {
    console.log("Transaction failed:", error)
}

所以，虽然 wait() 确实是在等待一个操作完成，但它被设计成异步接口是为了：

• 不阻塞主线程
• 允许在等待期间执行其他操作
• 提供更好的错误处理机制
• 符合 JavaScript 的异步编程模式

这就是为什么即使是在等待一个操作完成，wait() 仍然被设计成异步接口的原因。

Q3

语义有些奇怪，本来就是要等待交易完全确认，接口本身天生具备阻塞性，但又想在等待期间做其他事。除非在真正的生产环境的源码里，有这种“不想等待wait操作完成”的需求

您说得对！这确实是一个设计上的矛盾点。让我分析一下：

1. 接口设计的矛盾：

   • wait() 的语义就是"等待交易确认"
   • 如果调用者真的想等待，那么同步接口更符合语义
   • 如果调用者不想等待，那就不应该调用 wait()

2. 实际使用场景：

   • 在测试代码中，我们几乎总是需要等待交易确认
   • 在部署脚本中，我们也需要等待部署完成
   • 在大多数业务逻辑中，我们也需要等待交易确认

3. 可能的改进设计：

// 方案1：提供两个接口
const tx = await fundMe.fund({value: ethers.parseEther("0.01")})
// 如果确实需要等待
tx.waitSync()  // 同步等待
// 如果不需要等待
tx.getHash()   // 只获取交易哈希

// 方案2：提供选项参数
const receipt = await tx.wait({ async: false })  // 同步等待
const receipt = await tx.wait({ async: true })   // 异步等待

4. 为什么保持现状：
   • 保持与 Web3.js 等其他库的一致性
   • 遵循 JavaScript 的 Promise 模式
   • 避免在同步等待时阻塞主线程（特别是在浏览器环境中）

您说得对，这个设计确实有些奇怪。在大多数情况下，我们调用 wait() 就是想要等待交易确认，同步接口会更符合语义。但考虑到 JavaScript 的单线程特性和 Promise 的广泛使用，异步接口可能是为了保持一致性而做出的妥协。

这让我想到一个有趣的问题：如果 wait() 是同步的，那么在等待期间，JavaScript 引擎确实无法执行其他代码，但这是否真的是一个问题？因为：

1. 在测试环境中，我们就是要等待交易确认
2. 在部署脚本中，我们也要等待部署完成
3. 在大多数业务逻辑中，我们也需要等待交易确认

所以，除非有特殊的场景（比如在等待期间需要更新 UI 或执行其他操作），否则同步接口可能更符合实际使用需求。