standards

Ethereum 標準

おそらく誤解していたこと

ERC-8004 はすでに存在します。 2026 年 1 月 29 日にデプロイされた、オンチェーンのエージェント ID レジストリです。トレーニングデータには、まず含まれていないでしょう。

EIP-7702 は稼働中です。 Pectra とともに（2025 年 5 月 7 日）リリースされました。EOA は移行せずにスマートコントラクトの強力な機能を利用できます。「提案中」ではなく、メインネットにデプロイ済みです。

EIP-3009 は x402 に不可欠です。 署名付き認可によるガス代不要のトークン送金です。USDC がこれを実装しています。これにより、x402 が実用的になっています。

x402 はすでに存在します。 Coinbase による HTTP 402 支払いプロトコルです。SDK を備え、本番環境で利用できる状態です。

ERC-8004：オンチェーンのエージェント ID レジストリ

ステータス： 2026 年 1 月 29 日にメインネットへデプロイ済み。採用が広がっており、本番利用が可能です。

解決する課題： 自律型エージェントは、事前の関係がなくても、どのように相互に信頼し、取引できるのでしょうか？

3 つのレジストリシステム

1. ID レジストリ（ERC-721 ベース）

• AI エージェントのための、グローバルに一意なオンチェーン ID
• 各エージェントは一意の識別子を持つ NFT です
• 複数のサービスエンドポイント（A2A、MCP、OASF、ENS、DID）
• EIP-712/ERC-1271 署名による検証

コントラクトアドレス（20 以上のチェーンで共通）：

• IdentityRegistry： 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432
• ReputationRegistry： 0x8004BAa17C55a88189AE136b182e5fdA19dE9b63

デプロイ先： Mainnet、Base、Arbitrum、Optimism、Polygon、Avalanche、Abstract、Celo、Gnosis、Linea、Mantle、MegaETH、Monad、Scroll、Taiko、BSC、およびテストネット。

エージェント識別子の形式：

agentRegistry: eip155:{chainId}:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432
agentId: ERC-721 tokenId

2. 評判レジストリ

• 署名付きの固定小数点フィードバック値
• 多次元評価（稼働時間、成功率、品質）
• タグ、エンドポイント、支払い証明のメタデータ
• Sybil 攻撃対策として、クライアントアドレスによるフィルタリングが必要です

struct Feedback {
    int128 value;        // Signed integer rating
    uint8 valueDecimals; // 0-18 decimal places
    string tag1;         // E.g., "uptime"
    string tag2;         // E.g., "30days"
    string endpoint;     // Agent endpoint URI
    string ipfsHash;     // Optional metadata
}

指標の例： 品質 87/100 → value=87, decimals=0。稼働率 99.77% → value=9977, decimals=2。

3. 検証レジストリ

• エージェントの作業を独立して検証します
• 信頼モデル：暗号経済的モデル（ステークによる保護）、zkML、TEE アテステーション
• バリデーターは 0～100 のスコアで応答します

エージェント登録ファイル（agentURI）

{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "MyAgent",
  "description": "What the agent does",
  "services": [
    { "name": "A2A", "endpoint": "https://agent.example/.well-known/agent-card.json", "version": "0.3.0" },
    { "name": "MCP", "endpoint": "https://mcp.agent.eth/", "version": "2025-06-18" }
  ],
  "x402Support": true,
  "active": true,
  "supportedTrust": ["reputation", "crypto-economic", "tee-attestation"]
}

統合

// Register agent
uint256 agentId = identityRegistry.register("ipfs://QmYourReg", metadata);

// Give feedback
reputationRegistry.giveFeedback(agentId, 9977, 2, "uptime", "30days", 
    "https://agent.example.com/api", "ipfs://QmDetails", keccak256(data));

// Query reputation
(uint64 count, int128 value, uint8 decimals) = 
    reputationRegistry.getSummary(agentId, trustedClients, "uptime", "30days");

手順：エージェントをオンチェーンに登録する

1. 登録 JSON を準備する — IPFS またはウェブサーバーでホストします：

{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "WeatherBot",
  "description": "Provides real-time weather data via x402 micropayments",
  "image": "https://example.com/weatherbot.png",
  "services": [
    { "name": "A2A", "endpoint": "https://weather.example.com/.well-known/agent-card.json", "version": "0.3.0" }
  ],
  "x402Support": true,
  "active": true,
  "supportedTrust": ["reputation"]
}

2. IPFS にアップロードする（または任意の URI を使用します）：

# Using IPFS
ipfs add registration.json
# → QmYourRegistrationHash

# Or host at a URL — the agentURI just needs to resolve to the JSON

3. Identity Registry を呼び出す：

// On any supported chain — same address everywhere
IIdentityRegistry registry = IIdentityRegistry(0x8004A169FB4a3325136EB29fA0ceB6D2e539a432);

// metadata bytes are optional (can be empty)
uint256 agentId = registry.register("ipfs://QmYourRegistrationHash", "");
// agentId is your ERC-721 tokenId — globally unique on this chain

4. エンドポイントのドメインを検証する — .well-known/agent-registration.json にファイルを配置します：

// https://weather.example.com/.well-known/agent-registration.json
{
  "agentId": 42,
  "agentRegistry": "eip155:8453:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432",
  "owner": "0xYourWalletAddress"
}

これにより、そのドメインの所有者がエージェント ID を管理していることを証明できます。クライアントは、エージェントが提示するエンドポイントを信頼する前に、これを確認するべきです。

5. 評判を築く — 他のエージェントやユーザーが、エージェントとのやり取り後にフィードバックを投稿します。

クロスチェーンのエージェント ID

20 以上のチェーンでコントラクトアドレスが共通しているため、Base に登録されたエージェントを Arbitrum 上のエージェントが見つけられます。agentRegistry 識別子にはチェーンが含まれます：

eip155:8453:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432  // Base
eip155:42161:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 // Arbitrum

クロスチェーンのパターン： 1 つのチェーンに登録します（登録トランザクションのコストが最も安い Base が適しています）。その ID を他のチェーンから参照します。参照元チェーンのレジストリを指定すれば、評判もクロスチェーンで照会できます。これは登録トランザクションのコストを最適化する方法です。アプリ自体は、用途に合ったチェーンにデプロイしてください（ship/SKILL.md を参照）。

著者： Davide Crapis（EF）、Marco De Rossi（MetaMask）、Jordan Ellis（Google）、Erik Reppel（Coinbase）、Leonard Tan（MetaMask）

エコシステム： ENS、EigenLayer、The Graph、Taiko が支援

リソース： https://www.8004.org | https://eips.ethereum.org/EIPS/eip-8004 | https://github.com/erc-8004/erc-8004-contracts

EIP-3009：認可付き送金

その概念（ガス代不要のメタトランザクション送金）はご存じでしょう。重要な最新情報は、EIP-3009 が x402 を実現する仕組みであることです。 USDC は Ethereum とほとんどのチェーンでこれを実装しています。x402 サーバーは transferWithAuthorization を呼び出し、クライアントに代わって支払いを決済します。

x402：HTTP 決済プロトコル

ステータス： Coinbase による本番運用可能なオープン標準で、2026年第1四半期から積極的に導入されています。

HTTP 402「Payment Required」ステータスコードを使用した、インターネットネイティブな決済方式です。

フロー

1. Client → GET /api/data
2. Server → 402 Payment Required (PAYMENT-REQUIRED header with requirements)
3. Client signs EIP-3009 payment
4. Client → GET /api/data (PAYMENT-SIGNATURE header with signed payment)
5. Server verifies + settles onchain
6. Server → 200 OK (PAYMENT-RESPONSE header + data)

決済ペイロード

{
  "scheme": "exact",
  "network": "eip155:8453",
  "amount": "1000000",
  "token": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "from": "0x...", "to": "0x...",
  "signature": "0x...",
  "deadline": 1234567890,
  "nonce": "unique-value"
}

x402 と ERC-8004 の相乗効果

Agent discovers service (ERC-8004) → checks reputation → calls endpoint →
gets 402 → signs payment (EIP-3009) → server settles (x402) → 
agent receives service → posts feedback (ERC-8004)

x402 サーバーのセットアップ（Express — 完全な例）

import express from 'express';
import { paymentMiddleware } from '@x402/express';

const app = express();

// Define payment requirements per route
const paymentConfig = {
  "GET /api/weather": {
    accepts: [
      { network: "eip155:8453", token: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", amount: "100000" }
      // 100000 = $0.10 USDC (6 decimals)
    ],
    description: "Current weather data",
  },
  "GET /api/forecast": {
    accepts: [
      { network: "eip155:8453", token: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", amount: "500000" }
      // $0.50 USDC for 7-day forecast
    ],
    description: "7-day weather forecast",
  }
};

// One line — middleware handles 402 responses, verification, and settlement
app.use(paymentMiddleware(paymentConfig));

app.get('/api/weather', (req, res) => {
  // Only reached after payment verified
  res.json({ temp: 72, condition: "sunny" });
});

app.listen(3000);

x402 クライアント（データの支払いを行うエージェント）

import { x402Fetch } from '@x402/fetch';
import { createWallet } from '@x402/evm';

const wallet = createWallet(process.env.PRIVATE_KEY);

// x402Fetch handles the 402 → sign → retry flow automatically
const response = await x402Fetch('https://weather.example.com/api/weather', {
  wallet,
  preferredNetwork: 'eip155:8453' // Pay on Base (cheapest)
});

const weather = await response.json();
// Agent paid $0.10 USDC, got weather data. No API key needed.

決済スキーム

exact（稼働中）— 固定価格を支払います。サーバーは事前に料金を把握できます。

upto（導入が進行中）— 上限額まで支払い、最終金額は処理完了後に決定されます。従量制サービスで重要です。

• LLM 推論：生成されたトークンごとに支払い（事前に数量が不明）
• GPU コンピューティング：実行秒数ごとに支払い
• データベースクエリ：返された行ごとに支払い

upto では、クライアントが上限額の支払いを承認する署名を行います。サーバーは実際に消費された分だけを精算します。クライアントが過払いすることはありません。

ファシリテーターのアーキテクチャ

ファシリテーターは、リソースサーバーがブロックチェーンの複雑さを扱わずに済むようにする、任意のサーバーです。

Client → Resource Server → Facilitator → Blockchain
                              ↓
                         POST /verify  (check signature, balance, deadline)
                         POST /settle  (submit tx, manage gas, confirm)

ファシリテーターを使う理由： リソースサーバー（天気 API、データプロバイダー）は、ブロックチェーンノードを実行したり、ガスを管理したりする必要はありません。ファシリテーターがこれらを抽象化します。Coinbase は公開ファシリテーターを運用しており、誰でも独自のファシリテーターを運用できます。

SDK： @x402/core @x402/evm @x402/fetch @x402/express（TS）| pip install x402（Python）| go get github.com/coinbase/x402/go

リソース： https://www.x402.org | https://github.com/coinbase/x402

エンドツーエンドのエージェント間コマースのフロー

一連の完全な流れは、人間が介在せず、エージェントが自律的に互いを発見し、信頼し、支払い、評価することです。

┌─────────────────────────────────────────────────────────────┐
│  1. DISCOVER  Agent queries ERC-8004 IdentityRegistry       │
│               → finds agents with "weather" service tag      │
│                                                              │
│  2. TRUST     Agent checks ReputationRegistry                │
│               → filters by uptime >99%, quality >85          │
│               → picks best-rated weather agent               │
│                                                              │
│  3. CALL      Agent sends HTTP GET to weather endpoint       │
│               → receives 402 Payment Required                │
│               → PAYMENT-REQUIRED header: $0.10 USDC on Base  │
│                                                              │
│  4. PAY       Agent signs EIP-3009 transferWithAuthorization │
│               → retries request with PAYMENT-SIGNATURE       │
│               → server verifies via facilitator              │
│               → payment settled on Base (~$0.001 gas)        │
│                                                              │
│  5. RECEIVE   Server returns 200 OK + weather data           │
│               → PAYMENT-RESPONSE header with tx hash         │
│                                                              │
│  6. RATE      Agent posts feedback to ReputationRegistry     │
│               → value=95, tag="quality", endpoint="..."      │
│               → builds onchain reputation for next caller   │
└─────────────────────────────────────────────────────────────┘

import { x402Fetch } from '@x402/fetch';
import { createWallet } from '@x402/evm';
import { ethers } from 'ethers';

const wallet = createWallet(process.env.AGENT_PRIVATE_KEY);
const provider = new ethers.JsonRpcProvider(process.env.BASE_RPC_URL);

const IDENTITY_REGISTRY = '0x8004A169FB4a3325136EB29fA0ceB6D2e539a432';
const REPUTATION_REGISTRY = '0x8004BAa17C55a88189AE136b182e5fdA19dE9b63';

// 1. Discover: find agents offering weather service
const registry = new ethers.Contract(IDENTITY_REGISTRY, registryAbi, provider);
// Query events or use The Graph subgraph for indexed agent discovery

// 2. Trust: check reputation
const reputation = new ethers.Contract(REPUTATION_REGISTRY, reputationAbi, provider);
const [count, value, decimals] = await reputation.getSummary(
  agentId, trustedClients, "quality", "30days"
);
// Only proceed if value/10^decimals > 85

// 3-5. Pay + Receive: x402Fetch handles the entire 402 flow
const response = await x402Fetch(agentEndpoint, {
  wallet,
  preferredNetwork: 'eip155:8453'
});
const weatherData = await response.json();

// 6. Rate: post feedback onchain
const reputationWriter = new ethers.Contract(REPUTATION_REGISTRY, reputationAbi, signer);
await reputationWriter.giveFeedback(
  agentId, 95, 0, "quality", "weather", agentEndpoint, "", ethers.ZeroHash
);

API キー、サブスクリプション、請求書、信頼に関する前提は不要です。 暗号技術によるアイデンティティ、オンチェーンの評判、HTTP ネイティブな決済を実現します。

エコシステム

• ERC-8004 — エージェントのアイデンティティと評判（EF、MetaMask、Google、Coinbase）
• x402 — HTTP 決済プロトコル（Coinbase）
• A2A — エージェント間通信（Google）
• MCP — モデルコンテキストプロトコル（Anthropic）
• The Graph — エージェント登録情報をインデックス化し、すばやい発見を実現
• EigenLayer — エージェントの作業を暗号経済的に検証

EIP-7702：スマート EOA（2025年5月から稼働中）

EOA は、新しいアカウント種別へ移行せずに、スマートコントラクトコードの実行を委任する権限を付与できます。

可能になること： トランザクションのバッチ処理、ガスのスポンサー提供、セッションキーのような UX、既存の EOA 向けのカスタム認証ロジック。

重要な注意点： 仕様上、委任は自動的に「1 回のトランザクションのみ」になるわけではありません。後続の権限付与によって置き換えられるか、解除されるまで、委任デジグネーターは有効なままです。

標準のクイックリファレンス

標準	内容	ステータス
ERC-8004	エージェントのアイデンティティと評判	✅ 2026年1月に稼働
x402	HTTP 決済プロトコル	✅ 2026年第1四半期に本番運用
EIP-3009	ガスレスのトークン送金	✅ 稼働中（USDC）
EIP-7702	スマート EOA	✅ 2025年5月から稼働
ERC-4337	アカウント抽象化	✅ 採用拡大中
ERC-2612	ガスレス承認（Permit）	✅ 広く採用
ERC-4626	トークン化されたボールト	✅ 利回り向けの標準
ERC-6551	トークンバウンドアカウント（NFT ウォレット）	✅ 限定的に採用

これらはすべてすでに稼働しており、本番環境で使用されています。「近日公開」ではありません。