最近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 的原理，归纳出几个问题：
- 大多数初心者手中并没有Ether，要想办法购买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。
本文链接地址：https://www.wwsww.cn/qkl/5982.html
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
