簡述DeFi應用架構設計之道
正文
二級標題
前言
前言
正文
正文
前言
二級標題
前言
DeFi 應用跟傳統應用的差異性還是比較大的，商業模式不同，產品模型也不同，就連落地實現的技術棧也有很大不同。一般，傳統應用也稱為Web2 應用，而DeFi 應用則可被歸入Web3 之列。
我們不說商業模式和產品模型，就只說說技術棧。 DeFi 應用目前所涉及到的技術棧主要包括：Solidity、Subgraph、Price Oracle、Hardhat、Ethers 等等。這些技術棧，大多就連阿里、騰訊、字節等互聯網大廠裡一些高達P9 級別的大佬可能聽都沒聽過。傳統應用架構中所熱門的微服務架構、大數據架構、雲原生架構等，在DeFi 應用中也基本毫無用武之地。
我從2017 年中旬就開始研究區塊鏈，在這個行業深耕了幾年時間，做過了幾款DeFi 應用，才終於有了一些根基。基於我的經驗總結，來聊聊我理解的DeFi 應用的架構設計之道。
二級標題
二級標題
整體架構
先來看看一個DeFi 應用系統的整體架構一般是怎樣的：
下面我來一一介紹下幾個模塊：
Blockchain：底層的區塊鍊網絡，一個DeFi 應用一般都會部署到多個不同的區塊鍊網絡
Smart Contracts：智能合約，是DeFi 應用的核心業務實現，也是靈魂所在
Price Oracle：價格預言機，用來提供價格信息的，一般可分為鏈下預言機和鏈上預言機
Keeper Services：智能合約的任務觸發器和執行器，因為智能合約本身沒有自動觸發執行任務的能力，所以需要外部的任務觸發器協助
Subgraph：子圖，也被稱為索引器，主要將鏈上數據重新組裝成方便前端查詢的數據
Graph Node：Subgraph 所運行的環境，會同步鏈上區塊數據給Subgraph 處理
Wallet：錢包應用，最主流的就是MetaMask
WebUI：前端展示的UI 頁面，一般用Vue、React 等前端框架
SDK：封裝了對Subgraph 的查詢、智能合約的調用、錢包的連接等，方便前端UI 的調用相信有不少人會產生一個疑惑：為什麼一個DeFi 應用系統會有這麼多不同的組成？首先，智能合約本身缺乏自動執行的機制。 Web2 應用因為有定時器，所以很多任務都可以用定時器自動執行。但智能合約卻沒有定時器，因此有些任務就沒法自動執行，就需要外部程序來觸發執行這些任務。這樣的外部程序就被稱為Keeper，比如執行Compound 的清算任務的liquidator 就是一種Keeper。
大部分Keeper 都是鏈下中心化的程序。而近一年來，也陸續出現了一些去中心化的Keeper 網絡，我所知的就有keep3r.network、Chainlink Keepers、KeeperDAO。
其次，也同樣是因為智能合約本身的限制，無法像Web2 應用一樣主動向外部程序發起網絡請求獲取數據。否則，如果智能合約可以向Coinbase、Binance 等中心化交易所發送網絡請求獲取價格數據的話，那不同節點因為請求的時間不同，獲取到的價格也不同，就無法達成一致了。但智能合約又的確需要獲取價格信息，所以就有了Price Oracle。
鏈上預言機則以Uniswap 的TWAP（時間加權平均價格）為主流，其原理我在之前的文章
二級標題
《剖析DeFi交易產品之Uniswap：V2下篇》
已經聊過，就不再重複了。
另外，智能合約存儲的數據和傳統Web2 的數據庫完全不同，沒法像MySQL、MongoDB 這些數據庫一樣對數據進行索引查詢，也沒法做到對數據進行分組、排序或組合。而這種需求也屬於剛需，為了滿足這種需求，就出現了The Graph，區塊鏈數據索引協議。 Subgraph 就是該協議的核心組成，Graph Node 則是其運行環境。
具體到每個不同的DeFi 應用，實際的架構可能稍微有些許差異，比如Uniswap 就不需要Keeper Services，也不需要Price Oracle。但大部分稍微複雜些的DeFi 應用基本都需要這些組成，也因此，這種架構也已經成為大部分DeFi 應用的通用架構。
二級標題
二級標題
智能合約設計
整個DeFi 應用系統中，最核心也最複雜的當屬智能合約，且智能合約還是需要開源的，其安全性也至關重要，所以，智能合約的設計也自然是非常關鍵的一環。
滿足功能性是一個基本需求，比如，一個借貸產品，能存取借還就是必須滿足的基本需求；一個衍生品DEX，能放大槓槓交易也是必須滿足的基本需求。但要滿足到何種程度，就可能受其它約束條件限制了。比如，衍生品DEX 為了防止閃電貸攻擊，可能會禁止同個賬戶在同個區塊內既開倉又平倉。
二級標題
擴展性也是非常重要的一個特性，畢竟，一個應用系統並不是只發布一個版本就足夠了，總需要持續迭代添加新功能。比如，衍生品DEX，第一版可能只實現市價交易功能，第二版需要增加限價交易功能，第三版再增加止盈止損功能。
這幾個特性也不是全正相關的，比如，進一步提高安全性，就可能會減低功能性和擴展性，因此，要追求的並不是三種特性全都越高越好，而是要根據情況有所取捨，達到一種平衡狀態即可。
而要達成目標，所需要遵循的設計原則和背後本質的設計思想，其實還是架構師們所熟知的那些，比如，單一職責原則、開閉原則、依賴倒置原則、接口隔離原則等，以及關注點分離、低耦合高內聚、適度設計等架構思想。
做架構設計，最核心的就是要將復雜問題簡單化，這應用到開源的智能合約中，顯得更加重要。
二級標題
二級標題
設計實踐
下面以我目前負責的DeFi 應用為例，聊聊我的一些實踐總結。
先簡單介紹下背景，小部分朋友知道我最近加入了新團隊，在負責一個DeFi 產品，確切地說，是一個衍生品DEX。交易模式主要採用AMM 模式，但不是Uniswap 那樣提供雙幣流動性的AMM，而是提供單幣流動性的AMM，我們稱為Elastic AMM。具體業務就不展開了，以後再另外細聊，這次我主要還是講講架構設計方面的考量。
作為Trader 和LP 的用戶，都統一跟Router 交互，Router 在其中就相當於起到了路由網關的作用。而且，因為底層對它沒有依賴，所以就很容易升級替換。
二級標題
總結
總結
每個交易對分別有一個Amm 合約和一個Margin 合約，且Amm 和Margin 是相互綁定的。因此，自然而然地，就想到了用工廠模式來創建不同的交易對。原本的設計中，其實只有一個工廠合約，但在具體實現中，最終發現工廠合約超過了**智能合約最大字節數，**於是就將工廠合約拆分成了三個。
