OpenZepplin 虽然提供了支持元交易的工具类（metatx 目录下），但并未对元交易场景提供完整的支持，甚至在其 MinimalForwarder.sol 的源代码的注释中都建议采用别的框架。这个框架就是本文主题：OpenGSN。

OpenGSN 是元交易规范 ERC2771 的参考实现，它要解决的核心问题就是：如何让以太坊的用户在不交 gas fee 的前提下完成交易。也就是其官网的宣传语：“ETHless transactions made possible.”。

元交易

一个简单的类比：元交易提供了一种代付服务。其中涉及三方：交易发起方、元交易服务和交易执行方。

• 在元交易服务和交易执行方之间，依旧遵循以太坊的规则：凡交易必有 gas fee。
• 在交易发起方和元交易服务之间，如何结算和支付由元交易服务支付的 gas fee 则具体情况具体分析，但有一点可以肯定：绝对不是 gas fee 形式。

基本架构

它的实现机制可从其官网的架构图了解：

关键组件:

• Client：发送和签名交易，接收方为 relay server。注意，它俩之间一定不是通过 contract 完成交互，通常是通过 http 实现。为简化编程，OpenGSN 提供了 provider 包。
• Relay Server：交易转发和支付 gas fee。
• Paymaster：实现支付逻辑。
• Forwarder：验证元交易的签名，将交易转发到实际的接收者。
• Recipient Contract：执行实际交易，必须继承 ERC2771Recipient。
• RelayHub：整体流程的协调者。

整个交互过程如下图：

实现步骤

Contract

有两个关键 contract 需要实现：

• recipient，使 contract 支持 ERC2771：继承 ERC2771Recipient 。
  • 主要功能是确定实际的交易发起人，而不是简单地只看 msg.sender。
• paymaster，实现支付逻辑： 继承 BasePaymaster，覆盖：
  • _preRelayedCall，交易前逻辑，实现是否愿意为此交易支付。
  • _postRelayedCall，交易后逻辑，完成退款逻辑。

注意，上面的 recipient 不必是全新的合约，它也可以是现有合约。ERC2771Recipient 的一个特点就是：它会自动判断 recipient 接收到的交易：到底是来自直接调用，还是从 relay service 发起。这样，使得 recipent 可以无缝应用于两种场景：支付和代付 gas fee。

在部署时，需在 recipient 构造函数中设置可信的 forwarder。

同时，OpenGSN 提供了现有的 paymaster，在决定自行实现之前，先查看是否有满足需要的现成合约。

Client

在 dapp 中引入：@opengsn/provider。然后在其中设置：web3 provder 和 paymaster 地址。也可以设置 relay server ，但这是可选的。

整个集成过程可以查看 OpenGSN 文档的这个教程。

Relay Server

通常情况下，使用现成的 Relay Server 就行了，但对于特殊需要、想自立门户的，可以选择自建。这一点跟 WalletConnect 的 bridge server 类似。

其过程可以从此文档查看。

结语

本文对元交易框架 OpenGSN 提供了一个简要的整体介绍，目标是帮助开发者快速建立整体概念，降低上手的障碍。但要真正实际使用，还需自行阅读文档和研究代码。

与 OpenZepplin 的性质不同，OpenGSN 框架对于一般的合约编写并非必不可少，但假若你打算使你的 contract 能支持更多场景，简化目标客户使用系统的摩擦，它是一个不错的选择。