ERC-4626 是一種標準，它改進了收益型保險庫的技術引數。它為代表單個底層 ERC-20 代幣份額的收益保險庫提供標準 API。本文將解釋 ERC-4626 的特點，以及該協議將可以預防哪些問題和風險。（前情提要： 讀懂以太坊EIP-4626：「代幣化保險庫」的通用標準）（背景補充：以太坊推新代幣標準 ERC-4626 : Balancer YFI Convex 已採用，統一 Defi 金庫 API ）

在引入 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 不知道操縱此函式的可能性。

延伸閱讀：資安專欄｜DeFi 聚合器 Rari Capital 駭客如何得手 2600 ETH？遭駭細節全解析

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 來加以緩解。

延伸閱讀：一文讀懂區塊鏈、預言機和 DeFi 的權益質押機制

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 保險庫整合的合適場景。

延伸閱讀：Bankless : 2022下半5大市場關注點 (以太坊合併, L2, Cosmos, ERC4626, 宏觀)