草案 ERC：智能代理鏈下條件結算擴展介面

概述

這是針對 Agent 原生（agent-native）鏈下條件結算的正式 ERC 草案，由 RFC 前討論演進而來。

Pull Request: add ERC: Agent Off-Chain Conditional Settlement Extension Interface by xrqin · Pull Request #1614 · ethereum/ERCs · GitHub

問題

現有的 Agent 相關 ERC 涵蓋了身份、帳戶、權限和支付信號，但尚未定義一個通用的結算層，用於高頻的機器對機器（M2M）交互。

自主 Agent 是天然的狀態通道參與者：始終在線、能自動簽署與驗證，且實際上能從人類所排斥的「活躍性要求（liveness requirements）」中獲益。然而，目前缺乏一個標準來規範不同的錢包、樞紐（Hub）、中繼器（Relay）和裁決者（Adjudicator）應如何在鏈下通道語境中，表示並解決受證明約束的條件性義務。

此 ERC 標準化的內容

三個 EIP-712 類型化數據結構：

結構	用途
ConditionalLock	結算封裝——誰欠誰、欠多少、在什麼條件下、超時時間為何
SettlementProofRef	引用用於結算鎖定的證據——證明類型、摘要、驗證者地址
ClaimRelayRequest	允許中繼器代表 Agent 提交索賠，以實現隱私或便利性

兩個維度的規範標識符：

條件類型 (conditionType) —— 必須滿足哪種條件：

• HTLC, ORACLE_ATTESTATION, ZK_PROOF, MULTISIG, TIMELOCK, COMPOSITE

證明類型 (proofType) —— 使用哪種驗證路徑：

• RECEIPT_ROOT, ZK_PROOF, ORACLE_ATTESTATION, RELAY_CLAIM, MULTISIG_ATTESTATION, TEE_ATTESTATION

所有標識符均對人類可讀標籤使用 keccak256。第三方擴展遵循 keccak256("NAMESPACE.TYPE") —— 無需修改 ERC 即可添加新類型。

一個最小化的鏈上擴展接口：

function settleConditional(channelId, lock, proofRef, proof) external;
function refundConditional(channelId, lockId) external;
function lockStatus(channelId, lockId) external view returns (LockStatus);
function supportsConditionType(conditionType) external view returns (bool);
function domainSeparator() external view returns (bytes32);

三個可選擴展：

• 能力發現（Capability Discovery）—— 樞紐廣播支持的條件類型、證明類型、費用模型
• 私有索賠中繼（Private Claim Relay）—— 中繼器代表 Agent 提交索賠
• 本地再平衡協調（Local Rebalancing Coordination）—— 用於通道間容量轉移的證書格式

此 ERC 不標準化的內容：

• 通道生命週期（挑戰、檢查點、結論、關閉、爭議）
• 託管與退出（存款、轉帳、收回）
• 路由或再平衡算法
• 證明內部細節（ZK 電路、Merkle 樹細節、證明字節格式）
• 應用層協議（任務、訂單、市場）
• 樞紐經濟學（費用、抵押品、償付能力）

這些內容明確委託給宿主框架或留給實現者選擇。

關鍵設計決策：

• 獨立伴侶：不與任何特定框架耦合。此 ERC 可與 ERC-7824 等宿主框架組合，但在形式上不依賴它們。生命週期和託管仍由宿主框架負責。
• 零 Gas 快樂路徑：快樂路徑在鏈下以零 Gas 完成。鏈上接口（settleConditional / refundConditional）僅在爭議期間調用。正常結算通過共同簽名完成，無需觸碰區塊鏈。
• 證明系統不可知：proofType 識別驗證路徑（例如「使用 ZK 證明的驗證者合約」），而非證明內部細節（例如 Groth16 vs. PLONK）。這使得證明生態系統能夠在不破壞結算標準的情況下演進。
• 開放標識符註冊表：規範的條件類型和證明類型提供開箱即用的互操作性。任何人都可以通過 keccak256("NAMESPACE.TYPE") 慣例添加新類型。

自 Pre-RFC 以來的變化：
根據社區反饋（感謝 @Aboudjem）：

• 添加了證明類型標識符 —— 六個規範的 proofType 值，採用 keccak256 開放註冊慣例，防止實現碎片化。
• 明確了獨立定位 —— 旨在與 ERC-7824 及類似框架組合，而無形式耦合。
• 將批量結算移出範圍 —— settleConditional 是一個爭議路徑鉤子；快樂路徑在鏈下零 Gas 完成。批量結算更適合在宿主框架層解決，或作為未來的 ERC。

參考集成模式：

1. Agent 與樞紐在鏈下協商一個 ConditionalLock。
2. 宿主框架將該鎖定綁定到其原生狀態中。
3. 樞紐執行或路由請求的操作。
4. 系統生成一個 SettlementProofRef。
5. 快樂路徑通過共同簽名在鏈下完成 ← 零 Gas。
6. 若發生爭議：調用宿主框架生命週期 + settleConditional / refundConditional。
7. 若為私有索賠：中繼器提交 ClaimRelayRequest。

開放問題：

• 能力發現應作為核心標準的一部分，還是保留為擴展？
• 是否應更明確地說明與 ERC-8183 等應用協議的關係？
• 未來的 ERC 是否應為 capabilityURI 定義規範的 JSON 模式？
• 中繼費用結算是否應進一步標準化？
• 本地再平衡協調是否應拆分為專門的 ERC？

尋求：

• 對類型化數據結構和接口設計的反饋。
• 對規範標識符集的反饋（過多？過少？類別錯誤？）。
• 對貢獻參考實現或測試向量的興趣。
• 來自狀態通道 / 支付通道實現者的觀點。

完整規範見 PR。歡迎在此處或 GitHub 提供反饋。

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/draft-erc-agent-off-chain-conditional-settlement-extension-interface/28041)