自治状态网关：链下求解器的标准化执行路由协议

近期与 Agent 相关的 ERC 已经定义了 Agent 经济中的身份（8004/8239）、授权（8118）和托管（8183）层。ERC-8203 探讨了条件结算流程；自治状态网关（ASG）则更早地介入堆栈，将链下求解器输出标准化为可验证、可结算的状态。

ASG 将链下工作视为提议的状态转换。它定义了一个领域中立的网关，在该网关中，Agent 的输出——无论是代码补丁、漏洞证明、模型上下文更新、数据集转换还是策略更新——在最终结算前都会经过提交、抵押和验证。

为何现在关注此事

Agent ERC 堆栈在身份和商业方面的标准化速度，快于其在执行交接方面的标准化速度。

我们正进入一个阶段：Agent 将产生高价值、链下的结果，这些结果在到达账本之前就具有经济敏感性。如果没有标准的路由层，生态系统将面临每个市场都碎片化、临时性的验证网关。ASG 为这一中间步骤提供了一个标准形态：

链下结果 → 抵押承诺 → 验证者证明 → 争议窗口 → 结算

架构：核心 / 配置文件分离

ASG 采用分层设计，允许一个领域中立的引擎与特定领域的解释协同工作。

1. ASG 核心（网关）

核心层定义了通用的状态机和经济约束。

## Vyper 风格伪代码
struct StateTransition:
    proposer: address
    domain: bytes32              # 例如 REPOSITORY, MODEL_CONTEXT, DATASET
    job_id: bytes32
    commitment: bytes32          # keccak256(state_root, salt, proposer, job_id)
    state_root: bytes32          # 在提交后揭示
    evidence_hash: bytes32
    evidence_uri: String[256]
    collateral_reserved: uint256
    verifier_type: bytes32       # 例如 TEE, CI, MAINTAINER, ZK
    settlement_target: address

核心不变量：

• 揭示的 state_root 必须与先前的承诺匹配。
• 除非已预留抵押，否则转换不能结算。
• 验证者证明必须绑定 job_id、proposer、state_root、verifier_type、chain_id 和网关地址。
• 最早的有效承诺具有主要的索赔优先权。
• 结算和罚没是终局状态。

2. ASG 配置文件（领域）

配置文件定义了领域如何解释 state_root。

• 配置文件 A：仓库状态

state_root 是仓库补丁、PR 头提交或提交差异的哈希。

• 配置文件 B：漏洞证明

state_root 在抵押和排序被锚定之前，隐藏了一个可利用的证明。

• 配置文件 C：模型上下文更新

state_root 是应用提议更新后产生的上下文包的哈希。

• 配置文件 D：数据集转换

state_root 表示转换后数据集的 Merkle 根。

• 配置文件 E：策略状态

state_root 是提议的行动计划的哈希，例如 DeFi 再平衡或执行策略。

提交流程：网关路径

1. 提交

求解器用盐值对 state_root 进行哈希，并预留抵押。这减少了在建立排序之前的数据复制。

2. 揭示

求解器在承诺被锚定后，披露 state_root 和支持性证据。

3. 验证

网关将有效载荷路由到可插拔的验证器。参考实现优先采用 TEE，而 ASG 核心将验证器类型（如 CI、ZK、维护者签名、多签评估者）视为可插拔。

4. 争议

开启一个时间窗口，用于挑战、重复验证声明或仲裁请求。最早的有效承诺保留主要优先权；重复声明不会自动平分奖励。

5. 结算 / 罚没

最终状态被路由到 settlement_target。接受的转换进行结算；无效或欺诈的转换可能被罚没。

实现压力 / 参考工作

本草案源于实现压力，而非理论。首个参考实现 maceip/asg-genesis 源自早期关于 Agent 提交仓库改进和抵押化审核流程的工作。

示例参考流程：

1. 求解器发现针对某个仓库的安全补丁。
2. 求解器提交补丁哈希，并从虚拟化的内部账本中预留抵押。这对于高频工作流是高效的，不过 ASG 核心也支持直接 ERC-20 转账、Permit2 拉取和基于 Paymaster 的预留。
3. 求解器在排序被锚定后揭示补丁根。
4. TEE 验证器根据仓库审计策略运行补丁。
5. 如果被接受，则开启争议窗口。
6. 如果无人挑战，ASG 将转换路由到结算合约。
7. 如果自动验证无法得出结论，则通过维护者签名的仲裁路径解决转换。

开放问题

1. 队列范围

拥堵抵押应该按每个仓库、每个任务、每个验证者还是全局计算？

required_stake = base_stake * multiplier ^ unresolved_queue_depth

曲线应该是指数型、线性型、S 型还是基于拍卖？

2. 签名标准

ASG 是否应该强制要求 EIP-712 用于验证者证明，以确保更好的域分离和工具清晰度？还是允许 EIP-191 以实现更简单的验证者集成？

3. 一层 vs 二层

考虑到提交、揭示、验证、争议和结算的多步流程，ASG 是否实际上仅限于高吞吐量的二层网络？还是某些高价值的求解器输出值得在一层结算？

4. 配置文件注册表

ASG 核心是否应该维护一个已批准的配置文件模式的注册表？还是保持为一个仅路由字节和证明的哑网关？

5. 罚没逻辑

网关是否应该直接执行特定于配置文件的罚没逻辑？还是将罚没信号路由到 settlement_target？

边界声明

ASG 不定义 Agent 身份、技能分类、验证器内部逻辑、支付通道生命周期或市场用户体验。

它定义了网关路径：

提交 → 抵押预留 → 揭示 → 验证 → 争议 → 结算/罚没

这就是 ASG 所拥有的全部。

• 原文链接： ethereum-magicians.org/t...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～