이 글에서 다루는 내용이나 의견은 제가 속한 회사의 공식적인 입장이 아니며, 최근 블록체인과 DeFi 쪽의 업무를 진행하며 느낀 점들을 적은 지극히 개인적인 의견임을 밝힙니다.
최근 몇 년간 블록체인 기술을 기반으로 가상자산을 이용하여 탈중앙화 금융서비스를 구현하는 다양한 Decentralized Finance, 즉 DeFi 프로젝트가 매우 빠르게 성장하고 있다. 시장의 규모가 커짐에 따라 player들도 많이 늘어나는 추세인데, 여러모로 흥미로운 점들이 많다.
최근 우리 회사에서도 몇몇 DeFi 프로젝트에 대한 보안감사 서비스를 제공했는데, 이제까지 보안컨설팅을 해오던 기존 산업 분야와는 확연히 다른 특징이 있었다. 그것은 바로, 발견된 취약점 및 조치사항 내용에 대한 공개 여부이다. 대부분의 국내 고객들은 우리가 보안성 검수를 진행하며 발견한 취약점 내용을 (가끔은 취약점이 발견되었다는 사실 자체를) 외부에 공개하는 것을 극도로 꺼려한다.
기업 입장에서 취약점에 대하여 어떠한 행동이나 반응이 올바르다고 결정하기엔 고려해야 할 부분들이 너무나도 많고 각각 이유와 상황이 다르기 때문에 여기에서 이 주제에 대해서 토론하지는 않겠다.
하지만, 애당초 투명성 및 검증가능성을 태생으로 시작한 블록체인과 DeFi 프로젝트는 다르다. 대부분의 프로젝트 개발팀은 자신의 프로젝트에 취약점이 존재했다면 그에 대해서 root cause 분석까지 해가며 정확하게 알리고, (더 중요하게) 어떻게 조치가 이루어졌는지, 앞으로 어떻게 재발을 방지할 것인지 등에 대해 매우 투명하고 적극적으로 커뮤니티/사용자와 공유한다.
DeFi도 결국 사람이 설계하고 구현하는 것이기 때문에 실수가 있을 수 있고, 그로 인한 보안 취약점 또한 발생하기 마련이다. 다만, 앞서 설명했듯 그 risk와 impact를 이해하고 선제적으로 코드 리뷰를 진행하며 보안 검수를 받는 프로젝트도 있고, 그렇지 않은 프로젝트도 존재한다. 물론, 보안 검수를 받았다고 해서 무조건 안전하다는 것을 보장하지는 않는다.
하지만, 보안 검수를 진행하는 회사/팀의 기술에 대한 깊이와 실력에는 확실한 차이가 존재한다. 그렇기 때문에 단순히 “보안 검수를 받았다”는 것이 면죄부가 될 수 없고 개발팀과 지지자들이 안심해서도 안되는 것이다.
얼마전, 국내에서 개발한 DeFi 프로젝트(Donkey)에 대한 소개글을 페이스북을 통해 접하게 되었다. 아무래도 최근 DeFi 관련 프로젝트를 많이 모니터링하고 코드를 읽다보니 이 프로젝트도 자연스럽게 관심을 가지고 찾아보게 되었다. (캐릭터 넘나 귀여운 것..)
그런데 눈을 씻고 찾아봐도 etherscan이나 GitHub 등에 공개된 contract 소스코드가 없는 것 아닌가. 여기저기 헤매이고 다니다가 FAQ 페이지에서 다음과 같은 질문과 답변을 발견했다.
Q. 돈키의 소스코드 공개는 안하나요?
A. 돈키의 스마트 컨트랙트 코드를 공개할 계획이 있는지 커뮤니티를 통해 문의주시는 분들이 있었습니다. […] 물론 저희가 두번 세번 안정성을 확인하였고 외부 보안 전문업체를 통해서도 역시 두번 세번 감사를 진행하였습니다마는 […] 아직은 코드 공개의 득보다는 실이 더 크다고 판단하여 공개하지 않았습니다. […] 당연히 코드는 자신 있고, 깐깐한 외부 감사도 모든 컨트랙이 통과했고 […]
코드가 자신이 있고 깐깐한 외부 감사까지 모두 통과했다면 더더욱 공개해도 문제가 없어야 할텐데, 오히려 공개하지 않겠다는 입장이 뭔가 앞뒤가 맞지 않는다고 생각이 들었다. 아니나 다를까, 나 말고도 다른 사람들도 이런 비슷한 의문을 가졌던 것 같다. 페이스북 그룹 한 곳에서는 블록체인/DeFi 프로젝트임에도 컨트랙트 소스코드를 공개하지 않는 것에 대해서 분주한 공방이 있었던 것을 늦게나마 발견할 수 있었다 — 며칠이나 지난 후에 발견한지라, 내용을 읽어만 보고 직접 참여하여 토론하지는 못했다.
어찌됐든, 잠 들기 전에 심심풀이겸 코드나 살펴보려고 했는데 공개된 코드가 없다는 점에 꽤나 실망하고 침대에 누운 찰나 어떠한 생각이 불현듯 스쳐지나갔고, 다시 컴퓨터 앞에 앉은 나는 이내 Donkey contract 코드를 읽고 있었다 :)
앞서 말한대로 자기전에 잠깐 살펴본 정도이기 때문에 아래 내용에 너무 큰 의미를 두지는 않기를 바란다.
코드를 살펴보면 Donkey 프로젝트 관계자가 “잘 작동하고 있는 코드를 사용"했다고 이야기했듯 Donkey contract 코드의 대부분은 기존에 존재하는 프로젝트인 Compound 코드와 유사도가 매우 높다. 코드 상의 차이점이 있다면 1) Compound에서는 보통 ‘c’를 prefix로 붙이는데 Donkey에서는 ‘d’를 쓴다는 것과 2) 원본 코드에 있던 주석이 사라졌고 3) 일부 코드는 그대로 복사/붙여넣기는 아니지만 ‘코드를 보고 작성'한 것 같은 버전이라는 것이다.
또한, Donkey에는 Protected Asset 이라는 개념을 추가했고 자산 대부분이 Chainlink에서 price oracle을 제공하지 않는 국내 거래소에 상장된 코인들이기 때문에 자체적인 oracle을 활용할 것 같은데, 이 부분은 불투명하다. Off-chain 구조라면 크게 위험하지 않겠지만, on-chain 이라면 정말 조심하지 않는 한 심각한 문제로 이어질 수 있다. 이외에도 Compound 코드에 비해 몇 가지 변경사항들이 존재하고 관련하여 우려스러운 부분들도 있지만, 이번 글은 스마트컨트랙트 취약점 점검/분석이 요지가 아니므로 다루지 않겠다.
DeFi 생태계에 익숙하지 않은 사람이라면 ‘뭐야, 그냥 있던 것 가져다가 리브랜딩 한 수준 아니야? 새로 만든것도 아니고, 엄청 대단한게 아니었네’라고 생각할 수 있다. 위에서 취약점 공개에 대한 접근과 방법이 기존 산업들과 크게 다르다고 이야기한 것처럼, 블록체인 (특히 DeFi) 쪽에서는 투명성과 공개성에서 기인하는 이와 같이 존재하는 프로젝트를 fork하여 새로운 서비스를 개발하는 경우가 드물지 않다. 주요 프로젝트의 코드가 오픈소스로 공개되어 있다보니 훨씬 더 자유롭게 참고할 수 있고, 대부분 프로젝트의 라이선스가 재사용 및 재가공을 허용하며 새로운 player들의 진입을 장려하고 촉진시킨다. 이러한 점이 블록체인 산업의 성장을 가속화시키지 않았을까 생각한다.
실제로 바닥부터 설계되고 구현되어 자체적으로 쌓아 올려진 프로젝트는 그리 많지 않다. Compound는 그 몇 안되는 프로젝트 중 하나이고, 그 중에서도 단연 높은 코드 퀄리티와 보안성/안정성을 자랑하는 프로젝트이다. Compound 컨트랙트 코드는 오픈소스이고, 정말 다양한 DeFi 프로젝트들이 복사/붙여넣기로 사용하는 De facto 코드베이스이기도 하다. 안전하게 유지하기 위해 주기적으로 외부 감사를 진행하는데, 단순한 코드 오딧 뿐만 아니라 formal verification 기법을 동원한 검증과 금융공학적 공격 가능성까지 다양한 각도에서 여러 조직에게 검증을 받고 있다. 그래서인지, 사용자에게 (뿐만 아니라 공격자에게도) 많은 관심을 받고 있고, TVL이 12조원이 넘어갈 정도로 보안성과 안정성을 인정받았다.
다만, 이렇게 뛰어난 프로젝트를 기반으로 하더라도 각 프로젝트(파생상품) 특징에 맞춰 “튜닝"을 하게 되면 더이상 원본 코드와 동일하지 않기 때문에 그로 인한 예상치 못한 취약점들이 발생할 수 있다. 이에 대한 side-effect 여부와 발생할 수 있는 취약점 등 risk를 다시 평가할 필요가 있는 것이다. 수정된 (또는 아예 새롭게 작성된) 코드를 오픈소스로 공개하면 커뮤니티 차원에서 이러한 검증을 하기 수월해질 뿐만 아니라, “튜닝"이 내부자 공격을 위한 백도어 코드 등을 삽입한게 아니라는 것도 확인하여 신뢰성 향상 및 확보도 가능하다. Donkey를 이두희님 페이스북에서 “100% 스마트컨트랙으로 진행되기에 저희도 고객의 자산에 손을 댈 수 없는 De-Fi 프로젝트”라고 소개해주셨는데, 이것이 사실인지 코드 없이 어떻게 알 수 있겠는가? (물론, 설사 그럴 수 있더라도 고객의 자산에 손을 대지 않을 사람이라는 믿음이 있지만, 우리는 엔지니어고 엔지니어는 코드로 이야기해야한다고 생각한다. 특히, 이러한 부분을 증명 가능한 점이 이 기술의 꽃 아니던가.)
우리가 코드와 오픈소스를 이야기 할 때, 라이선스에 대한 부분을 간과하는 경우가 많다. Compound 코드의 license는 현재 BSD-3이다. 사실, 흥미롭게도 해당 코드가 2020년 초에 BSD로 바뀌기 전까지는 연구용 목적 이외에는 사용이 금지되어 있었다. 즉, 다른 프로젝트들이 Compound 코드를 활용하여 DeFi를 만드는 것은 허용되지 않았다는 말이다. 다행히 Donkey를 포함한 수 많은 프로젝트들은 이 점을 걱정할 필요는 없어졌다. 하지만, 새롭게 바뀐 라이선스를 정확히 숙지하고 필요한 행위를 이행하는 것은 매우 중요하다. BSD-3의 경우, 코드의 복제/배포/수정의 권한을 허용하고 상업적 사용에도 제한이 없지만, 원 저작권자를 표기하는 것이 요구된다.
Donkey 프로젝트는 위에서 언급했듯, 많은 부분을 Compound 프로젝트의 코드를 빌려온 것으로 보인다. 하지만, Donkey 웹사이트나 docs, 백서 등 어디에도 Compound에 대한 라이선스 저작자 표기는 찾아볼 수 없었다. 저작권 및 라이선스 존중은 소프트웨어 개발에서는 매우 기본적인 부분이면서도 중요한 부분으로, 해당 내용이 누락된 점은 많이 아쉽다. (혹시, 어딘가에 기재가 되어 있는데 제가 찾지 못한 것이라면 위치 알려주시면 감사하겠습니다.)
애당초 생각했던 것 보다 글이 길어졌기에, 슬슬 결론을 낼까 한다.
- 진정한 탈중앙화 서비스라면 정우현님이 위 페이스북 쓰레드에 언급하신 것과 같이, 웹 서비스 코드까지는 아니더라도 적어도 스마트컨트랙트는 오픈소스하면 좋겠다는 생각이다.
- 보안 감사는 확실한 scope과 목표를 가지고 가급적 다양한 그룹에게 받는 것이 좋다. 이는, 위에서 언급했듯 같은 대상이라고 할지라도 다양한 방법과 시각으로 검증함으로써 다양한 공격벡터와 공격 시나리오를 도출함으로써 “미지의 risk”에서 “관리 가능한 risk”로 발전시킬 수 있기 때문이다.
- 현재 Donkey의 TVL이 1,500억이 넘어가는데.. 지금 같은 상황에서는 나 같으면 무서워서 서비스 운영을 못할 것 같은데 개발자들도, 투자자들도.. 모두 엄청난 강심장들이다.
- 코드 라이선스는 항상 지키도록 하자!
- DeFi를 통해 예치/대출하는 사람들이 본인들이 사용하는 서비스와 코드에 대한 실질적 risk와 benefit을 정확히 이해하고 서비스를 이용하는 것이기를 바란다. 결국 투자는 본인의 몫이고 책임이다. 그런 의미에서 나는 내가 직접 audit 하지 않은 DeFi에는 절대 투자하지 않는다. 다들 성투~💰💰💰
