通過比較發現 IPFS 是短期方案,ICP 更有利於長期的佈局,並且更有利於實現前端自身商業變現。

原文標題:《兩方案看 Dapp 如何應對前端託管的風險》
撰文:Yolo
來源:大腦桿菌

我們都知道常見的 DeFi 應用一般都採用三層架構,前端-中間件-後端(智能合約),而這個三層架構當中只有後端是部署在區塊鏈上,一經部署不可更改。而前端和中間件都是部署在中心化的服務器上,這也意味着前端和中間件這些衍生的結構容易受到攻擊和作惡。

簡介:常見 DeFi 的架構

DeFi 如何應對前端託管風險?瞭解 ICP 與 IPFS 託管方案

當我們使用 DeFi 應用的時候,各個環節是如何協作的呢?圖上所示的是一個正常網絡環境下的調用。當我們輸入{website}的時候,用戶的遊覽器會訪問 DNS 服務器,去查詢{website}對應的 IP。查到這個 IP 之後,對面 DNS 服務器會返回 IP 地址,遊覽器會再次根據 IP 地址去尋找 web 服務器。一般來說,我們的網址所需要的圖片,文字,交互等內容會放在 web 服務器上(可能是真的物理服務器,也可能是雲)遊覽器讀到這些信息之後就會返回呈現給用戶。之後用戶的點擊,都會經由遊覽器,Web 服務器,去和鏈上的智能合約進行交互。經過用戶的簽名之後,行爲會經由共識機制和鏈上廣播,變成可信的狀態。

那麼這個過程之中,項目和用戶分別存在什麼風險呢?

  • 託管平臺的干預。早年應用部署在單個服務器上,單一服務器的物理狀態成爲風險之一。隨着技術成熟,雲逐漸出現,通過將計算分佈在大量分佈式計算機上,避免了單一服務器的物理風險。但是目前這種技術的仍然存在風險,這種風險就是雲平臺作惡的風險,前端的數據信息暴露在 big-tech 的視野之下,無從躲避。
  • 偷換前端。目前來看,大多數項目都會開源前端代碼讓用戶獨立審查,用戶下載前端代碼在本地運行之後,便可自行與託管在區塊鏈上的智能合約進行交互。通過這一流程,用戶可以評估前端的風險。但是由於實際前端仍然託管在中心化的服務器上,用戶很難驗證公開前端是否就是目前正在運行中的前端,前端仍然存在偷樑換柱的可能。舉例來講,正常前端連接到官方的智能合約,而惡意前端就可能連接到惡意合約,通過用戶授權對用戶造成傷害。

爲了應對上述兩類風險,市場上看到了一些實踐,主要是 Uniswap 的 IPFS 方案和 Liquity 的 ICP 方案。

方案一:Uniswap 的 IPFS 的方案

DeFi 如何應對前端託管風險?瞭解 ICP 與 IPFS 託管方案

Uniswap 直接將前端部署上 IPFS,他們具體是怎麼做的呢?

  • 前端文件存放於 Github,通過 Github Action 向 IPFS 部署,每天至少一次。
  • 通過 pinata.cloud 用戶的遊覽器可以獲取前端的頁面。

DeFi 如何應對前端託管風險?瞭解 ICP 與 IPFS 託管方案

從用戶視角來說來說,當他們在登錄 Uniswap 的時候,互聯網到底發生了什麼呢?用戶登錄 app.uniswap.org,遊覽器查看 DNS 記錄找到了前往 cloudflare-ipfs.com 的 CNAME,再通過 Cloudflare’s IPFS gateway 的雲網關,查詢 DNSLink record,找到存放在 IPFS 上的 hash 碼,最終通過 hash 碼獲取前端的文件。

方案二:Liquity 的 ICP 方案

Liquity 是以太坊上的抵押型算法穩定幣,該 DApp 擁有一個非常有趣的特性:開放式前端。開放式前端,指的是不同的前端運營商可以獨立運行前端,並且設置自己的 kickrate (kickrate 會調節用戶所得到的相關收入和獎勵,如果 kickrate=99%,意味客戶拿到 99%,前端拿到 1%)

在結構上,Liquity 分爲前端界面和後端智能合約,在商業上,Liquity 也將由前端運營商和後端智能合約開發商,分開運作。Waterslide 是 Liquity 的前端運營商之一,也是第一個部署在 Dfinity 上的 DeFi 前端,下面介紹的實踐主要來自於 Waterslide。

DeFi 如何應對前端託管風險?瞭解 ICP 與 IPFS 託管方案

ICP 方案當中前端應用的主體身份是根據域名來的。也就是說域名和 Canister 的內容是永遠聯繫在一起的,這一點適合傳統互聯網截然不同的。當項目組創造了自己 Canister,並將前端頁面所需要的的文件託管在 canister 中,caniser 就會被分配特定的域名,用戶會直接通過 DNS 訪問特定域名 https://{website}.ic0.app (什麼是 Canister?可以理解爲分佈式 Docker,詳細細節可以參考)也因此用戶和前端頁面通過 Dfinity 緊緊地聯繫在了一起。那麼具體 Canister 具體是怎麼運行前端的呢?

運行 canister

DeFi 如何應對前端託管風險?瞭解 ICP 與 IPFS 託管方案

運行 canister 的時候,系統會顯示兩個 Controller 和 Module hash,前者是治理容器對於運行容器管理的 ID,這個碼一般情況是不可更改的,除非向治理結點提出提案;後者,是每一次 Wasm 部署完後的證明。

提交 Commit 更改

運行 Canister 以後,我們會需要升級,但這種升級是需要 NNS 來進行審批的。(NNS 可以簡單理解爲子網的創建者,他將管理整個網絡的事務。詳細參考 《完整解析 | 網絡神經系統(NNS)是怎麼運行的》)我們會將所需更新的文件同步到 github,並將 Canister 更新的申請提交到 NNS 當中,申請文件當中包含幾個要素:Commit ID,Controller,Module hash,Repo 的位置。

DeFi 如何應對前端託管風險?瞭解 ICP 與 IPFS 託管方案

bd51eab 就是我們 Commit 的代碼,NNS 的治理 Canister 會根據我們的 proposal 對 Canister 進行升級。

DeFi 如何應對前端託管風險?瞭解 ICP 與 IPFS 託管方案

當我們再一次同步 canister 的時候,會發現 tag: mainnet-20210527T2203Z,這與我們提交的 Proposal 號相一致,也就證明 NNS 已經對我們的 proposal 已經進行了升級。

用戶是如何連接到前端的?

Waterslide 網站前端託管在 Canister 之中,用戶輸入網址以後,通過 DNS 服務器會連接到 https://{specific}.ic0.app. 然後這個域名會通過 Certifying Service Worker 提供的 Controller (如 'rdmx6-jaaaa-aaaaa-aaadq-cai') 連接到對應的 Canister,那麼也就讀取到了 Canister 當中的網頁文件。用戶與 Canister 之間的交互是直接的,這些行爲都會被完整的記錄下來。

兩種方案的對比與啓示

DeFi 如何應對前端託管風險?瞭解 ICP 與 IPFS 託管方案

這張表格梳理了兩種方案架構上的優劣,可以發現 IPFS 是短期方案,而 ICP 更有利於長期的佈局。而在商業上,ICP 更有利於前端自身的商業變現,如果我們過去將 DeFi 後端智能合約等價於 DeFi,那麼隨着 ICP 的成熟,將使得前端運營成爲獨立於後端智能合約的另一股力量。爲什麼那麼說呢?因爲 ICP 將用戶和前端頁面之間的價值流可信化了。不可造假的流量和交互,成爲了資產定價的重要基礎,這也將大大提升前端頁面的玩法和創造力。結合 Dfinity 和 ETH 的交互,價值層歸價值層,應用層歸應用層(參考 《ICP 與 ETH 互操作的原理與啓示 》)這將會爲我們帶來無窮的想象空間。

Tips:截止目前爲止,ICP 本身的容器並不能記錄自身歷史的數據,但是官方(nomeata 語)有意願創建一個可以記錄 wasm 部署 hash 的 Canister,這樣一來就可以針對不可信主體提供可信的歷史記錄

從 ICP 論壇當中的溝通來看,目前 ICP 整體的開發任務量仍然很大。目前 Proposal 的處理感覺仍較爲簡陋。

參考材料:

《什麼是 DNS?》

《waterslide – the first DeFi Frontend running on DFINITY's Internet Computer》

https://www.reddit.com/r/dfinity/comments/n1xosf/value_proposition_in_comparison_to_market_leaders/

《The DeFi Stack》