Meta Transactions 如何改變 DApp 付費生態

Image for post

最近 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 的原理,歸納出幾個問題:

  1. 大多數初心者手中並沒有 Ether,要想辦法購買 Ether 就得先申請交易所帳號,並且通過 KYC、AML 等繁瑣驗證
  2. 需要擁有區塊鏈、錢包等相關知識,不管是使用 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 呈現。

目前比較成熟的實作方法有三種:

  1. 原生:邏輯簡單、步驟精簡,但僅支援新的合約
  2. 代理:需要透過 Proxy Contract 互動,但現有的 DApp 皆可使用
  3. Gas Station Network:流程複雜,但解決了許多痛點,受到許多公司或組織的支持,下一篇文章詳細介紹

原生 Meta Transactions

Image for post

步驟

  1. Client 向 Relay Server 送出領養一隻貓的請求,並用本機端的私鑰將資料與指令簽名,Relay Server 應提供 API 介面給 Client 呼叫
  2. Relay Server 要求使用者透過信用卡或 In-App Purchase 付費,當然也可以選擇不收費
  3. Relay Server 支付 Gas 送出交易,由於 Relay Server 是交易的發起方,但 Client 才是領養貓的人,為避免合約以為是 Relay Server 是領養方,需要替換領養地址為 Client 的地址再上鏈
  4. 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 範例 中,其關鍵程式碼如下:

Image for post

其中巧妙地將發送者從 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

Image for post

步驟

  1. 第一次使用時 Client 應向 Relay Server 發起註冊裝置的請求,Relay Server 應提供 API 介面給 Client 呼叫
  2. Relay Server 會代為向 Proxy Contract 發送建立新合約或將裝置寫入合約白名單的交易。這裡的 Proxy Contract 可視作 Proxy Identity,運作方式相當於一個握有私鑰的使用者,屬於使用者的鏈上 ID
  3. Client 向 Relay Server 送出領養一隻貓的請求,並用本機端的私鑰將資料與指令簽名,Relay Server 應提供 API 介面給 Client 呼叫
  4. Relay Server 要求使用者透過信用卡或 In-App Purchase 付費,當然也可以選擇不收費
  5. Relay Server 支付 Gas 發送第一次交易,將 Client 端給的資料直接轉發給 Proxy Contract
  6. 驗證簽章正確後上鏈,雖然 Client 是原本的領養方,但 Proxy Contract 才是真正擁有貓的地址
  7. 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 協助編輯與校稿

本文由 AMIS Hao Chen 提供

原文連結

分享在 facebook
Facebook
分享在 google
Google+
分享在 twitter
Twitter
分享在 linkedin
LinkedIn
分享在 pinterest
Pinterest

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

這個網站採用 Akismet 服務減少垃圾留言。進一步瞭解 Akismet 如何處理網站訪客的留言資料

%d 位部落客按了讚: