[Research] ERC-8004 + x402 + MCP/A2A + TEE 기반 에이전트 네이티브 ZK 증명 인프라 설계

[hyuki0130]

에이전트 네이티브 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 설계

{
  "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..."
    }
  }
}

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_KEY

Step 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 변환 필요
rapidsnark	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. 확장 가능성

1. Prover 마켓플레이스 — 여러 Prover Agent가 ERC-8004에 등록 → 가격/평판 경쟁 → Client가 최적 선택
2. Circuit 마켓플레이스 — 새로운 회로를 A2A로 배포, x402로 사용료 과금
3. Cross-chain 검증 — A2A 카드에 멀티체인 verifier 주소 포함
4. Composable agents — Verifier Agent가 다른 에이전트에게 리포트 작성 위임 (A2A pipeline)
5. 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

x402

• x402.org
• coinbase/x402 GitHub
• x402 Coinbase Docs
• x402 Whitepaper

A2A

• A2A Protocol Specification
• Google A2A Announcement
• google-agentic-commerce/a2a-x402

MCP

• Model Context Protocol

TEE

• AWS Nitro Enclaves
• Phala Multi-Proof ZK + TEE
• TEE vs MPC vs ZK

Noir / bb Performance

• cuda-barretenberg
• Metal MSM v2
• Noirky2 (Plonky2 backend for Noir)

Telegram Integration

• OpenClaw LLM Framework
• mcp-telegram

[hyuki0130]

Privacy Data 전달 및 검증 상세 분석

회로 소스코드 분석 기반으로, 유저의 민감 데이터가 TEE Prover에 어떻게 전달되는지 구체적으로 정리

목차

• 1. 핵심 발견: 개인키는 필요 없다
• 2. 회로 입력값 완전 분석
• 3. 현재 모바일 앱의 데이터 수집 흐름
• 4. TEE 모델에서의 핵심 질문
• 5. 3가지 아키텍처 옵션
• 6. 권장 아키텍처: Pre-Sign + TEE Fetch
• 7. 각 데이터 항목별 보안 분석
• 8. Coinbase EAS Attestation 특수성
• 9. 고급 옵션: CoSNARK / Session Key
• 10. 결론 및 추천

---

1. 핵심 발견: 개인키는 필요 없다

회로 소스코드(circuits/coinbase-attestation/src/main.nr)를 분석한 결과:

✅ 회로 입력값에 "개인키(private key)"는 없다
✅ 필요한 것은 "서명(signature)"과 "공개키(public key)"뿐
✅ 서명은 유저 디바이스에서 생성 → 서명 결과만 전달하면 됨
✅ 개인키는 절대로 디바이스를 떠나지 않음

왜? 회로가 검증하는 것은 "이 사람이 이 주소를 소유한다"인데, 이를 증명하는 방법은:

• ❌ 개인키 자체를 보여주기 (위험!)
• ✅ 서명을 보여주기 → 서명에서 공개키를 복원(ecrecover) → 공개키에서 주소 유도 → 주소 일치 확인

---

2. 회로 입력값 완전 분석

coinbase_attestation (KYC) — Private Inputs

입력값	타입	내용	출처	개인키 관련?	민감도
user_address	[u8; 20]	유저 지갑 주소	지갑 연결	❌ 공개키 파생값	CRITICAL — 이것이 숨기려는 신원
user_signature	[u8; 64]	signal_hash에 대한 ECDSA 서명 (r, s)	personal_sign()	⚠️ 개인키가 생성하지만, 개인키 자체는 아님	CRITICAL — 주소 소유권 증명
user_pubkey_x	[u8; 32]	secp256k1 공개키 X좌표	서명에서 ecrecover로 복원	❌	HIGH — 주소 유도 가능
user_pubkey_y	[u8; 32]	secp256k1 공개키 Y좌표	서명에서 ecrecover로 복원	❌	HIGH
raw_transaction	[u8; 300]	Coinbase attestation TX (RLP 인코딩)	Base 체인에서 fetch	❌	CRITICAL — 유저 주소 + Coinbase 서명 포함
tx_length	u32	TX 실제 바이트 길이	계산	❌	LOW
coinbase_attester_pubkey_x/y	[u8; 32]x2	Coinbase 서명자 공개키	TX 서명에서 복원	❌	MEDIUM
coinbase_signer_merkle_proof	[[u8;32]; 8]	Merkle 증명 경로	공개 데이터에서 계산	❌	LOW
coinbase_signer_leaf_index	u32	Merkle 리프 인덱스	공개 데이터	❌	LOW
merkle_proof_depth	u32	Merkle 깊이	공개 데이터	❌	LOW

coinbase_attestation — Public Inputs

입력값	내용	민감도
signal_hash	keccak256(address + scope + "coinbase_attestation")	PUBLIC
signer_list_merkle_root	인가된 Coinbase 서명자 Merkle 루트	PUBLIC
scope	keccak256(scope_string)	PUBLIC
nullifier	keccak256(keccak256(address ++ signal_hash) ++ scope)	PUBLIC (이중 해시라 주소 역추적 불가)

핵심 포인트

┌──────────────────────────────────────────────────────────────┐
│                                                              │
│  유저가 직접 제공해야 하는 것:                                │
│  ├─ 1. 지갑 주소 (wallet address)                            │
│  ├─ 2. signal_hash에 대한 서명 (personal_sign 결과)          │
│  └─ 3. scope (dApp이 정의)                                   │
│                                                              │
│  TEE가 스스로 가져올 수 있는 것:                              │
│  ├─ 4. raw_transaction (Base 체인 RPC에서 fetch)             │
│  ├─ 5. user_pubkey (서명 + signal_hash에서 ecrecover)        │
│  ├─ 6. coinbase_attester_pubkey (TX 서명에서 ecrecover)      │
│  ├─ 7. Merkle proof (공개 signer list에서 계산)              │
│  └─ 8. nullifier, signal_hash 등 (주소+scope로 계산)         │
│                                                              │
│  개인키는? → 어디에도 없음. 필요 없음.                        │
│                                                              │
└──────────────────────────────────────────────────────────────┘

---

3. 현재 모바일 앱의 데이터 수집 흐름

현재 모바일 앱(useCoinbaseKyc.ts)의 13단계 플로우:

Step 1:  딥링크 수신 → scope, countryList 파싱
Step 2:  Privy 지갑 연결 → user_address 획득
Step 3:  EAS GraphQL 쿼리 → attestation txHash 검색
Step 4:  Base RPC → raw_transaction fetch
Step 5:  TX 파싱 → 함수 selector 확인, signer 복원
Step 6:  signal_hash 계산 → keccak256(address + scope + circuitName)
Step 7:  ⭐ personal_sign(signal_hash) → user_signature 생성
         └─ 이 순간만 개인키가 사용됨 (디바이스 내부)
Step 8:  서명에서 공개키 복원 → user_pubkey_x, user_pubkey_y
Step 9:  TX 서명에서 Coinbase pubkey 복원
Step 10: Merkle tree 구성 → proof, root, index
Step 11: scope, nullifier 계산
Step 12: (country만) country code 인코딩
Step 13: 전체 inputs flatten → mopro-ffi에 전달 → bb prove 실행

Step 7이 유일하게 개인키가 관여하는 순간이고, 이것은 지갑(Privy)이 내부적으로 처리합니다.

---

4. TEE 모델에서의 핵심 질문

"Step 7의 서명을 누가 하는가?"

모바일 모델: 유저 디바이스에서 서명 → 디바이스에서 증명 생성 (all local)

TEE 모델: 유저 디바이스에서 서명 → 서명 결과를 TEE에 전달 → TEE에서 증명 생성

모바일:   [서명 + 증명 생성] 전부 디바이스 내부
TEE:     [서명]만 디바이스 → [서명 결과 + 증명 생성]은 TEE

개인키는 두 모델 모두 디바이스를 떠나지 않음.

---

5. 3가지 아키텍처 옵션

Option A: Pre-Sign + TEE Fetch (권장)

┌─ 유저 디바이스 ─────────────────────────────────────────────┐
│                                                              │
│  1. 지갑 연결 → address 확보                                 │
│  2. signal_hash 계산 (address + scope + circuitName)         │
│  3. personal_sign(signal_hash) → signature (r, s) 생성       │
│     └─ 개인키는 여기서만 사용되고 디바이스를 떠나지 않음      │
│  4. TEE에 전달: { address, signature, scope }                │
│     └─ 3개 값만 전달 (총 ~116 bytes)                         │
│                                                              │
└──────────────────────────────────────────────────────────────┘
                          │
                          ▼ (encrypted channel)
┌─ TEE Enclave ───────────────────────────────────────────────┐
│                                                              │
│  5. 수신: { address, signature, scope }                      │
│  6. Base RPC → EAS attestation TX 조회 (address로 검색)      │
│  7. raw_transaction 복원 (eth_getTransactionByHash)          │
│  8. ecrecover(signature, signal_hash) → user_pubkey 복원     │
│  9. ecrecover(tx_signature, unsigned_tx_hash) → cb_pubkey    │
│  10. Merkle proof 계산 (공개 signer list 기반)               │
│  11. nullifier 계산                                          │
│  12. 전체 inputs 조합 → bb prove 실행                        │
│  13. 반환: { proof, publicInputs }                           │
│                                                              │
│  ⚡ 개인키는 enclave 안에 존재하지 않음                       │
│  ⚡ address + signature만 민감 데이터                         │
│                                                              │
└──────────────────────────────────────────────────────────────┘

장점:

• 개인키가 절대 디바이스를 떠나지 않음
• 유저 디바이스는 서명 1회만 수행 (가벼움)
• 체인 데이터 fetch는 TEE가 담당 (빠른 서버 네트워크 활용)
• 기존 지갑(Privy, MetaMask 등) 그대로 사용 가능
• 구현 복잡도 낮음

단점:

• TEE가 user_address를 알게 됨 (TEE 신뢰 필요)
• TEE가 Base RPC에 접근 필요 (네트워크 연결)

---

Option B: Full Client-Side Preparation

┌─ 유저 디바이스 ─────────────────────────────────────────────┐
│                                                              │
│  1~12단계 전부 디바이스에서 수행 (현재 모바일 앱과 동일)      │
│  모든 inputs를 다 만든 후 TEE에 전달                         │
│                                                              │
│  전달: { 모든 circuit inputs — ~800 bytes }                  │
│                                                              │
└──────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─ TEE Enclave ───────────────────────────────────────────────┐
│                                                              │
│  bb prove만 실행 (inputs validation + prove)                 │
│                                                              │
└──────────────────────────────────────────────────────────────┘

장점:

• TEE의 역할이 최소화 (prove만 실행)
• 기존 모바일 로직 재사용 가능

단점:

• 유저 디바이스에 SDK 통합 필요 (input 준비 로직)
• 더 많은 민감 데이터가 네트워크를 통과 (raw_transaction 포함)
• Client에서 Base RPC 호출 필요

---

Option C: TEE가 모든 것을 처리 (유저는 서명만)

┌─ 유저 ─────────┐
│                 │
│ 1. 지갑 연결   │
│ 2. 서명 요청   │◄─── TEE가 서명 챌린지 보냄
│ 3. 서명 반환   │───► TEE에 전달
│                 │
│ 전달: signature │
│ (64 bytes만!)   │
└─────────────────┘
        │
        ▼
┌─ TEE ──────────────────────────┐
│                                 │
│ address는 서명에서 복원         │
│ (ecrecover → pubkey → address) │
│ 나머지 전부 TEE가 처리          │
│                                 │
└─────────────────────────────────┘

장점:

• 유저 디바이스 부담 최소 (서명 1회)
• address도 명시적으로 전달할 필요 없음 (서명에서 복원)

단점:

• TEE가 signal_hash를 먼저 계산하려면 address가 필요 → 치킨-에그 문제
• 해결: TEE가 랜덤 챌린지 보내고, 서명에서 address 복원 후 signal_hash 재계산
• 회로 설계 변경 필요할 수 있음

---

6. 권장 아키텍처: Pre-Sign + TEE Fetch (Option A)

상세 시퀀스

User Device              Telegram Bot / Client         TEE Prover              Base Chain
    │                         │                           │                       │
    │── 지갑 연결 ────────────►│                           │                       │
    │   (Privy / WalletConnect)│                           │                       │
    │                         │                           │                       │
    │                         │── 증명 요청 ──────────────►│                       │
    │                         │   { circuit, scope }       │                       │
    │                         │                           │                       │
    │                         │◄── 서명 챌린지 ────────────│                       │
    │                         │   { signal_hash_to_sign }  │                       │
    │                         │                           │                       │
    │◄── 서명 요청 ───────────│                           │                       │
    │   "이 메시지에 서명해주세요"                          │                       │
    │                         │                           │                       │
    │── personal_sign() ─────►│                           │                       │
    │   { signature (r,s) }   │                           │                       │
    │   ⭐ 개인키는 여기서만   │                           │                       │
    │      사용됨 (지갑 내부)  │                           │                       │
    │                         │                           │                       │
    │                         │── { address, signature,   │                       │
    │                         │    scope } ───────────────►│                       │
    │                         │                           │                       │
    │                         │   ┌── TEE 내부 처리 ──────┤                       │
    │                         │   │                       │── EAS query ──────────►│
    │                         │   │ 6. attestation 검색   │◄── attestation TX ────│
    │                         │   │ 7. raw_tx 복원        │── getRawTx ──────────►│
    │                         │   │ 8. ecrecover(sig)     │◄── raw_transaction ──│
    │                         │   │    → user_pubkey      │                       │
    │                         │   │ 9. ecrecover(tx_sig)  │                       │
    │                         │   │    → cb_pubkey        │                       │
    │                         │   │ 10. merkle proof 계산 │                       │
    │                         │   │ 11. nullifier 계산    │                       │
    │                         │   │ 12. bb prove 실행     │                       │
    │                         │   └───────────────────────┤                       │
    │                         │                           │                       │
    │                         │◄── { proof, publicInputs }│                       │
    │◄── 증명 완료! ──────────│                           │                       │
    │                         │                           │                       │

네트워크를 통과하는 민감 데이터 (최소화)

유저 → TEE로 전달되는 것:
┌────────────────────────────────────────┐
│ address:   0xd6c714...d2f739 (20 bytes)│ ← 이게 숨기려는 신원
│ signature: r + s (64 bytes)            │ ← 주소 소유권 증명
│ scope:     "proofport:default" (string)│ ← 공개 정보
│                                        │
│ 총: ~116 bytes                         │
│ 개인키: ❌ 없음                         │
│ 여권 데이터: ❌ 없음                    │
│ KYC 문서: ❌ 없음                       │
└────────────────────────────────────────┘

전달 시 암호화

┌─ 암호화 옵션 ────────────────────────────────────────────┐
│                                                           │
│  방식 1: TEE Enclave 키페어 (가장 안전)                   │
│  ───────────────────────────────────────                  │
│  TEE 부팅 시 내부에서 키페어 생성                         │
│  → 공개키 + attestation document 반환                     │
│  → Client가 attestation 검증 후 공개키로 암호화           │
│  → 암호화된 { address, signature, scope } 전송            │
│  → TEE 내부에서만 복호화 가능                             │
│                                                           │
│  방식 2: AWS KMS (간편)                                   │
│  ───────────────────                                      │
│  KMS 키 정책: "이 PCR값의 enclave만 복호화 허용"          │
│  → Client가 KMS 공개키로 암호화                           │
│  → TEE가 KMS에 복호화 요청                                │
│  → KMS가 enclave attestation 검증 후 복호화               │
│                                                           │
│  방식 3: HTTPS (최소 보안)                                │
│  ────────────────────────                                 │
│  TLS 채널로 전송 (TLS termination이 enclave 내부여야 함)  │
│                                                           │
└───────────────────────────────────────────────────────────┘

---

7. 각 데이터 항목별 보안 분석

유저가 직접 제공 (3개)

데이터	크기	유출 시 위험	보호 방법
user_address	20B	치명적 — 유저 신원 노출, ZK 프라이버시 무력화	TEE 격리 + 암호화 전송 + 메모리 즉시 삭제
user_signature	64B	높음 — address 복원 가능 (ecrecover)	암호화 전송, TEE 내부에서만 처리
scope	~32B	낮음 — 공개 정보 (dApp이 정의)	별도 보호 불필요

TEE가 체인에서 가져옴 (자동)

데이터	출처	유출 시 위험	보호 방법
raw_transaction	Base RPC	높음 — 유저 주소가 calldata에 포함	TEE 내부에서만 처리, 로깅 금지
user_pubkey_x/y	ecrecover 결과	높음 — 주소 유도 가능	TEE 내부에서만 존재
coinbase_attester_pubkey	TX 서명에서 복원	중간 — Coinbase 서명자 식별 (공개 정보)	민감하지 않음
merkle_proof	공개 signer list	낮음 — 모두 공개 데이터	보호 불필요

TEE가 계산 (자동)

데이터	계산 방법	비고
signal_hash	keccak256(address + scope + circuitName)	Public input
nullifier	keccak256(keccak256(address ++ signal_hash) ++ scope)	Public, 이중 해시라 주소 역추적 불가
tx_length	raw_tx 바이트 길이	비민감

---

8. Coinbase EAS Attestation 특수성

핵심: Attestation은 이미 온체인에 있다

Coinbase EAS attestation은 100% 온체인 데이터:

속성	값
EAS 컨트랙트	0x4200000000000000000000000000000000000021 (Base)
Coinbase Attester	0x357458739F90461b99789350868CD7CF330Dd7EE
Verified Account 스키마	0xf8b05c79f090979bf4a80270aba232dff11a10d9ca55c4f88de95317970f0de9
Verified Country 스키마	0x1801901fabd0e6189356b4fb52bb0ab855276d84f7ec140839fbd1f6801ca065

TEE가 유저 주소만 알면:
  1. EAS GraphQL / Indexer 컨트랙트 쿼리 → attestation UID 확보
  2. eth_getTransactionByHash → raw_transaction 확보
  3. 유저에게 따로 "attestation 데이터를 보내달라"고 할 필요 없음

유저가 KYC 서류를 보내는 게 아니다

❌ 유저가 보내는 것: 여권 사진, KYC 문서, 개인 정보
✅ 유저가 보내는 것: 지갑 주소 + 서명 (116 bytes)

왜? Coinbase가 이미 KYC를 검증하고 attestation을 온체인에 기록했기 때문.
    TEE는 이 온체인 attestation을 직접 읽어서 증명을 생성한다.

회로가 실제로 검증하는 4가지

┌─ Noir 회로 내부 검증 로직 ──────────────────────────────────┐
│                                                              │
│  Part 1: 유저 소유권 (User Ownership)                        │
│  ├─ ecrecover(user_signature, signal_hash) → pubkey          │
│  ├─ derive_address(pubkey) → address                         │
│  └─ assert address == user_address                           │
│                                                              │
│  Part 2: TX 진위성 (Transaction Authenticity)                │
│  ├─ RLP 파싱 → coinbase_attester_pubkey 검증                 │
│  └─ merkle_verify(pubkey, proof, root) → signer가 인가됨     │
│                                                              │
│  Part 3: 논리적 연결 (Logical Linking)                       │
│  ├─ TX calldata에서 recipient address 추출                   │
│  └─ assert recipient == user_address                         │
│                                                              │
│  Part 4: Nullifier (이중 증명 방지)                          │
│  └─ nullifier = keccak256(keccak256(addr ++ sig_hash) ++ scope)│
│                                                              │
│  (Country만) Part 5: 국가 검증                               │
│  ├─ TX calldata에서 country_code 추출                        │
│  └─ assert country_code ∈ country_list (isIncluded 모드)     │
│                                                              │
└──────────────────────────────────────────────────────────────┘

---

9. 고급 옵션: CoSNARK / Session Key

CoSNARK (Collaborative SNARK) — 최고 보안

유저의 witness를 여러 TEE에 분산 (MPC 방식):

유저 디바이스
  │  witness를 3개 share로 분할
  ├─► TEE Prover 1 (share 1)
  ├─► TEE Prover 2 (share 2)
  └─► TEE Prover 3 (share 3)
       │
  3개 TEE가 협력하여 proof 생성
  어떤 단일 TEE도 전체 witness를 모름
       │
  최종 proof 반환

• 장점: TEE 1개가 해킹당해도 유저 데이터 안전
• 단점: 복잡한 구현, 높은 레이턴시, 아직 초기 기술
• 프로젝트: TACEO:Proof, EZKL CoSNARK

Session Key (ERC-4337) — 반복 증명용

유저: session key 생성 (제한된 권한, 시간 제한)
      └─ 권한: "1시간 동안 증명 요청 서명만 가능"

TEE:  session key로 서명 → 유저 대신 증명 요청
      └─ main key는 영원히 유저 디바이스에만 존재

• 장점: 반복적인 증명 생성 시 UX 개선 (매번 서명 안 해도 됨)
• 단점: ERC-4337 스마트 계정 필요, 표준 아직 성숙하지 않음

Privy TEE 기반 위임 — 이미 인프라 있음

현재 앱이 Privy를 사용하고 있는데, Privy의 임베디드 지갑은 이미 TEE 기반:

Privy: 유저 키를 TEE + 분산 샤드로 관리
       └─ 키 샤드가 이미 TEE 안에 있음

가능성: Privy TEE ↔ Prover TEE 간 mutual attestation
        → 키 샤드 공유 없이 서명 위임
        → Privy API가 이 기능을 지원해야 함 (현재 미지원 가능성)

---

10. 결론 및 추천

추천: Option A (Pre-Sign + TEE Fetch)

단계	위치	동작
1. 지갑 연결	유저 디바이스	Privy/WalletConnect로 address 확보
2. 서명	유저 디바이스	personal_sign(signal_hash) — 개인키 사용되는 유일한 순간
3. 전송	네트워크	{ address, signature, scope } 암호화 전송 (116 bytes)
4. Attestation 조회	TEE → Base 체인	EAS GraphQL/RPC로 raw_transaction fetch
5. Input 조합	TEE 내부	ecrecover, merkle proof, nullifier 계산
6. 증명 생성	TEE 내부	bb prove 실행
7. 반환	TEE → Client	{ proof, publicInputs } (공개 데이터만)

왜 이 방식인가

✅ 개인키는 절대 디바이스를 떠나지 않음
✅ TEE에 전달되는 민감 데이터 최소화 (주소 + 서명만)
✅ KYC 서류, 여권, 개인정보는 전혀 전달되지 않음
✅ 기존 지갑 인프라 그대로 사용 (Privy, MetaMask, Rainbow 등)
✅ 체인 데이터 fetch는 TEE가 서버 네트워크로 빠르게 처리
✅ 구현 복잡도 낮음 — 회로 수정 불필요
✅ Coinbase EAS attestation 특성상 최적 (이미 온체인)

보안 요구사항

요구사항	해결 방법
개인키 보호	디바이스 밖으로 나가지 않음 (서명만 전달)
address 보호	TEE 격리 + 암호화 전송 + 증명 후 즉시 삭제(zeroize)
중간자 공격	TEE attestation 기반 암호화 채널 (RA-TLS 또는 KMS)
TEE 탈취	하드웨어 격리 (Nitro/SGX), 선택적으로 CoSNARK 추가 가능
재사용 공격	nullifier로 이중 증명 방지 (이미 회로에 내장)

[hyuki0130]

에이전트 지갑 연결 및 대리 서명 — 업계 솔루션 분석

핵심 질문: "에이전트가 유저 대신 서명하려면 개인키가 필요한데, 이걸 어떻게 안전하게 처리하는가?"

목차

• 1. 문제 정의
• 2. 업계 5가지 해결 패턴
• 3. 패턴별 상세 분석
• 4. 실제 프로젝트 사례
• 5. ZKProofport 적용 방안
• 6. UX 플로우 비교

---

1. 문제 정의

우리 회로가 요구하는 것

회로 입력 중 서명이 필요한 것:
  user_signature = personal_sign(signal_hash, privateKey)
                                                    ↑
                                               이게 문제!

- 서명을 만들려면 개인키가 필요
- 개인키를 에이전트에게 주면 보안 위험
- 그렇다고 매번 유저가 수동 서명하면 자동화 불가

근본적 딜레마

┌─────────────────────────────────────────────────────────┐
│                                                         │
│  보안 ◄──────────────────────────────────► 편의성       │
│                                                         │
│  "개인키는 유저만"          vs          "에이전트가 자율 서명" │
│  (매번 수동 승인 필요)                   (개인키 위임 필요)  │
│                                                         │
│  업계가 찾은 해결책:                                     │
│  "개인키를 주지 않으면서 서명 권한을 위임하는 방법"       │
│                                                         │
└─────────────────────────────────────────────────────────┘

---

2. 업계 5가지 해결 패턴

패턴	핵심 아이디어	개인키 위치	유저 개입	대표 프로젝트
A. 에이전트 전용 지갑	에이전트에게 별도 지갑 발급 (유저 지갑과 분리)	TEE 서버	초기 설정 1회	Coinbase AgentKit, Privy Server Wallet
B. 세션 키 위임	유저가 임시 서명권을 제한 조건으로 위임	유저 스마트 계정	세션 승인 1회	ZeroDev, Biconomy, ERC-4337
C. 분산 키 (MPC/Threshold)	개인키를 여러 조각으로 분산, 단독 복원 불가	분산 노드들	정책 승인 1회	Lit Protocol PKP, Fireblocks
D. TEE 기반 키 관리	개인키가 하드웨어 격리 환경에만 존재	TEE enclave	초기 설정 1회	Turnkey, Privy
E. 스마트 계정 모듈	에이전트를 지갑의 승인된 모듈로 등록	유저 스마트 계정	모듈 설치 1회	Safe{Wallet}, ERC-7579

---

3. 패턴별 상세 분석

A. 에이전트 전용 지갑 (Agent-Owned Wallet)

원리: 에이전트에게 유저 지갑이 아닌 별도의 지갑을 발급. 유저는 이 지갑에 필요한 만큼만 자금을 넣거나 권한을 부여.

┌─ Coinbase AgentKit ──────────────────────────────────┐
│                                                       │
│  1. 에이전트 생성 시 CDP가 전용 지갑 발급              │
│  2. 개인키는 AWS Nitro Enclave에 저장                 │
│     → Coinbase도 키에 접근 불가                       │
│  3. 에이전트는 이 지갑으로 자유롭게 서명               │
│  4. 정책 제어:                                        │
│     - allowlist: 허용된 컨트랙트만                     │
│     - 금액 한도                                       │
│     - KYT(Know Your Transaction) 위험 스크리닝        │
│                                                       │
│  UX: 유저가 에이전트 지갑에 USDC 입금 → 끝            │
│      이후 에이전트가 자율적으로 서명/결제              │
│                                                       │
└───────────────────────────────────────────────────────┘

┌─ Privy Server Wallet ────────────────────────────────┐
│                                                       │
│  1. 서버 사이드에서 지갑 대량 생성 가능               │
│  2. 키는 TEE에서만 순간적으로 복원 (서명 시)          │
│     → 서명 후 즉시 파기                               │
│  3. 어플리케이션이 지갑 제어 (유저 승인 불필요)       │
│  4. EVM, Solana, Bitcoin 지원                         │
│                                                       │
│  UX: 유저 이메일 로그인 → 자동 지갑 생성 → 끝        │
│                                                       │
└───────────────────────────────────────────────────────┘

ZKProofport 적용 시:

유저: Privy 로그인 (이메일/소셜) → 임베디드 지갑 자동 생성
     → 이 지갑으로 Coinbase attestation 받기
     → 에이전트가 이 지갑의 서명을 서버사이드에서 수행
     → 유저 디바이스에서 서명할 필요 없음

---

B. 세션 키 위임 (Session Keys)

원리: 유저가 "이 조건 범위 내에서만 대리 서명 허용" 하는 임시 키를 발급.

┌─ ERC-4337 Session Key ──────────────────────────────┐
│                                                      │
│  Step 1: 유저가 세션 정책 승인 (1회)                 │
│  ┌──────────────────────────────────────┐            │
│  │ "이 에이전트에게 다음 권한을 줍니다:" │            │
│  │ ✅ 24시간 유효                       │            │
│  │ ✅ proof 생성 요청만 허용             │            │
│  │ ✅ 최대 10 USDC 결제                 │            │
│  │ ✅ 특정 컨트랙트만 호출 가능          │            │
│  │                                      │            │
│  │ [승인]  [거부]                        │            │
│  └──────────────────────────────────────┘            │
│                                                      │
│  Step 2: 에이전트가 세션 키로 자율 서명              │
│  - 정책 범위 내 → 즉시 서명 (유저 개입 없음)         │
│  - 정책 밖 → 거부됨                                  │
│                                                      │
│  Step 3: 세션 만료 또는 유저가 언제든 취소 가능       │
│                                                      │
│  도구: ZeroDev Kernel, Biconomy Smart Sessions       │
│  표준: ERC-7715 (권한 요청), ERC-7579 (모듈 계정)    │
│                                                      │
└──────────────────────────────────────────────────────┘

장점: 유저 메인 키 노출 없음, 범위 제한, 취소 가능
단점: ERC-4337 스마트 계정 필요 (EOA 불가)

---

C. 분산 키 — Lit Protocol PKP

원리: 개인키가 물리적으로 한 곳에 존재한 적 없음. 분산 노드들이 부분 서명 후 합산.

┌─ Lit Protocol PKP (Programmable Key Pairs) ──────────┐
│                                                       │
│  키 생성:                                             │
│  ┌─────┐  ┌─────┐  ┌─────┐                           │
│  │Node1│  │Node2│  │Node3│  ... (2/3 threshold)      │
│  │shard│  │shard│  │shard│                            │
│  └──┬──┘  └──┬──┘  └──┬──┘                           │
│     └────────┼────────┘                               │
│              ▼                                        │
│     완전한 키는 어디에도 존재하지 않음                  │
│     서명 시 각 노드가 부분 서명 → 합산                 │
│                                                       │
│  서명 조건 (Lit Action — JS 코드, IPFS에 고정):       │
│  ┌──────────────────────────────────────────┐         │
│  │ if (request.type === "proof_generation"   │         │
│  │     && request.amount < 10_USDC           │         │
│  │     && request.circuit in ALLOWED_LIST) { │         │
│  │   // 서명 승인                            │         │
│  │   Lit.Actions.signEcdsa(...)              │         │
│  │ }                                         │         │
│  └──────────────────────────────────────────┘         │
│                                                       │
│  PKP = ERC-721 NFT → 유저가 NFT 소유 = 키 제어       │
│                                                       │
└───────────────────────────────────────────────────────┘

장점: 최고 수준 보안, 프로그래밍 가능한 서명 조건
단점: 복잡한 구현, 레이턴시, Lit 네트워크 의존

---

D. TEE 기반 키 관리 — Turnkey

원리: 개인키가 하드웨어 격리 환경(TEE)에서 생성되어 절대 밖으로 나오지 않음.

┌─ Turnkey ────────────────────────────────────────────┐
│                                                       │
│  TEE Enclave:                                         │
│  ┌───────────────────────────────┐                    │
│  │ 키 생성 → 키 저장 → 서명 실행 │                    │
│  │ (전부 enclave 내부)           │                    │
│  │                               │                    │
│  │ 외부에서는:                   │                    │
│  │ - 키 추출 불가                │                    │
│  │ - 메모리 덤프 불가            │                    │
│  │ - Turnkey 직원도 접근 불가    │                    │
│  └───────────────────────────────┘                    │
│                                                       │
│  정책 엔진 (JSON 기반):                               │
│  {                                                    │
│    "effect": "ALLOW",                                 │
│    "condition": {                                     │
│      "requester": "agent-service-account",            │
│      "maxAmount": "10 USDC",                          │
│      "allowedMethods": ["personal_sign"],             │
│      "expiresAt": "2026-02-11T00:00:00Z"              │
│    }                                                  │
│  }                                                    │
│                                                       │
│  성능: MPC 대비 50-100x 빠름                          │
│                                                       │
└───────────────────────────────────────────────────────┘

장점: 빠름, 비커스터디얼, 정책 세밀 제어
단점: Turnkey 인프라 의존

---

E. 스마트 계정 모듈 — Safe{Wallet}

원리: 유저의 Safe(멀티시그 지갑)에 에이전트를 승인된 모듈로 등록.

┌─ Safe Module Pattern ────────────────────────────────┐
│                                                       │
│  Safe Wallet (유저 소유)                               │
│  ├─ Owner: 유저 EOA (메인 키)                         │
│  ├─ Module: AgentModule (에이전트 컨트랙트)            │
│  │   ├─ 허용 함수: proof_request, pay_fee              │
│  │   ├─ 금액 한도: 10 USDC/일                         │
│  │   └─ Guard: 추가 검증 (온체인 정책 체크)            │
│  │                                                    │
│  └─ Guard: TransactionGuard                            │
│      └─ 모든 TX 실행 전 정책 검증                      │
│                                                       │
│  에이전트: Module 권한으로 Safe를 통해 TX 실행          │
│  유저: 언제든 Module 제거 가능                          │
│                                                       │
└───────────────────────────────────────────────────────┘

---

4. 실제 프로젝트 사례

어떤 프로젝트가 어떤 패턴을 쓰는가

프로젝트	분야	패턴	지갑 도구	서명 방식
Coinbase AgentKit	범용 에이전트	A (전용 지갑)	CDP Wallet (Nitro)	TEE 내부 자율 서명
Eliza (ai16z)	소셜 에이전트	A + D	자체 Wallet System	TEE 기반 자율 서명
GOAT SDK	DeFi 에이전트	A + B + C	모든 지갑 호환	플러그인 방식 선택
Based Agent	Coinbase 에이전트	A	CDP Wallet	3분만에 에이전트+지갑 생성
Banana Gun	텔레그램 트레이딩	A (커스터디얼)	봇 생성 지갑	봇이 키 보관 + 서명
TradeWiz	텔레그램 트레이딩	D (로컬)	디바이스 암호화 저장	로컬 서명
ZeroDev	스마트 계정	B (세션 키)	Kernel Smart Account	정책 기반 자동 서명
Lit Protocol	분산 서명	C (MPC)	PKP (NFT 기반 키)	분산 threshold 서명
Turnkey	키 관리	D (TEE)	TEE Enclave 지갑	정책 엔진 기반 서명
Safe{Wallet}	멀티시그	E (모듈)	Safe Smart Account	모듈 권한 기반 서명

텔레그램 봇들의 현실

대부분의 텔레그램 트레이딩 봇(Banana Gun, Maestro, Unibot 등)은 가장 단순한 방식 사용:

1. /start → 봇이 새 지갑 생성
2. 유저에게 주소 + 개인키 보여줌 ("백업하세요")
3. 봇이 개인키를 AES-256으로 암호화 저장
4. 이후 모든 거래를 봇이 대리 서명

→ 완전 커스터디얼. 봇을 신뢰해야 함.
→ 하지만 UX가 가장 간단해서 가장 널리 쓰임.

---

5. ZKProofport 적용 방안

우리 상황의 특수성

일반 에이전트: "USDC 전송해줘" → 서명 1회
우리 에이전트: "내 Coinbase KYC attestation으로 ZK 증명 만들어줘"
              → 필요한 것:
              1. 유저 주소 (어떤 attestation을 찾을지)
              2. signal_hash 서명 (주소 소유권 증명)
              → 서명 1회면 충분

3가지 추천 방안

방안 1: Privy 임베디드 지갑 (가장 간단, 권장)

┌─ 유저 경험 ──────────────────────────────────────────┐
│                                                       │
│  1. "이메일로 로그인" 또는 "구글로 로그인"             │
│     → Privy가 임베디드 지갑 자동 생성                 │
│     → 유저는 개인키를 볼 필요 없음                    │
│                                                       │
│  2. Coinbase에서 이 지갑 주소로 attestation 받기      │
│                                                       │
│  3. "증명 생성" 버튼 클릭                             │
│     → Privy Server Wallet이 서버사이드에서 서명       │
│     → 유저는 서명 팝업을 볼 필요 없음                 │
│     → TEE가 증명 생성                                 │
│                                                       │
│  유저 개입: 로그인 1회 + 버튼 클릭 1회                │
│  개인키 노출: 없음 (Privy TEE가 관리)                 │
│                                                       │
└───────────────────────────────────────────────────────┘

왜 이게 가능한가:

• 우리 앱이 이미 Privy를 사용 중
• Privy Server Wallet은 서버에서 서명 가능 (유저 승인 불필요)
• 키는 Privy의 TEE 인프라에서 관리됨
• 이메일/소셜 로그인만으로 지갑 생성 → 크립토 초보도 사용 가능

아키텍처:

유저 (웹/앱/봇)
  │ 이메일 로그인
  ▼
Privy Auth → 임베디드 지갑 (서버사이드)
  │
  ├─ 지갑 주소 확인
  ├─ Privy Server Wallet로 signal_hash 서명 (서버에서)
  │
  ▼
TEE Prover
  ├─ Base 체인에서 attestation TX fetch
  ├─ 회로 입력값 조합
  ├─ bb prove 실행
  └─ proof 반환

---

방안 2: 기존 지갑 + 세션 키 (파워 유저)

┌─ 유저 경험 ──────────────────────────────────────────┐
│                                                       │
│  1. MetaMask/Rainbow 등 기존 지갑 연결 (WalletConnect)│
│                                                       │
│  2. 세션 키 승인 (1회):                               │
│     ┌────────────────────────────────────┐            │
│     │ "ZKProofport에 다음 권한을 줍니다:" │            │
│     │ ✅ signal_hash 서명 (proof 생성용)  │            │
│     │ ✅ 24시간 유효                      │            │
│     │ ✅ 최대 5회 사용                    │            │
│     │ [승인]                              │            │
│     └────────────────────────────────────┘            │
│                                                       │
│  3. 이후 증명 요청 시 자동 서명 (유저 개입 없음)      │
│                                                       │
│  유저 개입: 지갑 연결 1회 + 세션 승인 1회             │
│  이후: 완전 자동                                      │
│                                                       │
└───────────────────────────────────────────────────────┘

필요 조건: ERC-4337 스마트 계정 (ZeroDev Kernel 등)

---

방안 3: Coinbase AgentKit 지갑 (B2B 에이전트)

┌─ 에이전트 간 통신 (A2A) ─────────────────────────────┐
│                                                       │
│  외부 AI 에이전트 (고객사)                             │
│  ├─ AgentKit으로 자체 에이전트 지갑 보유               │
│  ├─ 이 지갑으로 Coinbase attestation 이미 보유         │
│  └─ A2A로 우리 Prover에게 증명 요청                   │
│                                                       │
│  우리 Prover Agent                                    │
│  ├─ 에이전트 지갑의 서명을 수신                        │
│  ├─ Base 체인에서 attestation 확인                     │
│  └─ 증명 생성 + 반환                                  │
│                                                       │
│  유저 개입: 없음 (에이전트끼리 자율 처리)              │
│                                                       │
└───────────────────────────────────────────────────────┘

B2B 시나리오: 고객사의 에이전트가 자체 지갑을 가지고 있고, 그 지갑의 attestation에 대한 증명을 우리에게 요청.

---

6. UX 플로우 비교

현재 (모바일 앱)

Step 1: 딥링크 열기
Step 2: Privy 지갑 연결
Step 3: 서명 팝업 승인    ← 유저 수동 개입
Step 4: 증명 생성 대기 (3~10초)
Step 5: 결과 확인

유저 수동 개입: 3회 (열기, 연결, 서명)

방안 1: Privy 임베디드 (최적 UX)

Step 1: 이메일/소셜 로그인
Step 2: "증명 생성" 클릭

유저 수동 개입: 2회 (로그인, 클릭)
서명: 서버사이드 자동 (Privy Server Wallet)

방안 2: 세션 키 (자동화 UX)

초기 설정 (1회):
  Step 1: 지갑 연결
  Step 2: 세션 키 승인

이후 매 요청:
  Step 1: "증명 생성" 클릭 (또는 에이전트가 자동)

유저 수동 개입: 초기 2회, 이후 0~1회

방안 3: B2B 에이전트 (완전 자율)

설정 (1회):
  에이전트에 AgentKit 지갑 설정

이후:
  에이전트가 A2A로 자율 요청 + 자율 결제

유저 수동 개입: 0회

---

핵심 정리

"에이전트가 대리 서명하려면 개인키가 필요한가?"

❌ 개인키를 직접 주는 방식: 텔레그램 트레이딩 봇 (Banana Gun 등)
   → 작동하지만, 봇 해킹 시 자금 탈취 위험

✅ 개인키 없이 서명 권한만 위임하는 방식:
   A. Privy Server Wallet — 키가 TEE에만 존재, 서버가 서명 API 호출
   B. 세션 키 — 임시 키 발급, 범위 제한, 만료 있음
   C. Lit PKP — 키가 분산됨, 조건부 서명
   D. Turnkey — TEE에서 정책 기반 서명
   E. Safe 모듈 — 스마트 계정에 모듈 권한 부여

ZKProofport 권장 조합

사용자 유형	방안	지갑 도구	서명 방식
일반 유저 (웹/앱)	Privy 임베디드	Privy Server Wallet	서버사이드 자동 서명
파워 유저 (기존 지갑)	세션 키 위임	ZeroDev + 기존 지갑	정책 범위 내 자동 서명
B2B 에이전트 (A2A)	AgentKit 지갑	CDP Wallet (Nitro)	에이전트 자율 서명

우리 앱에 이미 있는 것

✅ Privy 이미 통합됨 (proofport-app)
✅ Privy Server Wallet 사용 가능 (서버사이드 서명)
   → 추가 구현 최소화
   → 유저 UX 최적화 (서명 팝업 제거 가능)
   → TEE Prover와 자연스러운 연동

---

References

• Coinbase AgentKit — 에이전트 전용 지갑
• Privy Server Wallets — 서버사이드 서명
• ZeroDev Session Keys — ERC-4337 세션 키
• Lit Protocol PKP — 분산 키 서명
• Turnkey — TEE 기반 키 관리
• Safe Modules — 스마트 계정 모듈
• GOAT SDK — 범용 에이전트 지갑 툴킷
• ERC-7715 Permissions — 지갑 권한 요청 표준
• Eliza Agent Framework — 소셜 에이전트 지갑 시스템

[hyuki0130]

[수정] KYC 지갑의 서명 위임 — 기존 지갑 주소를 유지하면서 에이전트에게 서명 위임

이전 분석의 오류: "새 지갑 발급" 방식은 Coinbase attestation이 기존 지갑에 묶여 있으므로 불가능. KYC 받은 그 지갑으로 서명해야 한다.

목차

• 1. 문제 재정의
• 2. 시나리오별 분석
• 3. 해결 방안 상세
• 4. 결제 지갑은 별도
• 5. 최종 아키텍처
• 6. 주의사항 및 한계

---

1. 문제 재정의

왜 새 지갑이 안 되는가

Coinbase KYC attestation은 특정 주소에 묶여 있음:

  EAS 컨트랙트에 기록된 attestation:
  {
    attester: "0x357458... (Coinbase)",
    recipient: "0xABC... (유저의 KYC 지갑)",  ← 이 주소가 고정
    data: { verifiedAccount: true }
  }

  회로가 검증하는 것:
  1. raw_transaction의 calldata에서 recipient 추출
  2. assert recipient == user_address
  3. user_signature로 user_address 소유권 증명

  → 새 지갑(0xDEF...)으로는 #2에서 실패
  → 반드시 0xABC...의 개인키로 서명해야 함

정확한 요구사항

필요: 0xABC...(KYC 지갑)의 개인키로 signal_hash 서명
문제: 이 개인키를 에이전트에게 직접 줄 수는 없음
목표: 개인키를 노출하지 않으면서 서명을 위임하는 방법

---

2. 시나리오별 분석

유저의 KYC 지갑 유형에 따라 해결 방법이 다릅니다:

시나리오 A: Privy 임베디드 지갑으로 KYC 받은 경우

우리 앱에서 Privy 로그인 → 임베디드 지갑 생성 → 이 주소로 Coinbase KYC

✅ Privy Server Wallet의 "Delegated Actions" 사용 가능
   → 서버에서 이 지갑으로 서명 가능 (유저 승인 없이)
   → 키는 Privy TEE에서만 순간적으로 복원 → 서명 → 즉시 파기
   → 완전 자동화 가능

⚠️ Privy Delegated Actions는 Privy가 생성한 임베디드 지갑에만 적용
   → 외부 지갑(MetaMask 등)에는 불가

이 경우 플로우:

유저                     우리 서버 (Privy SDK)        TEE Prover
 │                            │                          │
 │── 이메일 로그인 ──────────►│                          │
 │   (1회, 이미 KYC 완료)     │                          │
 │                            │                          │
 │── "증명 생성해줘" ────────►│                          │
 │                            │                          │
 │                    Privy Delegated Actions:            │
 │                    signMessage(signal_hash)            │
 │                    → TEE에서 키 복원 → 서명 → 키 파기  │
 │                            │                          │
 │                            │── {address, sig, scope} ►│
 │                            │                          │
 │                            │   bb prove 실행          │
 │                            │                          │
 │                            │◄── proof ────────────────│
 │◄── 증명 완료! ─────────────│                          │

유저 개입: 로그인 1회만. 서명 팝업 없음.

---

시나리오 B: MetaMask 등 외부 지갑으로 KYC 받은 경우

이 경우가 가장 어렵습니다. 외부 지갑의 개인키는 유저 디바이스에만 있고, Privy로 서버사이드 서명 불가.

3가지 방법 존재:

---

시나리오 C: B2B — 고객사 에이전트가 자체 지갑 보유

고객사가 Coinbase AgentKit/Turnkey 등으로 관리하는 지갑에 KYC를 받은 경우.

고객사 에이전트 (자체 키 관리)
  │ 자체 인프라에서 서명 생성
  │── A2A로 {address, signature, scope} 전송
  ▼
우리 TEE Prover → 증명 생성 → 반환

유저 개입: 없음 (에이전트끼리 자율 처리)

---

3. 해결 방안 상세

방안 1: EIP-7702 + 세션 키 (가장 유망, 시나리오 B 최선)

EIP-7702란? 2025년 5월 Pectra 업그레이드로 이더리움 메인넷에 이미 적용. 기존 EOA를 스마트 계정처럼 사용 가능하게 만듦.

핵심: 기존 지갑 주소 0xABC를 유지하면서 세션 키 위임 가능

┌─ 초기 설정 (1회) ──────────────────────────────────┐
│                                                     │
│  유저의 MetaMask (0xABC — KYC 지갑):                │
│                                                     │
│  1. EIP-7702 delegation TX 서명                     │
│     → "이 스마트 컨트랙트 코드를 내 주소에 적용해줘" │
│     → 주소 변경 없음! attestation 그대로!            │
│                                                     │
│  2. 세션 키 생성 + 정책 설정                        │
│     {                                               │
│       sessionKey: "0xSESSION...",                   │
│       permissions: {                                │
│         allowedMethods: ["personal_sign"],           │
│         allowedPrefixes: ["signal_hash 접두사"],     │
│         maxUses: 100,                               │
│         expiresAt: "2026-03-01T00:00:00Z"           │
│       }                                             │
│     }                                               │
│                                                     │
│  3. 에이전트에게 세션 키 전달                        │
│                                                     │
└─────────────────────────────────────────────────────┘

┌─ 이후 매 증명 요청 (자동) ─────────────────────────┐
│                                                     │
│  에이전트:                                          │
│  1. 세션 키로 signal_hash 서명                      │
│     → 0xABC 주소 대신 서명하지만                    │
│     → 스마트 컨트랙트가 정책 범위 내인지 검증       │
│  2. {address: 0xABC, signature, scope} → TEE        │
│  3. TEE가 증명 생성                                 │
│                                                     │
│  유저 개입: 없음 (세션 만료 전까지)                  │
│                                                     │
└─────────────────────────────────────────────────────┘

장점:

• ✅ 기존 지갑 주소 유지 (attestation 보존)
• ✅ 세션 만료까지 완전 자동
• ✅ 정책으로 범위 제한 (서명 용도, 횟수, 기간)
• ✅ 유저가 언제든 취소 가능
• ✅ 이더리움 메인넷에 이미 적용 (2025.05~)

단점:

• ⚠️ MetaMask은 지원, 다른 지갑은 순차 지원 중
• ⚠️ 초기 설정에 가스비 필요
• ⚠️ 세션 키 관리 스마트 컨트랙트 배포 필요

관련 표준:

• EIP-7702: EOA → 스마트 계정 위임
• ERC-7715: wallet_grantPermissions — 지갑 권한 요청 표준
• MetaMask Delegation Toolkit: 위 표준의 공식 구현

---

방안 2: One-time 웹 서명 + WalletConnect (즉시 구현 가능)

세션 키처럼 완전 자동은 아니지만, 유저 부담을 최소화하는 현실적 방안.

┌─ 증명 요청 시 ─────────────────────────────────────┐
│                                                     │
│  에이전트 (봇/웹서비스):                             │
│  1. 증명 요청 수신                                  │
│  2. signal_hash 계산                                │
│  3. 유저에게 서명 요청 링크 전송:                    │
│     "https://sign.zkproofport.app/?req=abc123"      │
│                                                     │
│  유저 (폰/PC):                                      │
│  4. 링크 클릭 → 웹 페이지 열림                      │
│  5. WalletConnect로 KYC 지갑 연결                   │
│  6. signal_hash 서명 (1번 클릭)                     │
│  7. 페이지 닫기                                     │
│                                                     │
│  에이전트:                                          │
│  8. 서명 수신 (webhook/polling)                     │
│  9. {address, signature, scope} → TEE Prover        │
│  10. 증명 생성 완료                                 │
│                                                     │
│  유저 개입: 링크 클릭 + 지갑 연결 + 서명 = 3번      │
│                                                     │
└─────────────────────────────────────────────────────┘

시퀀스:

에이전트          서명 웹페이지         유저 + 지갑          TEE
  │                  │                    │                  │
  │── 서명 요청 ────►│                    │                  │
  │  {signal_hash,   │                    │                  │
  │   requestId}     │                    │                  │
  │                  │                    │                  │
  │              URL 생성                  │                  │
  │                  │                    │                  │
  │── URL을 유저에게 전달 ───────────────►│                  │
  │  "이 링크에서 서명해주세요"           │                  │
  │                  │                    │                  │
  │                  │◄── 유저가 링크 열기 │                  │
  │                  │                    │                  │
  │                  │── WalletConnect ──►│                  │
  │                  │◄── 지갑 연결 ──────│                  │
  │                  │                    │                  │
  │                  │── personal_sign ──►│                  │
  │                  │◄── signature ──────│                  │
  │                  │                    │                  │
  │◄── webhook ──────│                    │                  │
  │  {address, sig}  │                    │                  │
  │                  │                    │                  │
  │── {addr,sig,scope} ─────────────────────────────────────►│
  │                  │                    │                  │
  │◄── proof ────────────────────────────────────────────────│
  │                  │                    │                  │

장점:

• ✅ 어떤 지갑이든 사용 가능 (WalletConnect 지원만 되면)
• ✅ 스마트 컨트랙트 배포 불필요
• ✅ 가스비 없음
• ✅ 즉시 구현 가능

단점:

• ⚠️ 매 증명 요청마다 유저 서명 필요 (자동화 제한)
• ⚠️ 유저가 응답하지 않으면 대기

---

방안 3: Privy 임베디드 지갑 권장 (UX 최적)

유저가 처음부터 Privy 임베디드 지갑으로 KYC를 받게 유도.

┌─ 온보딩 플로우 ────────────────────────────────────┐
│                                                     │
│  1. ZKProofport 가입 (이메일/소셜 로그인)           │
│     → Privy가 임베디드 지갑 자동 생성 (0xABC)       │
│                                                     │
│  2. "Coinbase KYC를 받으세요" 안내                   │
│     → 유저가 Coinbase에서 0xABC 주소로 KYC 완료     │
│     → attestation이 0xABC에 기록됨                  │
│                                                     │
│  3. 이후 증명 요청 시:                               │
│     → Privy Server Wallet로 서버사이드 서명          │
│     → 유저는 아무것도 안 해도 됨                     │
│                                                     │
│  유저 개입: 온보딩 시 1회만                          │
│  이후: 완전 자동                                     │
│                                                     │
└─────────────────────────────────────────────────────┘

장점:

• ✅ 가장 간단한 UX (이메일 로그인 → 끝)
• ✅ 서버사이드 자동 서명 (Privy Delegated Actions)
• ✅ 추가 인프라 불필요 (이미 Privy 통합됨)

단점:

• ⚠️ 기존에 다른 지갑으로 KYC 받은 유저는 재KYC 필요
• ⚠️ Privy 인프라 의존

---

4. 결제 지갑은 별도

x402 결제는 증명 서명과 완전히 분리 가능:

┌─ 서명 지갑 (KYC) ─────────────┐  ┌─ 결제 지갑 (x402) ────────────┐
│                                │  │                                │
│ 주소: 0xABC (Coinbase KYC)    │  │ 주소: 0xPAY (별도)             │
│ 용도: signal_hash 서명만      │  │ 용도: USDC 결제만              │
│ 관리: 유저 본인 또는 Privy    │  │ 관리: 에이전트 자체 지갑       │
│                                │  │       (AgentKit, Privy 등)     │
│ 이 지갑에서 돈이 나가지 않음  │  │ 이 지갑에서 0.05 USDC 결제    │
│                                │  │                                │
└────────────────────────────────┘  └────────────────────────────────┘

→ 결제 지갑은 에이전트 전용 지갑으로 자유롭게 운영 가능
→ KYC 지갑의 보안과 무관

---

5. 최종 아키텍처

유저 유형별 최적 방안

유저 유형	KYC 지갑	서명 방식	자동화 수준	권장 방안
신규 유저	Privy 임베디드	Server-side (Delegated Actions)	완전 자동	방안 3
기존 유저 (EOA)	MetaMask 등	EIP-7702 세션 키	세션 내 자동	방안 1
기존 유저 (EOA, 지금 당장)	MetaMask 등	웹 서명 링크	요청마다 수동	방안 2
B2B 에이전트	AgentKit/Turnkey	자체 키 관리	완전 자동	시나리오 C

종합 플로우

┌─────────────────────────────────────────────────────────────┐
│                    Client / 에이전트                         │
│                          │                                  │
│            ┌─────────────┼─────────────┐                    │
│            ▼             ▼             ▼                    │
│     ┌───────────┐ ┌──────────┐ ┌────────────┐              │
│     │ Privy 지갑 │ │ EOA 지갑  │ │ B2B 에이전트│              │
│     │ (임베디드) │ │(MetaMask) │ │ (자체 지갑) │              │
│     └─────┬─────┘ └────┬─────┘ └──────┬─────┘              │
│           │             │              │                    │
│     Server-side    EIP-7702        자체 서명                │
│     Delegated      Session Key    (Turnkey/                 │
│     Actions        또는 웹 서명    AgentKit)                │
│           │             │              │                    │
│           └─────────────┼──────────────┘                    │
│                         ▼                                   │
│              { address, signature, scope }                   │
│                         │                                   │
│                    x402 결제                                 │
│              (별도 결제 지갑에서)                             │
│                         │                                   │
│                         ▼                                   │
│                ┌─── TEE Prover ───┐                         │
│                │                   │                         │
│                │ Base RPC fetch    │                         │
│                │ → attestation TX  │                         │
│                │ ecrecover         │                         │
│                │ merkle proof      │                         │
│                │ bb prove          │                         │
│                │                   │                         │
│                └───────┬───────────┘                         │
│                        │                                    │
│                        ▼                                    │
│                 { proof, publicInputs }                      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

6. 주의사항 및 한계

EIP-7702 세션 키 주의사항

⚠️ 세션 키로 서명한 것은 EOA의 직접 ECDSA 서명과 다름

문제: 우리 회로는 ecrecover(signature, signal_hash)로 주소를 복원
     → 세션 키 서명은 다른 키로 서명되므로 직접 ecrecover 불가
     → 스마트 계정 레벨에서 유효하지만, 회로 레벨에서는 다른 주소

해결 옵션:
  A. 세션 키 매니저 컨트랙트가 원본 키로 서명을 "중개"
     → 이건 결국 원본 키에 접근해야 하므로 불가

  B. 회로를 수정하여 EIP-1271 서명 검증 지원
     → isValidSignature(hash, signature) 온체인 호출
     → 회로 내부에서는 불가능 (온체인 호출 필요)

  C. ⭐ 세션 키 설정 시 원본 키로 "사전 서명 배치" 생성
     → 유저가 여러 signal_hash에 대해 미리 서명
     → 에이전트가 필요할 때 사전 서명 사용
     → 회로 수정 불필요!

  D. ⭐ 세션 키 설정 시 원본 키로 범용 서명 생성
     → scope별로 1개씩 미리 서명
     → 동일 scope 내에서는 동일 서명 재사용 가능
     → nullifier가 이중 사용 방지

가장 현실적인 접근

┌─ 현실적 우선순위 ──────────────────────────────────────────┐
│                                                             │
│  Phase 1 (즉시): 방안 3 — Privy 임베디드 지갑 권장         │
│  ├─ 신규 유저 온보딩: 이메일 → Privy 지갑 → KYC → 자동     │
│  ├─ 이미 Privy 통합되어 있으므로 추가 개발 최소             │
│  └─ 서버사이드 자동 서명 → 유저 개입 최소화                 │
│                                                             │
│  Phase 2 (단기): 방안 2 — 웹 서명 링크                     │
│  ├─ 기존 EOA 유저 지원 (MetaMask 등)                       │
│  ├─ 매 요청마다 서명 필요하지만 동작은 함                   │
│  └─ sign.zkproofport.app 간단한 서명 페이지 구축            │
│                                                             │
│  Phase 3 (중기): 방안 1 — EIP-7702 세션 키                 │
│  ├─ 지갑 지원 확대 후 (MetaMask, Rainbow 등)                │
│  ├─ 사전 서명 배치 방식으로 회로 수정 없이 구현             │
│  └─ EOA 유저도 세션 내 완전 자동화                          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

회로 수정이 필요한가?

방안 1 (EIP-7702 세션 키):
  → 사전 서명 배치 방식 사용 시 회로 수정 불필요
  → EIP-1271 지원 시 회로 수정 필요

방안 2 (웹 서명):
  → 회로 수정 불필요 (원본 키로 직접 서명)

방안 3 (Privy 임베디드):
  → 회로 수정 불필요 (Privy가 원본 키로 서명)

→ Phase 1, 2는 회로 수정 없이 즉시 구현 가능

---

References

• EIP-7702 (Pectra) — EOA → 스마트 계정 위임 (메인넷 적용)
• ERC-7715 — 지갑 권한 요청 표준 (wallet_grantPermissions)
• MetaMask Delegation Toolkit — EIP-7702 + ERC-7715 공식 구현
• Privy Delegated Actions — 서버사이드 서명 (임베디드 지갑 전용)
• Privy: 외부 지갑은 서버 서명 불가 — 공식 문서 확인
• WalletConnect Session Lifetime — 7일, 연장 가능
• SIWE → Session Keys — 1회 서명으로 세션 키 발급
• ZeroDev Session Keys — ERC-4337 세션 키 구현
• OpenZeppelin EIP-7702 Guide — 기존 주소 유지하면서 위임
• Turnkey Delegated Access — TEE 기반 정책 서명