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

撰文：Yolo
來源：大腦桿菌

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

簡介：常見 DeFi 的架構

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

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

• 託管平台的干預。早年應用部署在單個伺服器上，單一伺服器的物理狀態成為風險之一。隨著技術成熟，雲逐漸出現，通過將計算分布在大量分散式計算機上，避免了單一伺服器的物理風險。但是目前這種技術的仍然存在風險，這種風險就是雲平台作惡的風險，前端的數據信息暴露在 big-tech 的視野之下，無從躲避。

• 偷換前端。目前來看，大多數項目都會開源前端代碼讓用戶獨立審查，用戶下載前端代碼在本地運行之後，便可自行與託管在區塊鏈上的智能合約進行交互。通過這一流程，用戶可以評估前端的風險。但是由於實際前端仍然託管在中心化的伺服器上，用戶很難驗證公開前端是否就是目前正在運行中的前端，前端仍然存在偷梁換柱的可能。舉例來講，正常前端連接到官方的智能合約，而惡意前端就可能連接到惡意合約，通過用戶授權對用戶造成傷害。

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

方案一：Uniswap 的 IPFS 的方案

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

• 前端文件存放於 Github，通過 Github Action 向 IPFS 部署，每天至少一次。

• 通過 pinata.cloud 用戶的遊覽器可以獲取前端的頁面。

從用戶視角來說來說，當他們在登錄 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。

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

運行 canister

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

提交 Commit 更改

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

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

當我們再一次同步 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 之間的交互是直接的，這些行為都會被完整的記錄下來。

兩種方案的對比與啟示

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

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

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

冷萃財經原創，作者：awing，轉載請註明出處：https://www.lccjd.top/2021/06/11/defi-%e5%a6%82%e4%bd%95%e5%ba%94%e5%af%b9%e5%89%8d%e7%ab%af%e6%89%98%e7%ae%a1%e9%a3%8e%e9%99%a9%ef%bc%9f%e4%ba%86%e8%a7%a3-icp-%e4%b8%8e-ipfs-%e6%89%98%e7%ae%a1%e6%96%b9%e6%a1%88/?variant=zh-tw