ERC-8192：代幣化金庫的授權執行標準

大家好，

我想針對一個暫定名為 「代幣化金庫的授權執行」（Mandated Execution for Tokenized Vaults） 的新 ERC 提案發起初步討論。

流程說明： ERC 提案應提交至 ethereum/ERCs（而非 ethereum/EIPs）。此 EthMagicians 討論串是建議的第一步，並將透過 discussions-to 連結至草案。

相關連結

• 工作草案（規範）：mandated-vault-factory/docs/erc-xxxx-spec.md at master · tabilabs/mandated-vault-factory · GitHub
• 參考實現 (Foundry)：
• 測試：

摘要 (TL;DR)

此 ERC 為 ERC-4626 代幣化金庫 定義了一個極簡且具互操作性的委託策略執行介面，使外部執行者（代理/求解器）能夠在不持有授權方私鑰的情況下提交鏈上執行，同時由金庫在鏈上強制執行嚴格的風險限制。

核心概念：

• 金庫暴露一個標準化的 execute(…) 入口點。
• 授權方（Authority） 簽署一份 EIP-712 授權書（Mandate），定義：
  • 適配器白名單承諾（針對 (adapter address, adapter codehash) 的 Merkle 根），
  • 最大**單次執行回撤（drawdown）**限制，
  • 最大週期累計回撤限制（高水位線），
  • 可選綁定預期的操作批次（payloadDigest），
  • 哈希承諾的擴展內容（extensionsHash）。
• 執行者（Executor） 提交 execute(mandate, actions, signature, adapterProofs, extensions)。
• 金庫僅透過 CALL 執行適配器調用，隨後透過比較執行前後的 totalAssets() (ERC-4626) 來強制執行**斷路器（circuit breaker）**機制。

極簡介面（節錄）

struct Action {
  address adapter;
  uint256 value; // 在 Core v1 中必須為 0
  bytes data;
}

struct Mandate {
  address executor;
  uint256 nonce;
  uint48 deadline;
  uint64 authorityEpoch;
  uint16 maxDrawdownBps;
  uint16 maxCumulativeDrawdownBps;
  bytes32 allowedAdaptersRoot;
  bytes32 payloadDigest;
  bytes32 extensionsHash;
}

function execute(
  Mandate calldata mandate,
  Action calldata actions,
  bytes calldata signature,
  bytes32 calldata adapterProofs,
  bytes calldata extensions
) external returns (uint256 preAssets, uint256 postAssets);

設計目標 / 非目標

目標：

• 為金庫原生委託執行提供極簡的「細腰（thin waist）」介面，並具備強大的鏈上風險邊界。
• 同時支持 EOA（ECDSA）和合約授權方（ERC-1271）。
• 保持核心功能與 ERC-4626 金庫會計語義兼容。

非目標（至少在 Core v1 中）：

• 標準化完整的意圖（intent）系統、求解器市場或鏈下發現層。
• 在核心功能中支持任意 ETH 價值轉發（如有需要請使用擴展）。

動機

DeFi 正日益從「用戶手動調用合約」轉向「代理/求解器執行策略」。ERC-4626 標準化了資金池託管與會計，但尚未標準化一種信任最小化的方式，讓金庫將受限的執行權限授予第三方執行者。

現有標準涵蓋了鄰近層級（委託機制、意圖表達、智能帳戶執行），但缺乏一個針對金庫原生、風險受限的委託執行的極簡介面，且能滿足：

• 將授權保留在鏈下簽名中（EIP-712 / ERC-1271），
• 強制執行可調用策略組件（適配器）的白名單，
• 在金庫層級強制執行執行後的風險邊界（透過 ERC-4626 會計）。

規範概覽（核心）

核心概念：

• Action（操作）：對適配器的底層調用：{ adapter, value, data }。
  • 核心功能禁止原生價值轉移：action.value 必須為 0。
  • 調用僅透過 CALL 執行（禁用 DELEGATECALL）。
• Mandate（授權書）：帶有 nonce/deadline 重放保護的 EIP-712 簽名授權。
  • 支持 EOA 和 ERC-1271 合約授權方。
  • 包含 authorityEpoch 以在授權方輪換時進行簽名域隔離。
• 適配器白名單：針對 (adapter, extcodehash(adapter)) 的 Merkle 根，因此白名單會鎖定運行時字節碼。
• 斷路器（Circuit breaker）：
  • 單次執行損失限制：比較 preAssets = totalAssets() 與 postAssets。
  • 累計損失限制：比較 epochAssets（高水位線）與 postAssets。
  • epochAssets 會更新為該週期內觀察到的最大 totalAssets()。
  • 授權方可以調用 resetEpoch() 來開啟新週期。
• Extensions（擴展）：
  • 透過 extensionsHash = keccak256(extensions) 進行哈希承諾。
  • 規範編碼：extensions = abi.encode(Extension)，帶有嚴格遞增的唯一 ID。
  • 未知的必要擴展將導致回退（revert）；未知的可選擴展可能被忽略。
  • 擴展示例：SelectorAllowlist@v1 用於限制每個操作的 (adapter, selector) 對。

安全模型與注意事項

• totalAssets() 的可操縱性：此 ERC 的斷路器假設 totalAssets() 能夠抵抗執行者在同一筆交易中的原子操縱。估值可能被閃電貸操縱的金庫（例如使用現貨價格預言機）不應僅依賴此機制，應增加額外的保護措施（如 TWAP、預言機擴展）。
• 可升級代理適配器：字節碼哈希鎖定通常無法鎖定代理的實現合約；除非增加額外的鎖定機制，否則代理型適配器是不安全的。
• 重入 / 金庫繁忙：參考實現使用共享互斥鎖（mutex）來防止重入 execute，並防止在執行期間調用份額鑄造/銷毀入口點（deposit/mint/withdraw/redeem）。
• 禁止無限制的開放授權：如果 executor == address(0)，則 payloadDigest 必須為非零（綁定到預期的操作）。
• 審計狀態：參考實現未經審計，僅供討論。尚未經過正式的第三方安全審查。請勿在未經獨立審計的情況下用於生產環境。

預期問題 (FAQ)

Q1: totalAssets() 是否可以在同一筆交易中被操縱，從而規避斷路器？
是的，斷路器的強度取決於金庫 totalAssets() 的實現。從現貨價格（如 AMM 儲備）獲取估值的金庫容易受到同筆交易內的閃電貸操縱。這是規範中的明確注意事項（安全模型 §1）。建議的緩解措施是使用 TWAP 或基於預言機的估值，這可以透過擴展（例如 OracleValuation@v1）來強制執行。對於具有抗操縱會計機制的金庫（如借貸協議的 aTokens、質押封裝代幣），斷路器提供了有意義的限制。

Q2: 適配器白名單中的字節碼哈希鎖定對可升級代理適配器無效嗎？
正確。對於 ERC-1967 或類似代理，extcodehash 返回的是代理合約的字節碼哈希，而非實現合約的。代理升級會在不改變白名單字節碼哈希的情況下改變行為，因此升級前有效的 Merkle 證明在升級後依然有效。這已在草案和參考實現倉庫的 SECURITY.md 中記錄。建議的營運緩解措施為：(1) 長期授權優先選擇不可變適配器，(2) 當代理實現更改時，撤銷並重新簽署白名單根。未來的擴展可以增加實現層級的鎖定（如 ImplementationPin@v1），但這明確超出了核心功能的範疇。

Q3: 為什麼這應該是一個 ERC 而不是應用層的慣例？
ERC 層級的標準化能為整個執行者/代理生態系統提供共享介面：

• SDK 可組合性：代理框架和求解器網絡可以與任何合規金庫集成，無需為每個金庫編寫適配器。
• 審計複用：單一且經過審計的參考實現可降低每次部署的審計成本。
• 工具鏈：區塊瀏覽器、監控儀表板和風險分析工具可以統一解析所有金庫的 MandateExecuted 事件。
• 互操作性：存款人可以透過通用的鏈上介面評估金庫的風險約束（回撤限制、適配器白名單），無論金庫營運方是誰。
  如果沒有標準化，每個金庫都會用不兼容的介面重新發明執行委託，導致代理層碎片化。

Q4: 為什麼核心功能禁止 action.value != 0？這是否限制太嚴？
核心功能將 action.value == 0 作為基準線有三個原因：

• 會計清晰度：ERC-4626 totalAssets() 追蹤 ERC-20 餘額。原生 ETH 流動會產生斷路器難以推理的會計盲點。
• 減少攻擊面：允許透過適配器轉發任意 ETH 會引入重入和 Gas 操縱向量，使安全模型複雜化。
• 擴展路徑：如果金庫需要 ETH 流動，可以實現一個擴展（如 NativeValueForwarding@v1）並明確選擇加入。這在支持該用例的同時保持了核心功能的極簡。

徵求反饋（開放問題）

• Merkle 葉節點編碼安全性：目前草案使用 leaf = keccak256(abi.encode(adapter, codeHash))（64 字節原像）。OpenZeppelin 警告 64 字節的葉節點在某些構造中可能被重新解釋為內部節點。核心功能是否應該：
  • 為葉節點增加明確的域隔離 / 前綴，或者
  • 切換到帶有前綴的 abi.encodePacked，或者
  • 對白名單葉節點方案進行版本控制（例如 AdapterAllowlist@v2）？
• 原生 ETH 價值轉移：將核心功能保持為 value == 0 作為基準，並將 ETH 流動推向明確的擴展，這是否是正確的基準線？
• 回退數據大小 / Gas 操縱：實現是否應該限制回退數據（revert-data）的複製大小（代價是丟失完整的診斷字節），還是像參考實現一樣保留完整數據？
• 輸入大小限制：某些限制（操作數量/證明深度/擴展字節數）應該是強制要求的還是建議性的？
• 額外的標準化擴展：我們是否應該標準化常見擴展（預言機/TWAP 估值、滑點規則、適配器能力內省），還是保持核心極簡並讓生態系統自行定義？

後續步驟 (ERCs 提交流程)

• 建立 EthMagicians 討論串（即本帖）。
• 發布/確認公開的參考實現倉庫（規範 + 代碼 + 測試），以便評審者閱讀草案。
• 填寫草案中剩餘的前言內容（作者、discussions-to 等）。
• Fork ethereum/ERCs。
• 加入由草案轉換而來的 erc-XXXX.md。
• 開啟 PR；編輯將分配正式編號。
• 追蹤狀態進展：Draft → Review → Last Call → Final。

預先感謝各位的反饋。

— tabilabs (tabilabs) (lancy@tabilabs.org)

        3 則貼文 - 2 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/erc-8192-mandated-execution-for-tokenized-vaults/27877)