Decred 소개

국내에는 많이 알려져 있지 않지만 비트코인 초기 개발자들이 모여 만든 Decred라는 암호화폐가 있습니다.

Decred는 비트코인 Go 언어 구현체인 btcd를 포크하여 만들었는데, 비트코인과 달리 민주적인 운영 방법(governance)에 대한 고려가 프로토콜에 반영되어 있는 점이 특징입니다.

마이닝의 중앙화를 막기 위해 PoW와 PoS를 결합한 하이브리도 방식의 합의 알고리즘을 사용하고 있습니다. 여기서 PoS는 트랜잭션을 validate하여 보상을 받는 역할뿐만 아니라 프로젝트의 방향성을 결정하는 투표의 역할도 병행합니다.

보상의 60%는 PoW 마이너, 30%는 PoS 투표자, 10%는 개발팀에 갑니다. Decred 개발 팀 외에도 외부에서 제안을 내고 그 제안이 통과되면 직접 펀딩을 받을 수도 있습니다.

이 외에도 기술적으로는 on-chain atomic swap을 구현하는 등 비트코인에 비해 비교적 새로운 아이디어를 많이 시도하고 있기 때문에 비트코인에 관심 있는 개발자라면 한 번 살펴보시길 권합니다.

비트코인 공부의 정석

개발자가 비트코인 공부하려면 뭐부터 봐야 하는지 물어보는 분이 많이 계셔서 정리해 보았습니다.

일단 비트코인 입문자에게 추천 드리는 강의는 Coursera의 Bitcoin and Cryptocurrency Technologies입니다. 암호화폐 기초 개념 및 동작 원리를 잘 설명하고 있습니다.
https://www.coursera.org/learn/cryptocurrency

강의와 함께 보시면 좋은 책으로는 Mastering Bitcoin 있습니다.
https://www.bitcoinbook.info/

비트코인의 개념을 어느 정도 잡았으면 사토시 나카모토가 작성한 비트코인 논문도 꼭 읽어보시기 바랍니다. 9페이지 짧은 논문이지만 비트코인의 등장 배경과 동작 원리를 그 어느 문서보다 명료하게 설명하고 있습니다.
https://bitcoin.org/bitcoin.pdf

비트코인의 동작 원리는 알았고 구현 세부사항을 알고 싶으신 분은 Bitcoin Developer Guide을 추천 드립니다. 공식 매뉴얼이라 조금 따분하긴 하지만 다른 어느 문서보다 기술 세부사항을 자세히 설명하고 있습니다.
https://bitcoin.org/en/developer-guide

비트코인은 따로 스펙이 없고 Bitcoin Core 소스 코드를 스펙으로 하고 있습니다. 개발자 가이드에서 확인할 수 없는 코너 케이스는 소스 코드를 직접 확인할 수 밖에 없으니 다른 문서를 찾아 헤매지 말고 소스 코드를 공부하시면 됩니다.
https://bitcoin.org/en/bitcoin-core/

Bitcoin Core는 C++로 작성되어 있고 레거시 코드가 많다 보니 처음 보시는 분들이 이해하기에 조금 어려울 수 있습니다. 비트코인 공부의 시행착오를 줄이고 싶으신 분에게는 코드체인 에듀가 제공하는 “비트코인 프로그래밍 입문”을 추천드립니다! 비트코인 기초부터 구현까지 친절하게 안내해 드립니다.

http://edu.codechain.io/course/5

비트코인 머클 트리 알고리즘의 취약점과 우회방안

비트코인 마이너는 블록에 포함될 트랜잭션들의 머클 루트를 계산하여 블록 헤더에 넣고 블록을 생성합니다. 다른 비트코인 풀 노드들은 블록 헤더의 머클 루트가 스스로 계산한 머클 루트와 같은지 비교하여 해당 블록의 유효성을 검사합니다.

머클 루트는 세부적인 구현에서 약간씩 차이가 나는데, 비트코인은 각 라운드의 해시가 홀수 개이면 마지막 해시를 한 번 중복해서 넣는 방식으로 짝수로 만들고 계산을 합니다. 일례로 1 2 3 해시의 머클 루트를 계산하기 위해서는 1 2 해시를 합쳐서 A를 만들고 남은 해시가 홀수 개니 3을 하나 더 추가해서 3 3 해시를 합쳐서 B를 만드는 방식입니다. 그런 다음 A B를 합쳐서 해시를 계산하면 머클 루트가 나옵니다.

그런데 이런 방식으로 머클 루트를 만들면 트랜잭션을 중복해서 넣는 방식으로 머클 루트가 같은 블록을 쉽게 만들어 낼 수 있는 문제가 있습니다. 예를 들어, 아래 그림처럼 1 2 3 4 5 6 해시의 머클 루트가 A라고 하면 5 6해시를 중복해서 한 번 더 넣은 1 2 3 4 5 6 5 6의 머클 루트도 A가 됩니다. 다음 라운드에서 F가 하나인 것과 F가 두 개인 것이 해시 값이 C로 동일하기 때문입니다.

누군가가 고의로 머클 루트는 같지만 validation이 실패하는 블록을 고의로 보내게 되면, 이 블록을 받은 노드는 이후 정상적인 블록을을 invalid하다고 판단하게 되므로 심각한 DoS 공격이 가능해집니다.

비트코인 이 문제를 인지하고 해시 목록의 마지막에 두 개의 동일한 해시가 나오는 경우를 머클 루트가 invalid한 것과 동일하게 취급하는 방법으로 우회하고 있습니다. (호환성 때문에 머클 트리 알고리즘을 바꿀 수는 없었습니다.) 1 2 3 4 5 6 5 6의 경우 해시를 계산하고 나면 D E F F가 나오는데 마지막에 F가 2번 나오므로 invalid하다고 판단하는 방식입니다.

이는 머클 트리 구현 편의를 위해 선택한 간단한 구현 세부사항이 어떤 식으로 보안 문제를 일으킬 수 있는지를 보여주는 아주 좋은 예입니다. 참고로 이 문제는 CVE-2012-2459로 리포트되어 있습니다.

비트코인 코어 지갑의 UTXO 사용법

Bitcoin Core 지갑이 UTXO를 어떤 로직에 따라 사용하는지 궁금해서 찾아봤습니다.

  1. 하나의 UTXO가 사용할 금액(타겟)을 정확히 만족시키면 해당 UTXO를 사용.

  2. 타겟보다 작은 여러 개의 UTXO의 총합이 타겟을 정확히 만족시키면 해당 UTXO들을 사용.

  3. 타겟보다 작은 여러 개의 UTXO의 총합이 타겟보다 작으면 타겟보다 큰 UTXO 중에 가장 작은 UTXO를 사용.

  4. 랜덤하게 선택한 UTXO들 조합의 총합이 타겟과 같거나 클때까지 1000번 시도. 총합이 타겟을 정확히 만족시키면 즉시 종료.

  5. (1) 타겟보다 큰 UTXO 중 가장 작은 UTXO
    (2) 4번에서 찾은 UTXO 조합 중 총합이 가장 작은 조합.
    (1), (2)를 비교해서 작은 쪽을 선택

Bitcoin Core 지갑은 아웃풋 크기를 최소화하는 방법으로 최적화되어 있는 걸 알 수 있습니다.

물론 이 방법이 항상 정답은 아닙니다. 지갑을 만드는 엔지니어가 UTXO 아웃풋 크기, 성능, 보안 등 어떤 면을 강조하느냐에 따라 다양한 알고리즘이 가능한 영역입니다.

관련 코드는 Bitcoin Core 코드에서 확인 가능합니다.

스마트 컨트랙트 개발자의 특성과 커리어

스마트 컨트랙트 개발자의 특성과 커리어에 대해 잘 정리한 글이 있어서 공유합니다.

  • 1년 이하의 개발자의 연봉도 무척 높다. 스마트 컨트랙트를 2년 이상한 개발자는 이미 너무 부자라서 고용 시장에는 없다. 다만, 현재 투자 열풍과 ICO 붐이 꺼진 후에는 거품이 꺼질 수 있다.
  • 스마트 컨트랙트 개발자가 되기 위해 암호학, 게임 이론, 프로토콜 설계, 분산 시스템 등을 다 이해해야 하는 것이 아니다. 웹 개발자가 HTTPS나 TCP/IP가 어떻게 동작하는지 알 필요가 없는 것과 마찬가지다.
  • 기술 자체는 어렵지 않지만, 작은 문제를 하나 해결하기 위해 많은 수고를 할 각오를 해야 한다. 문서도 없고 스택오버플로에 제대로 답변도 없고, 언어나 개발 도구 등도 모두 아직 성숙하지 않은 상태이기 때문이다.
  • 출시하기 전에 검증 및 테스트를 엄격하게 해야 한다는 측면에서 소프트웨어 개발보다는 하드웨어 개발과 유사한 점이 있다.

 

DAML

Hypledger Fabric이나 R3 Corda 같은 permissioned blockchain은 public blochcain과 달리 스마트 컨트랙트 작성에 Go, Java, Kotlin 같은 범용 언어를 사용합니다.

인증 서버를 통해 인증된 노드만 네트워크에 접속할 수 있기 때문에 이더리움처럼 Gas를 사용해 프로그램의 종료를 보장하거나 하는 방법은 사용하지 않는 게 일반적입니다. 일례로, Fabric의 스마트 콘트랙트를 chaincode라고 부르는데, 일반적인 Go 바이너리를 가공 없이 그대로 사용합니다.

하지만, 꼭 악의적인 의도로 작성된 스마트 콘트랙트가 아니더라도 버그 때문에 이상 동작을 할 수 있고 이를 제대로 검증하지 못하면 심각한 문제가 발생한다는 사실은 public blockchain이나 permissioned blockchain가 차이가 없습니다.

이 문제를 해결하기 위해 permissioned blockchain을 만드는 일부 업체는 스마트 컨트랙트 작성을 위한 새로운 언어를 제공하는 경우도 있습니다. 대표적인 예로, permissioned blockchain을 만드는 디지털 애셋(Digital Asset)이 있는데, 작년 금융사를 위한 DSL을 만들던 스위스 기반의 Elevence 사를 인수하였습니다.

Elevence 사가 만들던 기술은 DAML이라는 디지털 자산 모델링 언어인데, Solidity와는 달리 Turing-complete 하지 않은 언어입니다. 오픈소스 계획을 밝혔지만 아직 소스 코드가 공개되지 않아 자세한 내용은 알 수 없지만 하스켈 스타일의 total functional programming 언어로 알려져 있습니다.

public blockchain에서는 Solidity가 디팩토 표준이 되어가고 있지만, 기술적으로는 훨씬 나은 방법이 존재하고 실제로 사용되는 예가 있다는 말씀을 드리고 싶었습니다. 물론 하스켈 계열의 언어들은 진입 장벽이 높긴 하지만, Solidity로 버그 없는 스마트 컨트랙트를 작성하기 위해 들여야 하는 노력을 생각하면 어느 쪽이 실제로 더 비용이 높은지 알기 어렵습니다.

이더리움 스마트 컨트랙 언어

이더리움은 제한된 일밖에 할 수 없는 비트코인 스크립트 언어와 달리 Turing-complete한 VM을 제공하는 것이 큰 특징입니다. 전산 전공이 아닌 분들은 complete라는 단어의 어감 때문에 막연히 어떤 계산이든 할 수 있는 강력한 언어 혹은 VM이라고 생각할 가능성이 큰데, Turing-complete한 언어는 강력한만큼 보장되는 것이 없는 언어이기도 합니다.

대표적인 예로 halting problem이 있습니다. computability theory에서 halting problem은 어떤 프로그램의 종료 여부를 실행 전에 알 수 있는지를 묻는 것인데, Turing complete한 언어는 종료 여부가 undecidable합니다.

이 문제는 생각보다 심각합니다. 어떤 스마트 컨트랙트를 종료되지 않고 무한히 실행되는 상태로 만들 수 있으면 이더리움 네트워크에 대한 DoS(Denial of Service) 공격이 가능하게 되고, 이더리움 네트워크의 가용성을 해칠 수 있기 때문입니다.

그래서 이더리움은 가스라는 개념을 만들고 각 EVM 바이트코드에 가스비를 부과하여 트랜잭션에 지정된 가스가 다 소진되면 Out of Gas 에러를 던지는 cost semantic을 만들었습니다.

바꿔 말해, 이더리움이 실제로 원했던 것은 종료 여부를 알 수 없는 Turing-complete한 언어가 아니라 종료를 보장 혹은 증명할 수 있는 total program이었던 셈입니다. 다만, 이미 탄탄한 이론적 배경이 있는 total functional programming이 아닌 Gas라는 adhoc한 방법을 사용한 것이 차이점입니다.

하지만 단순 종료 보장 정도로는 충분치 않습니다. correctness가 생명인 스마트 컨트랙트의 특성상 “specification”과 “implementation”이 같다는 걸 증명할 방법이 필요하기 때문입니다. 하지만 자바스크립트를 차용한 스마크 컨트랙트 언어 Solidity에서는 이것도 쉽지 않습니다. 여기에 Gas를 소모하는 EVM의 cost semantic이 결합되면서 온갖 종류의 버그가 나올 수 있는 최악의 프로그래밍 환경이 되었습니다.

이 문제를 해결하는 방법으로 많은 스마트 컨트랙트 프로젝트가 코드 리뷰를 크라우드-소싱하는 방법을 택했습니다. GitHub에 소스 코드를 올리고 스마트 컨트랙트 코드에 대한 동료 리뷰, 감사를 요청하는 방식입니다. 이미 코드 감사만 전문으로 수행하는 컨설턴시가 생기고 있고, 코드 감사를 크라우드-소싱하는 코드 감사 플랫폼에 개발이 진행되고 있습니다. 많은 돈이 걸려있는 만큼 관련 산업도 빠르게 발전하고 있습니다.

지난 수십 년간 연구된 프로그래밍 언어 이론, 검증 기술 등이 이미 존재하지만, 안타깝게도 이더리움의 인기를 등에 업은 EVM 기반의 언어가 당분간 스마트 컨트랙트의 주류 언어가 될 가능성이 매우 높습니다. 이미 Solidity는 다른 언어에 비해 우월한 지위를 누리고 있습니다. 분산 어플리케이션을 만들고 ICO을 통해 수백, 수천억원을 조달할 수 있는 상황에서 아무도 주목하지 않은 인프라 기술에 투자할 회사는 드물기 때문에 이런 상황은 쉽게 바뀌지 않을 겁니다.

앞으로 많은 개발자들이 애증을 가질 또 하나의 언어가 생겼습니다.