다이나믹 NFT 2 (EIP/ERC)
다이나믹NFT를 설명하기 위한 EIP/ERC 설명
지난 시간에 다이나믹 NFT 1에서 다이나믹 NFT를 설명하기 위해 오라클에 대해 살짝 다뤄봤다
오늘을 이에 이어서 dNFT를 설명하기 위한 EIP 와 ERC를 가볍게 다뤄보려고한다.
아니 dNFT 설명하기 위해서 미리 알아야 할게 뭐 이리 많나 싶겠지만
dNFT를 설명하기 위해서는 NFT도 알아야 하고
NFT를 알기 위해서느 ERC를 알아야 하고 ERC를 알기 위해서는
EIP라는 것도 알아야 하고 어쩔수 없다…
일단 ERC, EIP를 왜 설명하고자 하는지 이야기 하기 위해
NFT를 진짜 찐짜 살짝만 언급해서 알아보자면
NFT(Non Fungible Token)
대체불가능한 토큰이고 흔히들 ‘느프트’ 라고 부르기도 한다.
우리나라의 대표적인 K- NFT에는 메타콩즈가 있다.
NFT가 일반 코인(토큰)이랑 다른이유는
ECR20가 아닌 주로 ERC-721를 기반으로 유통되고 있으며 혹은 ERC-1155를 기반으로 만들어진게 NFT 이기 때문이다
그럼 여기서 또 ERC가-721이 뭔지 ERC-1155가 뭔지 ERC20가 뭔지 ERC에 대해 설명을 해야하는데…
이것 때문에 NFT를 설명하기 전에 ERC를 설명하고자 한것이다
이제 ERC를 알기 위해선 EIP를 알아야한다.
이 크립토판이 뭐하나 설명하자면 늘 이런식이다. 설명에 설명이 꼬리를 문다.
1. EIP (Ethereum Improvement Proposals)
위에서 언급한 것처럼ERC를 알기 위해서는 EIP를 먼저 알아보아야 한다. EIP는 이더리움 개선하기 위한 제안을 의미한다.
EIP는 3가지 EIP Type (Standart Track EIP / Informational EIP / Meta EIP)으로 구성되어 있다.
EIP를 제안할때는 따라야하는 규칙이 존재하고
이러한 규칙들을 준수하면서 EIP를 건의 할수 있다.
개선안의 프로세스는 아래과 같은데 참고만 하고
지켜야 하는 양식들도 다음과 같은데… 이것 또한 참고만 하자…
2. ERC : Ethereum Request (for) Comments
ERC : Ethereum Request (for) Comments
새로운 기능을 개발하기위해 개발자들이 따라야하는 규칙 또는 추천사항을 정의한 것이 EIP이다. 그리고 그 제안한 EIP 내용이 통과가 되었을 때 개발자들이 따라야 하는 약속이 ERC라고 생각하면 된다.
그리고 EIP는 여러가지 기능을 제공하는 것이기 때문에 이더리움 주요 기능에 대해 광범위 하게 다루지만 ,
ERC는 Application layer(dApp)에만 직접적으로 연관이 있다고 보면 될 것 같다.
그래서 결론적으로 단순히 블록체인을 응용한 dApp만 신경쓴다면 ERC라는 파트만 신경쓰면 되며,
개발때 쓰는 코드들은 다 ERC라고 생각하면 된다. 반대로 이더리움이라는 전반적인 생태계에 기여하고 싶다면 EIP라는 좀더 큰 카테고리를 건드리는 것이 맞다고 본다.
EIP를 먼저 다룬 이유는 ERC와 혼동이 있을 수도 있어서 다룬 것이고
정말 간단하게 내가 만든 표로 이해해 보자면
EIP 안에 Standard Track EIP 속에 토큰과 관련 내용들이 있게되면 그리고 EIP 제안이 통과가 되게 되면 ERC 로 자리 잡게 된다.
3. 다양한 ERC들 NFT와 관계
ERC에도 종류가 많지만
현재 가장 많이 채택되고 활용되는 ERC들은 ERC-20, ERC-721 , ERC-1155이 있다.
그중 NFT는 ERC-721 그리고 ERC-1155와 관련되어 있다.
위의 다양한 토큰을 종류들 중에
우리는 NFT를 이해하기 위해 기존 우리가 흔히 거래소에서 사고 파는
코인(토큰)과의 차이를 알아봐야 한다.
ERC20와 NFT(ERC721)의 작동적 코드적 차이
작동적으로는 이런식의 차이가 있고
function mint(address to) { // tokenId가 고유한 값인지 확인
require(!_exists(tokenId), "ERC721: token already minted"); // 고유한 tokenId의 소유자를 저장
_owners[tokenId] = to; // tokenId를 1 증가
tokenId = tokenId + 1;}
민팅 코드를 살펴보면 코드적으로는 정말 간단하다
0번 토큰을 하나만 발행하고 이후에는 1번 2번 3번 새로운 번호들에 대응하는 토큰들을 하나씩만 발행하고
해당 ID토큰의 소유자를 지정하는 방식이다.
이 0번 1번 2번 과 같은 값을 tokenID라고 하며 즉 tokenID가 unique 한 값이며 tokenID별로 소유자가 정해진다.
tokenId가 고유한지 확인하고 고유하다면 해당 tokenId의 소유자를 저장하고 tokenId를 1 증가시키고 있다.
NFT는 결국 고유한 tokenId에 맞게 발행되는 1개의 토큰인 것이다.
이후 10번 토큰에 대한 소유자를 조회한다면 딱 하나의 주소가 나올 것이며(한명) 이 주소가 10번 토큰에 대한 소유자 인 것이다.
여기서 포인트는은 위 코드에 이미지나 특성들이 들어가있지 않다는 점이다.
NFT의 본질은 단순 고유한 tokenId별로 발급되는 1개의 토큰일 뿐이다.
이미지나 특성을 저장하기 위한 토큰이 아니라는 것이다.
이미지가 없이도 NFT를 이용해 그림관련 소유권을 증명 할 수 있는데
만약, 루브르 박물관에서 AAA 컨트랙 주소의 0번 토큰의 소유자가 모나리자의 실제 소유권을 주장 할수 있다라고 발표한다면 굳이, 모나리자 그림을 NFT에 넣지 않아도 모나리자 그림의 소유자를 확인할 수 있는 것이다.
따라서, Opensea에서 흔히 보는 이미지나 특성은 NFT의 본질이 아니다.
다만, 현재 NFT의 표준은 이미지와 특성들을 포함한 메타데이터가 호스팅된 URI를 컨트랙 안에 포함시킬 수 있어 Opensea 같은 마켓 플레이스나 메타마스크 같은 지갑에서 해당 NFT의 이미지나 특성을 불러올 수 있는 것이다.
NFT에 그림을 담는다?
메타데이터?
URI ?
Non Fungible?
이미지를 불러온다?
여전히 새로운것과 어려운 것이 많을 수 있다고 생각한다. 하지만
이제 이것들만 설명하면 dNFT를 설명하기 위한 초석은 다 닦았다 라고 할수 있겠다.
다음편에서 계속 알아보자
*참고 사이트
https://securities.miraeasset.com/bbs/maildownload/2021120314230585_154