변장한 늑대 — 스마트하지 못한 스마트 계약
안녕하세요. 철학자입니다.
리서치를 하다가 근래에 탈중앙화 되어있지도 않고(non-decentralized), 자율적이지도 못한(non-autonomous) 황당한 계약 코드들을 보게 되어 여기에 대해서 이야기를 하고자 글을 남깁니다.
코드를 모르는 분들도 이해할 수 있도록 쉽게 작성했습니다. 궁금하신 점은 언제든지 댓글을 달아주세요.
ICO 전성시대
토큰 크라우드세일이 엄청난 붐을 이루고 있습니다. ICO(Initial Coin Offering) 혹은 TGE(Token Generation Event)라고도 불리는 이 과정은, 프로젝트의 초기 단계에서 이 프로젝트의 미래가치를 높게 평가하는 기여자(contributor)들이 보유한 이더리움(혹은 비트코인)등을 주고(contribute) 해당 프로젝트 토큰을 받아가는 과정을 거칩니다.
ICO = Crowdsale = TGE
프로젝트는 이러한 방식의 크라우드세일을 통해 초기 펀딩 자금을 확보할 수 있고, 해당 플랫폼의 주주격인 기여자를 여럿 확보하여 프로젝트의 열렬한 지지자도 확보할 수 있습니다.
2017년 11월 31일 기준으로 ICO는 누적투자액 37억달러(한화 4조원)를 기록하고 있으며, 11월에만 7억달러(한화 8천억원)를 모금했습니다.(https://www.coindesk.com/ico-tracker/) 이는 이미 전 세계적인 엔젤투자 및 초기 시드투자 규모를 훨씬 상회한 수준이고(https://www.cnbc.com/2017/08/09/initial-coin-offerings-surpass-early-stage-venture-capital-funding.html), 한해 미국에서 일어난 벤처케피털 총 투자규모인 600억달러의 약 6퍼센트에 해당하는 수준입니다.
ICO 시장의 규모가 급격히 커져가는 과정에서 초기 스타트업 및 프로젝트 수준의 회사가 받는 시드투자 위주에서, 어느정도 규모와 자본을 가진 기업들이 신규사업을 위해 자금을 조달하고자 참여하는 시장으로 확대되어가는 양상을 보이고 있고, 이 과정에서 ICO를 중개하는 여러 플랫폼이 탄생했습니다.(kickico, blockstarter 등)
파생서비스 또한 많이 등장했습니다. 토큰과 크라우드세일의 템플릿을 만들어주는 서비스도 등장했고, ICO의 전후 6개월의 총 과정을 집중 케어해주는 서비스를 제공해주는 곳도 있으며(tokenmarket 등), 만들어진 토큰과 크라우드세일 소스코드에 문제가 없는지 진단해주는 비즈니스(audit) 또한 성행하고 있습니다. 그 과정에서 이러한 진단과정(auditing) 전체를 블로그에 공개하고 토큰과 크라우드세일에 집중된 라이브러리를 제공해 슈퍼스타가 된 zeppelin과 같은 팀도 만들어졌습니다.
문제는..
관련 서비스와 사업이 성행하는 것이 나쁜것은 아닙니다. 돈이 있는 곳에 비즈니스가 생기는건 당연한 것이죠. 그런데 요즘 이러한 암호경제(crypto-economy)의 인기에 단순 편승해 탈중앙화에 대한 진지한 고민 없이 양산되는 질이 안좋은 소스코드들이 나타나고 있습니다.
빨간모자, 소녀 그리고 늑대
빨간모자라는 동화가 있습니다. 빨간 모자를 쓴 소녀가 할머니에게 드릴 음식을 가지고 숲속을 지나던 중 늑대를 만납니다. 늑대는 소녀를 손쉽게 잡아먹기 위해 할머니를 잡아먹고 “할머니 변장”을 한 채, 소녀를 잡아먹습니다.
ICO를 하기 위해 프로젝트팀은 (1)그럴싸한 백서를 작성합니다. (2)개발진들 및 운영진들의 이력도 그럴듯하게 포장합니다. 여기저기 (3)제휴와 파트너십도 맺습니다. 그리고 (4)토큰과 크라우드세일의 소스코드를 공개하죠.
1,2,3,4에 대한 평가는 모두 투자자의 몫입니다. 프로젝트에 대한 평가를 해주는 서비스들도 있지만 돈을 얼마나 주느냐에 의해 A등급, B등급 등으로 나오는 프로젝트 평가결과들은 믿기 힘듭니다.
이제 막 거래소에 가입해서 사고팔고 하시던 분들 혹은 더 공부 하셔서 이더리움을 마이이더월렛으로 보낼 줄 아는 정도 분들에게 (1) 백서의 참신성 (4)소스코드의 이상유무 등을 파악하는 것은 불가능에 가깝습니다. 그래서 보통 깃헙에 (4)크라우드세일과 토큰 컨트렉트 코드가 단순히 “올라와 있기만 해도” 어느정도 신뢰성을 갖춘 프로젝트라고 여기는 것 같습니다.(심지어 크라우드세일 소스코드를 열어두지 않은 프로젝트도 있습니다. 설마,, 보낸 이더로 무슨짓을 할지도 모르는 주소 — 코드가 공개되어 있지 않은 ICO — 에 큰돈을 보내시는건 아니죠??)
백서는 정말 그럴듯합니다. 탈중앙화에 가치에 대한 신봉과 이에 대한 극찬, 블록체인 기술에 대한 설명, 본인들의 프로젝트가 세상을 어떻게 바꿀 것인가에 대한 장밋빛 미래, 여태까지의 성과등을 멋지게 적어 놓죠.
문제는 이러한 도구들이 모두 변장을 한 늑대와 같다는 점입니다. 투자자는 교묘하게 짜여진 백서와 소스코드에 속아 잡아먹히고 있습니다.
왜냐하면 백서에서 말하는 것과 소스코드에서 말하는 것이 다르기 때문입니다.
payable(지불가능한, 이더를 받을 수있는)
이더리움체인 위에서 만들어지는 토큰과 크라우드세일 코드는 현 시점에 가장 유행하는 탈중앙화 어플리케이션(dapp)의 일종이라고 볼 수있습니다.
이더리움 플랫폼 위에서 토큰과 크라우드세일 개발이란 사실 별게 없습니다. 토큰이란 이더리움 계정을 가진 사용자들의 잔액을 관리해주는 프로그램이고, 크라우드세일이란 이더를 받아서 일정 배수를 곱해 새로운 토큰을 발행하는 프로그램입니다. 다만 그 모든 기록이 이더리움 블록체인에 기록되고, 이러한 기록을 남기기 위해 이더를 수수료로 내야 한다는 점이 다르죠.
이러한 프로그램도 이더를 보유할 수 있습니다. 꼭 마이이더월렛에서 만들어진 사용자 계정만 이더 잔액을 가지고 있는것은 아닙니다. 이더리움 블록체인에 올라가는 객체이자 프로그램인 컨트렉트 계정(Contract Account; CA)또한 잔액을 가지고 있고, 일정한 규칙에 의해 이를 주고받을 수 있습니다.
크라우드세일 컨트렉(ICO 컨트렉)을 개발한다는 것은, 이더를 받아 토큰을 발행하는 로직을 가지고 있는 프로그램이라고 볼 수 있습니다.
컨트렉이 이더를 받기 위해서 소스코드에는 특별한 키워드를 집어넣어야 합니다. payable이라는 키워드입니다.
payable이 없는 컨트렉트 소스코드는 이더를 받을 수 없습니다.
그런데.. 리서치를 하던 도중에 payable이 없는 ICO 소스코드를 발견했습니다.
이더를 받을 수 없는 크라우드세일(???).. 이게 무슨 말일까요?
관리자가 발행하는 토큰의 문제(1)
payable이 없는 크라우드세일 코드는 일관된 특징이 있습니다. 이러한 크라우드세일 전체를 통제하는 막강한 관리자 계정이 명시 되어 있습니다.
관리자는 거의 독재자의 가깝습니다. 토큰을 찍어낼수도, 없앨 수도 있고, ICO를 맘대로 시작할수도, 마음대로 끝낼 수도 있습니다. 전체 토큰 전송을 중단시킬 수도 있고, 이런 컨트렉 자체를 없애버릴수도 있죠. 백서에 세일기간이 몇 일이라고 적히건 말건, 기여자들에게 무슨 약속을 했건 말건, 관리자는 이에 구속되지 않고 마음대로 토큰을 주무를 수 있습니다.
payable이 없는 채 발행되는 크라우드세일 컨트렉을 이용한 ICO는 보통 다음의 과정을 거칩니다. 사실 보통이 아니라, 이러한 방법밖에 없습니다.
(1) ICO주소를 관리자의 개인주소로 공개한다(external account)
(2)관리자는 눈으로 들어온 이더 내역을 본인지갑에서 확인하고, 사전에 신청받은 database에 기록된 기여자들의 주소에 수동으로 토큰을 발행한다.
얼핏 보면 아무 문제 없어 보입니다. 다만 아주 강력한 가정을 해야하죠.
관리자는 매우 투명하고, 건실하며, 진실되고, 공평하다.
보통 계약과 스마트 계약
What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party
Bitcoin: A Peer-to-Peer Electronic Cash System by Satoshi Nakamoto
블록체인의 성서와 같은 사토시 나카모토의 논문의 첫장에 있는 문장입니다. 두 주체가 전자거래를 하기 위해서 우리는 신뢰할 필요가 있는 제3자를 필요로 하는 것이 아니라, 이에 대한 암호학적 증거만를 요하는 시스템이 필요하다(trustless)
블록체인은 두 사람이 어떠한 계약이 이뤄지는 과정에서, 제3자의 개입이나 서로간의 신뢰를 필요로 하지 않는 것을 특징으로 하고 있습니다.
특히나 이더리움 베이스로 만들어지는 토큰과 크라우드세일 코드는 더 그렇습니다. 스마트 계약의 구현체인 이더리움 컨트렉은 코드가 계약의 이행을 강제합니다. 다시 한번 강조하면 이 문장이 가장 중요합니다.
“코드가 계약의 이행을 강제한다”
블록체인 상에서 이뤄지는 계약과 스마트 계약이 다른점은, 바로 이 점입니다. 계약의 이행을 당사자나 혹은 신뢰할 수 있는 제3자에게 두지 않고, 블록체인 규칙 자체가 계약의 이행을 강제하는 것이죠. 그렇기에 계약의 당사자는 다른 중개자를 두지 않고 거래가 가능합니다. 마치 비트코인의 거래기록을 은행 등의 데이터베이스에 저장하지 않고, 비트코인 블록체인에 기록 함으로써 신뢰할 수 있는 제3자를 필요로 하지 않게 된 것 처럼요. 그렇기에 블록체인을 신뢰해야하는 중개자가 필요없는(trustless)시스템이라고 부릅니다.
그렇지만 코드가 계약의 이행을 강제하는 코드를 만들기 위해서는, 그렇게 설계를 해야 합니다. 코드를 만드는 것은 설계자(프로그래머)의 판단이기 때문입니다.
이더리움 컨트렉트 아키텍트는 계약의 어떠한 부분을 코드로써 강제할 수 있을지를 결정할 수 있습니다.
이더리움으로 만들어진 토큰과 크라우드세일일지라도, 설계자가 이행해야할 계약의 조항을 코드로 만들어 두지 않으면, 스마트 계약이 아니라 그냥 보통의 계약이 됩니다.
관리자가 발행하는 토큰의 문제(2) — 늑대 컨트렉트
다시 관리자가 발행하는 토큰의 문제로 돌아가겠습니다.
ICO도 일종의 계약입니다. 다만 계약의 내용이 “이더를 받아, 토큰을 발행”하는 스마트계약일 뿐입니다. 만약 관리자가 계약의 내용을 백서에만 명시해놓고, 본인 마음대로 토큰을 발행한다면(즉, 코드가 계약의 이행을 강제하지 못한다면) 그게 진정한 스마트 계약일까요?
전 이러한 코드를 늑대 컨트렉트(wolf contract)라고 부릅니다. 탈중앙화와 스마트 계약의 탈을 쓰고 기여자의 이더를 잡아먹는 늑대같은 존재입니다.
깨끗한 관리자 vs 계약 코드 그리고 일관성
제3자를 필요로 하지 않는다.
이것은 사실 특징(spec)인 동시에 가치( value)의 문제이기도 합니다. 가치란 처한 상황과 시대와 맥락에 따라서 사실 다르게 해석되어질 여지가 있습니다.
블록체인이 제3자를 없애고, 규칙과 프로토콜이 그 역할을 대신하게 만들었지만, 때때로 초인적인 관리자가 필요한 상황이 있을 수 있습니다. 악한 목적의 계약코드 보다는 성인(saint)에 가까운 관리자가 더 나을수도 있겠죠. 사실 이러한 부분에 대하서 무엇이 옳다, 무엇이 그르다 라고 말하고자 하는 것은 아닙니다.(물론 블록체인 사이드에 계시는 분들이 대부분 비슷한 가치관을 가지고 있는 경우가 많습니다만^^)
제가 지적하고자 하는 것은 일관성입니다.
앞에 얘기되었던 스마트 계약과 탈중앙화, 블록체인의 기술 가치는 대부분 백서(whitepaper)의 첫번째 장에 명시되어 있습니다. 보통의 백서는 이 프로젝트가 인지하는 문제는 무엇무엇이며, 우리는 어떠한 가치를 따르고 있고, 그렇기에 그것을 이렇게 해결하고자 한다고 적습니다.
만약 창립자와 팀이 어떠한 가치를 지향한다면, 목적달성을 위한 수단도 이에 맞춰서 만들어져야 합니다.
백서는 탈중앙화, 스마트계약을 강조 하면서, 그 프로젝트의 첫단추를 꿰는 ICO와 토큰 발행 로직을 스마트하지 않게 만드는 것은 일관되지 않습니다.
소스코드로 ICO평가하기 : 스마트 계약의 정도
개발 관점에서 다음의 몇 가지 기준을 ICO를 진행하는 프로젝트를 하는 평가의 잣대로 제시하고자 합니다.
- 토큰과 크라우드세일 컨트렉트 코드의 공개 여부
- payable모디파이어의 사용 여부
- 관리자의 자의적 토큰 발행 여부와 가능성
- (자의적 발행 로직이 있다면)백서를 통해 이를 명시하고, 이에 대한 이유를 설명했는지에 대한 여부
- 토큰과 크라우드 세일 이외의 프로젝트와 연관된 산출물 및 코드 존재여부
- 토큰과 크라우드세일 코드 검토(audit) 횟수 및 검토결과공개 유무
- vault컨트렉트의 사용 유무 : 크라우드세일이 끝날 때 까지 이더를 빼서 사용하지 못하게 하는 코드
1번의 경우가 가장 기본입니다. 보낸 이더가 어떠한 로직으로 처리되는지도 모르는 곳에 투자해서는 안됩니다.
2번은 계속 말씀드렸던 스마트 계약의 존재 여부입니다. ICO라는 것이 이더를 받아 토큰을 만들어내는 “계약”이라면, 이러한 계약은 코드에 명시되어야 합니다. payable이 없는 컨트렉이 만들어져서는 안됩니다.
3번은 컨트렉에 payable키워드가 있다고 해도, 일부 영역에서 자의적으로 토큰을 발행할 수 있는 로직에 대한 존재유무입니다. 프라이빗 세일이라는 명목으로 관리자가 따로 자금을 받아서, 수동으로 발행하는 로직이 숨어있기도 합니다.
4번의 경우, 어쩔수 없는 상황에 의해서 자의적 발행 로직이 들어갔다면, 이에 대해서 기여자에게 투명하고 명확하게 설명해야 합니다.
5번의 경우 프로젝트를 수행하는 팀이 해당 백서에 적혀있는 비전의 일부라도 보여줄 수 있는 수준에 올라와 있는지 확인할 수 있는 잣대가 될 수 있습니다. 자본을 긁어모아놓고, 개발이 진척되지 않는 경우가 종종 발생하고 있습니다.
6번의 경우 토큰과 크라우드세일 과정에서 혹여나 생길 수 있는 큰 문제를 사전에 예방할 수 있습니다. 마치 감기에 걸리기 전에 예방주사를 맞듯이, 이더를 다루는 모든 컨트렉트코드는 전문팀의 감수(audit)를 거쳐야 됩니다.
7번의 경우 이러한 로직이 없다면 심각한 문제를 낳을 수 있습니다. 크라우드세일 도중 이더를 빼서 다른곳에 사용할 수 있다면, 2차 3차 크라우드세일로 이어지는 요즘 ICO의 트렌드를 볼때, 미니멈캡이나 맥시멈캡을 충족하기 위해서 받은 이더를 재활용할 수 있는 여지를 줄 수 있습니다.
그렇지만..
이러한 기준이 만능이 되는 잣대는 아닙니다. 2~3년 이상을 바라보는 프로젝트의 비전에서 토큰과 크라우드세일은 첫걸음일 뿐 전부는 아닙니다. 급하게 시작해서 다 신경 못썼을 수도 있습니다. 문제는 그러한 부분에 대해서 문제라고 인식하고 이에 대해서 언급하고 이야기할 수 있는 용기와 자신감의 문제일지도 모르죠.
다만 옛말에 될성 부른 나무는 떡잎부터 알아본다는 말이 있습니다. 시작부터 거짓말을 하는 프로젝트는 그만한 경고를 받아야 마땅합니다. 기술을 마케팅 수단으로 여기고, 근본 가치를 무시한 채 컨트렉트의 탈을 쓰고 자금을 조달받는 프로젝트는 한번 다시 돌아볼 필요가 있습니다.
해야 하는 일
기여자들이 속지 않기 위해서는 이러한 코드를 선별해 경고할 수 있는 커뮤니티와 프로그래머들이 많아져야 합니다. 문제가 있으면 문제가 있다고 짚고 넘어갈 수 있는 문화가 필요합니다.
프로젝트팀은 본인들의 프로젝트가 얼만큼의 리스크를 가지고 있고, 어떠한 구조로 만들어져 있는지에 대해 용기있게 말할 수 있어야 합니다.
이를 통해 ICO 가 깨끗하고 공평하게 이뤄질 수 있는 기반이 만들어져야 합니다.
이 글을 통해 늑대 컨트렉의 존재가 더욱 알려져 암호경제가 성숙해지기를 바라며 글을 마칩니다.
감사합니다.
