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을 통해 수백, 수천억원을 조달할 수 있는 상황에서 아무도 주목하지 않은 인프라 기술에 투자할 회사는 드물기 때문에 이런 상황은 쉽게 바뀌지 않을 겁니다.

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

지난 몇 달간 블록체인 기술을 공부하면서 여러 블록체인 ICO 기술 백서를 읽고 몇 개의 ICO에 직접 참여해 보기도 하였습니다.

좋은 ICO와 나쁜 ICO를 구분하는 방법에 정답은 없지만, 소프트웨어 엔지니어 입장에서 최소한의 기준을 이야기해 보려고 합니다.

기술 백서

단순히 기술 백서가 존재하는 것만으로 충분하지 않습니다. 기술 백서의 내용이 명확하고 검증 가능해야 합니다. 많은 프로젝트가 합의 알고리즘의 성능 개선을 말하면서 구현 없이 아이디어와 성능 목표치만 이야기하는데, 성능은 실제로 구현하고 숫자로 증명하지 않는 이상 아이디어만 가지고는 아무 것도 안 한거나 마찬가지입니다.

그럴 듯해 보이는 아이디어도 실제로 구현하면 예상치 못한 이유로 성능이 안 나오는 경우가 많고, 겨우 겨우 성능 목표를 달성해도 버그 투성이 코드가 되거나 유지 보수가 불가등 할 정도로 복잡한 코드가 나오는 경우도 비일비재합니다.

구현해서 검증하지 않은 성능 개선 방법을 대단한 기술처럼 포장해서 보여주는 백서는 그만큼 기술적으로 보여줄 게 없다는 반증입니다. 리눅스 토발즈의 명언을 다시 한 번 인용합니다. “Talk is cheap. Show me the code.”

소스 코드

GitHub에 소스 코드가 공유되어 있어야 합니다. 단순히 코드를 공개한 것만으로는 부족합니다. 소스 코드 공개 후에도 지속적인 활동이 있어야 합니다. 매일 새로운 코드, 이슈, PR이 올라오고 활발한 개발 활동이 일어나야 합니다. 그게 아니라면, 그저 소스 코드가 있다는 걸 보여주기 위한 요식 행위일 가능성이 큽니다.

다른 프로젝트를 포크해서 시작한 프로젝트의 경우, 포크 이전과 이후를 구분해서 포크 이후에 얼마나 수정이 이루어졌는지를 파악해야 합니다. 이미 ICO를 받은 국내의 한 프로젝트는 stellar-core를 포크하여 README만 조금 고친 후에 전혀 개발 활동이 이루어지지 않았습니다. 물론 내부적으로 개발이 이루어지고 있을 수도 있곘지만, 개발 활동을 숨겨야 한다면 뭔가 이유가 있는 거겠죠.

그리고 개발팀에 포함된 개발자들이 실제 개발 활동을 하는지도 확인해야 합니다. 개발팀 명단에 이름만 올려놓고 실제로 개발에 참여하지 않는 개발자들이 생각보다 많습니다. 반대로 상당한 양의 코드를 작성한 개발자가 개발팀에 포함되지 않은 경우도 있습니다. ICO용으로 PoC 코드만 외주를 줬을 가능성도 있고, 개발팀은 개발 역량이 없을 가능성도 의심해야 합니다.

많은 ICO 프로젝트가 ICO 자체를 수익 모델로 하고 있습니다. 그러다 보니 기술 백서, 소스 코드 공개도 요식 행위 수준에서 이루어지고 있습니다. 다른 사람은 몰라도 소프트웨어 엔지니어라면 기술 백서, 소스 코드 존재만 확인하지 말고, 그 내용까지 꼼꼼히 살펴보시고 기본이 튼튼한 프로젝트에 투자하시기 바랍니다.