ERC-8126 AI 에이전트 검증 (AI Agent Verification)

Final · 서명·인증 · 2026-01-15 작성

ERC-8004로 등록된 AI 에이전트를 토큰·미디어·코드·웹·지갑 다섯 가지 전문 검증으로 점검하고 결과를 0~100 위험 점수와 영지식 증명으로 제공하는 표준입니다.

왜 필요한가

블록체인에서 활동하는 AI 에이전트가 늘어나면서 이 에이전트가 진짜인지, 믿어도 되는지를 확인할 방법이 필요해졌습니다. 그런데 지금까지는 검증 방식이 제각각이어서 에이전트 등록이나 검증에 통일된 기준이 없었습니다. 어떤 에이전트는 스마트 컨트랙트가 실제로 배포되어 있는지조차 확인되지 않고 프로필 이미지가 조작된 것인지, 웹사이트가 안전한지, 지갑이 위협 데이터베이스에 올라 있는지도 알 길이 없었습니다. 또 검증 과정에서 민감한 데이터가 노출되거나 저장되면 그 자체가 유출 위험이 됩니다. 이 표준은 다섯 가지 검증을 하나의 절차로 묶고 결과를 누구나 비교할 수 있는 0~100 위험 점수로 통일하며 영지식 증명(Zero-Knowledge Proof)으로 원본 데이터를 드러내지 않고도 검증이 이루어졌음을 증명할 수 있게 합니다.

구현해야 하는 것

심층 설명

검증 요청은 반드시 agentId로

검증 요청은 ERC-8004 신원 레지스트리의 uint256 토큰 ID인 agentId를 참조해야 합니다(MUST). 검증 제공자는 정식 신원 레지스트리 컨트랙트의 tokenURI(agentId)를 호출하고 반환된 URI에서 에이전트 등록 JSON을 가져와, agentWallet/walletAddress, chain_id, contractAddress, endpoints/url, image/imageUrl, platform_id, solidityCode 등 모든 메타데이터 필드를 ERC-8004 등록 스키마에 따라 추출해야 합니다. agentId 없이 개별 파라미터를 직접 제출하는 것은 허용되지 않습니다. 이렇게 하면 검증 대상이 항상 온체인 신원과 연결됩니다.

다섯 가지 검증 유형

준수 제공자는 다섯 유형을 모두 구현해야 합니다. ETV(이더리움 토큰 검증)는 contractAddress가 있을 때 eth_getCode로 해당 chain_id에 배포된 컨트랙트인지(바이트코드가 0x가 아닌지) 확인하고 알려진 취약점 패턴을 점검합니다. MCV(미디어 콘텐츠 검증)는 imageUrl이 있을 때 출처와 내장 메타데이터를 확인하고 조작·변조 흔적, 워터마크·스테가노그래피·서명을 검사하며 C2PA 같은 프레임워크 사용을 권장합니다. SCV(솔리디티 코드 검증)는 solidityCode가 있을 때 재진입(reentrancy), 플래시론 공격 같은 취약점을 점검합니다. WAV(웹 앱 검증)는 HTTPS 응답과 SSL 인증서 유효성을 확인하고 OWASP WSTG를 따르도록 권장합니다. WV(지갑 검증)는 지갑의 거래 이력을 확인하고 위협 정보 데이터베이스와 대조합니다. 각 검증은 0~100 위험 점수를 내야 합니다.

위험 점수와 등급

종합 위험 점수는 적용된 모든 검증 점수의 평균(mean)으로 계산해야 합니다(MUST). 등급은 다섯 단계입니다. 0~20은 Low Risk(우려 최소), 21~40은 Moderate(일부 우려, 검토 권장), 41~60은 Elevated(주목할 우려, 주의 필요), 61~80은 High Risk(상당한 우려 발견), 81~100은 Critical(심각한 우려, 상호작용 회피)입니다. 0~100 범위는 0~10이나 0~255보다 세분성과 해석 용이성의 균형이 좋다는 이유로 선택되었습니다. 범위를 벗어난 점수는 InvalidScore(0x08) 오류입니다.

오프체인 표준과 선택적 온체인 요소

이 ERC는 기본적으로 검증 제공자를 위한 오프체인 표준입니다. 검증 요청 제출이나 수행에 온체인 컨트랙트 인터페이스가 필요하지 않습니다. 오프체인 수행은 가스 비용을 없애고 온체인에서는 비싸서 불가능한 복잡한 검증 로직을 가능하게 하며 컨트랙트 업그레이드 없이 검증 기준을 발전시키고 여러 제공자가 경쟁할 수 있게 합니다. 다만 최종 점수나 어테스테이션 기록, 이벤트 발행, 결과 조회를 위해 온체인 컴포넌트를 선택적으로 배포할 수 있으며(MAY), 배포한다면 최소한 AgentVerified·AttestationPosted 이벤트와 getLatestRiskScore 함수를 포함해야 합니다(SHOULD). 제공자는 점수와 증명 ID를 ERC-8004 검증 레지스트리에 게시할 수도 있습니다.

PDV와 영지식 증명, QCV

검증 결과는 PDV(Private Data Verification)를 거쳐 영지식 증명(ZKP)으로 만들어집니다. 저장되는 데이터가 없으므로 유출될 것도 없고 제3자가 검증 완료 사실을 암호학적으로 확인할 수 있습니다. 상세 검증 결과는 에이전트의 지갑 보유자만 접근할 수 있습니다. PDV 구현은 검증된 회로(예: Groth16)와 다자간 연산 세리머니 기반 신뢰 설정을 쓰는 것이 권장됩니다. 선택 기능인 QCV(Quantum Cryptography Verification)는 AES-256-GCM 또는 동급 알고리즘으로 민감한 검증 데이터를 양자내성 방식으로 암호화한 뒤 암호화된 데이터의 record_id와 decryption_url을 제공합니다. 타원곡선 기반 ZKP는 양자 공격에 취약할 수 있어 장기 보관 데이터에는 QCV가 추가 계층으로 권장됩니다.

수수료와 결제

검증 제공자는 수수료를 받을 수 있습니다(MAY). 수수료를 받는 경우 검증 전에 수수료 구조를 명확히 공개해야 하고(MUST), USDC 같은 스테이블코인 정산 지원이 권장되며 EIP-3009 TransferWithAuthorization을 써서 가스 없는 결제를 지원하는 것이 권장됩니다(SHOULD). 이 방식에서는 제공자가 가스비를 부담하므로 사용자가 ETH를 보유하지 않아도 검증을 받을 수 있습니다.

표준 오류 코드

구현은 0x01부터 0x0D까지 13개의 표준 오류 코드를 사용해야 합니다(MUST). InvalidAddress(0x01), InvalidURL(0x02), AgentNotFound(0x03), VerificationFailed(0x04), InsufficientCredits(0x05), InvalidProof(0x06), ProviderUnavailable(0x07), InvalidScore(0x08), ContractNotFound(0x09), SolidityCodeNotFound(0x0A), ImageNotFound(0x0B), SteganographyFailed(0x0C), MediaVerificationFailed(0x0D)입니다. 온체인 구현은 같은 이름의 커스텀 에러로 revert하는 것이 권장됩니다(SHOULD).

쓸 때 주의할 점

ERC 원문 · ← ERCs