合約開發的奇妙技巧：從Uniswap代碼中學到的經驗

最近在編寫去中心化交易所開發教程時,參考了某知名DEX的代碼實現,學到了不少新知識。作爲一個曾經開發過簡單NFT合約的開發者,這是我首次嘗試Defi合約開發,相信這些小技巧對想要學習合約開發的新手會很有幫助。

接下來讓我們一起看看這些有趣的技巧吧,有些甚至可以稱得上是奇技淫巧。

可預測的合約部署地址

通常部署合約得到的是一個看似隨機的地址,因爲與nonce相關,所以合約地址不易預測。但在某些場景下,我們需要通過交易對和相關信息來推斷合約地址。這在很多情況下非常有用,比如判斷交易權限或獲取流動性池地址等。

可以通過添加salt參數使用CREATE2方式來創建合約,這樣創建的合約地址是可預測的。地址生成邏輯爲:新地址 = hash("0xFF",創建者地址, salt, initcode)。

善用回調函數

在Solidity中,合約之間可以相互調用。有一種場景是A在某個方法調用B,B在被調用的方法中回調A,這在某些場景中很實用。

例如,當你調用某DEX合約的swap方法交易時,它會回調swapCallback,傳入計算出的本次交易實際需要的Token。調用方需要在回調中將交易所需Token轉入DEX合約,而不是將swap方法拆分爲兩部分讓調用方調用。這確保了swap方法的安全性,保證整個邏輯被完整執行,無需繁瑣的變量記錄來確保安全性。

用異常傳遞信息,用try catch實現交易預估

在某些DEX的代碼中,我們發現它把swap方法用try catch包裹執行了一下。這是爲什麼呢?因爲我們需要模擬swap方法來預估交易所需Token,但預估時並不會實際產生Token交換,所以會報錯。它通過在交易回調函數中拋出特殊錯誤,然後捕獲這個錯誤,從錯誤信息中解析出所需信息。

這看起來有點取巧,但很實用。這樣就不需要爲預估交易的需求去改造swap方法了,邏輯也更簡單。

用大數解決精度問題

在DEX的代碼中,有很多計算邏輯,比如根據當前價格和流動性計算交換的Token。在這個過程中我們要避免除法操作時丟失精度。在某些實現中,計算過程會經常使用"<< FixedPoint96.RESOLUTION"這個操作,它代表左移96位,相當於乘以2^96。左移後再做除法運算,這樣可以在正常交易不溢出(通常用uint256計算,足夠)的情況下保證精度。

用Share方式計算收益

在DEX中,我們需要記錄LP(流動性提供者)的手續費收益。顯然,不能在每次交易時都給每個LP記錄各自的手續費,這會消耗大量Gas。那該如何處理呢?

可以在Position中定義包含feeGrowthInside0LastX128和feeGrowthInside1LastX128的結構體,它們記錄了每個頭寸上一次提取手續費時每個流動性應獲得的手續費。

簡單說,只需記錄總手續費和每個流動性應分配的手續費即可。LP提取手續費時,根據持有的流動性就能計算出可提取的手續費。這類似於持有某公司股票,提取股票收益時只需知道公司歷史每股收益,以及你上次提取時的收益即可。

並非所有信息都需從鏈上獲取

鏈上存儲相對昂貴,因此並非所有信息都要上鏈或從鏈上獲取。比如某些DEX前端網站調用的很多接口就是傳統Web2接口。

交易池列表、交易池信息等可以存儲在普通數據庫中,有些可能需要定期從鏈上同步,但不需要實時調用鏈或節點服務提供的RPC接口來獲取相關數據。

當然,關鍵交易肯定是在鏈上進行的。

學會合約拆分,利用已有標準合約

一個項目可能包含多個實際部署的合約。即使實際部署只有一個合約,我們也可以通過繼承方式將合約拆分爲多個合約來維護。

此外,可以直接使用像@openzeppelin/contracts/token/ERC721/ERC721.sol這樣的標準合約。這樣一方面可以通過NFT方式管理頭寸,另一方面也能用已有標準合約提高開發效率。

總結

親身實踐開發一個簡易版去中心化交易所,能讓你更深入理解DEX的代碼實現,也能學到更多實際項目中的知識點。無論你是對Web3還是DeFi項目開發感興趣,實戰經驗都會對你大有幫助。