以太坊基金会正在迅速推进的应用层标准 ERC-8004，是以太坊有望在 AI Agent 领域的重要发力点。此前已经在文章《Trustless Agents：EF 如何通过 ERC-8004 改变 AI 与区块链的游戏规则》介绍了ERC-8004的背景以及整体的架构，但由于目前还是在未定稿阶段，所以在以太坊魔术师论坛中，已经有了 80 多条讨论。其中涉及大量技术细节，比如该标准的抽象程度和应该放多少数据在链上等。
为了方便理解目前的进展，以下是目前社区讨论中最重要9个话题。
TL;DR
最大分歧：
应把多少数据放到链上？（仅事件/日志 vs. 提供最小可读视图函数 vs. 进一步上链索引/聚合）
显著共识：
最小化但可组合——在不显著增加 gas 的前提下，暴露少量链上可读接口以便合约使用（例如读取单次验证/评分的整数结果）。
声誉机制应模块化——反对单一聚合分数，支持多源、多维的声誉提供与过滤。
支付与结算不应写进核心规范，但允许在反馈中引用付款证明以便索引器/上层协议利用。
授权/代理能力需要补齐（不能只限制 msg.sender == agentAddress）。
密码学验证保持方法无关（TEE、抽样重执行、ZK 等均可），谨慎对待上链成本。
热点未决：域名绑定与解析（域名 vs URL/ENS/DID）、是否「每域名一个 Agent」、单例注册表 vs 多注册表生态、跨链身份可移植、是否需要事件/争议注册表。
1. 链上 vs 链下数据与合约可组合性
在讨论什么
现稿将「评分/验证响应」等核心数据主要放在链下（事件为主），合约读不到，从而限制了链上可组合（如托管释放、策略聚合、白名单过滤等）。
主要建议
增加最小链上读取接口（view）：
读取某验证响应或反馈的整数结果/ID（如 getValidationResponse(...) returns (uint256)、getAuthFeedbackIds(...) returns (uint256[])）。
可选增加任务/技能/上下文标识（有分歧：字符串/URI 上链气价高，建议以 bytes32 或 uint64 等小型字段承载）。
引入任务 taskId（预先引用），支持在「数据哈希生成前」绑定与查询（便于通用托管释放条件）。
将丰富元数据（反馈详情、签名、付款证明等）放到链下 URI（如 feedbackURI），必要时附 EIP‑712 签名，链上仅存引用与小字段。
利用 EAS（Ethereum Attestation Service） 做辅助索引/证明（作为可选扩展）。
共识倾向
✅ 赞成加少量链上可读字段/接口以解锁合约可组合场景（多数作者也正面回应）。
⚠️ 对「上链多少」仍有拉扯：整数/哈希可以，长字符串/URL不建议。
2. 身份与解析：域名 / URL / ENS / DID / AgentID
在讨论什么
是否强制.well‑known 域名卡片？「每域名仅一个 Agent」？如何验证域名所有权并防止抢注/DoS？
是否改用 URL 指向 Agent Card？是否支持 DID？AgentID 是否应可预测/跨链一致？
主要建议
不要强制「每域名一个 Agent」，允许同域多个 Agent，或以URL 级定位，避免 DoS。
若坚持域名模型：
引入提交‑揭示（commit‑reveal） 抗抢注（只缓解「同块/近块抢跑」，不能解决「先到先得的域名囤积」）。
更明确域名所有权校验策略（ENS？did:web？zkTLS/证明？或明确仅离线验证，链上不强约束）。
增加 DID 解析作为一等公民（如 resolveByDID），与 CAIP‑10/CAIP‑2 兼容，仅存可验证/短的链上字段。
标准化接口命名与类型（避免大小写不一/参数未定，提升互操作）。
AgentID 是否确定性计算：提案以 keccak256(domain,address[,contract]) 生成，优点是跨链一致；反对意见：会丧失域名/地址轮换的灵活性。
共识倾向
✅ 应标准化函数名/类型。
⚠️ 对「每域名一个 Agent、是否保留 resolveByDomain、是否单例注册表」的看法分裂。
⚠️ DID 支持有正反馈，但是核心还是扩展未定。
⚠️ 确定性 AgentID存在「可旋转性」与「跨链一致性」的权衡，尚无结论。
3. 声誉（Reputation）模型
在讨论什么
是否提供单一聚合分数？如何防偏见/串谋？是否需要多源评分与多维指标（SLA/可用性/参与度/经济信号等）？
主要建议
反对单一总分，倡导模块化：允许多提供方、多维度（如 SLA/正常运行时间、上下文相关、任务域相关）。
可在注册表暴露（Agent, Provider）对，让合约/索引器汇总；或仅存最小字段 + 链下聚合。
多人建议1–5 级评分 + 简评、多维度「SIGMA」类框架、Reputons (RFC‑7071) 参考等。
共识倾向
✅ 明确反对「一分定胜负」，支持多提供方/可过滤/可加权。
⚠️ 聚合发生在链上还是链下、注册表是否保存「聚合值」仍未统一。
4. 验证（Validation）与密码学保证
在讨论什么
验证结果用于托管释放、工作流推进等是否需要链上可读？采用哪些验证手段（重执行、抽样验证/SPEX、TEE 证明、ZK/zkML、「web 证明/zkTLS」等）？
主要建议
在验证注册表中保留最小链上可读结果（整数状态/ID），并为任务 taskId留接口，方便托管合约直接读取。
对TEE 验证建议离线批量验证再上链汇总（气价/尺寸考虑）。
方法无关：鼓励多种密码学方法（TEE、抽样重执行、zkML 等），注意区分zkTLS（来源真实性）与zkML（计算正确性）的适用边界。
共识倾向
✅ 最小可读接口 + 方法无关是主线。
⚠️ 是否把「事件/争议注册表（Incident/Dispute）」纳入核心有分歧：有方案（带保证金的举报/挑战状态机），但核心作者倾向认为「已由差评/失败验证覆盖」，建议放扩展。
5. 支付与加密经济
在讨论什么
是否把支付/托管/押金纳入 ERC‑8004？是否引入抵押/保证金以抗 Sybil/垃圾？
主要建议
核心不嵌入支付流程（如 x402/credits），保持解耦。
在反馈/验证对象中可携带「付款证明引用」（钩子），供索引器/上层合约相关联。
「轻量质押/保证金」用作信任信号的提案不少，但更适合扩展/外置协议而非核心。
共识倾向
✅ 支付与结算出核心，保留引用。
⚠️ 是否引入通用保证金机制：分歧明显，多数建议保持可组合/可插拔。