Pre-ERC：範圍限定代理授權 (AgentKeys) —— 針對代理人的功能範圍授權機制

問題

AI 代理（AI agents）正在獲得錢包。目前賦予代理鏈上權限的選項都很糟糕：

私鑰共享 – 代理可以執行任何操作。一旦模型上下文（context）洩露，你的資金就會化為烏有。

EIP-7702 – 允許外部帳戶（EOA）將執行權委託給合約，但這是「全有或全無」的。沒有內建的範圍限制，例如「僅限在 Uniswap 上調用 swap() 且上限為 100 USDC」。

ERC-7715 – 透過 JSON-RPC 進行錢包端權限授予。由錢包決定允許什麼。但這並未給予代理一個可以向任何協議展示的可攜式憑證。權限存在於錢包中，而非代理身上。

ERC-8118 – 經過生產環境驗證（在 WORLD3 上有超過 100 萬個錢包），具有時間限制和使用限制。最接近需求，但與單一委託人強耦合，不支援子委託（sub-delegation），沒有 calldata 限制，也沒有累計價值追蹤。

ERC-1207 (DAuth) – 2018 年曾嘗試過，但停滯不前，因為它要求每個目標合約都必須具備 DAuth 感知能力。

提議解決方案

一種委託原語（Delegation primitive）：由委託人向代理受託人發出的、經過簽名、有時間限制且具備功能範圍限制（capability-scoped）的授權。

具體範例

Alice 運行一個 DeFi 再平衡代理。她簽署了一份委託：

「代理 0xA1 可以在 Uniswap V4 Router (0x3fC9) 上調用 exactInputSingle()，每天最多花費 100 USDC，有效期為 7 天。該代理可以子委託唯讀的價格查詢，但不能委託交易（swaps）。」

代理攜帶這份簽名的委託。當它想要進行交易時，它將委託連同自己的簽名提交給 DelegationRegistry（委託註冊表）。註冊表驗證範圍、檢查累計支出並轉發調用。過程中沒有共享私鑰。Alice 可以隨時撤銷。如果代理被攻破，攻擊者只能執行委託所允許的操作。

核心結構

struct Capability {
    address target;           // 受託人可調用的合約
    bytes4 selector;          // 函數選擇器
    uint256 valueLimit;       // 最大累計 wei
    uint256 callsLimit;       // 最大調用次數
    bytes callDataConstraint; // 參數級別的限制
}

struct Delegation {
    bytes32 delegationId;
    address principal;
    address delegate;
    Capability[] capabilities;
    uint256 expiry;
    uint256 nonce;
    bytes32 parentId;         // 用於子委託
}

關鍵設計決策

鏈下創建 – 委託採用 EIP-712 簽名，並在執行時於鏈上驗證。創建時零 Gas 消耗。遵循 ERC-2612 的 permit 模式。

累計價值限制 – 追蹤委託生命週期內的總支出，而非單筆交易。100 USDC 的限制意味著總計 100 USDC。

白名單而非黑名單 – 預設拒絕。代理「只能」調用明確列出的內容。

強制縮小範圍的子委託 – 受託人可以將其功能的嚴格子集傳遞給子代理。絕不允許擴大範圍。樹狀結構，最大深度為 5。

單例註冊表 – 一個供錢包、瀏覽器和協議查詢「此代理能做什麼？」的統一合約。

核心接口

function executeDelegated(
    Delegation calldata delegation, bytes calldata signature,
    uint256 capIndex, bytes calldata callData, uint256 value
) external payable returns (bytes memory);

function revokeDelegation(bytes32 delegationId) external;
function invalidateNonce(uint256 newNonce) external; // 緊急按鈕
function subDelegate(
    Delegation calldata parent, bytes calldata parentSig,
    address newDelegate, Capability[] calldata childCaps, uint256 childExpiry
) external returns (bytes32 childId);

組合性

• ERC-8004 (代理身份) 用於受託人發現。

• EIP-7702 用於委託人上下文執行 (msg.sender = principal)。

• ERC-8203 (條件結算) 用於「誰授權此代理接受此結算？」。

• ERC-8183 (代理商業) 用於限定範圍的工作接收。

我正在尋求的建議

• Capability 結構是正確的抽象嗎？太細碎了？還是不夠細碎？

• 動態類型（bytes, string, arrays）的 calldata 限制很難可靠地執行。我們是否應該將限制僅限於靜態 ABI 類型？

• 子委託深度限制為 5。太低了？還是太高了？

• 註冊表應該是單例（singleton），還是應該由各個協議自行部署？

完整的規範與參考實現已就緒，將隨正式的 PR 一併發佈。

相關連結：ERC-8203, ERC-8004, ERC-8118

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/pre-erc-scoped-agent-delegation-agentkeys-capability-scoped-authorization-for-agents/28071)