이더 메인넷에 ERC-8004(Trustless Agents) 표준이 공식 도입됨에 따라, AI 에이전트의 신원 및 평판 관리는 검증 가능하고 신뢰할 수 있는 새로운 단계로 진입했습니다. 이 표준은 에이전트에게 세 가지 핵심 레지스트리(신원 레지스트리, 평판 레지스트리, 검증 레지스트리)를 통해 온체인 검증 가능한 "신원 시스템"을 제공합니다. 이 글에서는 보안 감사 관점에서 각 레지스트리의 리스크 위험 요소를 분석하고, ERC-8004의 기술적 세부 사항을 함께 다루며, 개발자와 감사 실용적인 감사 가이드를 제공합니다.
기술적 세부 사항 및 감사 항목
ERC-8004의 핵심은 세 개의 레지스트리 항목에 있습니다.
1. 신원 등록
URIStorage 확장 기능을 갖춘 ERC-721 기반의 최소한의 온체인 핸들은 에이전트의 등록 파일로 확인되어 각 에이전트에 대해 이식 가능하고 검열에 강한 식별자를 제공합니다.
ERC-8004 아키텍처에서 신원 레지스트리는 ERC-721 위에 구축되며 URIStorage 기능을 확장합니다. 즉, 각 에이전트는 온체인 상의 고유한 NFT에 해당하며, 이 NFT를 AgentID라고 합니다.
개발자가 에이전트를 생성할 때, 레지스트리 컨트랙트의 `register` 함수를 호출하여 새로운 AgentID를 민트. 이 토큰은 오프체인에 저장된 JSON 파일, 즉 "에이전트 등록 파일"을 가리키는 `tokenURI`에 바인딩됩니다. 등록 파일은 엄격한 사양을 준수해야 하며, 일반적으로 세 가지 핵심 요소를 포함합니다.
- 이름, 설명, 아바타 URL 등의 기본 정보;
- 프록시가 접근할 수 있는 네트워크 주소인 서버 엔드포인트는 HTTP, WebSocket, Libp2p, A2A, MCP 등 다양한 프로토콜을 지원합니다.
- 기능 선언은 이미지 생성, 차익 거래 또는 코드 감사 와 같이 에이전트가 수행할 수 있는 작업 목록입니다.
단순히 자체 선언만으로는 신뢰를 구축하기에 명백히 불충분하므로, ERC-8004는 도메인 검증 메커니즘을 도입했습니다. 에이전트는 선언된 도메인 아래의 경로(/.well-known/agent-card.json)에 서명 파일을 호스팅해야 합니다. 온체인 레지스트리는 이 연결을 검증하여 온체인 AgentID를 해당 DNS 도메인에 연결합니다. 이 단계는 피싱 및 사칭 공격을 방지하는 데 매우 중요합니다. 에이전트는 임의로 도메인 소유권을 주장할 수 없으며, 암호화 서명을 사용하여 제어권을 입증해야 합니다.
감사 중점 사항:
● setTokenURI 함수의 접근 제어를 확인하여 프록시 소유자 또는 권한 있는 역할(예: onlyOwnerAfterMint)만 URI를 업데이트할 수 있도록 설정하십시오.
● URI가 IPFS 또는 Arweave와 같은 불변 스토리지 솔루션을 지원하는지 확인하십시오. 중앙 집중식 HTTP 연결을 사용하는 경우 DNS 하이재킹을 방지하기 위해 도메인 제어의 보안을 평가하십시오.
● URI 형식의 유효성을 검증하여 널 포인터 또는 유효하지 않은 URI로 인해 발생하는 계약 예외를 방지하십시오.
● 서명 위조 또는 재전송 공격을 방지하기 위해 도메인 이름 서명 검증 시 암호화 서명 검증(예: EIP-712)을 엄격하게 수행하는지 계약 내용을 확인하십시오.
● 도메인 소유권 인증서의 만료 메커니즘을 확인하여 장기간 유효한 서명이 재사용되는 것을 방지하십시오.
● 도메인 이름 확인 프로세스가 중앙 집중식 오라클 에 의존하지 않도록 하여 단일 장애 지점이나 조작 가능성을 방지하십시오.
2. 평판 등록
피드백 신호를 게시하고 수신하기 위한 표준 인터페이스입니다. 점수 계산 및 집계는 온체인(구성 가능성)과 오프체인(복잡한 알고리즘) 모두에서 이루어지므로 프록시 점수 계산, 감사 네트워크 및 보험 풀을 포함하는 전문 서비스 생태계를 구축할 수 있습니다.
이는 등록된 AI 에이전트를 평가하고 피드백을 제공하는 데 사용됩니다. 간단한 피드백은 온체인 제출할 수 있으며, 보다 복잡한 피드백은 오프체인에서 제출할 수 있습니다. 이렇게 취합된 피드백은 다시 온체인 데이터베이스에 업로드됩니다.
ERC-8004는 "결제 증명 연결" 메커니즘을 통해 악의적인 평점 조작을 방지할 수 있습니다. 에이전트 A가 에이전트 B에 대한 리뷰를 작성하면 `giveFeedback` 함수가 호출됩니다. 이 함수는 평점(0~100)과 리뷰 해시값뿐만 아니라 `paymentProof` 필드(일반적으로 x402 트랜잭션의 해시값)도 허용합니다. 따라서 리뷰 조작 비용이 매우 높아져 Sybil어택 공격 가능성이 크게 줄어듭니다. 결과적으로 전체 시스템은 안정적이고 높은 품질의 서비스를 제공하는 에이전트에게 자연스럽게 보상을 제공하게 됩니다.
감사 중점 사항:
● `giveFeedback` 함수가 `paymentProof` 매개변수를 필수로 요구하는지 확인하고, 해당 매개변수가 유효한 x402 트랜잭션 해시(또는 다른 결제 표준을 준수하는지)를 갖는지 검증하십시오. 단일 결제에 대한 중복 평가를 방지하기 위해 결제 증명이 재사용되지 않도록 하십시오(예: 사용된 해시 기록).
● 점수 범위(0-100)가 계약 수준에서 제대로 적용되는지 확인하여 범위를 초과하는 점수로 인해 집계 로직이 오류가 발생하는 것을 방지하십시오.
● 오프체인 집계 알고리즘의 조작 저항성을 평가합니다. 예를 들어, 중앙값 사용, 극단값 제거 또는 가중 평균 사용 여부, 그리고 비정상적인 동작(예: 짧은 시간 내에 대량 평가를 수행하는 경우)에 대한 페널티 부여 여부 등을 고려합니다.
● 몰수 조건이 명확하고 검증 가능한지, 예를 들어 사기 증거 제출을 위해 온체인 증거 또는 제3자 오라클 에 의존하는지 여부를 검토하십시오.
● 제재 로직에 중앙 집중식 권한(예: 관리자가 스테이킹 자금을 임의로 몰수할 수 있는 권한)이 포함되지 않도록 하고, 제재 발동 조건이 스마트 계약에 의해 자동으로 실행되도록 합니다.
● 예금 인출 시 발생하는 불이익이나 몰수 조치를 방지하기 위해, 담당자들이 급하게 자금을 클레임 것을 막기 위해 스테이킹 클레임 락업 기간 및 조건을 테스트하십시오.
3. 레지스트리를 검증합니다.
독립 검증자 검사(예: zkML 검증자, TEE 오라클, 신뢰도 평가)를 요청하고 기록하기 위한 일반적인 후크입니다.
평판은 과거를 반영하지만, 리스크 시나리오(예: 대규모 자금 이체)에서는 과거 이력만으로는 충분하지 않습니다. 검증 레지스트리를 통해 에이전트는 제3자 또는 자동화 시스템에 결과를 제출하여 검증을 받을 수 있으며, 이러한 시스템은 스테이킹 보안 추론 재실행, zkML 검증기 또는 TEE 오라클 과 같은 메커니즘을 사용하여 요청을 검증하거나 거부할 수 있습니다.
첫 번째 모델은 게임 이론 기반 보안 설계를 활용한 암호경제학적 검증 방식입니다. 참여자는 레지스트리에 일정량의 네이티브 토큰이나 스테이블코인을 스테이킹 해야 합니다. 참여자가 의무를 이행하지 못하거나 잘못된 결과를 제공하는 경우, 검증자 네트워크는 사기 증거를 제출하여 스마트 계약을 실행하고 스테이킹 자금을 자동으로 몰수할 수 있습니다. 이 모델은 데이터 스크래핑이나 간단한 API 서비스처럼 결과는 쉽게 검증할 수 있지만 계산 과정은 불투명한 작업에 적합합니다.
두 번째 모델은 수학적 원리에 기반한 보안 설계인 암호화 검증입니다. TEE(Trusted Execution Environment) 인증을 통해 에이전트는 Intel SGX 또는 AWS Nitro와 같은 안전하고 강화된 하드웨어 환경에서 실행될 수 있습니다. 검증 레지스트리는 하드웨어에서 전송된 원격 인증 보고서를 저장하고 검증하여 에이전트가 실행하는 코드가 특정 코드의 정품이며 변조되지 않은 버전임을 입증합니다.
zkML(Zero-Knowledge 머신러닝(ML))은 또 다른 암호화 기반 검증 방식입니다. 에이전트는 추론 결과와 함께 영지식 증명을 제출합니다. 이 증명은 온체인 검증 계약을 통해 매우 낮은 비용으로 검증될 수 있으며, 특정 입력 조건에서 특정 모델(예: Llama-3-70B)을 사용하여 출력이 생성되었음을 수학적으로 보장합니다. 이는 서비스 제공업체가 고성능 모델을 사용한다고 주장하면서 실제로는 비용 절감을 위해 저성능 모델을 사용하는 "모델 대체" 공격을 방지합니다.
감사 항목
암호경제학적 검증이라면 다음 사항을 확인해야 합니다.
● 사기 증거 제출 기간을 확인하세요: 검증자가 사기 행위를 감지하고 증거를 제출할 충분한 시간이 확보되어 있습니까? 제출 기간이 너무 짧으면 악의적인 행위를 놓칠 수 있고, 너무 길면 자금이 장기간 동결될 수 있습니다.
● 사기 증명 검증을 위한 판정 로직: 다중 서명 검증자 집합에 의존하는가? 그렇다면 선택된 검증자의 탈중앙화 정도와 임계값 설정을 검토해야 한다. 판정이 전적으로 온체인 이루어지는 경우, 판정의 근거(예: 온체인 검증 가능한 결과)가 존재하고 명확한지 확인해야 한다.
● 스테이킹 금액이 리스크 에 상응하도록 하여 저비용 악의적 행위(예: 스테이킹 부족으로 인해 불법 행위로 얻는 이익이 손실보다 훨씬 큰 경우)를 방지하십시오.
TEE 인증인 경우 다음 사항을 확인해야 합니다.
● 만료된 증명이 수락되지 않도록 계약서에 TEE 증명의 적시성 검증 조항(예: 타임스탬프 또는 블록 높이 포함)이 있는지 확인하십시오.
● 증명 내용에 프록시의 코드 해시와 입력/출력 다이제스트가 포함되어 있는지 확인하여 증명이 특정 작업에만 국한되고 작업 간 재사용을 방지하는지 확인합니다.
● TEE 증명의 검증 로직이 외부 오라클 (예: Intel IAS)에 의존하는지 평가합니다. 의존하는 경우, 오라클 의 보안 및 탈중앙화 감사 .
zkML 유효성 검사인 경우 다음 사항을 확인해야 합니다.
● 계약에 감사 zk 검증 라이브러리(예: SnarkVerifier)가 통합되어 있고 특정 증명 시스템(예: Groth16, PLONK)에 대한 검증 키가 올바르게 구성되어 있는지 확인합니다.
● 검증 계약이 모델 대체 공격(예: 작은 모델에 대해 생성된 증명이 큰 모델의 출력이라고 주장하는 경우)을 방지하기 위해 증명에 적용 가능한 모델 및 입력 범위를 제한하는지 확인합니다.
● 증명 생성의 탈중앙화 정도를 평가합니다. 단일 증명자에 의존하는가? 여러 증명자가 존재하는 경우, 악의적인 증명자를 방지하기 위한 합의 메커니즘을 설계해야 합니다.
결론
ERC-8004는 AI 에이전트에 대한 신뢰를 구축하기 위한 표준을 제공하며, 그 보안은 전체 온체인 에이전트 생태계에 매우 중요합니다. 보안 감사 세 가지 레지스트리의 설계 의도와 잠재적 리스크 에 대한 심층적인 이해가 필요합니다. 또한, 복잡한 계약 간 상호 작용과 일반적인 취약점을 간과할 수 없습니다. 포괄적이고 엄격한 감사 통해 ERC-8004가 "신뢰할 수 없는 환경(trustlessness)"이라는 약속을 진정으로 이행하고 자율 에이전트의 미래를 위한 안전한 기반을 마련할 수 있도록 해야 합니다.
