newsence
探索AI 對話

代理人鏈下條件結算接口標準建議

Ethereum Magicians·25 天前
原文

我正在探索生態系統是否缺少一個針對高頻鏈下交互（特別是針對自主代理人）的標準結算層。本提案旨在定義一個狹義的接口規範，用於標準化鏈下條件結算的封裝，以便錢包、中心節點、中繼者和裁決者能夠共享使用。

大家好 —— 我一直在探討生態系統是否缺少一個用於高頻鏈下交互（特別是針對自主代理，autonomous agents）的標準結算層。

最近的標準和提案似乎已經很好地涵蓋了身份、帳戶、權限和支付信號。但我還沒有發現一個針對鏈下條件結算（conditional settlement）本身的通用接口：包括類型化鎖定消息（typed lock messages）、結算證明引用（settlement proof references）、中繼索賠請求（relay claim requests）以及最小化的條件結算擴展接口。

我正在考慮針對僅限於此接口範圍的內容制定一個範圍狹窄的 ERC。

重要的是，我並非試圖標準化一個完整的支付通道網絡、路由層、隱私後端或再平衡算法。這個想法要窄得多：標準化錢包、樞紐（hubs）、中繼器（relays）和裁決者（adjudicators）可以共享的結算封裝（settlement envelope）。

為什麼我認為這很重要

1. 代理（Agents）似乎是鏈下結算系統的第一批真正天然用戶

從歷史上看，狀態通道和類似的鏈下系統對人類用戶來說一直很困難，因為它們需要：

在線狀態（liveness），

頻繁簽名，

爭議處理，

生命週期管理，

以及對流動性的感知。

代理非常適合這種模式：

它們持續在線，

它們可以自動簽名和驗證，

它們可以通過程序處理爭議，

並且它們可以在無需人工干預的情況下管理通道狀態。

因此，我的直覺是代理系統可能最終會為鏈下條件結算創造一個真正的用戶群體。

2. 大部分代理交互具有高頻、低價值的特點

許多代理交互看起來像：

循環的 API/工具付費，

數據源訂閱，

求解器（solver）或服務付費，

流式支付，

帶有退款路徑的條件執行。

對於這些流程，單次操作的鏈上結算通常成本太高或延遲太長，即使結合了帳戶抽象（AA）或私有 RPC 方法也是如此。

3. 現有標準涵蓋了相鄰層，但未涵蓋結算層本身

粗略地說，目前的技術棧似乎是：

身份 / 註冊標準，

帳戶抽象與權限，

支付信號，

特定應用的執行邏輯。

目前似乎缺少的是一個面向結算的共享接口，用於：

條件鎖定對象，

證明或存證引用，

基於中繼的索賠，

條件結算 / 退款語義及其與宿主通道生命週期的綁定。

思考這點的一種方式是：

支付信號標準告訴你何時應該進行支付，

本提案則試圖標準化鏈下條件結算如何表示和解決。

為什麼不直接使用 Rollups？

本提案並非旨在替代 Rollups。

Rollups 仍然是鏈上執行、組合性和最終結算的正確場所。然而，即使在 L2 上，許多代理原生交互在執行模型和工作負載之間仍存在不匹配：

每項操作仍需競爭打包和區塊空間，

每項操作仍帶有單次執行的執行/證明/數據開銷，

且延遲模型與亞秒級的鏈下協調有本質區別。

我試圖解決的特定差距是針對那些頻率太高、價值太低或循環性太強，以至於無法單獨納入鏈上（即使該鏈是 Rollup）的交互結算層。

從這個意義上說，我認為本提案與 Rollups 是互補關係而非競爭關係。

Rollups 非常適合低頻、高價值的執行。缺失的部分似乎是針對高頻代理交互（如流式支付、循環工具/API 使用和條件微支付）的標準化結算接口。

與 ERC-7824 的關係

我了解 ERC-7824。從其發布的資料和參考接口來看，它似乎已經涵蓋了宿主狀態通道框架層：生命週期管理、挑戰/檢查點/結束流程、資產託管和退出處理、應用會話、經紀人協調以及鏈下 RPC。

這意味著我不想重新定義 ERC-7824 類系統已經暴露的生命週期原語。特別是，挑戰（challenge）、檢查點（checkpoint）、結束（conclude）、存款/轉帳/回收（deposit / transfer / reclaim）以及應用定義的狀態驗證等接口，似乎屬於宿主通道框架。

我在此探討的內容更窄：一個可以置於此類框架之上的條件結算擴展或伴隨接口。我認為可能仍然缺失的層是一個共享的封裝，用於：

條件鎖定類型化數據，

證明引用，

中繼索賠請求，

條件結算 / 退款鉤子（hooks），

以及鎖定狀態查詢。

因此，真正的問題不是「取代 ERC-7824？」，而是「是否缺少一個應該與 ERC-7824 風格的通道系統組合使用的條件結算接口？」

如果正確的方向是「這應該是一個 ERC-7824 擴展配置文件 / 伴隨 ERC」而不是一個獨立的 ERC，那將是非常有用的反饋。

提議範圍

範圍內

我目前正在考慮標準化：

用於證明綁定條件義務的 EIP-712 類型化數據

證明/存證引用封裝

中繼索賠請求封裝

一個最小的鏈上條件結算擴展接口，包括 settleConditional、refundConditional 和 lockStatus

許多通道系統已經包含某種鎖定或待處理條件轉帳的概念。然而，這些對象通常是框架局部或應用局部的：它們被編碼在特定應用的狀態中，由特定框架的驗證器解釋，並且沒有作為可重用的面向結算的接口暴露出來。

缺失的不是「鎖定的存在」，而是證明綁定條件義務的通用封裝。特別是，當結算依賴於外部證據（如收據根、預言機存證、zk 證明或委託中繼索賠）時，通用的 PCN 鎖定就不再足夠。錢包、樞紐、中繼器、驗證器和裁決者需要一種標準方式來就以下內容達成一致：條件支付的內容、授權結算的證明、超時退款的工作機制，以及如何查詢當前的鎖定狀態。

示例：代理和樞紐可能已經共享一個支付通道，但代理只想在樞紐能夠證明外部系統中確實發生了私有執行時才付款。通用的 HTLC 風格鎖定並未說明哪個驗證者具有權威性、引用了哪個收據根或證明摘要、誰可以中繼索賠，或者第三方如何觀察該鎖定是待處理、已結算還是已退款。這就是本提案試圖解決的較窄的互操作性差距。

可能的選用擴展

這些可能是擴展而非核心內容：

能力發現（capability discovery）

私有索賠中繼

本地再平衡協調擴展

明確排除在範圍外

我不認為以下內容應包含在核心提案中：

宿主框架已涵蓋的通道生命週期原語，如挑戰、檢查點和結束

託管 / 退出原語，如存款、轉帳、回收和退出格式

HTLC 與虛擬通道的對比

特定的再平衡算法或協調策略

特定的隱私保護路由或樞紐盲化構造

特定的零知識電路內部細節

私有執行後端設計

運營商抵押 / 償付能力模型

樞紐業務邏輯或費用策略

我的目標是保持提案足夠窄，使其標準化的是一個接口層，而不是整個協議棧。

核心對象的初步形態

在高層次上，我正在考慮類似以下的內容：

struct ConditionalLock {
    bytes32 channelId;
    address initiator;
    address responder;
    bytes32 assetId;
    uint256 amount;
    uint256 fee;
    uint256 expiry;
    bytes32 conditionType;
    bytes32 conditionCommitment;
    bytes32 applicationCommitment;
    bytes32 escrowCommitment;
    uint256 channelNonce;
}

struct SettlementProofRef {
    bytes32 channelId;
    bytes32 lockId;
    bytes32 proofType;
    bytes32 settlementRoot;
    bytes32 proofDigest;
    address verifier;
    bytes32 auxDataHash;
}

struct ClaimRelayRequest {
    bytes32 channelId;
    bytes32 lockId;
    bytes32 escrowCommitment;
    bytes32 outputCommitmentHash;
    uint256 maxRelayFee;
    uint256 deadline;
    bytes32 proofType;
    bytes32 proofDigest;
    uint256 nonce;
}

以及一個最小的條件結算擴展接口，大致如下：

interface IAgentConditionalSettlementExtension {
    enum LockStatus {
        None,
        Locked,
        Settled,
        Refunded
    }

    function settleConditional(
        bytes32 channelId,
        ConditionalLock calldata lock,
        SettlementProofRef calldata proofRef,
        bytes calldata proof
    ) external;

    function refundConditional(bytes32 channelId, bytes32 lockId) external;

    function lockStatus(bytes32 channelId, bytes32 lockId) external view returns (LockStatus);
}

生命週期方法（如關閉/爭議或挑戰/檢查點/結束）有意未在此顯示，將由底層通道框架提供。

這只是一個草案，並非最終規範。

為什麼我認為這應該是一個結算層 ERC，而不是「完整的狀態通道 ERC」

我認為試圖在一個提案中標準化整個鏈下協議棧範圍太廣了。

不同的系統可能會在以下方面做出不同的選擇：

路由，

隱私，

再平衡，

證明系統，

流動性來源，

以及信任假設。

但它們仍可能受益於一個共享的條件結算封裝。

這就是我感興趣標準化的層次。

徵求反饋的問題

我特別希望得到關於以下方面的反饋：

  1. 這個問題是否真實存在，還是我正在重新發明一個我遺漏的現有標準？

  2. 將其定義為通用的「鏈下條件結算 ERC」，而不是「代理（agent）」ERC 是否更好？

  3. 提議的範圍對於 ERC 討論來說是否足夠窄？

  4. 能力發現應該是核心提案的一部分，還是明確作為擴展分開？

  5. 私有索賠中繼是否應該是一個單獨的提案而不是擴展？

  6. 僅標準化條件結算擴展接口，並明確將生命週期原語留給 ERC-7824 等宿主框架，這是否合理？

  7. 這應該是一個獨立的伴隨 ERC，還是作為 ERC-7824 類通道框架的明確擴展配置文件更有意義？

我已經有了一份更長的規範草案，但在將其完善為更正式的 ERC 之前，我想先確認問題陳述和範圍對社區來說是否合理。

提前感謝 —— 我特別歡迎關於先前技術的參考、對範圍的批評，以及認為這不應該成為 ERC 的理由。

        1 則貼文 - 1 位參與者

        [閱讀完整話題](https://ethereum-magicians.org/t/pre-erc-agent-off-chain-conditional-settlement-interface/27949)
https://ethereum-magicians.org/t/pre-erc-agent-off-chain-conditional-settlement-interface/27949