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

概述

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

拉取請求 (Pull Request): Add ERC: Agent Conditional Settlement Interface by xrqin · Pull Request #1614 · ethereum/ERCs · GitHub

問題

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

自主代理（Autonomous agents）是天然的狀態通道參與者：始終在線、能自動簽名和驗證，並且實際上能從人類所排斥的「活躍度要求（liveness requirements）」中獲益。然而，目前還沒有標準來規定不同的錢包、樞紐（hubs）、中繼器（relays）和裁決者（adjudicators）應如何在鏈下通道上下文中表示和解決受證明約束的條件義務。

本 ERC 規範的內容

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

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

兩個維度的規範標識符：

條件類型 (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）—— 中繼器代表代理提交索賠。
• 本地再平衡協調（Local Rebalancing Coordination）—— 用於通道間容量轉移的證書格式。

本 ERC 不規範的內容：

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

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

關鍵設計決策：

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

自 Pre-RFC 以來的變化：

根據社區反饋（感謝 @Aboudjem）：

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

參考集成模式：

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

開放問題：

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

徵求內容：

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

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

        1 則貼文 - 1 位參與者

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