互补 x402协议，重构信任：ERC8004 标准从理论梳理到代码落地全解析

木西
5 阅读7分钟

前言

继上一篇对 x402 协议的详细解析后，本篇将重点介绍与 x402 功能高度互补、且常被一同讨论的 ERC 标准 ——ERC-8004。x402 作为一款可在 Base、Solana、Ethereum 等多链使用的跨链协议，核心解决的是 “如何完成支付” 的问题；而 ERC-8004 则与之形成互补，专注解决 “支付主体是谁” 以及 “为何可以信任该支付方” 的信任与身份验证问题。

一、核心定位

功能定位：以太坊上「AI 智能代理」的无信任协作标准，基于 ERC-721，让链上 AI 代理可被唯一标识、可信评估、安全协作

协作关系：在 AI 经济中，x402 负责处理高频微额的支付（如 API 结算），而 ERC-8004 负责验证对方的合法性，防止恶意机器人滥用资源

二、核心三件套（三大注册表）

  • 身份注册表：每个 AI 代理 = 唯一 ERC-721 NFT，固定身份、能力、地址，不可篡改、可转移。

  • 声誉注册表：链上记录任务反馈（评分 / 评价），需代理签名授权防刷分，跨平台复用信誉。

  • 验证注册表：提供通用验证接口，支持 zkML、TEE、抵押重执行等，证明代理执行结果真实。

三、完整工作流程示例

  1. 代理注册：开发者铸造 ERC-721 NFT 作为 AI 代理身份，填写能力元数据并上链

  2. 代理发现：用户 / 其他代理通过链上注册表查询，基于身份元数据筛选匹配能力的代理

  3. 交互发起：双方协商任务与报酬（可配合 x402 微支付协议）

  4. 任务执行：代理完成链上 / 链下任务

  5. 结果验证（可选）：

    • 高风险任务：代理提交验证请求，验证者（zkML/TEE/ 抵押节点）生成执行证明上链
    • 低风险任务：跳过验证，直接进入反馈环节

  6. 反馈提交：用户获取代理授权签名后，提交任务评分与评价至声誉注册表

  7. 声誉更新：系统聚合新反馈，形成代理最新可信度画像

  8. 循环复用：代理身份、声誉、验证记录跨平台永久有效，支撑后续无信任交互

四、核心价值

  • 让 AI 代理成为链上独立可信主体

  • 打破平台壁垒，跨协议 / 跨应用互认

  • 降低信任成本，无需中心化背书

五、典型场景

  • 去中心化 AI 服务市场：代理自主提供代码审计、数据分析、内容生成、DeFi 策略执行等服务，用户基于声誉自由选择

  • 代理协作网络：多个 AI 代理自动分工完成复杂任务（如科研数据分析→模型训练→结果验证），通过验证注册表保障各环节可信

  • 智能合约 + AI 融合：AI 代理作为合约 “执行者”，完成链下数据获取、复杂计算，通过 zkML/TEE 证明结果真实性后触发合约执行

  • DeFi 智能体：自动做市、风险对冲、借贷管理，验证注册表确保策略按预期执行，声誉系统反映历史业绩

  • 微支付生态：配合 x402 协议，AI 代理自主购买算力、数据或雇佣其他代理，形成完整代理经济闭环

六、x402 协议与ERC-8004 标准对比

概述：x402 是 Web3 时代的“钱包”，那么 ERC-8004 就是“身份证”与“信用分”

维度 x402 协议ERC-8004 标准
主要角色支付通道（支付谁、付多少）身份层（谁在付、是否可信）
技术实现HTTP 402 状态码 + ERC-3009链上注册表 + 签名验证
打个比方自动扣费的信用卡/POS机实名认证的营业执照

七、局限与未来展望

当前局限

  1. 存储与 gas 成本：声誉与验证记录上链，高频交互可能导致 gas 过高（可通过 L2 / 数据可用性层缓解）
  2. 验证生态不成熟：zkML、TEE 等验证基础设施尚未普及，验证者网络需要时间培育
  3. 声誉公平性：评分标准不统一，可能出现 “刷好评” 或恶意差评（依赖后续治理与激励设计）
  4. 代理执行边界：标准聚焦信任层，不涉及代理执行逻辑本身，需配合其他框架使用

未来展望

  1. 与 AI 原生协议深度融合（如 A2A、MCP、x402），构建完整代理经济栈
  2. 扩展至多链生态，支持跨链代理身份与声誉互认
  3. 集成更多先进验证技术（如 zk-STARKs、AI 验证即服务）
  4. 催生代理治理、保险、评分等专业化基础设施，完善代理经济生态

八、智能合约开发、测试、部署

智能合约

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
import "@openzeppelin/contracts/utils/cryptography/EIP712.sol";

/**
 * @title ERC8004Registry
 * @dev 实现 ERC-8004 标准：建立用户(User)与智能体(Agent)的授信关系
 */
contract ERC8004Registry is EIP712 {
    using ECDSA for bytes32;

    // 记录用户是否授权了该 Agent: User => Agent => IsAuthorized
    mapping(address => mapping(address => bool)) public isDelegated;

    // EIP-712 TypeHash: 用于 Agent 证明其被授权执行特定任务
    bytes32 private constant _DELEGATION_TYPEHASH = keccak256(
        "AuthorizeAgent(address user,address agent,uint256 nonce)"
    );

    event AgentAuthorized(address indexed user, address indexed agent);
    event AgentRevoked(address indexed user, address indexed agent);

    constructor() EIP712("ERC8004Registry", "1") {}

    /**
     * @notice 用户在链上显式授权一个 Agent 实体
     */
    function authorizeAgent(address agent) external {
        require(agent != address(0), "Invalid agent address");
        isDelegated[msg.sender][agent] = true;
        emit AgentAuthorized(msg.sender, agent);
    }

    /**
     * @notice 撤销授权
     */
    function revokeAgent(address agent) external {
        isDelegated[msg.sender][agent] = false;
        emit AgentRevoked(msg.sender, agent);
    }

    /**
     * @notice 验证 Agent 提交的身份证明（结合 x402 结算前使用）
     * @param user 原始资金拥有者
     * @param agent 执行操作的 AI Agent
     * @param signature Agent 使用其私钥对 AuthorizeAgent 结构体的签名
     */
    function isValidAgent(
        address user,
        address agent,
        uint256 nonce,
        bytes calldata signature
    ) public view returns (bool) {
        // 1. 检查链上委派记录
        if (!isDelegated[user][agent]) return false;

        // 2. 验证 Agent 签名，确保是 Agent 本人在操作
        bytes32 structHash = keccak256(abi.encode(_DELEGATION_TYPEHASH, user, agent, nonce));
        bytes32 hash = _hashTypedDataV4(structHash);
        
        return hash.recover(signature) == agent;
    }
}

测试脚本

测试说明：

  1. 成功建立委派并通过 Agent 身份验证
  2. 撤销授权后验证应当失败
import assert from "node:assert/strict";
import { describe, it, beforeEach } from "node:test";
import { network } from "hardhat";
import { getAddress } from 'viem';

describe("ERC-8004 Agent Delegation Test", function () {
    let registry: any;
    let publicClient: any;
    let user: any, agent: any;
    let chainId: number;

    beforeEach(async function () {
        const { viem } = await (network as any).connect();
        publicClient = await viem.getPublicClient();
        [user, agent] = await viem.getWalletClients();
        
        // 部署合约 (Solidity 0.8.24)
        registry = await viem.deployContract("ERC8004Registry", []);
        chainId = await publicClient.getChainId();
    });

    it("应该成功建立委派并通过 Agent 身份验证", async function () {
        const userAddr = getAddress(user.account.address);
        const agentAddr = getAddress(agent.account.address);
        const nonce = 8004n;

        // 1. 用户执行链上授权
        const txHash = await registry.write.authorizeAgent([agentAddr], { account: user.account });
        await publicClient.waitForTransactionReceipt({ hash: txHash });

        // 2. 构造 EIP-712 结构化数据 (符合 ERC-8004 规范)
        const domain = {
            name: 'ERC8004Registry',
            version: '1',
            chainId: chainId,
            verifyingContract: registry.address,
        };

        const types = {
            AuthorizeAgent: [
                { name: 'user', type: 'address' },
                { name: 'agent', type: 'address' },
                { name: 'nonce', type: 'uint256' },
            ],
        };

        const message = {
            user: userAddr,
            agent: agentAddr,
            nonce: nonce,
        };

        // 3. Agent 签名证明身份 (Agent 掌握私钥)
        const agentSignature = await agent.signTypedData({
            domain,
            types,
            primaryType: 'AuthorizeAgent',
            message,
        });

        // 4. 合约校验验证
        const isValid = await registry.read.isValidAgent([
            userAddr,
            agentAddr,
            nonce,
            agentSignature
        ]);

        assert.strictEqual(isValid, true, "ERC-8004 验证应返回 True");
        console.log("✅ ERC-8004 身份委派验证成功");
    });

    it("撤销授权后验证应当失败", async function () {
        const userAddr = getAddress(user.account.address);
        const agentAddr = getAddress(agent.account.address);

        // 撤销
        await registry.write.revokeAgent([agentAddr], { account: user.account });

        const isValid = await registry.read.isValidAgent([
            userAddr,
            agentAddr,
            1n,
            "0x" + "b".repeat(130) // 假签名
        ]);

        assert.strictEqual(isValid, false, "撤销后应返回 False");
    });
});

部署脚本

// scripts/deploy.js
import { network, artifacts } from "hardhat";
async function main() {
  // 连接网络
  const { viem } = await network.connect({ network: network.name });//指定网络进行链接
  
  // 获取客户端
  const [deployer] = await viem.getWalletClients();
  const publicClient = await viem.getPublicClient();
 
  const deployerAddress = deployer.account.address;
   console.log("部署者的地址:", deployerAddress);
  // 加载合约
  const ERC8004RegistryArtifact = await artifacts.readArtifact("ERC8004Registry");

 
  // 部署
  const ERC8004RegistryHash = await deployer.deployContract({
    abi: ERC8004RegistryArtifact.abi,//获取abi
    bytecode: ERC8004RegistryArtifact.bytecode,//硬编码
    args: [],
  });
   const ERC8004RegistryReceipt = await publicClient.waitForTransactionReceipt({ hash: ERC8004RegistryHash });
   console.log("ERC8004Registry合约地址:", ERC8004RegistryReceipt.contractAddress);
}

main().catch(console.error);

结语

至此，关于 ERC8004 标准的知识梳理与代码落地工作已全面完成。在理论层面，已系统梳理其核心定位、核心三件套、完整工作流、核心价值、应用场景，并对比了 x402 协议与 ERC-8004 标准的差异，同时分析了该标准的发展展望与面临的挑战；在代码层面，基于 openzeppelinV5+solidity0.8.24 + 技术栈，实现了从开发、测试到部署落地的全流程落地实践。

avatar
文章
阅读
粉丝