이더리움 백서를 쉽게 이해할 수 있도록 풀어서 설명하는 연재물을 작성하고 있습니다. 지난 포스팅을 읽지 못하셨던분은 먼저 아래의 포스팅을 읽어보시는것을 추천드립니다.
탈 중앙화된 통화 시스템을 유지하기 위해서는 분산 합의 과정이 필요하고, 네트워크가 정상적으로 유지될 수 있도록 도와주는 노드들이 필요하며, 이 노드들은 "블록(blocks)"이라 불리는 트랜잭션 패키지를 계속적으로 생성하고 합의하는 역할을 수행해야합니다.
작업 증명의 목적은 블록 생성을 계산적으로 어렵게 만들어서 sybile 공격자들이 마음대로 전체 블록체인을 조작하는 것을 방지 하기 위함이며, 네트워크는 평균적으로 10분마다 새로운 블록이 생성될 수 있도록 2016개의 블록마다 목표 값을 변경하게 됩니다.
채굴자는 이러한 연산 작업에 대한 보상으로 BTC를 획득하고, BTC를 획득하기 위하여 선의의 경쟁을 하게됩니다. 네트워크에 참여하는 노드가, 다양하고 많을수록 51% 공격과 같은 악의적인 사용자의 공격을 막아낼 수 있기 때문에 네트워크의 신뢰로가 향상될 수 있습니다.
블록 헤더는 200 바이트 정도의 데이터로, 타임 스탬프, 논스(nonce), 이전 블록 해시, 그리고 머클트리(Merkle tree)의 루트 해시 정보가 들어있습니다. 머클 트리는 이진트리(binary tree)의 일종으로 하나의 루트 노드의 집합입니다.
머클 트리의 목적은 어떤 블록의 데이터가 분리돼서 전달 될 수 있도록 하는것이며, 블록의 용량을 효율적으로 활용하수 있는 데이터 구조를 가지고 있습니다. 해시 함수의 특징으로 머클 트리 하위 노드들의 해시 값은 상위 노드에 영향을 주며, 어떤 악의적인 유저가 머클 트리 최하위에 있는 트랜잭션 정보를 가짜로 바꿔치기 하면 상위 부모들의 해시 값이 변경되고, 머클 루트 값 또한 변경됩니다. 머클 루트 정보가 변경될 경우 블록 해시 정보 또한 변경되어 해당 블록은 기존의 블록과 전혀 다른 블록으로 인식됩니다.
[출처 : 이더리움 백서(링크)]
위의 왼쪽 그림의 최하위 노드의 트랜잭션 정보를 살펴보면, Alice가 Bob에게 20 BTC를 보낸다는 트랜잭션 정보입니다. 그런데 만약 오른쪽의 그림과 같이 Alice가 Eve에게 20 BTC를 전송한다는 내용으로 트랜잭션 정보를 변경할 경우 상위 노드들의 정보가 변경되어 그림과 같은 오류가 발생하게됩니다.
머클트리 프로토콜은 비트코인 네트워크를 지속 가능하게 만드는 기초가됩니다. 비트코인 네트워크의 각 블록의 모든 정보를 처리하는 풀 노드(full noe)는 2014년 4월 기준으로 15GB의 디스크 저장 공간이 필요하며, 매달 1 GB 넘게 데이터가 증가하고 있습니다. 이 수치는 데스크탑 컴퓨터 정도에서는 수용할 수 있지만, 스마트폰에서는 불가능합니다. 아주 먼 미래에는 데이터의 용량문제로 인해 소수의 사업체들이나 풀 노드를 유지할 수 있을 것입니다.
스마트폰과 같이 저장 공간의 한계가 있는 디바이스에서는 단순화된 지불검증(simplified payment verification, SPV) 프로토콜을 활용하여 가벼운 노드(light node)가 운영될 수 있습니다. light node는 블록 헤더를 다운로드하고, 그 블록 헤더 정보를 토대로 작업증명을 검증하게 됩니다. 풀 노드와 달리, "곁가지들(branches)"만을 다운로드 하며, 이는 전체 블록체인의 매우 작은 비율만을 다운로드한 것입니다. 그럼에도 불구하고 강한 안정성을 보장 받을 수 있으며, 임의의 트랜잭션의 상태 및 잔고 상태를 확인할 수 있습니다.
1998년 "Nick Szabo"는 소유주 권한을 통한 재산권 보장(secure property titles with owner authority) 글을 발표 했습니다. 발표된 내용은 땅의 소유권의 등기 문제를 블록체인 기반 시스템으로 처리할 수 있다는 내용입니다. 하지만 그 당시에는 효과적인 파일 복제 시스템이 없었기때문에 Nick Szabo의 프로토콜은 구현되지 못했습니다. 하지만 2009년 이후 비트코인 분권 합의 시스템이 발전하면서 수 많은 응용 사례가 빠르게 부각되기 시작하였습니다.
.bit로 끝나며, DNS 주소 등록과, 거래 정보의 익명성을 보장합니다. 이러한 네임코인은 인터넷 주소를 관리하며, 네트워크에 참여한 노드의 컴퓨터 자원을 활용하여 인터넷 주소를 관리하고 보상으로 코인을 지급하고 있습니다.일반적으로 합의 프로토콜을 개발하기 위한 방법은 두 가지 접근 방법이 있으며, 하나는 독립적인 네트워크를 만들어내는것이며, 또 다른 하나는 비트코인 시스템과 연동되는 새로운 프로토콜을 만들어내는것입니다.
전자의 접근 방법은 네임코인과 같은 응용 사례에서 상당히 성공적이었지만, 실제 개발하기에는 어려움이 있습니다. 상태 변환과 네트워킹 코드를 개발하고, 점검해야 할 뿐만 아니라 독립적인 블록체인을 구동 시켜야 하며, 나아가 분권 합의 기술에 관한 어플리케이션의 집합이 멱함수분포를 따를 것으로 예상됩니다. 즉, 대다수의 어플리케이션은 자기 자신의 블록체인을 보장하기에는 너무 작을 것이고, 서로 교류를 하기 위한 분권화된 자율 기구(DAO)가 생겨날 것이라고 예상됩니다.
후자의 접근 장법은 비트코인에 기반한 접근 방법입니다. 비트코인은 블록체인 깊이(depth)를 검증 대리 수단으로 이용하여 단순 지불 검증(SPV)을 사용할 수 있지만, 후자의 접근 방법은 SPV 특징을 사용하지 못하는 단점이 있습니다. 메타 프로토콜은 무효 거래가 블록체인에 포함되지 않도록 막을 방법이 자기 자신의 프로토콜 자체에는 없습니다. 그렇기 때문에 안전을 보장하기 윟나 단순지불검증 메타-프로토콜이라면, 어떤 거래가 유효한지 아닌지를 결정하기 위해 항상 비트코인 블록체인의 원점까지 돌아가 확인하는 작업이 필요합니다. 현재까지 비트코인을 기반한 메타-프로토콜의 모든 라이트(light) 클라이언트 구현은 믿을만한 서버에 의지하는 형편입니다. 우리가 암호화폐를 만든 가장 중요한 목적이 제 3자의 신용기구의 필요성을 없애는 것이었다는걸 특히 되새겨본다면, 이것은 아주 분명하게도, 차선의 결과가 될 뿐입니다.
오늘은 이렇게 이더리움 백서 도입부에 기록된, 머클트리와 블록체인 기술을 이용한 다른 응용 사례에 대한 내용을 다뤄봤습니다. 오늘 학습한 이더리움 백서의 내용은 블록체인 기술을 활용한 시스템을 만들기에는 많은 비용이 발생하고, 개발적 난제들이 있다는 사실을 부각한것 같습니다. 그리고 기존의 블록체인 활용방법은 비트코인에 의지하였고, 비트코인에 의지할 경우 라이트 노드를 만들기 어렵다는 문제점을 제기하며, 이더리움에서는 어떻게 이 방법을 해결할것인지에 대한 내용이 나올것으로 예상됩니다.
이번편을 이해하기 위해서는 비트코인 시스템에서 활용된 머클 트리와, 블록 해시, 그리고 노드에 대한 개념정리가 필요합니다. 자세한 정보를 원하시는분들은 이전에 제가 작성한 포스팅 자료를 참조하시면 좋을것 같습니다.
백서의 내용중 설명이 조금 부족했던, 네임 코인, 컬러드 코인, 메타코인에 대한 자세한 정보를 원하시는 분들을 위해 자료를 모아봤습니다. 네임코인은 
피넥터 보고서, 블록체인 기술의 발전과정과 이해 자료의 자산 발행기술 챕터(25 Page)에 명시되어 있습니다. (추후 시간이 허락된다면 네임 코인, 컬러드 코인, 메타 코인에 대한 자료를 모두 취합하여 하나의 포스팅으로 만들보도록하겠습니다.)
다음 포스팅에서는 비트코인의 스크립트 부분에 대한 포스팅을 할 계획이며, 그 다음 포스팅인 이더리움 백서 5편에서는 본격적인 이더리움에 대한 설명으로 이어질것 같습니다. 혹시나 이더리움 백서를 먼저 읽고 싶으신분은 아래의 링크를 통해 백서를 먼저 확인해보셔도 좋을것 같습니다.
이상 긴 글 읽어주셔서 감사합니다!(보팅, 리스팀, 팔로워는 제게 큰 힘이됩니다!)
[참고문헌]