ERC-4955 NFT 벤더 메타데이터 확장 (Vendor Metadata Extension for NFTs)

Final · NFT·멀티토큰 · 2022-03-29 작성

NFT 메타데이터 JSON에 namespaces 필드를 추가해 프로젝트별 전용 데이터(3D 모델 정보 등)를 한 곳에 담을 수 있게 하는 표준입니다.

왜 필요한가

NFT 메타데이터에는 이름, 설명, 이미지 정도만 표준으로 정해져 있습니다. 그런데 메타버스나 마켓플레이스 같은 서비스는 NFT를 자기 화면 안에서 보여 주기 위해 3D 모델 같은 추가 데이터가 필요합니다. 디센트럴랜드(Decentraland), 더샌드박스(TheSandbox), 크립토아바타스(Cryptoavatars) 같은 프로젝트는 각자 고유한 미적 스타일과 데이터 형식을 쓰기 때문에, 한 프로젝트용으로 만든 3D 모델이 다른 곳에서는 호환되지 않습니다. 이런 프로젝트별 데이터를 넣을 표준 자리가 없으면 서비스마다 제각각의 방식으로 데이터를 저장하고 찾아야 하고, 지갑이나 마켓플레이스가 어떤 NFT든 똑같은 방법으로 읽어 활용하기 어렵습니다. 이 표준은 기존 메타데이터 JSON에 프로젝트별 공간인 namespaces를 마련해 이 문제를 풉니다.

심층 설명

namespaces 속성의 정의

EIP-721과 EIP-1155의 메타데이터 JSON 스키마에 namespaces라는 새 속성을 추가합니다. 타입은 object이고 설명은 "Application-specific NFT properties"입니다. 이 속성 안에는 프로젝트(벤더)마다 객체를 하나씩 둡니다. 기존 필드인 name, description, image는 그대로 유지되므로 기존 스키마를 깨지 않고 확장하는 방식입니다.

데이터를 직접 넣거나 URI로 연결하는 두 가지 방식

예시에서는 두 가지 기재 방식을 보여 줍니다. 첫째, namespaces 안의 각 프로젝트 이름 아래에 prop1, prop2 같은 속성을 직접 담는 방식입니다. 둘째, 각 프로젝트 이름에 URI 문자열 하나만 적어 두고 실제 데이터는 그 주소에서 받아 오게 하는 방식입니다. 두 번째 방식은 JSON 응답의 크기를 줄이는 데 쓸 수 있습니다.

공통 스타일 대신 네임스페이스를 택한 이유

메타버스마다 고유한 아마추어(armature, 3D 모델의 뼈대)와 미적 스타일을 쓰기 때문에 같은 GLB, GLTF 확장자라도 플랫폼마다 다른 모델이 필요합니다. 또 디센트럴랜드의 착용 아이템 설정처럼 replaces, hides, category, bodyShapes 같은 플랫폼 전용 표현 파일도 각자 다릅니다. 모든 플랫폼이 공유하는 "Decentraland 스타일" 같은 공통 스타일 표준이 없으므로, style 필드로 분류하는 대신 각 벤더가 자기 이름의 네임스페이스에서 fetch(metadata.namespaces["PROJECT_NAME"].uri) 같은 방법으로 필요한 모델을 바로 찾아 렌더링하도록 했습니다.

기존 메타데이터를 확장하는 이유

이더리움의 대부분 프로젝트는 업그레이드할 수 없는 컨트랙트를 씁니다. 새 컨트랙트 구현을 요구하는 표준이라면 기존 프로젝트가 컨트랙트를 다시 배포해야 하는데, 이는 시간이 들고 비용을 낭비합니다. EIP-721의 기존 메타데이터 필드를 활용하면 필요한 변경을 최소화할 수 있습니다. 또 메타데이터 JSON은 이미 image 필드로 자산의 표현물을 담고 있으므로, 한 자산의 모든 표현을 같은 곳에 두는 것이 합리적이라고 설명합니다.

메타데이터를 고칠 수 없는 기존 프로젝트의 대응

메타데이터 응답(스키마)을 수정할 수 없는 기존 프로젝트는, tokenId를 기준으로 갱신된 메타데이터 스키마를 반환하는 새 스마트 컨트랙트를 만들 수 있습니다. 다만 각 서비스가 이렇게 연결된 컨트랙트를 유효한 것으로 받아들여야 tokenURI 함수로 메타데이터를 가져올 수 있습니다.

쓸 때 주의할 점

ERC 원문 · ← ERCs