Meta Transactions 如何改變 DApp 付費生態 – getamis
假設我們要開發一款領養貓咪的 DApp，使用者要透過專屬前端（Web or App）來發送領養的請求，最終在 DApp 的合約中記載領養的貓咪，並於前端的 UI 呈現。
目前比較成熟的實作方法有三種：
- 原生：邏輯簡單、步驟精簡，但僅支援新的合約
- 代理：需要透過 Proxy Contract 互動，但現有的 DApp 皆可使用
- Gas Station Network：流程複雜，但解決了許多痛點，受到許多公司或組織的支持，下一篇文章詳細介紹
步驟
- 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 的服務。
步驟
- 第一次使用時 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。
Published at Tue, 11 Feb 2020 07:46:24 +0000
{flickr|100|campaign}
