Solidity 非权威开发指南（4）： OpenGSN
- 胡键
- 更新于 2023-02-07 11:00
- 阅读 1937
OpenZepplin 虽然提供了支持元交易的工具类（metatx 目录下），但并未对元交易场景提供完整的支持，甚至在其 MinimalForwarder.sol 的源代码的注释中都建议采用别的框架。这个框架就是本文主题：OpenGSN。
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 能支持更多场景，简化目标客户使用系统的摩擦，它是一个不错的选择。
相关文章：
