[Research] ERC-8004 + x402 + MCP/A2A + TEE 기반 에이전트 네이티브 ZK 증명 인프라 설계 #39
Description
에이전트 네이티브 ZK 증명 인프라 설계
AI 에이전트가 다른 에이전트에게 ZK 증명 생성/검증을 요청하고, 결제하고, 신뢰를 쌓는 플로우 설계
목차
- 1. 핵심 아이디어
- 2. 프로토콜 스택
- 3. 등장 인물 (Agents)
- 4. End-to-End 플로우
- 5. A2A Agent Card + Discovery
- 6. MCP Server 도구 정의
- 7. x402 결제 플로우
- 8. TEE 증명 생성
- 9. Privacy Data 전달 방식
- 10. ERC-8004 에이전트 등록
- 11. 추가 컨트랙트/서킷 필요 여부
- 12. TEE 프로버 성능 최적화
- 13. 테스트 인프라
- 14. 기존 아키텍처와 비교
- 15. 확장 가능성
1. 핵심 아이디어
현재 ZKProofport는 모바일 앱 ↔ 릴레이 ↔ SDK 구조. 이를 에이전트 네이티브 구조로 확장하여, 사람이 아닌 AI 에이전트가 다른 에이전트에게 ZK 증명 생성/검증을 요청하고, 결제하고, 신뢰를 쌓는 플로우를 구축한다.
핵심 조합:
- ERC-8004 — 에이전트 온체인 신원 + 평판
- A2A — 에이전트 간 탐색 + 통신
- x402 — HTTP 네이티브 USDC 마이크로페이먼트
- MCP — 에이전트 → 도구 호출 인터페이스
- TEE — 격리 환경에서 증명 생성 + 하드웨어 attestation
2. 프로토콜 스택
| 레이어 | 기술 | 해결하는 문제 |
|---|---|---|
| Identity | ERC-8004 | "이 Prover Agent를 믿을 수 있는가?" → 온체인 ID + 평판 |
| Discovery | A2A Agent Card | "증명 생성 가능한 에이전트를 어떻게 찾는가?" → 표준화된 탐색 |
| Payment | x402 | "증명 생성 비용을 어떻게 지불하는가?" → HTTP 네이티브 USDC 마이크로페이먼트 |
| Interface | MCP | "에이전트가 어떻게 도구를 호출하는가?" → JSON-RPC 표준 도구 |
| Confidentiality | TEE | "프라이빗 입력값이 유출되지 않는가?" → 하드웨어 격리 |
| Integrity | ZK + TEE Dual Proof | "증명이 올바르게 생성되었는가?" → 수학적 + 하드웨어 이중 보장 |
3. 등장 인물 (Agents)
| Agent | 역할 | 실행 환경 |
|---|---|---|
| Client Agent | dApp 개발자의 AI 에이전트. 사용자 대신 증명 요청 | 일반 서버/Telegram Bot/curl |
| Prover Agent | ZK 증명 생성 전문 에이전트 | TEE (AWS Nitro Enclave) |
| Verifier Agent | 온체인 증명 검증 | TEE + 온체인 |
| Facilitator | x402 결제 정산 처리 | Coinbase CDP |
Client Agent는 반드시 AI일 필요 없음. Telegram 봇, curl, MCP 직접 연결 등 HTTP 요청을 보낼 수 있는 무엇이든 Client가 될 수 있다.
4. End-to-End 플로우
Client Agent A2A Registry Prover (TEE) Facilitator On-chain
│ │ │ │ │
│── discover("zk") ──►│ │ │ │
│◄── Agent Card ──────│ │ │ │
│ (agentId #42, │ │ │ │
│ rep: 4.8, │ │ │ │
│ x402 pricing) │ │ │ │
│ │ │ │ │
│── POST /a2a/tasks ──────────────────────►│ │ │
│ {task: "generate_proof", │ │ │
│ circuit: "coinbase_attestation", │ │ │
│ encryptedInputs: "..."} │ │ │
│ │ │ │
│◄── 402 Payment Required ────────────────│ │ │
│ {amount: "0.05 USDC", payTo: "0x.."} │ │ │
│ │ │ │
│── sign USDC payment ──────────────────────────────────────►│ │
│◄── payment verified ──────────────────────────────────────│ │
│ │ │ │
│── POST /a2a/tasks (retry) ──────────────►│ │ │
│ + X-PAYMENT header │ │ │
│ │ │ │
│ ┌──── TEE Enclave ────┐ │ │
│ │ 1. KMS decrypt │ │ │
│ │ 2. bb prove │ │ │
│ │ (pre-compiled │ │ │
│ │ circuit JSON) │ │ │
│ └─────────────────────┘ │ │
│ │ │ │
│◄── SSE: task.progress ──────────────────│ │ │
│ "Generating proof..." │ │ │
│◄── SSE: task.completed ─────────────────│ │ │
│ { proof, publicInputs } │ │ │
│ │ │ │
│── verify on-chain ──────────────────────────────────────────────────────────►│
│ UltraVerifier.verify(proof, inputs) │ │ │
│◄── true ────────────────────────────────────────────────────────────────────│
│ │ │ │
│── giveFeedback(agentId:42, score:95) ───────────────────────────────────────►│
│ (ERC-8004 Reputation Registry) │ │ │
회로 컴파일은 빌드 타임에 1회만 수행. TEE enclave 이미지에 컴파일된 JSON + VK를 bake-in하고, 런타임에는
bb prove만 실행한다.
5. A2A Agent Card + Discovery
A2A 동작 방식
Agent Card는 통신 시 보내는 것이 아니라 well-known URL에 게시해놓는 정적 명함. 상대 에이전트가 GET으로 읽고, 실제 통신은 JSON-RPC over HTTP로 진행.
1. 게시: https://prover.zkproofport.app/.well-known/agent.json
2. 외부 에이전트가 GET으로 발견
3. 실제 통신: POST /a2a (JSON-RPC + SSE 스트리밍)
Agent Card 설계
A2A vs MCP 역할 구분
| A2A | MCP | |
|---|---|---|
| 관계 | Agent ↔ Agent | Agent ↔ Tool |
| 비유 | 사람 ↔ 사람 대화 | 사람 ↔ 도구 사용 |
| 누가 쓰나 | 외부 에이전트가 우리한테 요청할 때 | 우리 에이전트가 내부 도구를 호출할 때 |
방식 A: 에이전트 자율 동작 (A2A)
외부 Agent ──A2A──► 우리 Agent ──MCP──► TEE 도구
방식 B: 개발자 직접 사용 (MCP)
개발자의 Claude Code ──MCP──► TEE 도구 (직접 연결)
두 진입점 모두 제공 가능.
6. MCP Server 도구 정의 (TEE 내부)
{
"tools": [
{
"name": "generate_proof",
"description": "Noir ZK proof 생성 (pre-compiled circuit 사용)",
"inputSchema": {
"type": "object",
"properties": {
"circuitId": {
"type": "string",
"enum": ["coinbase_attestation", "coinbase_country_attestation"]
},
"encryptedInputs": {
"type": "string",
"description": "AWS KMS로 암호화된 입력값"
},
"requestTeeAttestation": {
"type": "boolean",
"default": false,
"description": "TEE 하드웨어 attestation 포함 여부 (선택적)"
}
},
"required": ["circuitId", "encryptedInputs"]
}
},
{
"name": "verify_proof",
"description": "ZK proof 로컬 검증 (on-chain 전 사전 확인)",
"inputSchema": {
"type": "object",
"properties": {
"circuitId": { "type": "string" },
"proof": { "type": "string" },
"publicInputs": { "type": "array", "items": { "type": "string" } }
}
}
},
{
"name": "get_supported_circuits",
"description": "지원하는 회로 목록 반환"
}
],
"resources": [
{
"uri": "circuits://coinbase_attestation/vk",
"name": "Coinbase Attestation Verification Key",
"mimeType": "application/octet-stream"
},
{
"uri": "circuits://supported",
"name": "Supported Circuit List",
"mimeType": "application/json"
}
]
}7. x402 결제 플로우
x402는 HTTP 402 "Payment Required" 상태 코드를 활용한 인터넷 네이티브 결제 프로토콜 (Coinbase 개발).
Client Prover Facilitator
│ │ │
│── POST /generate-proof ───────────►│ │
│ │ │
│◄── 402 Payment Required ───────────│ │
│ PAYMENT-REQUIRED header: │ │
│ { │ │
│ "amount": "0.05", │ │
│ "asset": "USDC", │ │
│ "network": "eip155:8453", │ (Base) │
│ "payTo": "0xProver..." │ │
│ } │ │
│ │ │
│── POST /generate-proof ───────────►│ │
│ X-PAYMENT: <signed USDC tx> │ │
│ │── verify payment ────────►│
│ │◄── verified + settled ────│
│ │ │
│◄── 200 OK + { proof, inputs } ────│ │
특징:
- 계정/API키/구독 불필요 — per-request USDC 결제
- $0.001 수준 마이크로페이먼트 가능
- AI 에이전트 자율 결제에 최적화
- Base, Solana 지원 (USDC)
SDK: @x402/fetch, @x402/express, @x402/next 등 공식 NPM 패키지 제공
8. TEE 증명 생성
Enclave 이미지 구성
회로 컴파일은 빌드 타임에 1회만 수행. 런타임에는 bb prove만 실행.
TEE Enclave Image (빌드 시 고정)
├── bb (barretenberg binary)
├── circuits/
│ ├── coinbase_attestation.json ← 컴파일 완료
│ ├── coinbase_attestation_vk ← VK 생성 완료
│ ├── coinbase_country_attestation.json
│ └── coinbase_country_attestation_vk
├── srs/ ← bn254 SRS
└── prover-server ← 요청 받아서 bb prove 실행
런타임 플로우
1. Client의 encrypted inputs 수신
2. AWS KMS로 복호화 (enclave 내부에서만 가능)
3. bb prove -b circuit.json -w <witness> -o proof
4. 반환: { proof, publicInputs }
5. (선택적) NSM attestation document 생성
TEE 리포트 — 기본 불필요, 옵션으로 제공
ZK proof 자체가 수학적 증명이므로 기본 플로우에서는 리포트 불필요.
| 시나리오 | ZK proof만으로 충분? | TEE 리포트 필요? |
|---|---|---|
| 일반 증명 생성/검증 | 충분 | 불필요 |
| 규제 감사 (금융, 의료) | 증명은 OK, 과정 추적 필요 | 선택적 |
| 입력값 기밀성 증명 필요 | ZK는 출력만 보장 | 유용 |
| Prover 코드 무결성 의심 | ZK는 결과만 검증 | 유용 |
9. Privacy Data 전달 방식
사용자의 민감한 입력값(여권 데이터, attestation 등)을 TEE Prover에게 안전하게 전달하는 방법
전체 흐름
User/Client TEE Prover (Nitro Enclave)
│ │
│ 1. Enclave의 공개키 요청 │
│─── GET /public-key ──────────────────►│
│◄── { publicKey, attestation } ────────│
│ │
│ 2. Attestation 검증 │
│ - Nitro root cert 확인 │
│ - PCR 값 매칭 (예상 바이너리) │
│ - 공개키가 enclave 내부 생성 확인 │
│ │
│ 3. 공개키로 입력값 암호화 │
│ encryptedInputs = encrypt( │
│ publicKey, │
│ { passport, attestation, ... } │
│ ) │
│ │
│ 4. 암호화된 데이터 전송 │
│─── POST /a2a { encryptedInputs } ────►│
│ │
│ ┌── Enclave 내부 ──┐│
│ │ 5. 개인키로 복호화││
│ │ 6. bb prove 실행 ││
│ │ 7. 메모리 즉시삭제││
│ └─────────────────┘│
│ │
│◄── { proof, publicInputs } ───────────│
│ (원본 입력값은 절대 반환 안 됨) │
방식 A: TEE Enclave 자체 키페어 (권장)
┌─────────────────────────────────────────────────────────┐
│ TEE Enclave 부팅 시: │
│ 1. enclave 내부에서 키페어 생성 (외부 접근 불가) │
│ 2. 공개키 + attestation document 함께 반환 │
│ → attestation에 공개키 해시 포함 │
│ → "이 공개키는 이 enclave에서 생성됨" 증명 │
│ │
│ Client 측: │
│ 1. attestation 검증 (AWS Nitro root cert chain) │
│ 2. PCR 값 확인 (예상 바이너리 해시와 매칭) │
│ 3. 검증된 공개키로 inputs 암호화 │
│ 4. 암호화된 데이터만 네트워크로 전송 │
│ │
│ 보안 보장: │
│ - 개인키는 enclave 메모리에만 존재 (디스크 저장 없음) │
│ - enclave 외부에서 개인키 추출 불가능 (하드웨어 격리) │
│ - 네트워크 전송 구간은 암호화된 데이터만 통과 │
│ - enclave 재시작 시 새 키페어 생성 (forward secrecy) │
└─────────────────────────────────────────────────────────┘
방식 B: AWS KMS 통합 (간편)
┌─────────────────────────────────────────────────────────┐
│ 사전 설정: │
│ 1. AWS KMS에 키 생성 │
│ 2. KMS 키 정책: "이 enclave PCR 값을 가진 요청만 복호화" │
│ │
│ Client 측: │
│ 1. KMS 공개키로 inputs 암호화 │
│ aws kms encrypt --key-id alias/prover-key \ │
│ --plaintext '{"passport": "...", ...}' │
│ │
│ TEE Enclave 내부: │
│ 1. KMS에 복호화 요청 │
│ 2. KMS가 enclave attestation 검증 │
│ 3. PCR 매칭 시에만 복호화된 데이터 반환 │
│ 4. 복호화된 데이터로 bb prove 실행 │
│ │
│ 장점: │
│ - Client가 attestation 직접 검증할 필요 없음 │
│ - KMS가 대신 enclave 무결성 검증 │
│ - 키 관리를 AWS에 위임 │
│ │
│ 단점: │
│ - AWS KMS에 대한 의존성 │
│ - KMS 호출 시 추가 레이턴시 (~50ms) │
└─────────────────────────────────────────────────────────┘
방식 C: TLS 채널 (가장 간단, 보안 약함)
┌─────────────────────────────────────────────────────────┐
│ Client ──HTTPS──► TEE Prover │
│ │
│ - 일반 HTTPS TLS 채널로 전송 │
│ - TEE 내부에서 TLS 종단 (서버 인증서) │
│ - 별도 암호화 불필요 │
│ │
│ 장점: 구현 가장 간단 │
│ 단점: TLS 종단이 enclave 밖이면 복호화된 데이터 노출 │
│ → TLS termination이 반드시 enclave 내부여야 함 │
└─────────────────────────────────────────────────────────┘
회로별 입력값 구조 (어떤 데이터가 전달되는가)
// coinbase_attestation — KYC 검증
{
"circuitId": "coinbase_attestation",
"inputs": {
"attestation": "0x...", // Coinbase EAS attestation 원본
"attestationSignature": "0x...", // EAS 서명
"userAddress": "0x...", // 사용자 지갑 주소
"scope": "kyc_verification" // 증명 범위
}
}
// coinbase_country_attestation — 국가 검증
{
"circuitId": "coinbase_country_attestation",
"inputs": {
"attestation": "0x...", // Coinbase EAS attestation
"attestationSignature": "0x...",
"userAddress": "0x...",
"countryList": [840, 826], // ISO 3166 국가 코드
"isIncluded": true, // 포함/제외 여부
"scope": "country_check"
}
}데이터 생명주기 (보안 보장)
1. [Client] 원본 데이터 → 암호화 → encryptedInputs
2. [Network] encryptedInputs만 전송 (원본 노출 없음)
3. [TEE] 복호화 → 메모리에만 존재 (디스크 저장 없음)
4. [TEE] bb prove 실행 → proof 생성
5. [TEE] 원본 입력값 메모리에서 즉시 삭제 (zeroize)
6. [TEE] proof + publicInputs만 반환
7. [Client] 원본 데이터는 Client 로컬에만 존재
→ 원본 privacy data는 TEE enclave 메모리를 제외하면
어디에도 평문으로 존재하지 않음
10. ERC-8004 에이전트 등록
이미 배포된 컨트랙트 — 우리가 배포할 필요 없음
| 네트워크 | IdentityRegistry | ReputationRegistry |
|---|---|---|
| Base, Ethereum, Polygon, Arbitrum (메인넷) | 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 |
0x8004BAa17C55a88189AE136b182e5fdA19dE9b63 |
| Base Sepolia, Sepolia (테스트넷) | 0x8004A818BFB912233c491871b3d84c89A494BD9e |
0x8004B663056A597Dffe9eCcC1965A193B7388713 |
등록 절차 (3단계)
Step 1 — 메타데이터 JSON 작성 → IPFS 업로드:
{
"type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
"name": "ZKProofport TEE Prover",
"description": "Noir ZK proof generation with TEE attestation",
"image": "https://zkproofport.app/agent-avatar.png",
"active": true,
"services": [
{ "name": "A2A", "endpoint": "https://tee-prover.zkproofport.app/.well-known/agent.json" },
{ "name": "MCP", "endpoint": "https://tee-prover.zkproofport.app/mcp" }
],
"registrations": [
{
"agentId": 0,
"agentRegistry": "eip155:8453:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432"
}
]
}Step 2 — 온체인 등록 (ethers v6):
import { ethers } from 'ethers';
const IDENTITY_REGISTRY = '0x8004A169FB4a3325136EB29fA0ceB6D2e539a432';
const ABI = ['function register(string agentURI) external returns (uint256 agentId)'];
const provider = new ethers.JsonRpcProvider('https://mainnet.base.org');
const wallet = new ethers.Wallet(process.env.PRIVATE_KEY, provider);
const registry = new ethers.Contract(IDENTITY_REGISTRY, ABI, wallet);
const tx = await registry.register('ipfs://QmXxx.../agent.json');
const receipt = await tx.wait();
// agentId가 ERC-721 NFT로 발급됨또는 cast:
cast send 0x8004A818BFB912233c491871b3d84c89A494BD9e \
"register(string)" "ipfs://QmXxx.../agent.json" \
--rpc-url https://sepolia.base.org \
--private-key $PRIVATE_KEYStep 3 — 완료. agentId (NFT) 발급됨.
비용
| 네트워크 | 예상 가스비 |
|---|---|
| Base Sepolia (테스트) | 무료 (faucet ETH) |
| Base 메인넷 | < $0.10 |
| Ethereum 메인넷 | $1~5 |
SDK 옵션
| SDK | 언어 | 비고 |
|---|---|---|
@0xgasless/agent-sdk |
TypeScript | 추천, x402 통합 포함 |
chaoschain-sdk |
Python | 5+ 테스트넷 지원 |
Foundry cast |
CLI | 의존성 최소 |
11. 추가 컨트랙트/서킷 필요 여부
서킷: 추가 배포 불필요
기존 coinbase_attestation, coinbase_country_attestation 회로 그대로 사용. 회로 로직은 동일하고 증명 생성 위치만 변경.
현재: 모바일 (mopro) → bb prove → proof
에이전트: TEE 서버 (bb) → bb prove → proof ← 같은 회로, 같은 VK
컨트랙트 현황
| 컨트랙트 | 배포 필요? | 이유 |
|---|---|---|
| UltraVerifier (증명 검증) | 이미 배포됨 | 기존 그대로 사용 |
| ZKProofPortNullifierRegistry | 이미 배포됨 | 기존 그대로 사용 |
| ERC-8004 Identity/Reputation | 이미 배포됨 (8004팀이) | register() 호출만 |
| TEE Attestation Verifier | 선택적 | 기본 플로우엔 불필요 |
12. TEE 프로버 성능 최적화
Noir ACIR 백엔드 옵션
Noir는 ACIR (Abstract Circuit Intermediate Representation)로 컴파일되며, 백엔드 교체 가능:
| 백엔드 | 상태 | 장점 | TEE 적합성 |
|---|---|---|---|
| bb (UltraHonk) | 프로덕션 | 기본, 5-50x faster than Groth16 | 최선 |
| bb (UltraPlonk) | 프로덕션 | 더 작은 proof size | 좋음 |
| Plonky2 (Noirky2) | 실험적 | 재귀증명 170ms | 미래 고려 |
| Halo2 | 그랜트 완료 | Trusted setup 불필요 | 특수 케이스 |
| Gnark (Groth16) | 사용 가능 | 가장 작은 proof | ACIR 변환 필요 |
| Circom 전용 | - | Noir 미지원 |
bb 성능 최적화
1. UltraHonk 사용 (기본값, UltraPlonk 대비 5-50x)
2. 멀티스레딩 (libomp) — EPYC 48코어에서 선형 확장
3. 서버 하드웨어 스케일업 — 모바일 3초 → 서버 < 1초
4. GPU 가속 (CUDA) — 실험적, cuda-barretenberg 존재
5. 수평 확장 — TEE 인스턴스 풀 + 로드밸런서 (가장 실용적)
성능 기대치
| 환경 | 예상 증명 시간 |
|---|---|
| 모바일 (현재, mopro) | 3~10초 |
| TEE 서버 (bb, 멀티코어) | < 1초 |
| TEE + GPU (실험적) | < 0.5초 |
| 수평 확장 (N 인스턴스) | 처리량 N배 |
13. 테스트 인프라
Phase 1: 로컬 MCP 테스트
Claude Code ──MCP──► 로컬 Docker (bb prove)
- Docker 컨테이너에 bb + 컴파일된 회로 포함
- MCP 서버로 도구 노출
- 비용: $0
Phase 2: A2A 엔드포인트 테스트
curl / Postman ──HTTP──► A2A 서버 (스테이징)
- A2A JSON-RPC 엔드포인트 구현
- Agent Card 게시
- ERC-8004 Base Sepolia에 등록
- x402 결제 모킹
- 비용: faucet ETH만
Phase 3: Telegram Bot 통합 테스트
유저 ──Telegram──► TG Bot ──A2A──► Prover 서버
- /prove, /verify, /balance 커맨드
- x402 테스트넷 USDC 결제
- Telegram Mini App으로 리치 UI 가능
Telegram 봇 명령어 예시:
/prove <circuit> - ZK 증명 생성 요청
/verify <proof_id> - 증명 검증 상태 확인
/balance - USDC 잔액 확인
/history - 증명 생성 이력
/agent - Prover Agent 정보 (ERC-8004 ID, 평판)
Phase 4: TEE 프로덕션 배포
유저/에이전트 ──A2A──► AWS Nitro Enclave Prover
- 하드웨어 attestation 활성화
- ERC-8004 Base 메인넷 등록
- x402 메인넷 USDC 결제
- 수평 확장 (인스턴스 풀)
14. 기존 아키텍처와 비교
| 현재 (모바일 중심) | 에이전트 네이티브 | |
|---|---|---|
| 요청자 | 사람 (dApp 웹페이지) | AI 에이전트 / Telegram Bot |
| 증명 생성 | 사용자 모바일 디바이스 (mopro) | TEE 서버 (bb) |
| 결제 | 무료 크레딧 | x402 per-proof USDC |
| 신뢰 | SDK clientId + relay 검증 | ERC-8004 온체인 평판 |
| 탐색 | SDK에 하드코딩된 relay URL | A2A Agent Card로 동적 발견 |
| 보안 모델 | ZK proof만 | ZK + TEE dual proof (선택적) |
| Privacy | 모바일 로컬 증명 (데이터 안 나감) | TEE 격리 환경 (데이터 enclave 밖으로 안 나감) |
15. 확장 가능성
- Prover 마켓플레이스 — 여러 Prover Agent가 ERC-8004에 등록 → 가격/평판 경쟁 → Client가 최적 선택
- Circuit 마켓플레이스 — 새로운 회로를 A2A로 배포, x402로 사용료 과금
- Cross-chain 검증 — A2A 카드에 멀티체인 verifier 주소 포함
- Composable agents — Verifier Agent가 다른 에이전트에게 리포트 작성 위임 (A2A pipeline)
- Telegram Mini App 확장 — QR 코드, 지갑 연결, 실시간 증명 상태 대시보드
References
ERC-8004
- ERC-8004 Official EIP
- erc-8004/erc-8004-contracts
- nuwa-protocol/nuwa-8004
- Phala-Network/erc-8004-tee-agent
{ "name": "ZKProofport TEE Prover", "description": "Generates Noir ZK proofs inside AWS Nitro Enclave with hardware attestation", "url": "https://tee-prover.zkproofport.app/a2a", "version": "1.0.0", "provider": { "organization": "ZKProofport", "erc8004": { "chainId": 8453, "identityRegistry": "0x8004A169FB4a3325136EB29fA0ceB6D2e539a432", "agentId": 42 } }, "capabilities": { "streaming": true, "pushNotifications": false, "stateTransitionHistory": true }, "skills": [ { "id": "generate-proof", "name": "ZK Proof Generation", "description": "Generate ZK proof with optional TEE attestation", "inputModes": ["application/json"], "outputModes": ["application/json"], "parameters": { "circuitId": { "type": "string", "enum": ["coinbase_attestation", "coinbase_country_attestation"] }, "encryptedInputs": { "type": "string", "description": "KMS-encrypted proof inputs" } } } ], "payment": { "protocol": "x402", "pricing": { "generate-proof": { "amount": "0.05", "asset": "USDC", "network": "eip155:8453" } } }, "trustMetadata": { "teeType": "AWS_NITRO_ENCLAVES", "pcrMeasurements": { "PCR0": "0xabc123...", "PCR2": "0xdef456..." } } }