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


通過比較發現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》

免責聲明:作為區塊鏈信息平台,本站所發布文章僅代表作者個人觀點,與鏈聞ChainNews 立場無關。文章內的信息、意見等均僅供參考,並非作為或被視為實際投資建議。

.



Source link