Intro to TokenOS
TaaS(Token as a Service), ICO 자본시장 합리화의 지름길
온더가 지향하는 목표 중 하나는 TokenOS 라는 TaaS(Token-as-a-Service)를 만들어 ICO 자본시장을 합리화시키는 것입니다.
TokenOS란 사용자가 원하는 스펙에 맞추어 커스터마이징된 토큰과 ICO 컨트랙을 자동으로 배포하기 위한 툴입니다.
작년 말부터 올해 초까지 우리나라에는 암호화폐 투자 열풍이 불었습니다. 투자라는 것이 언제나 그렇듯 누군가에게는 기쁨이, 누군가에게는 절망이 찾아오기도 했습니다. 다만 그 절망이 매일같이 우리와 마주하는 평범한 청년들이었기에 더욱 안타까웠지요. 뿐만 아니라, 수 많은 스캠성 코인들이 난립하면서 장기적으로 dApp의 발전을 도모하기보다는 당장 자금을 조달하는 것에만 집중하는 프로젝트들도 많았습니다.
이러한 작태로부터 피해를 입는 주체는 희망을 가지고 살아가야 할 청년들, 그리고 산업의 발전을 위해 열심히 노력하던 블록체인 산업 종사자들이 대다수일 것입니다. ICO와 관련해서 뚜렷한 정책이 설립되지 못한 것도 이러한 시장 불안정성도 큰 비중을 차지했을 것으로 판단합니다. 그만큼 블록체인 산업의 안정화와 발전을 위해서 암호화폐 자본시장의 안정화는 필수적인 선결 과제였죠.
그렇다면 ICO 시장의 안정화란 어떤 것일까요? MakerDAO와 같이 암호자산의 가격 변동성을 최소화시키기 위해 노력하는 Stable Coin 프로젝트가 될 수도 있을 것이고, DeadCoin처럼 사기성 ICO 프로젝트를 리스팅하는 방법을 채택할 수도 있습니다.
최근에는 스마트 컨트랙트를 감사하는 움직임이 많아지고 있는데요. 대표적으로 SMT 해킹 사건을 통해서, ICO 자본시장에서 스마트 컨트랙트의 Audit은 매우 중요한 문제임을 우리 모두가 인지하게 되었습니다.
국내에도 이러한 사건사고들을 예방하기 위해 HAECHI LABS 등의 스마트 컨트랙 보안 및 감사 회사가 생겨나고 있으며 ICO를 하는 회사들 사이에서는 컨트랙 크로스 체킹 및 Auditing에 대한 수요가 많아지고 있습니다.
그렇다면 온더는 어떤 방법을 통해서 ICO 자본시장에 기여하려고 할까요? 상대적으로 오랜 기간동안 다수의 ICO 컨트랙트를 개발하고 직접 감사해왔던 온더였기에, ICO 시장 합리화를 위해 온더가 선택한 방법 역시 ICO와 관련하여 가장 실제적인 내용이었습니다.
합리적이고 안전한 ICO 컨트랙을 수요자가 원하는 스펙으로, 편리하게 배포할 수 있도록 유용한 TaaS를 만드는 것입니다.
저는 오늘 온더가 고민했던 합리적인 컨트랙이란 무엇이며, 그 구성요소는 어떻게 이루어져 있는지에 대한 내용을 설명하고자 합니다 :)
Let’s Dive into TokenOS !
TokenOS는 다수의 질의응답을 통해 자신이 원하는 스펙의 토큰 컨트랙을 자동으로 배포하는 툴입니다. 현재 구현되어 있는 스펙을 기준으로, TokenOS에 내재되어 있는 기능을 도입한 배경과 목적을 설명드리도록 하겠습니다.
우선 TokenOS 구현의 최종 목표인 구글 독스 Q&A 폼을 가지고 TokenOS를 설명하도록 하겠습니다. 기존에는 텔레그램 봇으로 컨트랙 자동화 툴을 구현시킬 예정이었지만, 많은 유저들이 이 서비스를 활용하기에 좀 더 편리하고 유저 친화적인 방법에 대한 갈증이 컸습니다. 그래서 좀 더 범용성 높은 Q&A 수단인 구글 독스 설문지를 채택하기로 했습니다 :)
이처럼 ICO 컨트랙의 기능과 관련된 문항들을 취사선택하여 답을 하고 제출하기만 하면, 자동으로 컨트랙이 배포되는 Customized Tool을 만들고자 합니다. 온더는 TokenOS를 통해 좀 더 많은 사람들이, 좀 더 편하게 자신들이 원하는 ICO 컨트랙을 배포할 수 있기를 원합니다. 그리고 이 컨트랙에는 온더가 ICO 자본시장에 대해 깊이 고민한 내용들이 담겨있을 것입니다.
그럼 지금부터 본격적으로 TokenOS를 알아볼텐데요! 구글 독스 설문지의 첫 번째 질문인 ICO Trilemma를 시작으로, TokenOS를 구성하고 있는 주요 요소와 그 기능에 대해 알아보도록 하겠습니다 :)
ICO Trilemma
우선 첫 번째 질문은 이미 많이 다뤄졌던 ICO Trilemma에 대한 내용입니다. 이 부분은 ICO 컨트랙트를 작성함에 있어 뼈대 내지 사상처럼 고려되는 요소입니다. 어떻게 보면 ICO와 관련해서 온더가 고민했던 철학 중에 가장 깊은 내용이기도 합니다. 이미 국내 커뮤니티에서는 온더의 정순형(철학자) 님에 의해 여러번 다뤄진 논점이기도 하죠.
우선 ICO Trilemma라는 것은 위 삼각형의 세 가지 꼭짓점들이 동시에 고정될 수 없다는 것입니다. 이 개념이 제안된 근본적인 배경은 “백서에 고정적으로 표시되는 상기 세가지 요소들이 ICO가 끝난 이후 그 결과값이 명백히 달라지는 경우가 생긴다”는 문제의식에서 출발했습니다.
일반적으로, ICO를 진행하는 프로젝트의 백서에서는 토큰이 분배되는 상황에 대해서 고정된 분배율을 주로 명시한다는 것은 모두가 인지하고 계셨을 겁니다. 그런데 사전적으로 고정된 분배율은 토큰의 판매 상황에 따라 유동적으로 변할 수 있음을 먼저 인지하셔야 합니다.
최근 들어 커뮤니티에서 가장 큰 이슈가 되어왔던 사후적 분배율(Allocation)의 예를 들면서 이 개념을 살펴보도록 하겠습니다. ICO를 진행한 팀이 실질적으로 몇 %의 토큰을 가져갔는지의 내용은 암호화폐 투자자들에게 아주 민감한 문제니까요 :) 자, 그러면 어떻게 사후적 분배율이 변동된다는 것일까요?
Example Case
토큰의 단위는 ONT 라고 가정하겠습니다. 현재 사전적으로 정해놓은 예시 파라미터의 상황은 다음과 같습니다.
총 발행량 (Total Supply) : 50,000,000 ONT (고정)
가격 (Price) = 1 ETH : 200 ONT (고정)
Hard Cap = 100,000 ETH (20,000,000 ONT)
Min Cap = 30,000 ETH (6,000,000 ONT)
Allocation 중 팀 분배율 = 10 % (고정)
위처럼 총 발행량이 고정된 상태에서 토큰이 전부 안팔린다면 어떻게 될까요? 미판매분에 대한 이슈가 생길 것이고, 이는 Reserve 토큰으로 배분한다는 가정을 해봅시다.
위와 같은 사전적 파라미터와 가정 하에서 토큰의 분배비율을 그래프로 표시해보면, 다음과 같은 그래프를 그릴 수 있고 이 그림이 백서에 그대로 인쇄될 것입니다.
10%의 디폴트를 갖게끔 팀분배율을 고정시키고 판매되는 토큰의 상황에 따라 미판매분이 Reserve로 설정된다고 가정했으니, Reserve 토큰의 비율은 50%가 될 것입니다. 다만, 이는 자신들이 설정해놓은 Hard Cap인 100,000 ETH = 50,000,000 ONT만큼의 자금을 그대로 조달하여, Hard Cap만큼의 토큰이 전부 팔릴 것이라는 가정 하에 작성된 차트입니다.
따라서 판매되는 토큰의 상황에 종속되어 Reserve 비율이 유동적으로 변경되는 상황이 도출됩니다.
사후적 분배율의 변동 시나리오
i) 최소 공모액 달성 시
30,000 ETH = 6,000,000 ONT에 해당하는 토큰이 판매될 경우에 남은 물량을 전부 Reserve 토큰으로 분배한다면, 기존에 설정했던 50%보다 28%p 높은 78%의 분배율을 갖게 됩니다.
현재 Reserve 비율은 50%라는 큰 규모의 비율로 설정되어 있지만, Reserve 토큰의 사전적 분배 비율을 20~30% 수준에서 고려했다면 팀이 보유하는 토큰의 비율은 쉽게 과반을 넘을 수 있습니다.
ii) 중간 공모액 달성시
중간 수준의 판매액인 50,000 ETH = 10,000,000 ONT의 토큰이 팔린 경우에도 결과는 유사합니다. 위와 동일한 논리로 바라봤을 때, 20%p 더 높은 비율의 Reserve 분배율이 도출됩니다. 결국 중요한 것은, 팀이 가져갈 수 있는 토큰의 비율이 백서에서 사전에 명시해놓은 비율보다 훨씬 높은 비율로 결정될 수 있다는 것입니다.
총 발행량의 변동 상황
위 예시의 상황은 총 발행량이 고정되는 상황이었습니다. 현재 TokenOS에는 총발행량이 변동되는 모델을 채택하고 있습니다.
얼마 전 ICO를 진행하시는 한 분과 대화를 하다가, 총 발행량이 변동될 수 있다는 말씀을 드린적이 있는데 저에게 이렇게 되물으시더군요.
총 발행량이 변동되면 그 자체로 문제 아닌가요 ??
결론적으로 말씀드리면 토큰을 발행할 때, 어떤 함수를 쓰냐에 따라 다릅니다.
mint() 함수를 사용하면 ETH가 컨트랙트 주소에 입금됨에 따라 토큰이 발행됩니다(MiniMeToken의 경우 generateToken()을 사용합니다). 이 경우 토큰이 미판매되는 경우는 없습니다. 판매 여부에 따라 총 발행량이 변동될 뿐이죠. 이 모델이 현재 TokenOS에서 차용하는 모델입니다.
반면에, trasnfer() / transferFrom() 함수를 사용하면 총 발행량이 사전적으로 고정된 토큰을 배포한 다음, 사후적으로 투자자들에게 분배하게 됩니다. 이 경우에는 미판매분에 대한 이슈가 남게 됩니다. 그리고 이 미판매분을 소각하거나 Reserve 토큰으로 보류시키고 사후적 분배율이 변동되는 현상을 당연시해왔습니다.
위 상황을 그대로 가져왔을 때, 최소 또는 중간 공모액의 자금 조달 상황에 의해서 Crowdsale에 할당되어 있던 토큰이 미판매되었다고 합시다. 미판매분을 그대로 소각해버리면 어떤 문제가 생길까요?
소각과 동시에 총 발행량(분모) 자체가 줄어들어 Crowdsale을 제외한 다른 요소의 토큰 분배율(분자)이 그 즉시 상승하면서, 결과적으로 총 발행량에서 차지하는 비율이 그만큼 높아진다는 것을 직관적으로 느끼실 겁니다. 이렇게 ICO에서의 비율 조정은 그야말로 숫자 싸움 그 자체입니다.
앞서 조금은 어렵기도 하고 복잡한 ICO Trilemma에 대해 설명드렸는데요. 이제부터는 Trilemma를 설명하며 강조했던 맥락과 흐름을 토대로, TokenOS에 포함되어 있는 컨트랙의 기능을 소개하도록 하겠습니다. ICO에서 어떤 컨트랙들이 필요하고 실제적으로 활용되고 있는지에 대한 내용을 논해보도록 하죠 :)
토큰의 소각 기능(burnable)
TokenOS에서 토큰을 소각하는 기능은 현재 MinimeToken에서 구현되고 있는데요. 특정_amount만큼의 자신의 토큰을 소각할 필요가 있을 때, burnable기능을 사용하게 됩니다. 토큰을 발행하는 것은 다들 익숙하시겠지만 소각 과정에 대해서는 잘 알려지지 않은 것 같아 코드를 한 번 가져와봤습니다. 특정 dApp 생태계에서 토큰을 소각해야 할 필요성이 있다면, 아래와 같은 절차에 의해 토큰이 소각됩니다.
일단 6~9번째줄을 보시면 기존의 총 발행량이었던 curTotalSupply와 소각 대상 토큰을 보유하고 있던 잔액인 previousBalanceFrom이 소각할 토큰의 양인 _amount가 더 커야 할 것입니다.
그리고 10~11번째줄을 보시면 curTotalSupply 와 previousBalanceFrom 값에서 _amount 만큼의 토큰이 소각되는 것을 확인할 수 있습니다.
토큰 전송의 일시정지 기능(pausable)
pausable 기능은 해킹에 의해 침해되는 개인의 재산권을 보호하거나 토큰 컨트랙의 안정성을 위해 꼭 필요한 기능입니다. 국내 거래소 관련 뉴스에서도 심심찮게 들리는 ‘토큰 전송 중지'를 가능하게 하는 기능이기도 하죠.
pausableToken의 코드 앞 부분에서 modifier 함수를 사용해 토큰 일시 정지를 위한 선결 조건을 설정하긴 하지만, 내용이 복잡해지기 때문에 토큰이 일시 중지되는 것 자체에만 집중하겠습니다.
일단 위 코드에도 언급되어 있듯이, 특정한 상황 하에서 컨트랙의 owner(개발진)가 일시 정지를 요청하면 emit Pause() 함수에 의해 토큰 트랜잭션이 중단됩니다.
이런 기능이 필요한 개별 상황은 너무 많은데요. 일단 위에서 말씀드린 것 처럼 보안적 측면에서 활용될 수 있습니다. 가령, AirSwap팀의 경우 토큰 전송의 일시중지가 발생할 수 있는 상황에 대해 이렇게 이야기한 바 있습니다
The token contract is also “pausable”, which means that we can pause transfers in case of a major security vulnerability.
뿐만 아니라, 보안적 목적 외에도 자체적으로 블록체인을 만들어 자신들만의 고유 메인넷을 새로 만든다면 토큰의 전송을 정지 하는 기능이 필요할 수 있습니다.
새로 발행하는 암호화폐와 기존의 토큰을 스왑해야 하는 경우가 생길 수 있는데, 이 때에도 토큰 전송중지 기능이 활용되기 때문이죠.
예컨대, ERC20이었던 EOS의 토큰 스왑을 진행한 Kraken 거래소의 경우, 스왑이 진행되기 이전에 토큰의 트랜잭션을 중단하기 위해 다음과 같은 설명을 한 적이 있습니다.
We pause funding ahead of the transition, swap all the old coins for new and when we resume funding, all the old balances are for the new coins.
토큰의 추가발행 기능(Mintable)
mintable 기능은 아직까진 TokenOS 안에 구현되어 있진 않고 커스텀 기능으로 활용 중인 기능인데요. 인플레이션에 따른 지분 희석효과 등을 고려할 때, 토큰을 추가로 발행해야 할 목적이 있다면 명백한 이유가 있어야 하기 때문에 무조건적인 선택사항으로 구현시켜놓진 않았습니다 :) 이 기능의 목적은 ICO 컨트랙의 종료 시점이 끝난 후에 특정 용도를 위해 Reserve 해놓은 토큰이 존재할 경우, 이를 추가적으로 발행하기 위함입니다.
Reserve 뿐만 아니라 ICO 이후에 바운티 프로그램, 에어드랍 등 추가적으로 발행이 필요한 경우가 생길 수 있습니다. 이 때 MintableToken의 기능이 활용됩니다. 토큰을 Reserve하는 것의 의미 자체는 따로 논해야 할 깊은 내용이고, 여기에서는 “TokenOS 내부에 이런 기능도 고려할 수 있다!”는 정도로만 이해하시면 될 것 같아요 :)
일단 ICO가 끝나고 토큰을 추가 발행하려는 예시적 상황은 다음과 같은 경우가 있습니다.
i) 추후 토큰의 추가 판매 (Kin, SimpleToken, etc)
ii) Reward Pool, Emergency, Ecosystem 등의 목적성을 가지고 컨트랙에 유보시켜두는 경우 (OmiseGo, Singularity Net, Matrix… Too many)
iii) PoW 합의 알고리즘을 목표하는 경우 (Ziliqa, 0xBitcoin, etc)
이 외에도 토큰 이코노미 내부적으로 통화 팽창을 일으키거나 특정 어카운트에 토큰을 추가 발행하는 경우 등등 상황이야 여러가지가 있겠지만, 결론은 ICO 컨트랙의 종료 시점 이후에도 추가적으로 토큰을 발행하기 위해서는 mintable 기능을 사용한다는 것입니다.
암호화폐경제 측면에서 바라보면, 앞서 설명드린 burnable 기능과 정확히 반대되는 기능입니다. ICO가 끝난 후 암호화폐 통화정책에 변동을 주고 싶을 때 burnable 기능을 사용하면 디플레이션을, mintable 기능을 활용하면 인플레이션을 발생시킬 수 있습니다.
P.S) Ziliqa는 자체적으로 PoW 기반 고성능 블록체인을 만들기 때문에 Reserve 시켜둔 것인데, ERC20 토큰에 비트코인 합의 알고리즘을 구현시켜놓은 0xBitcoin이라는 프로젝트가 있습니다. 이 경우 투자자가 토큰을 사려면 마이닝 작업을해야 합니다. 어쨌든 ERC20이기 때문에, 결국 개발진이 고정된 총 발행량만큼 선발행하고 후배분…이라기 보단 후 마이닝(^^..)하는 구조인 것이죠.
ICO Stage
ICO Stage는 토큰을 판매하는 기간이 몇 번 나눠져있는가를 구분하는 개념입니다. ICO를 진행하면서 프라이빗 세일, 메인 크라우드 세일 등이 나눠지는 것을 많이 보셨을거에요. 이렇게 판매 구간을 구분 가능하게 해주는 컨트랙이 Stage 컨트랙입니다.
위처럼 하나의 독립된 스테이지를 만들어 ICO를 진행한다고 할 때, function initStages()를 호출하고 다음과 같은 변수들을 설정합니다.
시작시간 :
_startTimes종료시간 :
_endTimes해당 스테이지의 하드캡 비율 :
_capRatios인당 최대/최소 구매량 :
_max/minPurchaseLimitskyc 여부 :
bool[] _kycs
이를 좀 더 확장시켜서 하나의 예를 들어보겠습니다.
만약 어떤 팀이 ICO를 진행하는데 Private Sale을 1회, Crowdsale을 2회 진행한다고 한다면 아래와 같은 그림으로 표현될 수 있습니다. 그리고 각 Stage마다 위와 같은 변수들을 각각 독립적으로 설정할 수 있습니다.
가격 정책
토큰을 판매할 때, 판매 가격에 보너스를 주거나 할인 혜택을 주는 ICO가 많아지고 있는데요. 이 때, 토큰의 구매 가격에 대해 차등을 두는 것을 온더 내부에서는 가격 정책이라고 부릅니다.
가격 정책은 각각의 ICO Stage 내부에서 활용될 수 있는 논리로 볼 수 있습니다. 결국 가격 정책이 활용되기 위해서는 토큰을 파는게 가능해야 하는 것인데, 그러기 위해서는 특정 ICO Stage가 진행되고 있어야 하니까요 :)
좌우지간 가격 정책 자체는 크게 두 가지로 구분될 수 있습니다.
i) 기간 보너스(Periodic Bonus)
ii) 수량 보너스(Amount Bonus)
i) 기간 보너스 (Periodic Bonus)
Periodic Bonus는 아래 표를 보면서 설명해드리도록 하겠습니다.
상기 내용은 세계 탑 거래소인 바이낸스에서 활용되는 Buy-back 토큰 BNB의 ICO 정책을 일부 변형한 것인데요. 기간에 따라 토큰 구매 가격에 차등을 두는 방식인데, 7월 1일부터 총 3주 동안 ICO가 진행된다고 가정할 때 시간이 지남에 따라 ONT 토큰의 가격이 비싸집니다. 1ETH로 살 수 있는 토큰의 양이 줄어들죠. 이 때 일찍 투자에 참여해서 토큰을 싸게 사는 사람들을 보통 Early Bird라고 많이들 부르더군요 :)
그렇다면 여기에서의 ICO Stage는 총 몇개일까요? 3주 동안 각각 3번씩, 1주일 동안 ICO가 진행되니 토큰 컨트랙은 총 3개의 Stage로 이루어져 있을 것입니다.
만약 위처럼 보너스 구간이 2개 이상 존재한다면, 아래 플로우 차트와 같이 질의응답이 반복 처리되는 구조로 TokenOS가 설계되고 있습니다. 이는 보너스 구간에 대한 문항 뿐만 아니라, 반복적으로 변수를 입력해야하는 경우가 있다면 다른 문항들에서도 동일합니다.
ii) Amount Bonus
두 번째 보너스는 양적인 측면의 보너스인데요. 토큰을 구매하는 양에 대한 보너스, 즉 투자액(=토큰 구매 수량)에 대한 보너스를 의미합니다. 이 경우 투자자가 받는 혜택의 방법론은 크게 두 가지로 나눠질 수 있습니다.
첫번째 경우는 토큰의 관점에서 바라봤을 때, 투자액에 비례해서 토큰을 + N%만큼 추가로 발행하여 최종적으로 (1 + N%)의 토큰을 발행해줄 수 있습니다.
100 ONT 구매 (0%) : 투자 금액에 대한 보너스가 없어, 100 ONT 만큼을 수령.
1,000 ONT 구매 (10%) :
1000 * 1.1 = 1,100에 해당하는 ONT를 수령.10,000 ONT 구매 (30%) :
10,000 * 1.3 = 13,000에 해당하는 ONT를 수령.
두번째 경우는 투자자가 지불하는 ETH에 대해서 — N%만큼 할인혜택을 주어 최종적으로 (1-N%) ETH 를 지불하게 하는 할인 혜택이 있습니다.
그런데 두 가지 경우는 방법만 다를 뿐이지 결국 투자자에게 돌아오는 경제적 실질은 똑같습니다. 어쨌든 N%만큼의 돈을 더 버는 셈이니까요 !
Stage와 가격 정책 간의 관계를 좀 더 자세히 이해하고 싶은 분들은 TokenOS 항목들이 구조화되어있는 json 파일에서 Stage와 Crowdsale 항목을 살펴보시면 좋을 것 같습니다.
Stage 내부에서 가격에 차등이 생긴다고 말씀드렸는데, 이는 Crowdsale의 요소 가운데 기본 가격(base_rate ) 항목을 자체적으로 설정할 수 있음을 확인하실 수 있습니다.
Multi-Signature Wallet
멀티시그니처 지갑에 대한 기능입니다. 멀티시그니처 지갑도 결국 스마트 컨트랙트(CA)의 일종이라고 볼 수 있는데, 토큰을 출금할 때 하나의 개인키만을 사용하는 일반 지갑과는 달리 멀티시그니처 지갑을 활용하면 여러개의 개인키를 보관할 수 있게 됩니다.
멀티시그 지갑을 활용한다면 누군가 출금을 하려고 할 때 전체 개인키 보유자의 과반 혹은 특정 정족수를 충족시켜야, 즉 다중 서명이 있어야 비로소 출금이 가능해지는 지갑 구조입니다. 출금을 하기 위해서 편리성을 일부 포기하고 보안성을 강화한 형태로 볼 수 있겠지요. TokenOS를 활용하고자 하는 팀이 월렛의 보안성을 제고시키기 원한다면 멀티시그 지갑 기능을 고려할 것입니다.
아래는 멀티시그니처 지갑의 구조를 가볍게 도식화한 것입니다.
총
2개의 멀티시그 월렛이 있고, 각 월렛에는3개의 외부소유 계정(EOA) 주소가 들어있다고 가정하겠습니다. 이 경우, 각 멀티시그 월렛에서EOA 1의 소유자가 자신의 토큰을 출금하길 원한다면,EOA 2와EOA 3소유자로부터 출금 허가를 받아야 합니다. 즉, 자기가 돈을 빼고 싶다고 해서 즉시 빼낼 수 있는 구조가 아닙니다.
그러나 멀티시그니처 지갑이라고 해도 해킹이 불가능한 것은 아닌데요. 위에서 제가 멀티시그 월렛도 결국 스마트 컨트랙트의 일종이라고 말씀드렸는데, 코드를 제대로 안짜면 해킹당할 수 있습니다. 대표적인 사례가 패러티 멀티시그 어택이었죠. 멀티시그 컨트랙트의 해킹에 대한 정보는 아래 분석 자료에서 확인하실 수 있습니다 :)
Locker
말 그대로 토큰을 잠금(Lock)시키는 기능입니다. 락커라는 것 자체는 일종의 어카운트인데요. 컨트랙 상에 존재하는 락커에 토큰을 보내놓으면 락커 컨트랙이 해당 토큰을 일정 기간 동안 묶어놓습니다. 이런 락킹이 가능해지는 이유는 토큰의 TX가 블록체인에 기록되기 때문이겠죠?
이런식으로 특정 기간동안 토큰을 묶어둔다는 내용을 입력해놓으면 그 기간동안 지정해놓은 락커 어카운트에 토큰이 묶이게 됩니다. 예를 들어, 팀이 받아가는 토큰에 락킹이 필요하다고 한다면 TeamLocker라는 컨트랙 주소를 만들어서 팀에게 할당되는 토큰을 Vesting 기간만큼 묶어둡니다.
최근에 진행되는 ICO 프로젝트의 경우, Team이나 Advisor에게 토큰을 일정 기간 분할해서 주는 Vesting 문화가 거의 관습처럼 자리잡고 있습니다. Vesting 정책 자체는 벤처 투자업계에서 스톡옵션을 부여할 때 전통적으로 활용되던 방법이기도 하구요. ICO에서 이러한 분할 수령을 가능하게 만드는 방법론이 바로 Locker 컨트랙입니다. 유명한 팀 중에서는 Aragon이 ICO를 진행하면서 다음과 같은 이야기를 한 적이 있습니다.
개발진이나 Founder가 한 번에 돈을 받아가는 것이 아니라, 분할해서 수령하게하는 효과는 팀에게 열심히 일해야 할 동기를 할당합니다. 뿐만 아니라, 토큰을 받자마자 거래소에 매도 물량을 풀어 재빨리 털고 나가려는 ‘토큰 덤핑 시도’를 줄일 수 있습니다.
앞서 말씀드렸던 Locker 기능에 의하면, 토큰에 Lock을 걸었다는 것은 자신이 받은 토큰을 한 번에 받아가지 못하고 분할해서 수령함을 의미합니다. 이 과정을 그림과 코드로 설명드리도록 하겠습니다.
위 코드 상에서 1~12줄을 보시면 계단형 그래프가 보이실 것입니다. 일반적인 Vesting 정책에 해당한다고 볼 수 있는데요. 총 3번 에 걸쳐 토큰을 분배받는다고 가정할 때, 위와 같은 계단형 그래프가 도출됩니다.
14~19줄을 보게되면 releaseTimes 을 설정해 언제 이 토큰들을 추가적으로 풀어낼 지 그 시간을 정할 수 있습니다.
first release time: 락커에서 토큰이 첫 번째로 릴리즈되는 시간으로서, 그 비율은30%에 해당합니다.
second release time: 락커에서 토큰이 두번째로 릴리즈되는 시간으로서, 그 비율은70%(누적)에 해당합니다.
third release time: 락커에서 토큰이 두번째로 릴리즈되는 시간으로서, 그 비율은100%(누적)에 해당합니다.
고려하지 않는 기능
스마트 컨트랙트를 작성해놓긴 했지만 실질적으로는 투자자들을 우롱하는 컨트랙트들이 많이 있는데, 그 가운데 대표적인 것이 관리자가 막강한 권한을 사용하여 토큰 TX를 좌지우지하는 경우입니다.
예를 들면, 관리자가 특정 계좌를 동결시킬 수 있다거나 특정 계정에만 토큰을 발행 및 소각시킬 수 있는 등의 기능들은 TokenOS에서 고려하지 않고 있습니다. 이러한 기능이 TokenOS의 스펙에 추가되면, 중앙화된 관리자가 해당 기능들을 오남용할 가능성이 크기 때문입니다.
스마트 컨트랙트에서의 탈중앙성
맨 처음 말씀드렸다시피, 온더가 TokenOS를 만드는 본질적인 목적은 ICO 자본시장을 좀 더 합리적으로 만들기 위함입니다. ICO 자본시장에도 탈중앙성이 필요한 이유는 ICO라는 행위를 가능하게 만든 블록체인의 탄생 배경으로부터 기인할 수 있습니다.
블록체인의 효시인 비트코인은 기존의 중앙 집권형 금융기관 내지 무제한적 화폐 발행권한에 반기를 들며 등장했습니다. 개인간 금융 거래에 있어서 제 3자로서의 중앙 기관을 최대한 배제하고, 상호간 발생하는 거래를 직접적으로 연결시키고자 한 것이 비트코인의 철학이자 목적이었죠.
이는 스마트 컨트랙트를 통한 토큰의 발행에도 고스란히 전달되어야 할 중요한 가치이며 비트코인이 등장한지 10년이 된 지금까지도 유효합니다. 따라서 스마트 컨트랙트에 막강한 권한 또는 영향력을 행사할 수 있는, 중앙화 가능성이 다분한 기능들은 TokenOS의 스펙으로서 고려하지 않는 것입니다.
기능의 확장 : DAICO
이상으로 현재 TokenOS에 구현되어 있는 주요 기능과 배경에 대한 설명을 마쳤습니다 :) 그러나 앞서 언급했다시피 더 많은 기능을 TokenOS 내부에 추가해야 할 필요가 있는데, 그 중 대표적인 기능은 DAICO 모델입니다.
ICO 문화가 정착되어감에 따라서 자금을 조달하는 것이 상대적으로 쉬워졌지만, 모은 자금을 유용할 가능성 역시 높아졌습니다. 이에 따라 비탈릭에 의해서 DAICO(DAO + ICO)라는 대안적 ICO 방식이 제안되었습니다.
ICO를 진행하게 되면 토큰과 더불어 ETH를 받게 됩니다. 현재까지 나와있는 Locekr 컨트랙에는 팀이 발행한 토큰이 묶이지, 받은 이더가 묶이진 않습니다. 즉, 모인 이더를 맘대로 유용하는 것에는 별다른 제동 장치가 없기 때문에 이를 막는 방법 또한 필요했다는 것이죠. 그래서 고안된 개념이 DAICO입니다.
DAICO의 Tap Mechanism을 활용하면, 개발진들이 ETH를 인출하는 과정에 투자자의 투표 절차가 추가 됩니다. 이는 개발진들의 ETH 인출 행위를 어렵고 귀찮게 만든 아이디어였는데, 얼마 전 Abyss 팀이 DAICO 구조를 활용한 ICO를 진행해서 화제가 되기도 했지요.
Tap Mechanism by Vitalik Buterin
Tap이란 개발진이 1초에 인출할 수 있는 이더의 양(wei / sec)입니다. 투자자들(토큰 홀더)은 이러한 Tap을 이용해서 개발진으로 하여금 조달된 이더를 유용하지 못하도록 제재를 가할 수 있습니다.
만약 개발진이 인출 가능한 이더의 양을 변경하거나 일방적으로 인출하려 한다면, 토큰 홀더들은 투표에 의해 Tap을 높여 인출 시도를 막습니다. 또는 withdraw() 함수를 호출해서 현재 토큰 보유분에 비례하게끔 자신이 투자한 이더를 환불(refund)받을 수 있습니다.
Specified DAICO Contract by Abyss
Abyss가 만든 DAICO 컨트랙트는 크게 2가지로 구성되어 있습니다.
i) 토큰 판매에 대한 기능
ii) 투표에 관한 기능
집중해야 할 것은 당연히 투표에 관한 기능이며, 첨부한 github 링크는 투표의 구조를 설계해놓은 BasePoll.sol에 해당합니다. 그러나, Abyss의 DAICO 컨트랙은 개발진의 영향력이 투자자들의 투표에 완전히 배제되지 않는 등 여러가지 한계점들을 포괄하고 있기도 합니다. 관련 내용은 다음 기회에 자세히 다루도록 하겠습니다 :)
🌎 Github TokenOS Schema
이상으로 TokenOS의 전반적인 흐름에 대한 설명을 마쳤습니다 :)
오늘 설명드린 내용은 TokenOS의 Schema에서 전부 확인하실 수 있습니다. 현재까지 구현되어 있는 TokenOS의 진행 상황이 오픈소스로 공개되어 있습니다.
현재는 ICO 컨트랙과 관련된 다양한 기능들을 리서치하고 질문 사항에 반영(ICO 컨트랙 기능 개선)하는 과정 중에 있습니다. 동시에 ICO 스마트 컨트랙과 구글 독스 설문지 간의 연결 지점을 찾아가면서 컨트랙 배포를 자동화시키는 개발도 진행 중입니다.
역동적으로 움직이는 스마트 컨트랙트 씬이기 때문에 아직 추가해야 할 기능들이 많이 남아있고, 이에 대해서 지속적인 팔로업과 리서치가 이루어지고 있습니다. 추가적인 기능이 구현될 때마다 수시로 그 도입 목적과 기능을 설명드리도록 하겠습니다 :)
P.S) 레포 이름이 Tokyo로 되어있는 것은 온더 내부에서 TokenOS의 코드네임(codename)으로 Tokyo를 쓰고 있기 때문입니다 :)
