ERC-8211：智慧批次處理 — 智慧帳戶的執行階段參數解析與斷言門控執行

摘要 (Abstract)

智能批處理（Smart Batching）是一種批處理編碼標準，其中每個參數都聲明了 如何在執行時獲取其值 以及 該值必須滿足什麼條件。參數可以是字面量（Literals）、實時的靜態調用（staticcall）結果或餘額查詢 —— 每個參數都在鏈上獨立解析，並在組裝成調用之前根據內聯約束進行驗證。

至關重要的是，批處理不再僅僅是一系列步驟的序列 —— 它可以包含內聯 斷言（assertions）：即執行必須滿足的鏈上狀態條件。用戶不僅僅是說「執行 A，然後執行 B」；他們說的是「執行 A，斷言結果是可接受的，然後執行 B」。步驟和斷言在同一個批處理編碼中是平等的，這將盲目的交易列表轉變為具有內置安全保障的可驗證程序。

這消除了靜態批處理（ERC-4337, EIP-5792）的根本限制：即每個參數在簽署時就被凍結，對執行時的鏈上狀態一無所知。如果交易（Swap）返回的代幣少於預期、Gas 成本發生變化，或者跨鏈橋交付時出現意外滑點 —— 批處理就會回滾。目前的唯一解決方案是為每個多步流程部署自定義智能合約，或者依賴並非每個目標合約都會提供的協議級滑點參數。

拉取請求 (Pull Request): Add ERC: Smart Batching by oxshaman · Pull Request #1638 · ethereum/ERCs · GitHub

完整規範 (Full Specification): ERCs/ERCS/erc-xxxx.md at smart-batching · oxshaman/ERCs · GitHub

---

動機 (Motivation)

現實世界的 DeFi 流程會產生動態且不可預測的輸出。一次交易產生變動的代幣數量；從借貸池撤資返回變動的份額對資產轉換率；跨鏈橋在不可預測的延遲後交付代幣並收取變動的費用。靜態批處理強迫用戶在兩個糟糕的選擇中做決定：硬編碼樂觀的金額（面臨回滾風險）或保守地低估金額（導致價值殘留）。

智能批處理在執行時解析參數。用戶簽署一個批處理，其中每個參數指定 如何獲取其值（作為字面量、靜態調用或餘額查詢），而不是預先編碼一個靜態的 calldata 二進制大對象。執行邏輯在交易過程中解析每個參數並從頭構建 calldata。

但動態解析只是故事的一半。另一半是 斷言（assertions） —— 批處理能夠聲明在執行過程中任何點必須為真的條件。今天的批處理是動作的扁平列表：「調用 A，調用 B，調用 C」。如果調用 A 的結果不利，你只有在整個批處理回滾後（或者更糟，以錯誤的結果成功後）才會發現。通過智能批處理，斷言作為一等公民存在於步驟之間，讓用戶可以表達：「調用 A，驗證輸出至少為 X，然後調用 B」。批處理變成了一個帶有嵌入式安全檢查的程序，而不是一個全憑運氣的腳本。

靜態批處理 (當前模型)
步驟 1: swap(100 USDC) → 成功
步驟 2: supply(0.05 WETH) → 回滾 (實際輸出為 0.0495)
問題：「0.05」是在簽名時的猜測。
無法表達「僅在輸出 ≥ 閾值時繼續」。

智能批處理 (本標準)
步驟 1: swap(100 USDC) → 成功，返回 0.0495
斷言: BALANCE(WETH, account) ≥ 0.04 ✓ (用戶定義的安全底線)
步驟 2: supply(amount) → amount = BALANCE(WETH, account) = 0.0495 ✓
參數在鏈上解析。斷言守衛每次轉換。

關鍵設計決策

1. Calldata 構建，而非佔位符修補

智能批處理是從頭開始構建 calldata，而不是在已知偏移量處使用哨兵字節預編碼 calldata 並進行修補 —— 每個 InputParam 都是自包含的，帶有其獲取器類型、路由目標和約束。不需要偏移量運算，也不需要了解目標函數的 ABI 佈局。

2. 編碼優先，與帳戶標準無關

該標準定義了編碼方案和接口，而不是特定的模塊。同樣的 ComposableExecution[] 編碼可用作：

• ERC-7579 執行器模塊
• ERC-6900 插件
• 原生帳戶 方法
• ERC-7702 委託目標

統一的傳輸格式。統一的接口 (IComposableExecution)。薄適配層處理安裝和權限；核心邏輯是共享的。

3. 斷言作為一等批處理條目

在所有現有的批處理標準中，批處理條目意味著「執行此調用」。智能批處理引入了第二種條目：斷言（assertion） —— 批處理繼續執行必須滿足的鏈上狀態條件。斷言不是附加組件；它們使用與動作條目相同的 InputParam 解析和約束機制，只是沒有調用目標。

這在三個方面具有重要意義：

無需自定義合約的安全性。 今天，如果你想強制執行「僅在我的交易輸出超過閾值時才存入 Aave」，你需要一個定製合約（或一個恰好暴露 minAmountOut 參數的協議）。通過斷言，安全檢查是批處理本身的一部分 —— 任何用戶都可以在任何解析值上對任何協議表達任意條件，而無需部署任何內容。

防範 MEV 和狀態操縱。 斷言讓用戶能夠防範夾心攻擊、預言機操縱和不利的執行條件。批處理可以斷言價格餵價在預期範圍內、資金池儲備未被扭曲或餘額滿足最小值 —— 所有這些都在同一筆交易中原子化地評估。如果任何斷言失敗，整個批處理會在價值損失前回滾。

可組合的意圖表達。 斷言將批處理從命令式腳本（「做 X，做 Y」）轉變為聲明式程序（「做 X，要求 P，做 Y」）。用戶表達他們認為可接受的結果，而不僅僅是要採取的行動。這是一個根本不同的模型 —— 批處理編碼意圖，而 EVM 強制執行它。

4. 通過約束產生的湧現謂詞

每個解析值都可以攜帶內聯約束（GTE, LTE, EQ, IN）。一個沒有調用目標（address(0)）的條目變成了鏈上狀態的純布爾門控 —— 即 謂詞條目（predicate entry）。不需要單獨的謂詞機制。

這免費產生了跨鏈編排：中繼者通過 eth_call 模擬批處理，並在謂詞滿足時提交。多鏈流程作為單個簽名程序執行，每個步驟都由可驗證的鏈上謂詞門控 —— 與互操作層（原生橋、ERC-7683、ERC-7786，任何消息協議）無關。

5. 從交易到程序

const batch = smartBatch([
  swap({ from: WETH, to: USDC, amount: fullBalance() }),
  assert({ balance: gte(USDC, account, 2500e6) }),     // 如果交易輸出太低則中止
  supply({ protocol: "aave", token: USDC, amount: fullBalance() }),
  assert({ balance: gte(aUSDC, account, 2400e6) }),    // 驗證存款已入帳
  stake({ token: aUSDC, amount: fullBalance() }),
]);

步驟和斷言自由交織。開發者在 TypeScript 中編寫多步、多鏈程序 —— 動作 與 安全條件並排 —— 編譯為標準的鏈上編碼，簽名一次，並完全由 EVM 執行。無需合約部署。新流程無需審計週期。

核心原語 (Core Primitives)

輸入參數 (Input Parameters) — 每個參數指定兩個正交的關注點：

• 值去向何處 (TARGET, VALUE, CALL_DATA)
• 如何獲取值 (RAW_BYTES, STATIC_CALL, BALANCE)

輸出參數 (Output Parameters) — 將返回值捕獲到外部存儲合約中，供後續條目使用 (EXEC_RESULT, STATIC_CALL)。

約束 (Constraints) — 解析值上的內聯謂詞 (EQ, GTE, LTE, IN)。如果任何約束失敗，整個批處理將回滾。

存儲合約 (Storage Contract) — 具有按帳戶、按調用者隔離的命名空間鍵值存儲。支持瞬態存儲 (EIP-1153) 以提高 Gas 效率。

向後兼容性 (Backwards Compatibility)

完全向後兼容。編碼是自包含且增量的 —— 現有的智能帳戶不需要遷移。可與現有的 executeBatch 操作並行工作，並與 EIP-8141 Frame Transactions 向前兼容。

參考實現 (Reference Implementation)

github.com/bcnmy/composable-batch-erc/tree/main/contracts

composable-batch-erc/contracts at main · bcnmy/composable-batch-erc

通過創建帳戶為 bcnmy/composable-batch-erc 的開發做出貢獻。

參考實現包括：

• IComposableExecution.sol — 標準接口
• ComposableExecutionLib.sol — 帶有完整解析算法的共享庫
• Storage.sol — 外部命名空間存儲合約
• ComposableExecutionModule.sol — ERC-7579 適配器
• ComposableExecutionBase.sol — 原生帳戶集成基類

參考實現已通過審計，所有發現均已修復。

---

作者: Mislav Javor (@oxshaman), Filip Dujmušić (@fichiokaku), Filipp Makarov (@filmakarov), Venkatesh Rajendran (@vr16x)

我們歡迎對該規範的反饋，特別是關於：

• 約束機制以及四種約束類型 (EQ, GTE, LTE, IN) 是否足夠

• 存儲合約設計和瞬態存儲的權衡

• 用於跨鏈編排的謂詞條目模式

• 不同帳戶標準 (ERC-7579, ERC-6900, ERC-7702) 的集成考慮

        1 則貼文 - 1 位參與者
  
        [閱讀完整主題](https://ethereum-magicians.org/t/erc-8211-smart-batching/28135)