ERC-5375 NFT 저자 정보와 동의 표준 (NFT Author Information and Consent)

Final · NFT·멀티토큰 · 2022-07-30 작성

NFT 메타데이터에 작가 주소 목록과 '작가로 표기되는 데 동의한다'는 서명 증명을 담는 JSON 형식을 정합니다. 민팅한 사람과 실제 작가가 달라도 작가 정보를 표준 방식으로 제공할 수 있게 합니다.

왜 필요한가

지금까지 NFT의 작가가 누구인지 알려 주는 표준이 없었습니다. 흔히 민팅(발행) 트랜잭션을 보낸 주소를 작가로 간주하지만 이는 민팅한 사람과 작가가 같다고 가정하는 방식이라 컨트랙트가 민팅한 경우, 레이지 민팅, 기술에 익숙하지 않은 작가를 대신해 중개인이 민팅한 경우에는 맞지 않고 여러 작가도 표현하지 못합니다. 첫 Transfer 이벤트를 보거나 컨트랙트마다 다른 자체 필드를 쓰는 방법도 있지만 이 경우 컨트랙트나 민팅자가 본인 동의 없이 다른 사람을 작가라고 주장할 수 있고 NFT 플랫폼이 컨트랙트마다 따로 지원해야 하는 문제가 있습니다. 이 표준은 민팅자가 작가 정보를 제공하되, 작가 본인의 서명 동의 없이는 작가로 표기할 수 없게 막는 공통 형식을 정의합니다.

구현해야 하는 것

심층 설명

authorInfo 필드와 스키마

EIP-721 메타데이터 확장을 지원하는 컨트랙트는 tokenURI(uint256 _tokenId)가 가리키는 JSON에, EIP-1155는 uri(uint256 _id)가 가리키는 JSON에 최상위 필드 authorInfo를 반드시 포함해야 합니다. authorInfo는 authors 배열(필수, 빈 배열 가능)과 consentInfo 객체(chainId, id, contractAddress)로 구성됩니다. 각 작가 항목(ERC5375AuthorSchema)은 address가 필수이고 consent는 선택입니다. consent가 있으면 consentInfo도 반드시 있어야 합니다. consent(ERC5375AuthorConsentSchema)는 consentData(version, issuer, metadataFields 필수), publicKey, signature를 모두 요구합니다. 모든 주소는 EIP-55 체크섬 표기를 따라야 합니다.

EIP-712 동의 메시지와 metadata 인코딩 규칙

동의는 struct Author { address subject; uint256 tokenId; string metadata; } 형태의 EIP-712 메시지에 서명해 표현합니다. metadata는 metadataFields에 나열된 최상위 필드들의 JSON 인코딩이며 나열된 필드와 정확히 같은 필드를 같은 순서로 담아야 합니다. 비ASCII 문자는 모두 이스케이프하되 16진수 알파벳은 대문자로 써야 하며 필드 이름이나 값에 속하지 않는 공백을 넣으면 안 됩니다. metadataFields의 키는 전체 필드의 부분집합(빈 집합 포함)일 수 있습니다. 도메인 구분자는 name, version, chainId로 구성되고 consentData와 메시지 구조는 다른 EIP가 정의한 추가 필드를 지원할 수 있습니다.

검증 절차와 해석의 한계

검증은 작가별로 EIP-712로 수행합니다. JSON 문서에 ERC5375AuthorInfoSchema에 맞는 authorInfo가 있고 consent가 ERC5375AuthorConsentSchema에 맞고 tokenURI 또는 uri가 가리키는 문서에 metadataFields의 모든 최상위 필드가 같은 값으로 존재하며 signature의 EIP-712 서명이 유효하면 동의 증명이 유효합니다. 검증자는 주소 X의 유효한 동의 증명이 있어도 X가 실제 작가라고 가정해서는 안 됩니다. 반대로 X의 유효한 동의 증명이 없으면 X는 작가가 아니라고 가정할 수 있습니다.

왜 완전한 저자 증명이 아니라 동의 증명인가

'X가 Y의 유일한 원작자인가'를 판별하는 프로토콜이 있다고 가정해도, 공격자가 이미지 픽셀 몇 개를 바꾸거나 단어를 동의어로 바꿔 약간 변형한 Y'를 만들면 Y'의 작가라고 정당하게 주장할 수 있습니다. 이를 막으려면 두 NFT가 의미상 같은지에 대한 일반적 형식 정의가 필요한데, 이는 이 EIP의 범위를 벗어납니다. 이 문제는 민팅자 주소를 작가로 간주하는 기존 방식에도 똑같이 존재합니다. 그래서 이 표준은 '이 주소가 작가로 표기되는 데 동의했다'는 사실만 증명합니다.

왜 오프체인 저장인가

오프체인 방식은 기존 스마트 컨트랙트를 수정할 필요가 없고 온체인 저장보다 훨씬 저렴해 도입 장벽이 낮습니다. 또 작가 동의 정보는 주로 사용자가 NFT의 주관적 가치를 판단하는 데 쓰이므로 온체인 활용처가 제한적입니다. consentInfo의 chainId, id, contractAddress는 문맥에서 유도할 수도 있지만 JSON 문서만으로 동의를 검증할 수 있도록 포함을 요구합니다. 철회 시스템은 두지 않았는데, 저자성은 보통 최종적이고 철회 시스템은 구현 부담과 검증 복잡도를 높이기 때문입니다. 컨트랙트가 다른 EIP의 철회 시스템을 구현하는 것은 가능합니다.

작가의 기술 장벽 완화

작가는 EVM 지갑을 만들고 EIP-712 메시지를 읽고 서명하는 법만 알면 됩니다. 체인의 기본 토큰을 구하거나, 트랜잭션에 서명하거나, 수수료 책정 방식을 이해하거나, 트랜잭션이 블록에 포함됐는지 확인할 필요가 없습니다. 덕분에 작가가 키를 중개인에게 넘기지 않고도 민팅의 기술적 부분을 민팅자에게 맡길 수 있습니다. 다만 이 표준은 어떤 주소가 동의했는지만 검증하며 그 주소가 기대한 작가 본인(예: 이름으로 알려진 인물)과 연결되는지는 보장하지 않습니다.

리플레이 공격과 이름 필드 삭제

체인 id, 컨트랙트 주소, 토큰 id가 NFT를 고유하게 식별하므로 논스 같은 추가 리플레이 방지 장치는 필요 없습니다. 초기 설계에는 검증 없는 사람이 읽을 수 있는 작가 이름 필드가 있었지만 다른 사람 이름을 도용해 민팅하는 스푸핑 위험이 커서 삭제됐습니다. 복잡한 작가 정보는 NFT가 아니라 작가의 주소에 연결해 증명하는 방식이 가장 안전하다고 봅니다. 비ASCII 문자를 이스케이프하는 이유는 스마트 컨트랙트에서 비ASCII 문자열 처리가 매우 복잡해 온체인 검증 가능성을 열어 두기 위해서입니다.

쓸 때 주의할 점

ERC 원문 · ← ERCs