EIP-6969: ERC 및 NFT 메타데이터 구축을 위한 새로운 아이디어

NFT 및 토큰화된 자산이 점점 더 컴포저블하고 동적으로 발전함에 따라, 메타데이터는 확장성, 영속성 및 상호 운용성의 병목 현상으로 부상했습니다. 현재의 메타데이터 관행—가장 흔하게 HTTP를 통해 제공되는 JSON—은 취약하고, 버전 관리가 어려우며, 다운타임에 취약합니다. 비공식적으로 “EIP-6969”로 불리는 새로운 방향은 향후 10년간 ERC 및 NFT 메타데이터가 어떻게 구축되어야 하는지 탐구합니다: 설계상 콘텐츠 주소 지정, 검증 가능, 업그레이드 가능 및 체인 인식.

이 글은 “EIP-6969 스타일” 메타데이터에 대한 실용적인 아키텍처를 개략적으로 설명하고, 기존 표준으로 대부분을 구현하는 방법을 보여주며, 고성능 L2와 모듈식 계정이 보편화된 Cancun 이후 세계에서 이것이 왜 중요한지 설명합니다.

메타데이터 재고가 필요한 이유

기본이 되는 ERC-721 및 다중 토큰 ERC-1155를 포함한 최초의 NFT 표준은 일반적으로 오프체인 JSON으로 확인되는 tokenURI를 정의합니다. 간단하지만, 개발자와 마켓플레이스는 일상적으로 다음과 같은 문제에 직면합니다:

• 중앙 집중식 HTTP 엔드포인트에 의존할 때의 취약성 및 링크 끊김
• 진화하는 컬렉션에 대한 신뢰할 수 있는 버전 관리 및 출처 부족
• 인덱서 및 UI에 메타데이터 업데이트 신호 전달의 어려움
• L1/L2 생태계 전반에 걸친 일관성 없는 다중 체인 확인
• 창작자를 위한 모호한 로열티 및 라이선스 신호

이미 여러 EIP가 이 퍼즐의 일부를 해결하고 있습니다. 예를 들어, ERC-4906은 인덱서에 메타데이터 업데이트를 알리는 이벤트를 추가합니다; EIP-2981은 로열티 정보를 표준화합니다; EIP-3668 (CCIP-Read)는 신뢰를 최소화하는 오프체인 읽기를 가능하게 합니다; EIP-1014 (CREATE2)는 레지스트리 및 리졸버에 대한 결정론적 계약 주소를 허용합니다. 한편, 이더리움 Cancun-Deneb 업그레이드 (EIP-4844 참조)는 L2의 데이터 가용성을 실질적으로 개선하여 더 많은 온체인 또는 반-온체인 메타데이터 접근 방식을 열었습니다.

“EIP-6969 스타일” 메타데이터는 어떤 모습일까

EIP-6969를 단일 인터페이스가 아닌, 온체인 레지스트리, 콘텐츠 주소 지정 오프체인 데이터 및 지갑 및 마켓플레이스에 대한 강력한 신호를 결합한 청사진으로 생각하십시오.

• 결정론적 메타데이터 레지스트리

  • 예측 가능한 주소에 컬렉션별 “메타데이터 레지스트리”를 배포하기 위해 CREATE2를 사용합니다.
  • 레지스트리는 스키마 커밋먼트, 기본 리졸버, 대체 전략 및 버전 태그를 저장합니다.
  • 체인 전반에 걸쳐 재현 가능한 배포를 가능하게 하여 모호성과 스푸핑을 줄입니다.

• 기본적으로 콘텐츠 주소 지정 스토리지

  • 변경 가능한 URL 대신 해시로 메타데이터를 참조합니다; IPFS 콘텐츠 주소 지정 또는 Arweave Permaweb을 통해 확인합니다.
  • 성능을 위해 선택적으로 HTTP 미러를 사용할 수 있지만, 항상 검증 가능한 다이제스트에 고정됩니다.

• 업그레이드 가능하고 신호가 명확한 메타데이터

  • 토큰 수준 또는 컬렉션 수준 메타데이터가 변경될 때 ERC-4906 이벤트를 발생시켜 신뢰할 수 있는 새로 고침을 가능하게 합니다.
  • 스키마 변경 또는 리졸버 업그레이드를 나타내기 위해 레지스트리에서 시맨틱 버전을 사용합니다.

• 검증 가능한 오프체인 확인

  • 데이터가 온체인에 있을 수 없는 경우 신뢰를 최소화하는 오프체인 가져오기를 위해 CCIP-Read를 채택합니다.
  • EIP-712 형식화된 데이터를 사용하여 메타데이터 다이제스트에 서명합니다; 지갑 및 마켓플레이스는 계약 계정의 경우 EIP-1271을 사용하여 서명을 검증할 수 있습니다.

• 체인 인식, 다중 리소스 URI

  • L1 대 L2 변형을 명확하게 구분하기 위해 URI 및 레지스트리 기록에 CAIP-2 체인 식별자를 포함합니다. 이는 CAIP-2와 일관됩니다.
  • “다중 리소스” 설계를 선호합니다: 기본 콘텐츠 주소와 선택적 미러 (예: IPFS CID + HTTPS 게이트웨이 + Arweave TX).

• NFT 및 대체 가능 ERC를 위한 컴포저블 스키마

  • 인덱서의 모호성을 줄이기 위해 트레이트 구조, 속성 및 미디어 관계에 대한 JSON 스키마 또는 JSON-LD를 게시합니다; OpenSea의 메타데이터 표준과 같은 마켓플레이스 지침을 참조하십시오.
  • 단일 토큰 상태당 하나의 캐논ical 다이제스트를 유지하면서 역할 기반 보기(창작자 대 보유자 대 마켓플레이스)를 지원합니다.

• 선택적 계정 참여

  • 창작자가 업데이트, 라이선스 게이트 또는 토큰별 로직에 대한 프로그래밍 가능한 정책이 필요한 경우 EIP-6900 (모듈식 계정) 또는 토큰 바운드 컨트롤러(예: EIP-6551)를 통해 모듈식 스마트 계정과 메타데이터 제어를 통합합니다.

기존 EIP로 오늘날 구축하는 방법

공식 EIP가 도입되기 전까지, 대부분의 아키텍처는 입증된 표준과 간단한 패턴을 사용하여 구현할 수 있습니다:

1. CREATE2로 메타데이터 레지스트리 배포

   • 저장 내용:
     • schemaHash (콘텐츠 주소 지정 스키마)
     • resolver (계약 또는 CCIP 엔드포인트)
     • version (semver 문자열)
     • fallbacks (다중 리소스 URI 배열)
   • ERC-165를 통한 인터페이스 감지.

2. CCIP-Read를 통한 토큰 메타데이터 확인

   • 온체인 메서드는 클라이언트가 허가된 출처에서 오프체인 데이터를 가져오도록 지시하는 선택자를 반환합니다.
   • 오프체인 페이로드는 메타데이터와 EIP-712 서명을 반환합니다; 클라이언트는 EOA의 공개 키 또는 EIP-1271 계약에 대해 서명을 검증합니다.

3. 업데이트 시 ERC-4906 이벤트 발생

   • 트레이트 진화 또는 동적 아트를 가진 NFT 컬렉션의 경우, MetadataUpdate(tokenId) 또는 BatchMetadataUpdate(fromTokenId, toTokenId)를 트리거합니다.

4. 모든 곳에서 콘텐츠 주소 지정 URI 사용

   • IPFS 또는 Arweave에 캐논ical JSON을 고정합니다; CID/TX를 레지스트리 기록에 포함시킵니다.
   • 미러는 지연 시간을 개선할 수 있지만, 클라이언트는 다이제스트를 신뢰해야 합니다.

5. 스키마 게시

   • 기계 판독 가능한 스키마(예: JSON 스키마)로 속성, 미디어 관계, 애니메이션 및 에디션링을 문서화하고 스키마 해시를 레지스트리에 게시합니다.
   • OpenSea의 메타데이터 지침과 같은 마켓플레이스에서 예상하는 데이터 필드와 일치시킵니다.

6. 로열티 및 라이선스 신호

   • 로열티를 위해 EIP-2981을 구현하고, 법적 메타데이터를 이식 가능하고 검증 가능하게 유지하기 위해 스키마의 일부로 라이선스 참조를 노출합니다.

성과가 좋은 디자인 패턴

• 2단계 확인

  • 1단계: 버전, 리졸버 및 콘텐츠 다이제스트에 대한 온체인 레지스트리 데이터를 읽습니다.
  • 2단계: CCIP-Read 또는 오프체인 가져오기를 수행하고, 리졸버의 예상 서명자에 대해 서명을 검증하고, 다이제스트를 비교합니다.

• 다중 체인 일관성

  • 체인별 레지스트리 주소와 함께 CAIP-2 식별자를 사용합니다. 마켓플레이스와 지갑은 토큰이 속한 체인 변형을 명확하게 구분하여 크로스체인 UX를 개선할 수 있습니다.

• 거버넌스 및 복구

  • 레지스트리 업데이트는 잘 정의된 정책에 따라 제어되어야 하며, 이상적으로는 모듈식 계정(EIP-6900) 또는 시간 잠금 역할(time-locked roles)을 통해 제어되어야 합니다. 새 리졸버 또는 스키마가 지연 후 활성화되는 단계적 업데이트를 고려하십시오.

• 캐싱 및 재검증

  • 클라이언트는 콘텐츠 주소 지정 페이로드를 캐싱하고, ERC-4906 이벤트 또는 버전 변경 시 재검증합니다. 이는 대역폭을 줄이는 동시에 데이터를 최신 상태로 유지합니다.

보안 고려 사항

• 신뢰 경계

  • “메타데이터에 서명할 수 있는 사람”과 “리졸버를 업그레이드할 수 있는 사람”을 명확하게 분리합니다. 별도의 키를 사용하고 레지스트리에 게시하십시오.

• 서명 위생

  • 도메인 분리, 체인 ID, 만료 및 논스를 포함한 EIP-712를 선호하여 재실행 및 크로스 도메인 혼동을 방지합니다.

• 게이트웨이 및 미러

  • HTTPS 미러를 사용하는 경우 클라이언트 측에서 다이제스트 검사를 강제합니다. 진위성을 위해 게이트웨이 가용성에 의존하지 마십시오; 콘텐츠 주소 지정에 의존하십시오.

• 하위 호환성

  • 최소한의 호환성을 위해 기존 tokenURI를 유지하지만, 콘텐츠 주소 지정 다이제스트를 가리키고 고급 클라이언트를 위한 레지스트리 참조를 포함합니다.

사용자와 마켓플레이스에 대한 의미

컬렉터에게 EIP-6969 스타일 메타데이터는 깨진 이미지가 줄어들고, 새로 고침이 빨라지며, 출처가 명확해지는 것을 의미합니다. 마켓플레이스의 경우, 결정론적 레지스트리와 강력한 신호는 오프체인 휴리스틱을 줄이고, 인덱싱 정확도를 개선하며, 로열티 또는 라이선스 분쟁을 줄입니다. 창작자의 경우, 프로그래밍 가능한 정책이 실용적이 됩니다: 민팅 후 트레이트를 진화시키거나, 에디션을 분기하거나, 모듈식 계정을 통해 업데이트를 게이트할 수 있습니다—검증 가능성을 희생하지 않으면서 말입니다.

표준의 통합은 도구에도 도움이 됩니다. 인덱서는 ERC-4906 이벤트를 신뢰할 수 있습니다. 지갑은 EIP-1271로 서명을 검증할 수 있습니다. 다중 체인 dApp은 CAIP-2에 맞춰 일관된 크로스체인 컬렉션을 표시할 수 있습니다. 그리고 IPFS 또는 Arweave를 통한 콘텐츠 주소 지정은 캐논ical 기록을 변조 방지 상태로 유지합니다.

2025년 대비 로드맵

• 콘텐츠 주소 지정 URI로 컬렉션 마이그레이션을 시작하고 스키마 해시를 게시하십시오.
• 간단한 CREATE2 레지스트리 계약을 추가하고 업데이트 시 ERC-4906을 발생시키십시오.
• 온체인에 완전히 있을 수 없는 동적 데이터를 위해 CCIP-Read를 구현하고; EIP-712로 페이로드에 서명하십시오.
• L2의 새 민트의 경우, Cancun 지원 데이터 가용성(개요)을 활용하여 더 많은 메타데이터를 온체인 또는 블롭에 저장하고, 오프체인 페이로드를 체인 상태에 고정하십시오.
• 프로그래밍 가능한 업그레이드 정책이 필요한 경우 모듈식 계정 제어(EIP-6900)를 탐색하십시오.

마무리 생각과 실용적인 팁

메타데이터가 검증 가능하고, 콘텐츠 주소 지정되며, 모듈식 디자인으로 이동하더라도, 한 가지 변하지 않는 것은: 서명이 신뢰의 근원이라는 것입니다. 스키마 변경을 게시하는 창작자든, CCIP-Read 페이로드를 검증하는 마켓플레이스든, 안전한 EIP-712 서명과 키 격리는 필수적입니다.

더 강력한 키 보안을 위해 하드웨어 지갑을 선호한다면, OneKey는 오픈 소스 펌웨어, 강력한 보안 요소 보호, 인기 있는 dApp에서의 EIP-712와 같은 최신 서명 흐름에 대한 원활한 지원을 제공합니다. 메타데이터 아키텍처가 명확하고 검증 가능한 서명—특히 CCIP-Read 및 EIP-1271을 통한 계약 기반 검증—에 점점 더 의존함에 따라, 신뢰할 수 있고 감사 가능한 서명을 워크플로우에 포함하는 것은 창작자와 수집가 모두에게 실용적인 업그레이드입니다.

오늘날 이러한 “EIP-6969 스타일” 패턴을 채택함으로써, 생태계는 ERC 및 NFT 메타데이터를 더욱 내구성이 있고, 상호 운용 가능하며, 미래에 대비할 수 있도록 만들 수 있습니다—이더리움과 그 L2가 꾸준히 제공하고 있는 다중 체인, 고성능 세계에 준비될 수 있습니다.