從架構角度分析，什麼才是真正的 Crypto-native DApp？

撰文： msfew，Foresight Research

0. Web2 App 架構

當我們開發一個現代化 toC 應用程式的時候, 無論是 Web App 還是 Mobile App 還是 Desktop App, 他們的基本架構都可以用以下三端來概括:

從左到右分別是:

• 前端: 也叫客戶端. 應用的前端是用戶在瀏覽器內看到的頁面, 或者移動設備裡使用的 App. 前端掌控了視圖和展示.

• 後端: 也叫伺服器端. 應用的後端存在的意義主要就是為前端提供接口和數據, 通常應用的主要業務邏輯會在後端中.

• 數據庫: 數據庫顧名思義, 專門存儲數據的. 後端會讀取或者修改數據庫的內容.

為什麼軟體都需要這三端? 為什麼前端不直接連數據庫呢? 中間為什麼還要有一個後端? 這其實有很多方面的原因:

a) 工程化

開發者角度: 現代化應用的前端沒有精力同時處理複雜的數據模型以及視圖的狀態管理. 工程化的角度而言, 讓每個工程師都全知全能地維護一套臃腫的系統是不好的. 除此之外很多的邏輯是不需要前端參與展示的, 比如電商平台的庫存等.

架構角度: 每個端都有自己的一套規則和語言去描述數據. 前端用人類能理解的思路來構建頁面, 後端用面向對象的語言來操作數據, 數據庫使用關係代數語言來訪問物理存儲. 沒有辦法規定一套萬金油的規則來統一三端. 同時由於語言各司其職, 所以性能側重點也不同.

b) 通信

協議角度: 觀察圖中, 可以看到連接三端的兩個連接方式是不一樣的. 通常 toC 的應用程式前端和後端溝通使用 HTTP 協議, 而後端和數據庫則有不同的協議, 如 MySQL 就和 MongoDB 有著不同的協議. 我們可以通過一層很薄的後端 (GraphQL + Hasura) 或者規定新的協議 (OData) 來達到類似前端直連數據庫的效果, 也有 CouchDB 這樣為這樣的通信而生的協議, 但依然沒有解決其他的缺點.

數據映射角度: 前端處理 UI, 後端處理對象, 數據庫處理數據. 前端與後端的連接使用了 UI 與對象的映射, 後端與數據庫的連接需要使用對象關係進行映射.

c) 安全性

數據角度: 因為在目前, 我們所使用的應用越來越多是基於 Web 的應用, 所以如果讓前端直連數據庫, 那麼在瀏覽器這個不安全且開放的環境下, 很難防住數據洩露和黑客攻擊. 數據庫理論上可以通過各種鑑權等手段控制數據可見度, 但是後端存在的另一個巨大意義就是確保在可信的環境中, 以設計好的方式運行, 並排除已知的安全性問題.

d) Web2 應用架構給 DApp 的啟示

從以上三個角度, 我們分析了為什麼 Web2 應用是三端架構, 而這也帶給了我們對區塊鏈 DApp 的一些思考:

1. 工程化: 對應了區塊鏈中的模組化思想. 各個組件各司其職, 存儲則可以用存儲鏈, 用戶數據則用傳統的公鏈存儲. 開發者無需太高的開發心智負擔.

2. 通信: 對應了區塊鏈網絡不同的共識機制. 這些不同的機制也讓區塊鏈的互通變成難題, 但也有如 Cosmos 和 Polkadot 的互通協議, 嘗試去鏈接整個網絡. 但從 Web2 應用的角度來說, 這並不意味著是最佳的解決方案. 數據映射則可以對應面向賬戶或者 UTXO 的設計模式, 兩者在性能, 隱私, 和開發複雜度上各有優劣.

3. 安全性: 對應了區塊鏈的去中心化與 Verify, Not Trust 思想. 安全性在區塊鏈領域中更為重要, 因此需要可驗證, 甚至完全透明公開的方式來對數據的處理和數據的可見度進行調整, 從而實現透明和 Permissionless 的 DeFi, 公開且具有所有權的 NFT, 以及 DApp 最重要的可組合性。

1. Web3 DApp 架構

大多數的 Web3 DApp 都遵循了如下的架構:

• 簡單應用 (純鏈上數據且交互並不複雜), 例如: Uniswap 以及純鏈上存儲的 NFT 項目.

• 前端與 Web2 App 沒有區別.

• 無後端 (鏈上智能合約作為後端).

• 區塊鏈作為數據庫.

a) Web3 DApp 細化組件

更細化地說, 完整的 Web3 DApp 的工作流程涉及到更多的組件:

• 前端: 瀏覽器, 錢包, 頁面.

• 前後端通信: 節點 Provider, 索引協議.

• 概念上的後端: 區塊鏈網絡上的智能合約.

• 後端數據庫通信: 節點 Provider, 存儲網絡網關.

• 數據庫: 智能合約狀態和去中心化存儲網絡.

b) Web3 DApp 如何做到無後端?

區塊鏈網絡上的圖靈完備的智能合約的存在, 讓區塊鏈能成為最好的 Serverless 平台, 或者說是可以被視作 Trustware 的 World Computer. 應用的數據和後端邏輯都可以在智能合約中實現.

和 Serverless 函數相比, 智能合約更加優秀, 也造就了比 Web2 應用更加優秀的架構和模式:

• 付費方式: Serverless 函數通常是開發者支付費用, 而智能合約大部分交互費用都是由用戶來支付, 且用戶也會心甘情願地為鏈上空間而付費.

• 執行環境: Serverless 函數有非常靈活的執行環境, 而智能合約的執行環境雖然選擇很少, 但非常輕量級.

• 部署環境: Serverless 函數部署在中心化雲服務平台, 而智能合約部署在去中心化和無需許可的去中心化網絡上. 除此之外, 網絡的運營成本也是從中心化平台轉嫁到了礦工, 經濟系統會更加具有自主性.

但是, 對於一個真正完整的應用來說, 只通過智能合約作為後端, 是無法實現完整的功能的, 因此會需要有 Keeper 網絡或預言機等其他組件.

2. Web3 Crypto-native DApp 架構

Web3 DApp 指的是通過智能合約作為後端實現的, 簡單的去中心化應用. 要完成一個複雜應用, 可能或多或少會引入中心化的服務, 真正要實現一個 Crypto-native 且 trustless 的 DApp, 則需要在架構上加入新的變化.

Web2 的複雜應用其實也遠遠不止是我們之前所概括的三端了, 需要非常多模組化, 中間層以及水平拓展的架構拆分.

a) 前端 ⇒ 開源 + Self-hosted 前端

Web3 前端的觸發邏輯其實和 Web2 本身就不太一樣. Web3 的操作都是用戶進行通過和確認的, 且以鏈上地址為核心, 而不是 Web2 中, 客戶端直接發送到伺服器和數據庫觸發數據更新.對於 Web3 前端的發展, 我認為有兩個大的趨勢：

• 框架的選擇: 前端的兩大框架 React 與 Vue 中, React 占了 Web3 的主導地位, 主要就是因為生態與各種組件的積累

• 比如 web3-react 與 Center.dev. 但是我個人感覺 React 項目的主導權始終還是在 Meta 手裡, 開源協議的更改也多次引起爭議, 所以如果有機會使用 Vue 框架搭配一些依賴盡量少的第三方庫來進行前端開發的話, 還是比 React 更加好的.

• 前端的 Hosting: 前端是 DApp 被黑 (惡意劫持或腳本注入) 以及被 censor (Uniswap 和 Flashbots 的源碼中都有 OFAC 的黑名單) 的重災區. Yearn Finance 很早就鼓勵用戶自己托管 DApp 的前端; 在 Arweave 這樣的永久存儲網絡上托管前端也能保證每個版本的前端都不會被刪除, 永久可訪問; Trustless.fi 也提出了前端 Marketplace 的概念, 讓用戶在多個社區托管的前端中選擇, 這也能保證中立性和 "前端多樣性"; Etherscan 等其他區塊鏈瀏覽器其實也算是中立的前端, 用戶可以通過它來直接進行交互, 或者也有專門的應用給合約生成前端, 如 okcontract; 最近 Tornado 被 censor, 也有很多社區 (比如 codeisspeech 和 theshake) 在自發托管它的前端.

  

  這兩個點的發展會讓 DApp 的前端有 censorship resistence, 大大地提升 DApp 整體的安全性和去中心化程度.

  

b) 後端 ⇒ ZKP + 智能合約

App 架構的演進過程會是這樣的:

1. Web2 應用: 前端 ⇒ 後端 ⇒ 數據庫

2. Web3 簡單應用: 前端 ⇒ 智能合約

3. Web3 複雜應用: 前端 ⇒ ZKP ⇒ 智能合約

智能合約雖然讓整個應用變得去中心化，但用一個公開網絡上的智能合約去處理應用的邏輯是一把雙刃劍. 數據與代碼公開了, 保證了透明可查與可組合性, 但也把隱私和安全風險完全暴露, 同時鏈上空間與計算的成本非常高.

ZKP 會成為 Web3 時代的 RSA, 消除應用的通信安全性短板, 和去中心化短板, 真正實現 trusted 且 trustless 的 DApp.

ZKP 的加入作為一個前後端之間的中間層與通信方式, 又一次非常好地發揮了它的兩大優點:

• 隱私: Web2 應用中, 隱私一直算是默認選項, 但區塊鏈網絡的性質讓 DApp 一直擁有著形同虛設的 "隱私", ZKP 作為中間層, 可以將敏感數據在鏈下處理, 從而解決這一個問題.

• 擴容: 鏈上空間有限, 因此很多 Web2 應用中的複雜算法無法實現, ZKP 能在保證計算可信的情況下, 將算法在鏈下執行, 鏈上驗證.

有無數項目正在朝著這兩個方向努力, 這裡就不列舉了. 主要需要攻克兩個難點:

• 計算可行性: ZKP 的計算種類是受限制的, 並非所有的計算可以通過 ZKP 來解決.

• 優化: 當操作的複雜度提高時, 計算時間和空間會顯著提高, 這就需要非常多的軟硬件優化. 同時很多情況下只能在吞吐量上進行顯著提升, 整體 Proving 的 overhead 很難削減.

c) 數據庫 ⇒ 去中心化節點服務

我們之前講述了 DApp 如何用區塊鏈來作為後端與數據庫. 要讓 DApp 連接上區塊鏈網絡, 就需要節點服務.

目前來說, DApp 常用的都是中心化的 NaaS, 比如 Alchemy 與 Infura, 未來在我的構想裡有三個更好的方向:

• 去中心化 NaaS, 協議化 Infura, 但是這個其實沒有特別大的必要和可行性, NaaS 去中心化的目的主要是為了抗審查而已, 不用其他的需求.

• 多中心 NaaS, 使用多個中心化 NaaS 作為備選 (類似 Chainlink + Uniswap 的預言機組合). 這是一個更加可行且可靠的方案, 能保證抗審查和 uptime.

• 自托管 NaaS. 終極方案, 不僅可以保證 "數據庫" 連接的可信與各種數據的隱私和抗審查, 也可以增加網絡的去中心化程度. 搭配上自托管前端, 整個 DApp 就會無比去中心化.

d) Crypto-native DApp 實例

最近剛被制裁的 Tornado.cash (尤其是舊版本) 是一個非常 Crypto-native 的 DApp, 它滿足了我們很多的定義:

• 前端使用了 NuxtJS 的 Vue 框架, 而不是常用的 React 框架.

• 完全使用前端代碼中的 ZK 電路和智能合約實現, 沒有任何伺服器端代碼.

• 代碼完全開源, 托管在 IPFS 中.

• 舊版本無私鑰或多簽控制.

我相信未來會有更多應用以 Tornado.cash 的範式來進行架構的打造, 這是目前我心目中最完美的去中心化的 Web3 應用架構.

3. Web3 Infra

上述只是簡化版的架構, 以下是較為具體的一個實際 DeFi 應用的架構:

其中包含了除了節點服務以外的幾個補充的基礎設施:

• Indexer: 左側的 The Graph. 鏈上數據沒有辦法方便地查詢, 所以需要 indexer 對合約相關數據進行組裝.

• Oracle: 右下角的 Chainlink. 鏈上需要拿到合約或者網絡以外的價格等數據, 因此需要鏈上 (Uniswap TWAP) 或者鏈下預言機 (Chainlink) 喂價.

• Keeper: 右下角的 Keep3r Network. 智能合約本身沒有自動觸發執行任務能力, 因此需要外部觸發器進行協助.

這幾個基礎設施在一個 DApp 的搭建中至關重要, 我們會在未來的文章中詳細介紹 Oracle 與 Indexer 的問題與革新機會.

為什麼只有這幾個基礎設施被納入考量中, 而諸如 NFT 創作工具, No-Code 合約生成工具, 和合約前端生成器沒有被考慮到呢? 因為我個人認為, 一個好的 Web3 基礎設施需要有不斷的價值捕獲的能力, 持續和使用它的應用一起增長, 而不是一次付費就結束了, 這也是 Web2 SaaS 和 Web3 Protocol 中得出的經驗。

熊市是一個非常好的搭建和提升基礎設施的機會. 我相信這些革新的 Fat Infra 會撐起下一輪 DApp 的創新, 並且作為 Base Layer 捕獲到巨大的價值。