最近 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，運作方式相當於一個握有私鑰的使用者，屬於使用者的鏈上 IDClient向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。
感謝 Chang-Wu Chen 與 Yu-Te Lin 協助編輯與校稿