KIP7 구조

npm으로 클레이튼 패키지를 설치하면 다음과 같은 폴더 구조를 볼 수 있다.

 

@klaytn

 

차례대로

• access: 컨트랙트의 접근 권한인 role을 설정할 수 있는 컨트랙트.
• drafts: 개발 진행 중인 단계의 컨트랙트
• GSN: 어떤 약어인지는 모르겠다. 컨트랙트의 모든 기원인 context.sol이 있다.
• introspection: KIP토큰 구조의 기본이 되는 KIP13이 있다.
• lifecycle: 컨트랙트의 폐기또는 일시정지 등의 기능을 담고 있다.
• math: 솔리디티 자체의 uint형 계산을 안전하게 처리할 수 있도록 돕는 SafeMath.sol이 있다.
• mocks: 개발용으로 토큰 고유기능들을 테스트하기 위해 제작된 컨트랙트들이 있다.(실제 배포용으로는 안 쓰는 것이 좋다.)
• token: erc20, erc721, erc1155가 각각 KIP7, KIP17, KIP37로 리팩토링 되어있다.
• utils: 컨트랙트에서 자주 사용되는 객체나 함수들을 정의한다.(address.sol밖에 없다....)

 

이 중에서 KIP7에 대해서 자세히 다뤄본다.

 

일단 솔리디티 기반의 소스들은 C++ 언어와 매우 흡사하다.

 

C++ 언어에서의 클래스와 인터페이스가 솔리디티에서의 컨트랙트와 인터페이스로 이루어져 있다.

 

@klaytn/contracts/token/KIP7

 

일단 이러한 소스를 분석하기 위해서는 인터페이스 파일 안에 정의되어있는 함수들을 주의 깊게 볼 필요가 있다.

 

function totalSupply() external view returns (uint256);
function balanceOf(address account) external view returns (uint256);
function transfer(address recipient, uint256 amount) external returns (bool);
function allowance(address owner, address spender) external view returns (uint256);
function approve(address spender, uint256 amount) external returns (bool);
function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
function safeTransfer(address recipient, uint256 amount, bytes memory data) public;
function safeTransfer(address recipient, uint256 amount) public;
function safeTransferFrom(address sender, address recipient, uint256 amount, bytes memory data) public;
function safeTransferFrom(address sender, address recipient, uint256 amount) public;
event Transfer(address indexed from, address indexed to, uint256 value);
event Approval(address indexed owner, address indexed spender, uint256 value);​

 

totalSupply() : 해당 토큰의 총발행량을 리턴하는 함수.

balanceOf(account) : account의 토큰 소유량을 리턴하는 함수.

transfer(recipient, amount) : recipient에게 amount개의 토큰을 전송하는 함수.

allowance(owner, spender) : owner가 spender에게 토큰 전송 권한을 넘겨준 수량을 리턴하는 함수.

approve(spender, amunt) : spender에게 amount개의 토큰의 전송권한을 넘겨주는 함수.

 

이 정도가 가장 많이 사용되는 함수들이다.

 

여기서 많은 사람들이 어려워하는 부분이 approve이다.

 

transfer와 approve의 차이점이 무엇일까?

 

transfer는 은행에서의 이체와 동일한 결과를 얻을 수 있다.

 

보내려는 수량만큼 내 지갑에서 값이 빠져나가고, 상대방의 지갑에서 값이 추가된다.

 

하지만, approve는 이체와 다르게 차용증서와 비슷하게 작동한다.

 

권한을 상대방에게 전송했지만, 내 지갑에서 값이 빠져나가지 않는다.

 

상대방이 나의 토큰으로 제 3자에게 토큰을 전송하는 경우에 사용된다.

 

그렇게 될 경우에 안전거래와 비슷한 형식으로 내가 제 3자에게 돈을 지불하게 되는 것이다.

 

따라서 중간 역할을 컨트랙트가 수행하면서 별도의 개입 없이 시스템적으로 처리하는 구조가 된다.

 

사실 블록체인 개발자들은 얼추 느낌적으로라도 알고 있을 것이다.

 

쇼핑몰의 포인트나 컨트랙트의 토큰이나 까고 보면 하나의 변수라는 것을...

 

따라서 블록체인 상의 데이터를 수정하여 토큰을 추가, 전송, 삭제할 수 있는 것이다.

 

이를 대비한 KIP7Burnable, KIP7Mintable, KIP7Pausable이 있다.

 

KIP7Burnable은 해당 토큰의 totalSupply를 수정하고 토큰을 소각(제거, 삭제)하는 컨트랙트이다.

 

KIP7Mintable은 해당 토큰의 totalSupply를 수정하고 토큰을 민팅(생성, 추가)하는 컨트랙트이다.

 

KIP7Pausable은 해당 토큰의 transfer와 approve의 수행 가능 여부를 설정할 수 있는 컨트랙트이다.

 

여기에서 오류가 발생하는데.

 

KIP7Mintable같은 경우 MinterRole을 상속받아서 mint를 할 수 있는 접근 권한을 설정할 수 있다.

 

하지만 KIP7Burnable과 KIP7Pausable는 별도의 권한이 없다. 

 

KIP7Token과 같은 모든 기능이 포함된 컨트랙트의 경우 편의성이 좋지만, 개발 구조라던지, 앞으로의 변화될 구조에 따라 대응하기 위해서는 권한 설정을 정확하게 해주는 것이 필요하다.

 

기업의 경우 총발행량을 유지시켜야 하는 경우가 생길 수 있는데, burn함수의 권한을 public으로 풀어주게 된다면, totalSupply는 변경될 가능성이 있는 것이다.

 

위와 같은 경우에는 KIP7Token을 그대로 수정 없이 사용하게 된다면 아주 큰 오류가 생길 것이다.

 

그리고 이더리움 기반 토큰의 경우 토큰의 이름과 심볼, 소수점 자릿수를 블록체인에 기록하도록 되어있다.

 

클레이튼은 이것을 KIP7Metadata에 포함하고 있다.

 

퍼블릭 블록체인의 경우 openzeppelin과 같이 컨트랙트의 틀을 만들어 공용으로 재사용하는 경우가 있는데, 개발이란 모두가 그렇듯 본인의 상황에 맞게 커스텀을 할 수 있는 능력이 중요하다.