最近Meta Transactions一词开始在中文区块链圈流行，但其实这并不是新名词，早在2018年中就由Alex Van de Sande提出的EIP-1077带起讨论，而Austin Thomas Griffith也紧接着提出他的解决方案bouncer-proxy，成了目前许多实作的参考。

那什么是Meta Transactions 呢

让使用者免费使用DApp

其实这是个杀人标题，使用者当然还是可以付费使用DApp，但不可否认目前多数DApp 需要使用者支付Gas 才能使用，已是公认DApp 无法普及的主要原因之一。

使用者付费，听起来很合理，但使用者早已经习惯App Store / Google Play 上众多免费的App，我该怎么跟我爸妈解释他们要Line 之前得先买以太币（于是得办交易所帐号、通过KYC，甚至要装个钱包App、写下注记词…）

教育市场接受Gas是很困难的

开发应用必然要评估市场的接受度，支付Gas 对使用者来说违反直觉，也缺乏动机去了解Gas 的原理，归纳出几个问题：

大多数初心者手中并没有Eth​​er，要想办法购买Ether 就得先申请交易所帐号，并且通过KYC、AML 等繁琐验证 需要拥有区块链、钱包等相关知识，不管是使用MetaMask、冷钱包或是将Ether 保管在交易所，都仍然要具备发送交易、私钥保管等基本观念，甚至需要了解如何计算Gas Limit 跟Gas Price

这成为使用者进入DApp 世界的巨大障碍，许多App 开发者因此不采用以太坊作为基础架构，与其要解决这些问题本身还不如从UX 体验上作改善。

事实上

开发者很愿意为获取用户而支付伺服器成本

大家不都是在AWS 或GCP 上架设服务，一开始免费使用再让使用者付费升级吗

Meta Transactions 就是解法，透过中继的Relayer 来代替使用者上链并支付Gas，绕过了开启钱包支付Gas 的步骤，体验立刻改善。而就算是需要收费的DApp，也可以让使用者透过信用卡或In-App Purchase 消费，不需要使用者拥有加密货币钱包，大幅降低使用门槛。

实现方法

假设我们要开发一款领养猫咪的DApp，使用者要透过专属前端（Web or App）来发送领养的请求，最终在DApp 的合约中记载领养的猫咪，并于前端的UI 呈现。

目前比较成熟的实作方法有三种：

原生：逻辑简单、步骤精简，但仅支援新的合约 代理：需要透过Proxy Contract互动，但现有的DApp皆可使用 Gas Station Network：流程复杂，但解决了许多痛点，受到许多公司或组织的支持，下一篇文章详细介绍

原生Meta Transactions

步骤

Client向Relay Server送出领养一只猫的请求，并用本机端的私钥将资料与指令签名，Relay Server应提供API介面给Client呼叫 Relay Server要求使用者透过信用卡或In-App Purchase 付费，当然也可以选择不收费 Relay Server支付Gas送出交易，由于Relay Server是交易的发起方，但Client才是领养猫的人，为避免合约以为是Relay Server是领养方，需要替换领养地址为Client的地址再上链 Client透过Web3 得知猫咪已经被领养成功，显示在UI 上

原理

每次Client端发起请求时，会用本机端的私钥（可能保存在KeyChain或Browser Cookie）打包上链的资料以及要执行的指令，生成签名给Relay Server验证并取得signer，该签名又被称作Executable signed message （EIP-1077 Gas relay for contract calls）。

在Austin Griffith的Native Meta Transactions范例中，其关键程式码如下：

其中巧妙地将发送者从msg.sender替换成signer，因为msg.sender其实是Relay Server，交易的signer才是真正的使用者，因此购买的资产会转交给使用者而不会交给Relay Server。

听起来解决问题了，但很可惜…

现有的合约无法支援原生Meta Transactions

因为现有的DApp合约通常都是使用msg.sender作为资产接收者，因此必须是全新的合约才能支援原生Meta Transactions，不能相容现有的DApp 。

优缺点

Relay Server 实际上是交易的发起方，在此架构下Relay Server 拥有绝对的权力，若Relay Server 窜改资料，会造成验证失败交易无法执行，使用者拿不到应得的资产，Relay Server 也有可能审查内容后决定拒绝服务。

Relay Server 中必须准备好足够的Ether 做为Gas，若有需要使用者可透过信用卡或In-App Purchase 购买Relay Server 的服务。

代理Meta Transactions

步骤

第一次使用时Client应向Relay Server发起注册装置的请求，Relay Server应提供API介面给Client呼叫 Relay Server会代为向Proxy Contract发送建立新合约或将装置写入合约白名单的交易。这里的Proxy Contract可视作Proxy Identity，运作方式相当于一个握有私钥的使用者，属于使用者的链上ID Client向Relay Server送出领养一只猫的请求，并用本机端的私钥将资料与指令签名，Relay Server应提供API介面给Client呼叫 Relay Server要求使用者透过信用卡或In-App Purchase 付费，当然也可以选择不收费 Relay Server支付Gas发送第一次交易，将Client端给的资料直接转发给Proxy Contract 验证签章正确后上链，虽然Client是原本的领养方，但Proxy Contract才是真正拥有猫的地址 Client透过Web3 得知猫咪已经被领养成功，显示在UI 上

原理

Meta Transactions 在授权执行的合约动作上，会遇到授权（Client）与执行（Relay Server）是不同角色的问题。

原生Meta Transactions 可以在全新的合约中将资产发送给正确的角色，但对于已经部署的合约则需要将相关动作拆解为另一个合约，才能够支援Meta Transactions。

优缺点

与原生Meta Transactions 最大的差别在于支援现有的DApp，但并不能解决Relayer 过于中心化，可能审查内容或是停止服务的问题。

Proxy Contract对应到Client形成一个身份，实际上猫的拥有者是Proxy Contract，因此需要一套可以将Client对应到Proxy Contract的身份验证机制，可以参考bouncer proxy和Universal Login。

结论

以上提到的两种方法，已经可以满足大多数应用替使用者付费或是透过第三方付费的需求，但缺点也是相当明显。

Relayer 的权力集中某些程度上与区块链的核心价值相抵触，若Relay Server 因故无法继续提供服务，也可能造成使用者无法继续使用DApp。

所以这已经是最好的作法了吗

下篇文章透过Gas Station Network（GSN）打造更好的DApp开发与入门体验会详细介绍另一种解决方案Gas Station Network。