Aave: evolving slow systems in the age of speed | Ernesto Boado (BGD Labs)
三句話摘要
Aave 協議核心開發團隊 BD Labs 揭示其功能迭代與安全審核的決策框架，以流動性模式與虛擬帳戶兩個真實案例說明如何在協議演進與安全風險之間取得平衡。 協議安全的核心不是拒絕改變，而是建立嚴謹的三問評估框架、去中心化的多組織審核機制，以及開發者與審計員之間不間斷的持續溝通。 功能評估三問框架：每個新功能上線前，團隊必須依序回答三個問題——這個功能是否有高層次價值？它為現有代碼庫增加多少複雜度？安全審查的難度與所需時間為何？三者缺一不可，且越早發現問題越好，因為修改的是管理數十億美元資產的生產代碼。
重點整理
重點- 1
功能評估三問框架：每個新功能上線前，團隊必須依序回答三個問題——這個功能是否有高層次價值？它為現有代碼庫增加多少複雜度？安全審查的難度與所需時間為何？三者缺一不可，且越早發現問題越好，因為修改的是管理數十億美元資產的生產代碼。
- 2
流動性模式解決 E-mode 單一綁定限制：Aave V3 的 E-mode 原本限制每個資產只能屬於一個效率模式，導致 LRT 對 LST、LST 對普通資產等多重用例無法在同一池中實現。流動性模式讓資產可同時參與多個 E-mode 子組，在架構改動相對有限的前提下大幅擴展用例覆蓋。
- 3
虛擬帳戶是防禦性縱深設計：Aave 長期以來動態讀取 `balanceOf` 來判斷流動性，這種模式容易受通脹攻擊與餘額操縱影響。虛擬帳戶將流動性追蹤改為內部儲存變數，雖然改變了協議不變性的驗證方式，但屬於增量防禦（defense in depth），不破壞主流程，同時對代碼審查友好，代碼量也相對精簡。
- 4
去中心化組織結構降低單點失敗風險：BD Labs 刻意仿效以太坊多客戶端模式，與 Chaos Labs、獨立緊急應對實體（如 Multi6）等多個技術獨立的組織平行運作，所有參數調整、新資產上架或新網路部署均需鏈上治理合約授權，確保沒有單一組織握有完全控制權。
實用技巧與重點
乾貨- Aave V3（AB3）目前版本為 V3.2，已部署於 11 個網路，V2 部署於 3 個網路
- 協議支援資產超過 100 種，市值達數十億美元
- 資產類型包含：流動性質押代幣（LST）、流動性 Restaking 代幣（LRT）、穩定幣、跨鏈橋資產
- 新功能：Liquidity Mode（流動性模式）——允許單一資產加入多個 E-mode，主要用於 LRT vs LST、LST vs 普通資產等子組
- 新功能：Virtual Accounts（虛擬帳戶）——以儲存變數取代 `balanceOf`，防禦通脹攻擊與餘額操縱類漏洞
- 安全流程包含：單元測試、代碼審查、形式驗證（Formal Verification）
- 組織架構：BD Labs（核心開發）、Chaos Labs（安全貢獻）、Multi6（緊急應對實體）、DAO 治理合約（最終授權）
- 代碼變更流程：Pull Request → BD Labs 審核 → 鏈上治理投票 → 自動執行
- 審計偏好：持續溝通模式（非最終交付才給反饋），安全專家與開發者全程保持對話
- 正在推進：GitHub 組織去中心化，讓多個獨立貢獻者擁有各自維護的 repo，統一歸屬 DAO
結論
結論“協議安全的核心不是拒絕改變，而是建立嚴謹的三問評估框架、去中心化的多組織審核機制，以及開發者與審計員之間不間斷的持續溝通。”
完整解析
詳細BD Labs 聯合創始人 Ernesto B 在這場演講中，從一個協議核心開發者的視角，說明 Aave 如何在高速增長的 DeFi 環境中安全地演進協議。他首先點出當前的現實背景：Aave 已是一個橫跨 11 個網路、管理超過百種資產、市值達數十億美元的大型基礎設施，這意味著任何代碼改動都牽動著龐大的生產資金，靜態不變固然安全，但拒絕演進等於放棄生態競爭力——尤其是 LST、LRT 等新資產類型每年湧現，原有協議若無法跟上就會失去市場。
為了讓演進有序且可控，BD Labs 建立了一套三問框架來評估每個新功能：第一，這個功能在高層次上有沒有真實需求？第二，它對現有代碼庫增加多少複雜度？第三，安全審查的難度和時間成本是多少？Ernesto 以流動性模式（Liquidity Mode）為例說明這套框架的運作。Aave V3 的 E-mode（效率模式）原本限制每個資產只能綁定一個效率模式，這在 LRT 對 LST、LST 對一般資產等多重組合場景中形成了障礙。流動性模式突破這個限制，讓資產可同時參與多個 E-mode 子組，邏輯改動相對獨立、可隔離，代碼審查友善，加入新安全合作夥伴也因此更容易上手——三個問題的答案都指向「值得推進」。
第二個案例虛擬帳戶（Virtual Accounts）則源自於一個安全觀察。Aave 長期以動態讀取 `balanceOf` 的方式判斷池內流動性，這種設計在通脹攻擊（Inflation Attack）與餘額操縱類漏洞中暴露了潛在風險。虛擬帳戶將流動性追蹤改為內部儲存變數，屬於「縱深防禦」（Defense in Depth）設計，本身不破壞現有主流程，但改變了協議不變性的驗證方式（從 `balanceOf` 變為儲存變數）。由於是升級部署，整個系統的虛擬餘額必須在升級時全面重新初始化，這需要極為謹慎的數據遷移規劃，以避免影響成千上萬個已在生產環境運行的用戶倉位。
在組織與安全流程層面，BD Labs 刻意仿照以太坊多客戶端的去中心化模式運作：安全貢獻由多個技術獨立的實體並行負責，包括 Chaos Labs、緊急應對實體 Multi6 等；所有協議變更——從資產上架到新網路部署——都必須通過鏈上治理合約投票後才能執行，BD Labs 只負責審核提案而非單方決策。在審計方式上，他們明確偏好「持續溝通」而非「最後交付才給反饋」，認為開發者與安全研究員的全程對話能更有效地傳遞協議的內部邏輯，避免理解落差演變成被忽略的漏洞。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
