慢霧：AAVE V2 安全審計手冊
引言
隨著去中心化金融(DeFi)生態系統的迅速發展，AAVEV2作為領先的去中心化借貸協議之一，在提供創新借貸與流動性管理解決方案方面始終處于行業前沿。其獨特的無信任機制和高效的資本利用率吸引了大量用戶和機構的參與。然而，隨著其應用的普及及所涉及的資金規模逐步擴大，安全審計和風控措施的重要性日益凸顯。本手冊將深入探討AAVEV2協議的核心設計、關鍵功能及相關審計要點。項目背景概述
AAVEV2是一個基于EthereumBlockchain構建的開放式借貸平臺，允許用戶存入各種ERC-20Tokens并從中賺取利息，同時也允許以支付利息的形式借用市場中的Tokens。通過引入“利率市場”的概念，AAVEV2實現了去中心化的資金池管理和自動化的利率調整機制。此外，AAVEV2還提供了閃電貸、抵押貸款和Tokens交換等高級功能，以滿足用戶的多樣化需求，進一步鞏固了其在DeFi領域的領先地位。項目架構分析
OraclesProxy：依賴外部預言機(Chainlink)提供資產市場價格數據，用于評估用戶抵押資產的價值，確保借貸行為的定價準確性和系統的穩定性。
LendingRateOracle：根據系統的狀態和市場情況，提供動態的借貸利率，優化資本利用率和流動性。配置與管理
Configurator：用于配置系統參數，如不同資產的風險參數和借貸限額，管理儲備金的各種操作，包括激活、借款、抵押、凍結、更新參數及在緊急情況下啟用或禁用功能。確保協議可以根據市場變化進行動態調整。其他關鍵功能
LiquidationManager：當用戶抵押品價值下降至清算門檻以下時，管理清算操作，保護系統的資金安全。清算人可以通過清算操作獲得獎勵。
ReservesBalances：存儲系統的儲備資金數據，用于計算和調整利率策略。利率策略
InterestRateStrategy：根據市場和用戶需求，動態調整利率以實現最佳資本配置，同時考慮流動性風險，確保系統在不同市場條件下的靈活性和穩定性。
盡管存在兩種利率模型（穩定型和浮動型），但是其模型計算都類似于一個拐點型模型。在拐點最優利用率下的slope1和超過最優利用率的slope2分段計算，且在這個條件下也分為固定利率模型和可變利率模型。
用戶通過調用LendingPool合約的deposit函數進行存款，該函數接受四個參數：資產地址、存款金額、接收方地址及推薦碼。首先驗證合約未處于啟用狀態，然后通過ValidationLogic.validateDeposit驗證存款金額必須大于0，同時確認儲備處于激活狀態且未被凍結。接著系統會更新儲備狀態，調用reserve.updateState()更新流動性累積指數和可變借款指數，并計算時間段內產生的利息，其中一部分利息會被鑄造并轉入協議國庫。
公式如下：
與Compound相比，AAVEV2的提現過程有以下主要特點：
使用aToken代表用戶在協議中的存款，提現實際上是銷毀aToken。
允許用戶提現到指定地址（通過to參數），增加了靈活性。
提供了部分提現和全額提現的選項。
在提現驗證中，AAVE使用了更復雜的balanceDecreaseAllowed函數來檢查提現對用戶整體抵押品狀況的影響。
AAVE的提現過程直接更新了利率，而不是像Compound那樣通過accrueInterest函數來更新。借貸
用戶通過borrow函數進行借貸，執行借款會先從價格預言機獲取資產的當前價格，將借款金額轉換為ETH等價。隨后通過ValidationLogic.validateBorrow檢查以及GenericLogic.calculateUserAccountData用戶借款是否合法，計算包括onBehalfOf地址的總抵押資產、總債務、當前貸款價值比率(LTV)、清算閾值和健康因子以及市場的穩定性等（類似于Compound的getHypotheticalAccountLiquidityInternal），是否有足夠的抵押資產借貸。reserve.updateState更新儲備狀態，如利率和借款指數（這一步類似于Compound中的accrueInterest），用于計算并更新利息。
隨后根據用戶選擇進行的interestRateMode（穩定利率或浮動利率）生成債務，選擇不同的利率模型的Tokens合約來鑄造Tokens。同時，鑄造Tokens時也會進行檢查，如果onBehalfOf地址不是調用者，則會在Tokens合約中減去其對調用用戶的借貸授權。如果是用戶的首次借款，會將其配置為活躍借款者。DebtToken鑄造給用戶后，協議會通過updateInterestRates更新借款利率，反映借款后的新利率和儲備池的變化。如果用戶請求釋放借款的底層資產，協議會將資產直接轉移給用戶。
與Compound相比，AAVEV2的借貸過程有以下主要特點：
支持穩定和可變兩種利率模式。
使用單獨的驗證邏輯合約進行借貸驗證。
使用債務Tokens(DebtToken)來表示用戶的借款。
支持信用委托，允許用戶代表其他地址進行借款。
還款
用戶通過repay函數進行還款，首先獲取用戶的當前債務（包括穩定債務stableDebt和浮動債務variableDebt）。根據用戶選擇的利率模式（穩定或浮動），由ValidationLogic.validateRepay驗證用戶的還款操作合法性，包括用戶的債務余額是否足夠進行還款。根據用戶選擇的利率模式來確定還款的具體債務類型（穩定利率或浮動利率）。如果用戶要還的金額小于當前債務余額，系統會使用用戶提供的還款金額進行部分還款；否則，將償還所有債務。更新儲備的狀態updateState，用于計算并更新協議中的利息、借貸量以及借貸指數。隨后燃燒相應的穩定債務Tokens，并通過updateInterestRates更新借款利率。此時，如果用戶的所有債務（包括穩定和浮動債務）在還款后為零，則會將該用戶的借款狀態標記為false，表示用戶不再借款。最后用戶將還款金額從其賬戶轉移到協議的aToken合約地址。
與Compound相比，AAVEV2的還款過程有以下主要特點：
支持穩定和浮動兩種利率模式的還款。
使用DebtToken來表示和管理債務，還款時燃燒對應債務Tokens。
支持部分還款和全額還款，并分別處理穩定債務和浮動債務。
支持用戶通過信用委托為其他地址還款。清算
用戶通過lendingpool的liquidationCall函數進行清算，函數通過代理模式調用LendingPoolCollateralManager的liquidationCall函數，確保函數的成功執行。首先GenericLogic.calculateUserAccountData獲取抵押品資產及債務資產的儲備數據和用戶的配置信息，計算用戶的健康因子，并通過getUserCurrentDebt獲取用戶的當前穩定和可變負債。
ValidationLogic.validateLiquidationCall函數驗證清算調用的合法性，包括檢查用戶的健康因子、債務狀態和抵押品配置。若健康因子小于閥值，已作為抵押品，且兩種債務都不為0則驗證通過。接著計算用戶的最大可清算債務，并確定實際需要清算的債務數量。如果清算的債務超過用戶的可用抵押物，將調整清算金額。
如果清算人選擇接收被清算人抵押的底層資產，需要確保抵押物儲備中有足夠的流動性。更新債務儲備的狀態，并根據清算人是否接收aToken情況，燃燒相應數量的可變和穩定債務Tokens。更新債務的利率，反映清算后的市場情況。清算人獎勵如果選擇接收aToken，清算人將獲得相應數量的aToken。如果不接受aToken，則更新其抵押狀態和抵押物的利率，從用戶賬戶中燃燒掉對應數量的aToken，將底層資產轉移給清算人。最后，將清算所需的債務資產從清算人轉移到相應的儲備aToken中，完成清算過程。
與Compound相比，AAVEV2的清算過程有以下主要特點：
支持多種抵押品和債務資產的組合清算。
允許清算人選擇接收aToken或底層資產。
清算過程更加模塊化，將驗證邏輯、計算邏輯等分離到不同的函數中。
支持穩定利率和可變利率兩種債務類型的清算。閃電貸
用戶通過lendingpool的flashLoan函數進行閃電貸。作為借貸協議的閃電貸，可以允許當前閃電貸立刻還款或是作為債務來后續還款，其中以傳入的modes參數不同而決定。0為立刻還款，1為作為穩定型債務，2為浮動型債務。
函數首先通過ValidationLogic.validateFlashloan檢查輸入參數匹配，計算閃電貸所需的溢價成本，并直接將所需的aToken轉給接收者地址。調用接受者的executeOperation操作實現預設的閃電貸。AAVE實現的閃電貸操作已包括了兌換，兌換清算，以及兌換償還操作。在executeOperation完成以上操作后，記錄需償還的閃電貸金額和相應的費用。如果用戶選擇以非債務模式歸還資金：系統更新儲備狀態，累積儲備流動性以及更新流動性指數。最后再從請求者轉移資金和費用至儲備池。若用戶選擇以債務模式處理，則調用_executeBorrow，開啟相應的債務頭寸。轉換債務模式
在AAVEV2中，用戶可以通過swapBorrowRateMode函數在穩定利率模式和浮動利率模式之間切換。首先通過getUserCurrentDebt函數獲取用戶在目標資產上的當前穩定利率債務和浮動利率債務，確定用戶的債務狀況。接著調用ValidationLogic.validateSwapRateMode函數驗證切換操作是否合法。其中檢查用戶是否有足夠的穩定或浮動債務以支持模式切換，確保切換目標模式符合資產的配置和用戶的債務情況。調用reserve.updateState更新資產儲備的狀態，確保儲備數據最新。隨后就是對于兩種債務Tokens的相互轉換，燃燒穩定債務Tokens鑄造浮動債務Tokens或是燃燒浮動債務Tokens鑄造穩定債務Tokens。轉換完成后，reserve.updateInterestRates更新目標資產利率，確保反映當前市場狀態和用戶債務的變化。安全漏洞Checklist空市場導致的舍入漏洞
在AAVE和Compound中，都存在空市場中精度損失而造成的漏洞問題。如果在一個空市場的情況（即沒有用戶在市場中進行借貸），由于cumulateToLiquidityIndex函數中liquidityIndex的值依賴于合約對應的底層資產Tokens的數量，所以攻擊者可以通過閃電貸向合約存入大量的底層資產Tokens來操縱aToken的價格。
與之前Compoundfork項目HundredFinance第一次被黑相似，在HopeLend事件中，攻擊者先操縱liquidityIndex將hETHWBTC兌WBTC的價值控制為1:1，通過兌換底層資產以及借貸的方式又提高liquidityIndex的值。隨后通過循環的閃電貸不斷調用_handleFlashLoanRepayment函數。
審計要點：在審計時，需要關注兌換率的計算方式是否容易被操控以及舍入的方式是否恰當，同時可以建議項目團隊在新的市場創建后立刻鑄造aToken，以防止市場為空進而被操控。ERC677/ERC777Tokens導致的重入漏洞
與之前Compoundfork項目HundredFinance第二次被黑相同，在Agave攻擊事件中，攻擊者在沒有任何負債的情況下調用了liquidateCall函數來清算自己。而清算的Tokens是GnosisChain鏈上使用的ERC-677標準Tokens，該類Tokens轉賬時會外部調用接收地址的函數,所以使得清算合約調用了攻擊合約，攻擊合約在此過程中存入了2728個通過閃電貸獲取的WETH，鑄造出2728aWETH，并以此為抵押，借出了Agave項目中所有可用資產。外部調用結束后，liquidationCall函數直接清算了攻擊者之前存入的2728aWETH，并將其轉給清算者。
審計要點：在審計時，需特別關注與外部第三方協議的交互代碼。重點評估外部合約的輸入和輸出是否經過嚴格限制，交互邏輯是否對協議核心模型或資金安全產生潛在影響，輸入數據是否經過清理和驗證，防止惡意數據引發安全問題。通過嚴格審查外部交互的代碼邏輯以及數據驗證機制，可有效降低此類漏洞風險。Tokens與利率策略兼容問題
在Polygon鏈上，AAVE部署過程中，由于InterestRateStrategy設置不兼容的問題導致功能異常，錯誤地為WETH設置了不兼容的利率策略。
錯誤設置的InterestRateStrategy合約中的interface如下：
而AAVEV2的LendingPool實現的代碼如下：
(參考來源：https://x.com/mookim_eth/status/1659589328727859205)
由于接口不兼容，新InterestRateStrategy無法正常被LendingPool調用，直接導致AAVEV2的WETH池功能中斷，用戶無法存入或提取ETH。
審計要點：在審計時，需確保代碼（或fork）中關鍵組件的接口完全兼容。同時，盡管以上問題并不是由多鏈特性導致的原因，但是審計時仍需要注意不同鏈的特性下是否會造成非預期的結果。DustTokens問題
AAVE的存款和取款會通過setUsingAsCollateral函數設置usingAsCollateral來實現，從而靈活地管理抵押策略。當外部協議或合約通過AAVE借貸函數第一次借入資金時，借貸函數會將usingAsCollateral設置為true。當外部協議或合約從AAVE完全提取資金時，AAVE中協議處理程序的usingAsCollateral狀態將被設置為false。但實際上，AAVE在計算取款需要燒掉的aToken數量時，此時如果由于算術精度誤差，協議處理程序中可能還有極少的aToken剩余。因此，當協議處理程序下次向AAVE存款時，usingAsCollateral將不會變動，依然設置為true，由于協議處理程序合約中沒有調用setUserUseReserveAsCollateral函數的接口，這可能導致協議處理程序無法再執行借款操作。
審計要點：在審計時，需要對所調用的協議有充分的熟悉度，充分了解其特性的情況下，判斷是否對于其與外部協議交互存在一定的兼容性問題，如Tokens兼容性、調用實現邏輯兼容性等。
寫在最后
本手冊深入探討了AAVEV2協議的核心設計、關鍵功能及相關審計要點，我們希望該手冊可以更好地幫助開發人員和安全研究人員識別潛在風險并確保協議的安全運行。由于篇幅限制，本文省略了部分代碼和圖片，讀者可點擊文末的閱讀原文跳轉至GitHub閱讀完整版(https://github.com/slowmist/AAVE-V2-Security-Audit-Checklist)。