이전 포스팅들에서는 이더리움의 EIP중 Standard Track EIP에 해당하는 ERC에 해당하는 세가지 ERC-20, ERC-721, ERC-1155에 대한 기본 개념을 정리해보고, ERC-20 토큰표준 함수들에 대해 살펴보았다.

Chapter 3에서는 이더리움에서 NFT를 발행할 때 사용되는 표준인 ERC-721 토큰표준에서 제공하는 표준함수들에 대해 살펴보도록 하자.

Chapter 3

ERC-721

ERC-721 표준 콘트랙트는 사용자에게 API를 제공하여, 자신만의 대체 불가능한 토큰(NFT)을 주조하고 메타 데이터(이미지, 설명 등)를 표현할 수 있게 한다.

EIP 공식문서에 따르면, ERC-721와 ERC-20는 요구하는 피라미터부터 차이가 있다. ERC-20은 토큰의 개수(amount)를 주로 파라미터로 다룬다면, ERC-721은 토큰의 소유권(토큰ID, 토큰 소유자) 을 주요 파라미터로 다룬다.

예를들어, transfer함수를 비교해보면, ERC-20의 경우 송신주소(from)에서 수신주소(to)로 지정한 수량(amount)만큼의 토큰을 보내게 되지만, ERC-721의 경우 "권한"과 "tokenId"를 송신주소(from)에서 수신주소(to)로 변경하는 처리를 한다.

또한, ERC-721과 ERC-20을 구분하기 위해서는 ERC-165 자체 검사를 수행하여야 한다.

ERC-165 란, 스마트 컨트랙트가 구현하는 인터페이스를 게시하고 있는지 감지하는 표준 방법이다.

이제 ERC-721에서 사용되는 표준함수들에 대해서 좀 더 자세히 알아보도록 하자.

1. ERC-721 표준 Events

해당 Events들은 아래에서 다룰 "ERC-721 표준 Functions"가 호출될 때 함수에서 호출하는 Event이며, 이 Event들을 통해 실제 블록체인에 데이터를 기록한다고 보면 된다.

1-1. event Transfer

event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId)

1-2. event Approval

event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId)

1-3. event ApprovalForAll

event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved)

2. ERC-721 표준 Functions

2-1. balanceOf

파라미터로 넘어온 주소가 보유하고있는 NFT 토큰의 개수를 조회해주는 함수이다. _owner가 스타유닛 "드론", 스타유닛 "저글링", 스타유닛 "히드라"를 보유하고 있을 때, owner.balanceOf는 3을 리턴한다. 참고로, 각각의 스타유닛은 대체 불가능한 토큰(NFT)이기 때문에 "드론" 2마리, "저글링" 5마리 이런식으로 보유할 수 없다.

function balanceOf(address _owner) external view virtual override returns (uint256) {
    require(_owner != address(0), "ERC721: balance query for the zero address");
    return _balances[_owner];
}

2-2. ownerOf

파라미터로 넘어온 token id에 해당하는 토큰을 소유하고 있는 주소를 반환한다. 이 함수를 호출할 때 NFT 토큰의 ID를 변수로 넘겨준다. ownerOf 함수는 token의 id를 파라미터로 받고, 토큰을 소유하고 있는 address를 리턴한다. 예를들어, 스타유닛 "드론"의 token id와 함께 함수를 호출하면 "드론"을 보유하는 address "0x...." 이런식으로 값을 리턴한다. 스타유닛 "드론"은 유일하기 때문에, "드론"을 보유하고 있는 address는 오직 하나밖에 없다.

function ownerOf(uint256 _tokenId) external view virtual override returns (address) {
    address owner = _owners[_tokenId];
    require(owner != address(0), "ERC721: owner query for nonexistent token");
    return owner;
}

2-3. transferFrom

NFT토큰 소유자를 _from에서 _to로 변경한다.

function transferFrom(address _from, address _to, uint256 _tokenId) external payable {
    address addr_owner = ownerOf(_tokenId);

    // 인자로 받는 _from이 토큰의 소유 계정과 일치하지 않으면 예외 발생.
    require(addr_owner == _from, "_from is NOT the owner of the token");
    // 인자로 받는 _to가 0(null)이라면 예외 발생.
    require(_to != address(0), "Transfer _to address 0x0");

    // 해당 토큰의 allowance address 여부 저장
    address addr_allowed = allowance[_tokenId];
    // 토큰의 본 소유계정이 메소드를 호출한 사람에게 소유권을 이전할 수 있도록 승인을 했는지 여부 저장
    bool isOp = operators[addr_owner][msg.sender];

    //msg.sender가 토큰의 소유계정이거나, 토큰의 allowance에 있는 계정이거나, 중개인 계정 true인 경우가 아니라면(세개 모두다 해당 안된다면) 예외 발생.
    require(addr_owner == msg.sender || addr_allowed == msg.sender || isOp, "msg.sender does not transferable token");

    // transfer : change the owner of the token
    // 토큰의 주인을 _to 계정으로 변경
    tokenOwners[_tokenId] = _to
    // safematch를 사용해서 balance 감소
    balances[_from] = balances[_from].sub(1);
    // safematch를 사용해서 balance 증가
    balances[_to] = balances[_to].add(1);

    // reset approved address
    // ERC-721 표준에 의하면, 이전의 allowance를 갖고있던 계정을 리셋해줘야 한다.
    if (allowance[_tokenId] != address(0)) {
        // null로..
        delete allowance[_tokenId];
    }

    // 이벤트 발생
    emit Transfer(_from, _to, _tokenId);
}

2-4. safeTransferFrom

기능상으로는 transferFrom 함수와 동일하지만, 매개변수로 넘어온 _to 주소가 contract계정인지 체크하는 로직이 추가된다.

두 종류의 safeTransferFrom 함수가 존재한다. 하나는 bytes타입의 인자를 더 받는다.

function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;

function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes _data) external payable {
    transferFrom(_from, _to, _tokenId);

    // check if _to is ContractAddress

    // 토큰을 수신하는 계정(주소)가 Contract라면
    if (_to.isContract()) {
        bytes4 result = ERC721TokenReceiver(_to).onERC721Received(msg.sender, _from, _tokenId, _data);

        // erc165 selector 구하여 일치하지 않으면 예외 발생
        require(
            result == bytes4(keccak256("onERC721Received(address, address, uint256, bytes)")), "receipt of token is NOT completed"
        )
    }

}

후자의 경우, 실제 유저의 주소(EOA)가 아닌 SmartContract 주소에 보낼 때 사용한다. 해당 스마트컨트랙트가 ERC-721토큰을 받을 수 있는 컨트랙트인지 확인을 하는 것이다. 그래서 transferFrom을 사용할 때, 실제 유저의 주소로 보내는 것은 상관없지만, 스마트컨트랙트 주소에 ERC-721토큰을 보낼 때, 그 스마트컨트랙트가 ERC-721토큰을 받을 수 없는 컨트랙트라면 전송한 토큰이 소실될 수 있음을 유의해야한다.

2-5. approve

ERC-721의 approve함수는 ERC-20의 approve 함수와 동일하다.

ERC-20은 토큰을 전송하는 것 뿐만 아니라, 승인받은 제 3자가 토큰을 전송하는 기능에 대한 표준을 제공한다. 토큰을 대신 전송하는 사람을 "operator"라고 하며, 토큰을 보유하고 있는 사람이 tokenId와 operator의 address를 입력하면 operator에게 해당 토큰에 대한 거래를 허용하게 되는 것이다.

function approve(address _to, uint256 _tokenId) external virtual override {
    address owner = ERC721.ownerOf(_tokenId);
    require(_to != owner, "ERC721: approval to current owner");
    require(_msgSender() == owner || isApprovedForAll(owner, _msgSender()), "ERC721: approve caller is not owner nor approved for all");

    _approve(_to, _tokenId);
}

2-6. getApproved

파라미터로 tokenId를 넘겨주면, 그 토큰에 해당하는 operator를 반환해준다.

function getApproved(uint256 _tokenId) external view virtual override returns (address) {
    require(_exists(_tokenId), "ERC721: approved query for nonexistent token");

    return _tokenApprovals[_tokenId];
}

2-7. setApprovalForAll

위의 approve함수를 한꺼번에 처리해주는 함수라고 생각하면 된다. setApprovalForAll 함수는 NFT토큰 소유자가 함수호출시 파라미터로 넘겨주는 주소에게 본인의 모든 NFT토큰에 대한 전송 권한을 부여 또는 해제하는 함수이다. 즉, setApprovalForAll을 호출한 NFT토큰 owner는 자신이 보유한 모든 NFT토큰에 대해 operator에게 전송권한을 부여한다. _approved 변수에 true를 입력하면 모든 토큰에 대한 전송권한을 갖도록, false를 입력하면 모든 토큰에 대한 전송권한을 취소하도록 한다.

function setApprovalForAll(address _operator, bool _approved) external virtual override {
    require(_operator != _msgSender(), "ERC721: approve to caller");

    _operatorApprovals[_msgSender()][_operator] = _approved;

    // 이벤트 호출
    emit ApprovalForAll(_msgSender(), _operator, _approved);
}

2-8. isApprovedForAll

isApprovedForAll함수는 setApprovalForAll의 권한이 있는지 bool의 형태로 리턴해주는 함수이다. 함수 호출시 파라미터로는 토큰 owner의 address와, operator의 address를 입력한다.

function isApprovedForAll(address owner, address operator) external view virtual override returns (bool) {
    return _operatorApprovals[owner][operator]
}

3. 메타데이터 관리 함수

3-1. name

function name() external view returns (string _name);

3-2. symbol

function symbol() external view returns (string _symbol);

3-3. tokenURI

function tokenURI(uint256 _tokenId) external view returns (string);

4. Wallet Interface

ERC-721 토큰을 받으려는 스마트컨트랙트의 주소는 아래의 인터페이스들을 필수적으로 구현해야한다. 다시말해서 지갑, 옥션, 중매 관련 앱은 반드시 아래의 인터페이스들을 갖고있어야만 한다.

/// @dev Note: the ERC-165 identifier for this interface is 0x150b7a02.
interface ERC721TokenReceiver {
    /**
     * @notice NFT 수신 처리
     * @dev ERC721 스마트 컨트랙트는 `safeTransfer` 후 수신자가 구현한
     * 이 함수를 호출합니다. 이 함수는 반드시 함수 선택자를 반환해야 하며,
     * 그렇지 않을 경우 호출자는 트랜잭션을 번복할 것입니다. 반환될 선택자는
     * `this.onERC721Received.selector`로 얻을 수 있습니다. 이 함수는
     * 전송을 번복하거나 거절하기 위해 예외를 발생시킬 수도 있습니다.
     * 참고: ERC721 컨트랙트 주소는 항상 메시지 발신자입니다.
     * @param _operator `safeTransferFrom` 함수를 호출한 주소
     * @param _from 이전에 토큰을 소유한 주소
     * @param _tokenId 전송하고자 하는 NFT 식별자
     * @param _data 특별한 형식이 없는 추가적인 데이터
     * @return bytes4 `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`
     */
    function onERC721Received(address _operator, address _from, uint256 _tokenId, bytes _data) external returns(bytes4);
}

5.Metadata Extention

메타데이터(NFT에 대한 정보)를 관리할 때에는 아래의 인터페이스를 사용한다.

/// @title ERC-721 Non-Fungible Token Standard, optional metadata extension
/// @dev See https://eips.ethereum.org/EIPS/eip-721
///  Note: the ERC-165 identifier for this interface is 0x5b5e139f.
interface ERC721Metadata /* is ERC721 */ {
    /// @notice A descriptive name for a collection of NFTs in this contract
    function name() external view returns (string _name);

    /// @notice An abbreviated name for NFTs in this contract
    function symbol() external view returns (string _symbol);

    /// @notice A distinct Uniform Resource Identifier (URI) for a given asset.
    /// @dev Throws if `_tokenId` is not a valid NFT. URIs are defined in RFC
    ///  3986. The URI may point to a JSON file that conforms to the "ERC721
    ///  Metadata JSON Schema".
    function tokenURI(uint256 _tokenId) external view returns (string);
}

아래는 ERC-721 Metadata Sample JSON Schema 이다.

{
    "title": "Asset Metadata",
    "type": "object",
    "properties": {
        "name": {
            "type": "string",
            "description": "Identifies the asset to which this NFT represents"
        },
        "description": {
            "type": "string",
            "description": "Describes the asset to which this NFT represents"
        },
        "image": {
            "type": "string",
            "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive."
        }
    }
}

6. Enumeration Extension (선택사항)

모든 NFT 리스트를 퍼블리시 하거나 탐색할 수 있게 해준다.

/// @title ERC-721 Non-Fungible Token Standard, optional enumeration extension
/// @dev See https://eips.ethereum.org/EIPS/eip-721
///  Note: the ERC-165 identifier for this interface is 0x780e9d63.
interface ERC721Enumerable /* is ERC721 */ {
    /// @notice Count NFTs tracked by this contract
    /// @return A count of valid NFTs tracked by this contract, where each one of
    ///  them has an assigned and queryable owner not equal to the zero address
    function totalSupply() external view returns (uint256);

    /// @notice Enumerate valid NFTs
    /// @dev Throws if `_index` >= `totalSupply()`.
    /// @param _index A counter less than `totalSupply()`
    /// @return The token identifier for the `_index`th NFT,
    ///  (sort order not specified)
    function tokenByIndex(uint256 _index) external view returns (uint256);

    /// @notice Enumerate NFTs assigned to an owner
    /// @dev Throws if `_index` >= `balanceOf(_owner)` or if
    ///  `_owner` is the zero address, representing invalid NFTs.
    /// @param _owner An address where we are interested in NFTs owned by them
    /// @param _index A counter less than `balanceOf(_owner)`
    /// @return The token identifier for the `_index`th NFT assigned to `_owner`,
    ///   (sort order not specified)
    function tokenOfOwnerByIndex(address _owner, uint256 _index) external view returns (uint256);
}

참고링크 https://ethereum.org/ko/developers/docs/standards/tokens/erc-721/ https://earthteacher.tistory.com/94

이전 포스팅에서는 이더리움의 EIP중 Standard Track EIP에 해당하는 ERC에 해당하는 세가지 ERC-20, ERC-721, ERC-1155에 대한 기본 개념을 정리해보는 시간을 가졌다. 해당 내용을 잘 알지 못하거나, 확인하고 싶은 사람은 아래 링크를 참조하면 된다. https://velog.io/@hoo_park95/ERC-%ED%86%A0%ED%81%B0-%ED%91%9C%EC%A4%80-%EC%A0%95%EB%A6%AC

Chapter 2를 포함한 이후 Chapter에서는 ERC-20, ERC-721, ERC-1155 세가지 토큰 표준별로 제공해주는 표준함수들에 대해 자세히 살펴보는 시간을 가져보려한다.

우선 Chapter 2에서는 ERC-20 토큰표준에서 제공하는 표준함수들에 대해 살펴보도록 하자.

Chapter 2

ERC-20

ERC-20 토큰표준을 통해 토큰이 생성되면, 이는 ERC-20 표준을 지원하는 서비스 및 소프트웨어(소프트웨어 지갑, 하드웨어 지갑, 거래소 등)와 자동으로 호환된다.

한가지 중요한 개념이 있다. 이더리움 자체 암호화폐(코인)인 이더(ETH)와 달리, ERC-20기반 토큰은 계정에 보관되지 않는다. 토큰은 실제로는 Contract내부에만 존재하며, 이는 독립적인 데이터베이스와 같다. 이름, 심볼, 가분성과 같은 "토큰 규칙"들을 구체적으로 명시하여 사용자 계정에 상응하는 목록을 이더리움 주소에 보관하는 방식이다.

만약 사용자가 본인 소유의 토큰을 이동하고 싶다면, 자신의 잔고 일부를 다른 곳으로 전달해달라는 요청을 하는 트랜잭션을 Contract에 전송해야만 한다. 예를들어 P라는 사람이 XX토큰 500개를 YH라는 사람에게 전송하고자 하는 경우, XX토큰 내부의 SmartContract에 구현되어있는 함수를 호출해서 이를 요청한다.

간단한 설명은 마치고 ERC-20의 Contract 내부 구조를 살펴보도록 하자.

ERC-20 토큰표준을 준수하기 위해서는 Contract에 다음의 "6가지" 함수가 "필수적으로" 포함되어야 한다.

• 전체 공급량 (totalSupply)
• 잔고 (balanceOf)
• 전송 (transfer)
• ~에서 전송 (transferFrom)
• 승인 (approve)
• 허용 (allowance) 또한,
• 이름 (name)
• 심볼 (symbol)
• 소수점 (decimal) 과 같은 부가적인 함수들을 설정할 수도 있다.

1. ERC-20 표준 Events

해당 Events들은 아래에서 다룰 "ERC-20 표준 Functions"가 호출될 때 함수에서 호출하는 Event이며, 이 Event들을 통해 실제 블록체인에 데이터를 기록한다고 보면 된다.

1-1. event Transfer

event Transfer(address indexed _from, address indexed _to, uint256 _value)

1-2. event Approval

event Approval(address indexed _owner, address indexed _spender, uint256 _value)

2. ERC-20 표준 Functions

2-1. totalSupply

사용자가 이 함수를 호출하면, 해당 함수는 Contract가 보유하고있는 토큰의 "전체 공급량"을 전달한다. 함수 호출시 입력 파라미터는 존재하지 않는다.

function totalSupply() public view returns (uint256)

2-2. balanceOf

totalSupply와 달리 balanceOf는 입력 파라미터로 주소를 받는다. 이 함수가 호출되면, 파라미터로 넘어온 주소가 보유하고 있는 토큰의 잔고가 출력된다. 이더리움 네트워크의 계정은 공개적이기 때문에 주소만 알고있다면 모든 사용자의 토큰잔고를 요청할 수 있다는 점을 알아야한다.

function balanceOf(address _owner) public view returns (uint256 balance)

2-3. transfer

transfer는 다른 사용자에게 토큰을 전송하는 기능을 제공하는 함수이다. 함수 호출시에는 함수를 호출하는 사람이 전송하고자 하는 "목적지 주소"와 "금액"을 파라미터로 넘겨주어야 한다. 다시말하면, 이 함수는 토큰을 전송할 사용자가 호출해야만 한다. 함수가 호출되면 transfer는 이벤트(event transfer)를 호출하며, 이 이벤트 호출을 통해 블록체인에 데이터를 기록한다.

function transfer(address _to, uint256 _value) public returns (bool success)

2-4. transferFrom

transferFrom 함수는 transfer을 좀 더 구체화 한 것으로, 이 함수를 통해 Dapp에서 좀 더 활용도 높게 사용이 가능하다. 이는 transfer와 마찬가지로 토큰을 전송하지만, 전송되는 토큰이 반드시 Contract를 호출하는 사람의 소유일 필요는 없다. 즉, 다른 누군가 또는 다른 Contract에서 나를 대신하여 내 자금을 전송하도록 허락할 수 있다. 예를들어, 매일/매주/매월 수동으로 결제해야 하는 구독형 서비스 결제에서 이 함수를 사용할 수 있다. 프로그래밍을 통해서 이 함수를 자동으로 호출한다면, 구독형 서비스 자동결제 시스템에 활용이 가능할 것이다.

해당 함수는 transfer함수와 동일한 이벤트(event transfer)를 호출한다.

function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)

2-5. approve

approve라는 함수를 통해, SmartContract가 내 잔고에서 인출할 수 있는 토큰 수량을 제한할 수 있다. 이 함수가 없다면 함수 오작동(또는 부정한 이용)과 자금 탈취의 위험이 있다.

예를들어, 내가 구독형 서비스 자동결제 시스템을 사용하고 있다고 생각해보자. 나는 매달 자동결제 되는 토큰수량보다 훨씬 더 많은 양을 가지고 있는데, 어떠한 오작동(또는 부정한 이용)으로 인해 자동결제 되어야 하는 토큰수량보다 훨씬 더 많은 토큰이 빠져나갈 수도 있을 것이다. 이러한 경우를 방지하기 위해서 나의 approve한도를 OO개의 토큰으로 제한할 수 있고 이러한 경우를 위해 제공되는 함수가 approve이다. 최악의 경우에 Dapp이 악의를 품고 나의 자금을 모두 출금하려 하거나, 해킹 시도가 들어온다고 하더라도 내가 approve를 통해 한도를 걸어놓은 자금까지만 잃게 될것이다.

approve함수는 호출되면 approve 이벤트를 호출한다. transfer 이벤트처럼, 이 이벤트를 통해 블록체인에 데이터를 기록하게 된다.

function approve(address _spender, uint256 _value) public returns (bool success)

2-6. allowance

allowance는 approve와 함께 사용할 수 있다. 내가 특정 Contract에 "토큰관리기능"을 부여했다면, 이 allowance함수를 통해 얼마나 많은 토큰을 인출할 수 있는지 확인하는데 사용할 수 있다. 예를들어, 내가 approve를 통해 토큰수량을 10개로 제한했고, 그 중 3개를 사용했다면, 이 경우 allowance함수를 호출할 경우 7개의 토큰을 사용할 수 있다는 메세지가 출력될 것이다.

function allowance(address _owner, address _spender) public view returns (uint256 remaining)

2-7. name, symbol, decimal

이 세가지 function들은 ERC-20 토큰표준을 사용하기 위한 필수 함수들은 아니다. 하지만 이를 추가할 경우에 사람이 읽을 수 있는 이름을 추가할 수 있고, 심볼(예를들면, ETH, BTC, SOL, ..)을 설정할 수 있고, 소수점 몇 자리까지 토큰이 분할될 수 있는지를 지정할 수 있다. 예를들어 FT토큰들(통화로 사용되는 토큰들)은 NFT토큰들(토큰의 소유권을 나타내는 토큰) 보다 더 많이 분할되도록 설정하는게 좋을 것이고, 그런경우에 해당 함수를 추가하여 사용하면 된다.

function name() public view returns (string)
function symbol() public view returns (string)
function decimals() public view returns (uint8)

마무리하며

위의 모든 기능들을 모아두면 ERC-20 표준을 준수하는 Contract, 즉 ERC-20 Contract가 된다. 우리는 해당 Contract를 통해 전체 공급량 요청, 잔고 확인, 자금 전송, 토큰 관리를 위한 다른 Dapp에 권한 부여 등 을 수행할 수 있다.

추가적으로, ERC-20 토큰의 가장 큰 장점은 유연성이다. ERC-20 표준의 경우 개발을 제한하지 않으며, 이러한 특성덕에 당사자들은 자신에게 적합한 부가적인 기능을 추가하고, 특정 변수들을 설정하는 등 본인이 만들고자 하는 토큰에 맞게 활용할 수 있다.

다음 챕터에서는 ERC-721 표준토큰이 제공하는 함수들에 대해 살펴보도록 할 것이다.

참고 : https://ethereum.org/ko/developers/docs/standards/tokens/erc-20/

이번 포스팅에서는 블록체인상에서 다루는 용어인 "코인"과 "토큰"에 대해 알아보는 시간을 갖도록 해보자.

코인 vs 토큰

코인

• 전용 블록체인 네트워크에서 사용하는 모든 암호화폐를 코인이라고 부름
• 이더리움에도 BTC와 같은 방식으로 사용할 수 있는 자체 '코인' ETH가 있음
  • 그러나 이더리움의 주요 사용 사례는 네트워크에 구축된 앱과 프로토콜의 트랜잭션과 운영에 동력을 공급하는 가스 역할을 수행하는 것임

토큰

• 이더리움 네트워크에 구축된 앱의 개발자는 전용블록체인이 없는 인앱 통화를 만들 수 있음
  • 이러한 인앱 통화는 이더리움 자체에 저장됨
  • 이와 더불어, 이더리움은 사용자가 이더리움 자체에 위변조 불가능한 방식으로 저장할 수 있는 다양한 형태의 독립형 디지털 자산을 생성하도록 해줌
• 이렇듯, 이더리움에서 생성되고 저장되는 "인앱 통화"나 "디지털 자산"을 일컬어 토큰이라고 부름

요약

전용 블록체인을 갖고있는 암호화 자산은 코인이다. 반대로 전용블록체인이 없어서 타사 블록체인에서 생성된 기타 모든 자산은 토큰이다.

이번 포스팅에서는 이더리움의 EIP중 Standard Track EIP에 해당하는 ERC에 해당하는 세가지 ERC-20, ERC-721, ERC-1155에 대해 정리해보는 시간을 갖도록 한다. Chapter 1 에서는 EIP와 ERC용어에 대한 간단한 정리를 해보도록 하고, Chapter 2 에서는 ERC-20과 ERC-721, 그리고 ERC-1155 토큰 표준에 대해 자세히 살펴보는 시간을 갖도록 한다. 이때 각 토큰 표준별로 제공해주는 표준함수들에 대해 자세히 살펴보는 시간을 가져보자.

Chapter 1

1. EIP

먼저 EIP에 대해 간단하게 이야기 해보자. EIP는 Ethereum Improvement Proposals의 약자로, 이더리움의 품질 개선 제안을 의미한다. ERC는 표준이 되기전에 EIP를 통해 커뮤니티에서 수정, 주석처리 및 승인이 되어야 한다. 즉 실제로 ERC는 EIP의 특정 유형이라고 볼 수 있다.

EIP는 Standard Track EIP, Informational EIP, Meta EIP 3가지 종류로 구분되어지는데, ERC는 이중 Standard Track EIP에 해당된다. 즉, ERC-20, ERC-721, ERC-1155는 Standard Track EIP에 있는 ERC범주에 속해 있는 제안이라고 볼 수 있다.

Informational EIP는 이더리움 디자인 문제에 대해 설명하거나, 일반적인 지침 또는 이더리움 커뮤니티에 정보를 제공하지만, 새로운 기능을 제안하지는 않는다. Informational EIP는 반드시 이더리움 커뮤니티 컨센서스 또는 권고를 나타내는 것은 아니므로 사용자 및 구현자는 Informational EIP를 무시하거나 따르거나 선택할 수 있다. (강제성X, 정보제공성O)

Meta EIP는 이더리움을 둘러싸는 프로세스를 설명하거나 변경하는 방법을 제안한다. 프로세스 EIP는 Standard Track EIP와 유사하지만, 이더리움 프로토콜 자체 이외의 영역에도 적용된다.

2. ERC

크게 ERC-20, ERC-721, ERC-1155에 대한 개념들을 간단하게 정리해보자 세부적으로 살펴보기에 앞서 간단하게 말하면, ERC-20, ERC-721, ERC-1155 들은 이더리움 블록체인 네트워크에서 발행되는 토큰들의 "토큰표준"이라 칭하고, 이 토큰표준들을 기준으로 "토큰"들이 생성된다.

• ERC-OO의 의미
  • ERC는 Ethereum Request for Comments를 의미하고, OO는 이 요청에 부여된 번호 이다.

    2-1. ERC-20

• 이더리움 "대체 가능 토큰"의 표준 (Fungible Token)
• ERC-20은 가장 보편화된 토큰 표준
• ERC-20은 Dapp이 발행하는 토큰을 이더리움의 통화인 이더와의 호환성을 충족시키기게 하기 위해서 규정하고 있는 프로그래밍 기준들이다
  • 따라서 ERC-20에 기준을 맞춰 Dapp을 설계한 후, 토큰을 발행하면 해당 토큰들을 이더와 쉽게 교환할 수 있고, My Ether Wallet에도 자유롭게 전송할 수 있게 된다.
• ERC-20 기반으로 생성된 토큰들은 상호 호환성이 가능하기 때문에, ERC-20 기반 토큰들은 동일한 이더리움 지갑으로 전송이 가능하다

2-2. ERC-721

• 이더리움 "대체 불가능 토큰"의 표준 (Non-Fungible Token)
  • 각 토큰은 고유의 가치를 가짐. ERC-20기반 토큰처럼 서로 교환하는 것이 불가능
• 기존 ERC-20토큰과 ERC-72Q 토큰에는 많은 중복된 불필요한 데이터가 쌓이고 블록체인의 변경할 수 없는 속성으로 인해 불필요한 코드가 영원히 남게되어 대규모의 저장공간과 처리 용량, 전력을 소모하게 되는 문제를 안고 있어서 이에 대한 대안으로 제시된 토큰표준
• ERC-20토큰들과 ERC-721토큰들은 이더리움 기반 토큰이라는 점이 동일
• ERC-20토큰들과의 차이점은 "대체가능성(Fungibility)"
  • "대체가능성"이란, 어떤 자산이 누구에게나 동등한 가치를 지니고 있는것을 의미하는데, ERC-721토큰은 대체가능성을 갖고있지 않음

2-3. ERC-1155

• ERC-1155는 단일 컨트랙트를 통해 대체 가능한 ERC-20이나 대체 불가능한 ERC-721을 무한히 발행할 수 있다
• 복잡한 게임 아이템 시스템에 쓰일 수 있다
• 아래와 같은 문제를 해결하기 위해 ERC-1155 토큰표준이 수립됨.
  • ERC-20 및 ERC-721 표준의 문제점은 하나의 스마트 컨트랙트가 단일 유형의 대체가능 또는 대체불가능 토큰만을 지원하도록 허용한다는 점이다. 따라서 이런 경우 새로운 토큰을 배포하려면 항상 새로운 스마트 컨트랙트를 작성해야 한다. 또한 ERC-20, ERC-721 표준은 "부분 대체 가능 토큰"을 생성하는 방법을 제시하지 않는다.
• 즉, ERC-1155는 이더리움 개발자가 동일한 표준을 사용하여 쉽게 "대체가능", "부분대체가능", "대체불가능" 토큰을 생성하도록 해주는 표준이다
• 예를들어, 개발자가 NFT게임을 개발하고자 하는 상황을 상상해보자.
  • 개발자는 하나의 FT토큰을 만들어 게임 내에서 통화로 사용하기로 한다.
  • 그리고 스킨, 총기, 상품 등과 같은 고유한 게임 내 자산에 대해서는 대체 불가능 토큰(NFT)을 여러가지 만든다.
  • 이러한 경우, ERC-20 및 ERC-721 표준을 사용하는 경우, 새로운 자산 유형을 생성할 때 마다 새로운 스마트 컨트랙트를 작성해야만 자산을 지원할 수 있다. 그러나 ERC-1155 토큰표준을 사용한다면 단 하나의 스마트컨트랙트만 작성해도 게임 내 모든 종류의 토큰을 지원할 수 있다.