Compound代碼更新事故

2021-10-10 00:10:29

"有些事,發生在別人身上是故事,發生在自己身上就成了事故"

Compound代碼更新事故

代碼的升級是一件痛苦且脆弱的事。尤其是在本就十分復雜的代碼大廈上,任何微小的改動,都可能因為某些邊界條件的疏忽而造成崩塌,Compound最近就遇到了這事

Compound代碼更新事故

背景介紹

Compound是一個老牌的去中心化借貸平臺

Q1: 為什么要有借貸這回事兒?

在區塊鏈上,所有的資產都是代幣化的。我們看好一個項目,但是卻沒有這個項目發行的代幣。這時最簡單的方法就是去交易所用手裏有的幣來換。但是,如果我們又不舍得自己手裏的幣,該怎么辦呢。這時可以去借,抵押品便是我們擁有的幣。如果這個項目漲了,獲得收益的同時,還可以贖回曾經抵押的幣。

交易會發生所有權的轉移,而借貸不發生所有權的轉移,只是被暫時鎖在合約中

同時,由於借貸的引入,我們可以操控更大的資金敞口,實現槓杆交易...

Q2:Compound的運作流程?

和AMM類似,在區塊鏈上實現自動化的借貸,首先要做的便是吸引資金(流動性),而用戶所以能將錢存在一個平臺,必然是受到利益的驅使。AMM通過交易費來激勵用戶添加流動性,而借貸平臺的手段便是借款利息

由於存在借貸這一需求,總會有人愿意付出利息來借幣。而有了利息的激勵,也有人愿意將闲錢拿來提供流動性。此外,借貸平臺通過利率模型參數的動態調整,可以維持整個系統的供給平衡與風險

Q3: 如何與Compound交互?

用戶與Compound的交互接口主要是CToken/CEther合約(這些合約本身就是一種代幣), CToken 相當於 Compound這一平臺的"入場券"。通過向不同CToken合約質押其底層代幣(underlying token)便可以獲得相應的CToken

這一操作,表現在代碼層面就是 ctoken.mint(amount),比方說:我手裏有1000個ETH,便可以調用cEth.mint(1000) 來向cEth池中 "注入流動性"

要注意的是,cToken和底層代幣並不是1:1的兌換關系,當蛋糕越做越大時,cToken所能換出的底層代幣也就越多。這和LP token的類似,利息便是以這種形式來發放的

Compound代碼更新事故

那有了cToken以後,我們可以做什么呢?

最簡單的便是借錢,因為cToken代表用戶質押在Compound的資產,因此可以通過"過抵押"的方式來借出Compound擁有的代幣。Compound會先計算用戶擁有所有cToken的價值(可能來自於不同的池),根據抵押率來計算用戶的流動性(Liquidity)

表現在代碼層面就是 ctoken.borrow(amount),比方說:我通過 ceth.mint(1000) 質押了 1000 個 ETH,如果我想借 Dai 的話,需要調用 cDai.borrow(x) 這裏的 x 最多價值750 ETH (抵押率75%)

這些都是以美元計算的,再根據Oracle來換算成不同的Token數量

而Comptroller這一合約是一個中間層,它所做的事情,便是交互前的一些計算與驗證工作,類似銀行的審計員。比方說:張三借了多少錢,欠了多少錢,這小子又來借1000個ETH還能不能借給他

表現在代碼層面就是:getHypotheticalAccountLiquidityInternal()borrowAllowed()mintAllowed() ...

Q4: COMP代幣與Compound的關系?

COMP代幣是Compound發行的平臺代幣,可以用於管理。因為Compound採用DAO的治理模式。對Compound所有的操作,都需要通過投票來決定,提案(proposals)通過後由一個特權合約來執行寫在提案中的操作。通過COMP可以獲得投票的權重

詳情見:https://compound.finance/governance

當然只能用來投票顯然還是缺少些吸引力的,COMP本質上就是Compound發行的股票,擁有更多的COMP,可以享受更優的利率,隨着Compound的發展,COMP帶來的價值也會越來越大,因此COMP值錢(目前 $300 左右)

同時,為了激勵用戶使用Compound,無論是向Compound提供流動性,還是從Compound借出資產,都會獲得一定的COMP獎勵,這些獎勵以區塊為單位計算(劃重點:這裏與本次事件相關

修了東牆又補西牆

事故1:Bug的原理

事故1代碼地址:0x75442Ac771a7243433e033F3F8EaB2631e22938f

事情的起因是這樣的:

2021年9月31日,Compound DAO出現這樣一條提案(Proposals 62: https://compound.finance/governance/proposals/62):

該提案提出更新 Comptroller 合約以修復一些 Bug

Compound代碼更新事故

這裏我們可以看出 Bug 和 CompSpeed 有關,CompSpeed 這個變量代表是每個區塊可以挖出的 COMP 數量

這裏以 mint 為例簡單介紹Bug的原理:

ctoken 的 mint 函數的調用鏈為:mint → mintInternal → mintFresh

Compound代碼更新事故

可以看到,在 mintFresh 中,會先調用 Comptroller 的 mintAllowed 函數,再更新用戶 ctoken 的余額

Compound代碼更新事故

而 mintAllowed 中,會先調用 updateCompSupplyIndex,再調用 distributeSupplierComp

Compound代碼更新事故

前者會更新借貸池的獎勵狀態,主要是 compSupplyState

Compound代碼更新事故

這一結構體中,block字段記錄了更新時的區塊號,index字段記錄的是更新時的獎勵指數

**什么是獎勵指數(index)呢?**這是一個隨時間不斷累加的值,其公式為

Compound代碼更新事故

表示的是一個借貸池,隨着時間的推移,向每個cToken分發的COMP數量。因此,其差值可以簡單理解為,這段時間內一個cToken可以獲得的COMP數量

接下來我們看另一個函數:distributeSupplierComp。這個函數的作用,就是將用戶可以獲得的COMP數記錄到compAccrued[supplier] 中

Compound代碼更新事故

每次有用戶來和 Compound 交互,都會觸發全局的獎勵指數 compSupplyState 更新

與此同時,在上面的函數中,我們可以看到,用戶會先從 compSupplierIndex 中取得上次的 compSupplyState 保存在臨時變量 supplierIndex 中,接下來更新 compSupplyState

這裏要區分好 supplyIndex 和 supplierIndex,前者表示當前的獎勵指數,後者表示用戶上次交互時的獎勵指數

而兩個時間點全局獎勵指數的差 * 用戶擁有的 cToken 數量,就是這段時間獎勵給該用戶的 COMP 數量

現在看起來都是一起正常,歲月靜好,直到...

有一天Compound調用了 setCompSpeed

Compound代碼更新事故

因為一個Market的CompSpeed是可以設置為0(表示暫停發放COMP獎勵),所以存在這樣一種情況:

  1. 我們先把一個市場的CompSpeed設置為0

  2. 過了一段時間後又想要重新开啓COMP獎勵,這時就會調用setCompSpeed設置compSpeed為一個非零值

這會發生什么呢?

很顯然,合約會走到 else if (compSpeed != 0) 這個分支。我們來看這個分支中有兩個if判斷(以第一個為例):if (compSupplyState[address(cToken)].index == 0 && compSupplyState[address(cToken)].block == 0)。其作用是:為一個未初始化的市場,初始化獎勵指數(index)和區塊號(block)

問題1:這裏可以想想:未初始化的市場(index = 0 && block = 0)和被暫停的市場(index = 0)一樣嗎?

先別急,我們重新來看 updateCompSupplyIndex

Compound代碼更新事故

這裏我們可以回答一下問題1:未初始化的市場和暫停的市場是不一樣的,暫停的市場雖然index = 0,但是block會一直更新!

因此,當我們為一個暫停的市場重新設置compSpeed時:index不會被初始化!

【注】Compound假設獎勵指數初始值為CompInitialIndex = 1e36

這會有什么影響呢?

我們再來看下獎勵分發函數 distributeSupplierComp

Compound代碼更新事故

看出來了嗎?用戶自己的獎勵指數(supplierIndex)會被初始化為compInitialIndex (1e36),而市場的獎勵指數(supplyIndex)由於上面的問題為0,這就導致:Double memory deltaIndex = sub_(supplyIndex=0, supplierIndex=1e36) 出現下溢!

Compound代碼更新事故

事故2:修復後引入的Bug

事故2代碼地址:0x374abb8ce19a73f2c4efad642bda76c797f19233

Compound方面對事故1的修復如下:

Compound很顯然意識到了問題出在setCompSpeed函數只考慮了"未初始化市場",而沒有考慮"暫停的市場"

因此,新代碼中,增加了函數:_initializeMarket 這個函數會在添加新市場時調用。也就是說,只要添加新市場,就會初始化其獎勵指數為compInitialIndex

Compound代碼更新事故

但是既然市場獎勵指數初始化為了compInitialIndex,那用戶的獎勵指數呢?這是我們來看新的distributeSupplierComp 函數:

Compound代碼更新事故

因為很多市場的 CompSpeed 為0,所以其獎勵指數會停留在 compInitialIndex(1e36) 這個值,此時如果調用這個函數會發生什么?

很顯然上圖中的if被繞過了,這意味着沒有初始化用戶的獎勵指數(supplierIndex),而市場的獎勵指數(supplyIndex)是compInitialIndex

所以deltaIndex本應是(compInitialIndex - compInitialIndex = 0)就變成了 (compInitialIndex - 0 = 1e36)

哦豁,出大問題。可是,獎勵不僅僅依賴於這個deltaIndex,還需要用戶有cToken(supplierTokens)

是否存在這一情況呢?顯然是存在的,如果用戶在合約更新之前就做了mint操作,其supplierIndex=0,但是手裏是存在cToken的。當合約更新後,用戶再次調用該函數,就可以獲得 1e36 * ctoken.balanceOf(user) 數量的COMP獎勵

Real World

通過compStateIndex = compInitialIndex,可以很容易的得到受到影響的市場有:

0xF5DCe57282A584D2746FaF1593d3121Fcac444dC: cSAI
0x12392F67bdf24faE0AF363c24aC620a2f67DAd86: cTUSD
0x95b4eF2869eBD94BEb4eEE400a99824BF5DC325b: cMKR
0x4B0181102A0112A2ef11AbEE5563bb4a3176c9d7: cSUSHI
0xe65cdB6479BaC1e22340E4E755fAE7E509EcD06c: cAAVE
0x80a2AE356fc9ef4305676f7a3E2Ed04e12C33946: cYFI

我們以一位涉事者為例:0xa7b95d2a2d10028cc4450e453151181cbcac74fc

我們看到在這筆交易中:0x6416ed016c39ffa23694a70d8a386c613f005be18aa0048ded8094f6165e7308

Compound代碼更新事故

其Claim大量的COMP代幣,通過調試我們發現,在調用distribute時:

Compound代碼更新事故

由於事故2,獲得的deltaIndex = 1e36,而恰恰該用戶之前有cToken

Compound代碼更新事故

從而可以薅到大量的COMP:

Compound代碼更新事故

尾聲

最終,事情的解決方式也很簡單

在接下來一條提案中(Proposal 63),暫停COMP獎勵,但是最終被取消掉了

最新的一條提案,更新了Comptroller合約,該提案目前仍在排隊中:

Compound代碼更新事故

最新的合約裏,distributeSupplierComp函數中初始化用戶獎勵指數的判斷條件修改如下:

Compound代碼更新事故

總結與反思

Compound作為借貸平臺的老大哥,本次的事件有些唏噓

雖然Compound軟硬兼施,一方面承諾拿出10%的白帽獎勵給獲得"意外之財"的用戶,一方面又尋求法律的手段。但是,事故終究已經發生

當我們不斷探索區塊鏈,不斷追求更高的APY,追求項目快速落地。是否還有人記得,區塊鏈最基本的一條原則就是:覆水難收!

啓示如下:

  1. 代碼部署上鏈前一定要做好充足的審計與測試工作

  2. 使用代理模式時,更新邏輯合約要保證一致性,注意是否會對原來的Storage產生影響

  3. DAO模式雖然減少了中心化的風險,但是應對緊急情況時的反應遲緩問題

  4. 即使是大公司依然會有犯錯誤的可能,借鑑其他項目代碼時要注意檢查

參考

Comptroller: compSpeed bug: https://www.comp.xyz/t/comptroller-compspeed-bug/2111

github issue: https://github.com/compound-finance/compound-protocol/pull/144/commits/f6d717bb78bef0c9851ad672f7b9aa1d90b0f00a

鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播信息之目的,不構成任何投資建議,如有侵權行為,請第一時間聯絡我們修改或刪除,多謝。

推薦文章

Hyperliquid:從史上最有價值空投到高估值警鐘

毫無疑問,Hyperliquid 是近期加密市場炙手可熱的焦點,它通過一場震撼行業的空投,不僅引發...

coincaso
11 2天前

Arthur Hayes 新文聚焦 | 全球貨幣政策的真相,比特幣接下來何去何從?

作為一名宏觀經濟預測者,我試圖基於公开數據和當前事件,作出能夠指導投資組合資產配置的預測。我喜歡“...

coincaso
18 3天前

Ouroboros DeFi:為什么 Usual Money 被低估了?

前言:Ouroboros DeFi 方法論在Ouroboros DeFi收益基金,我們的投資策略始...

coincaso
14 3天前

WEEX 唯客交易所贊助臺北區塊鏈周 支持更多全球用戶Onboard Web3

第三屆臺北區塊鏈周(Taipei Blockchain Week, TBW)於 12 月 12-1...

coincaso
14 3天前

DeFi 3.0正在到來:下一代去中心化金融的演進

DeFi 3.0正逐步成形,多個前沿項目正在引領這一波技術浪潮。$HYPE、$PENDLE、$IN...

coincaso
16 6天前

生息穩定幣協議分析:安全要點與監管難題

穩定幣在加密行業的交易、支付以及儲蓄中佔據至關重要的地位。截至目前,穩定幣市值約 2000 億美元...

coincaso
24 6天前