一文讀懂ERC-4626：DeFi代幣化保險庫的新標準

TLDR： ERC-4626 是用於代幣化保險庫 (Vault) 的標準。

在引入 ERC-4626 之前，每個保險庫都有其各自的規範和實現細節。這使得集成變得困難、容易出錯且浪費資源。

ERC-4626 試圖通過標準規範來解決這個問題，以降低集成工作量，並創建更一致和強大的實現模式，就像 ERC-20 一樣。

什麼是 ERC-4626 ？

ERC-4626 是一種標準，它改進了收益型保險庫的技術參數。它為代表單個底層 ERC-20 代幣市佔率的收益保險庫提供標準 API。

代幣化保險庫已經成為 DeFi 中極為常見的模式。收益聚合器、借貸市場、質押衍生品等許多 dApp 都利用和依賴於代幣化保險庫。代幣化保險庫的示例包括 Yearn 和 Balancer。作為一個收益聚合器，Yearn 保險庫使用戶可以存入數字資產並獲得收益。Balancer 是一個自動化的組合管理器和流動性提供商，其業務邏輯的核心依賴保險庫。這些保險庫管理各種池中的代幣。同時，它們將代幣管理與池子本身的邏輯分離開來。

協議通過代幣化其保險庫來增強流動性和靈活性。代幣化保險庫可以輕鬆進行交易，並在 DeFi 平台上使用資產。此外，它們還能夠創建多樣化、相互連接的金融產品。該行業一直倡導這種範式，通常稱為「貨幣樂高」。

然而，沒有適當的適應性或標準化的可組合性會帶來挑戰。它不僅使開發人員難以遵守 ERC-20 等行業標準，而且還會使新開發人員感到困惑。如果沒有適當的適應性或標準化，就很難審查新的變化並驗證集成的實施細節。

於是 ERC-4626 被提出來解決這個問題，並簡化集成，同時允許 DeFi 參與者最終採用更安全和強大的統一保險庫規範。這反過來也將減少協議可能遭受的攻擊面，同時在多個協議之間集成代幣。

ERC-4626 可以預防哪些安全問題？

通過提供統一的標準，ERC-4626 加速了跨協議集成的構建速度。熟悉的、統一的標準也更容易讓開發人員理解，從而減少編碼錯誤的可能性。這有助於防止可組合性問題。標準化還可以防止工作重複，因為社區只需要設計一次保險庫，而不是為每個協議單獨設計。由於這種設計工作通常容易出錯，它有助於避免重複已經建立但普遍存在的設計缺陷。

我們將在這裡介紹兩個案例研究，以展示 ERC-4626 可以預防哪些問題。

Rari Capital 事件

Rari Capital 被盜取了價值約 1100 萬美元的代幣，這相當於 Rari Capital Ethereum 池中所有用戶資金的 60 ％。

總的來說，Rari Capital 被駭客攻擊是由於不安全的跨協議實現。其 Ethereum 池通過將 ETH 存入 Alpha Finance 的 ibETH 代幣合約作為產出策略。這種特定策略通過某些合約及公式（具體如 ibETH.totalETH / ibETH.totalSupply 函數）跟蹤其 ibETH/ETH 匯率的價值，在此攻擊場景中可能會有錯誤的輸出，例如在調用 ibETH.work（）函數時，債務價值可能會被人為地膨脹。

攻擊者只需重複調用 RariFundManager 合約中的 deposit 和 withdraw 函數，就可以耗盡 Rari Fund Manager。deposit 和 withdraw 函數需要獲取池子的餘額以計算要發行給調用者的 REPT 代幣數量，或要發放給調用者的 ETH 金額，這個操作會分別調用 Alpha 池的 getBalance 函數，調用 ibETH 合約及其 totalETH 函數。Rari 不知道操縱此函數的可能性。

ibETH 合約中還有另一個函數：ibETH.work 。該函數可以調用用戶指定的任何合約。這使得 Rari 的 deposit 和 withdraw 函數可以變得可重入並被多次調用。

work 函數是一個可支付的函數，意味著用戶可以通過 work 函數控制 ibETH 合約中的 ETH 數量，從而改變 totalETH 函數返回的值。更糟糕的是，work 函數還支持調用任何其他合約，例如 RariFundManager。

通過這個函數，攻擊者可以再次發送 ETH 並增加 ibETH 合約中的 totalETH 金額，同時調用 RariFundManager 合約中的 withdraw 來贖回更多資產。

這次事件突顯了 DeFi 合約中集成不足和不兼容的設計所帶來的重大風險。它強調了像 ERC-4626 這樣的標準通過增加關鍵的安全和可預測性層可以防止這樣的攻擊，並促進統一行為和相互理解。

Cream Finance 事件

Cream Finance 遭受了一場複雜的攻擊，利用了平台中兩個基本弱點：可操縱的混合預言機和沒有上限的代幣供應。攻擊的關鍵部分是對混合預言機的操縱，這影響了 yUSD 代幣的感知價值。當攻擊者向 yUSD 保險庫發送大量 Yearn 4-Curve 代幣時，他改變了保險庫報告的匯率，因此還影響到了預言機對 yUSD 代幣的感知價值。

這裡的關鍵教訓是一個強大且無法操縱的價格預言機對於 DeFi 協議的穩定性至關重要。按時間加權平均價格（TWAP）預言機可以幫助防止此類駭客攻擊，因為他們對突然的價格操縱更具有韌性。

這些問題，以及其他脆弱的設計模式，可以通過謹慎採用和實施 ERC-4626 來加以緩解。

ERC-4626 中的潛在安全風險

使用新的協議總有一些取捨。對於代幣化的保險庫，將其集成到智能合約中可能存在潛在問題，需要特別注意。

管理 feeOnTransfer 代幣

如果保險庫旨在支持 feeOnTransfer 代幣，請在轉移資產時檢查保險庫中的金額和市佔率是否處於預期範圍內。

適當使用 decimals 變量

儘管 convertTo 函數應該無需使用 EIP-4626 保管庫的 decimals 變量，但仍強烈建議在可行的情況下鏡像底層 Token 的 decimals 。這種做法有助於消除潛在的混淆來源，並簡化各種前端和鏈下用戶的集成。

四捨五入

根據規範，保險庫實現者應意識到在不同的可變和視圖方法中需要特定且相反的捨入方向，因為在計算過程中更安全的做法是優先考慮保險庫本身而不是其用戶：

- 如果它正在計算要發行給用戶的股票數量，以獲得他們提供的某些基礎代幣的金額，或者它正在操作將特定市佔率的基礎代幣轉移給用戶，則應向下捨入。

- 如果它正在計算用戶必須提供多少市佔率才能獲得一定數量的基礎代幣，或者正在計算用戶必須提供多少基礎代幣才能獲得一定數量的市佔率，則應向上捨入。

其中首選捨入方向將是模稜兩可的是 convertTo 函數。為確保在所有 EIP-4626 保險庫實現中保持一致性，指定這些功能必須始終向下捨入。集成者可以自己模仿捨入方向向上的版本，例如通過添加一個 Wei 到結果來實現。

一個用戶通過贖回他們在保險庫中的股份（previewRedeem）來獲得基礎資產的數量，可能會與發行相同數量的股份（previewMint）時需要付出的數量有很大差異。這些差異可能很小（例如由於捨入誤差），也可能很大（例如保險庫實現了提款或存款費用）。因此，集成者應該注意使用最適合他們用例的預覽函數，並且永遠不要假設它們是可互換的。

覆蓋核心功能

為了實現或擴展預期的功能，建議使用現有的掛鈎而不是更改核心功能。這種做法可確保更易於管理的跟蹤，以進行有效的代碼測試和審核。

零市佔率

ERC-4626 的原始規範沒有概述如何處理保險庫中沒有市佔率的極端情況，以及保險庫是否應該像正常情況一樣工作或者回滾。這可能會成為混淆和錯誤的潛在來源。

保險庫作為價格預言機

關於預言機價格操縱攻擊的風險，這些 preview 方法返回的值儘可能接近準確。因此，它們可以通過更改鏈上條件進行操作，並且不總是安全用作價格預言機。 ERC-4626 規範包括允許不精確的 convert 方法和 totalAssets 方法，因此可以實現為強大的價格預言機。例如，在資產和股份之間轉換時，使用時間加權平均價格來實現 convert 方法是正確的。

具體實施問題

在進一步集成之前，集成者必須審查任何代幣化保險庫的實現，因為可能存在惡意實現，看起來符合接口規範，但其核心函數由完全不同的設計規範組成。

EOA 直接訪問

如果要直接訪問一個保險庫，則其實現需要具備可用於容納滑點損失或意外存款/提款限制的功能。與智能合約不同，EOA 沒有交易回滾的故障保護機制，如果在調用核心函數時沒有實現精確輸出，則無法回退。

擴展保險庫

隨著越來越多的參與者開始採用 ERC-4626 標準，我們將看到為該標準實施的更多擴展。例如，Superform 開發了一個試驗性的 Multi 保險庫擴展，支持在一個保險庫合約內使用不同的計算。自然而然，實現越偏離原始標準，引入新漏洞的可能性就越高。開發人員和審計人員可以根據用例找到自己的最佳選擇，以確定實際風險值。

需要注意的是，導致災難性事件的不是每個協議的最小添加，而是它們集成在一起時的總和。

上面提到的潛在攻擊向量是圍繞 ERC-4626 標準討論較多的一些問題。隨著採用率的增加，我們肯定將探索更多實現用例，以及更多與 ERC-4626 保險庫集成的合適場景。

原文連結