이더리움(Ethereum)의 역사
이더리움은 '이더'라고도 하며 화폐 단위는 'ETH'이다. 비트코인 이후 등장한 가장 큰 알트코인으로 비트코인 다음의 가치를 지닌 암호화폐이다. 이더리움은 블록체인 기술을 기반으로 스마트컨트랙트 기능을 구현하기 위해 만들어졌다. 이번 포스팅은 차세대 스마트 컨트랙트와 탈중앙화된 어플리케이션 플랫폼 '이더리움(Ethereum)' 백서에서 발췌한 이더리움의 역사부분을 정리했다. 해당 백서는 이더리움의 창시자인 비탈릭 부테릭(Vitalik Buterin)에 의해 작성되었다.
개요
사토시 나카모토에 의해 2009년 개발된 비트코인은 종종 화폐와 통화분야에서 매우 근본적인 혁신으로 묘사되어 왔는데, 이것은 비트코인이 어떤 담보나 내재적인 가치를 가지지 않으며, 중앙화된 발행기관이나 통제기관도 없는 디지털 자산의 첫 번째 사례였기 때문이다. 하지만 비트코인 실험의 더욱 중요한 측면은 비트코인을 떠받치고 있는 분산 합의 수단으로서의 블록체인 기술이며, 이에 대한 관심이 급격하게 늘어나고 있다.
블록체인 기술을 이용한 대안적 어플리케이션들에는 다음과 같은 것들이 자주 거론되고 있다. 사용자 정의 화폐와 금융상품을 블록체인 위에 표현하는 컬러드 코인(colored coins), 물리적 대상의 소유권을 표현하는 스마트 자산(smart property), 도메인 이름과 같은 비동질적 자산을 기록하는 네임코인(namecoin), 임의적인 계약규칙을 구현한 코드에 의해 디지털 자산을 관리하는 좀 더 복잡한 형태의 스마트 컨트랙트(smart contracts), 더 나아가 블록체인을 기반으로 한 탈중앙화된 자율 조직(decentralized autonomous organzations, DAOs) 등이다.
이더리움이 제공하려는 것은 완벽한 튜링완전(turing-complete) 프로그래밍 언어가 심어진 블록체인이다. 이 프로그래밍 언어는, 코딩 된 규칙에 따라 '어떤 상태'를 다르게 변환시키는 기능(arbitrary state transition fuctions)이 포함된 "계약(contracts)"을 유저들이 작성할 수 있게 함으로썬 앞서 설명한 시스템들을 구현 가능하게 할 뿐만 아니라 우리가 아직 상상하지 못한 다른 많은 어플리케이션들도 매우 쉽게 만들 수 있도록 도와줄 것이다.
이더리움을 소개하기 앞서 비트코인과 기존 개념들에 대한 소개를 하겠다.
분산화된 디지털 통화의 개념은, 재산등록 같은 대안 어플리케이션과 마찬가지로 지난 수십 년간 우리 주변에 있었다. 1980~90년대의 익명 e-cash 프로토콜은 주로 'Chaumian blinding'으로 알려진 '로우레벨 암호 알고리즘(cryptographic primitive)'에 기반하였고 개인정보를 강력하게 보호하는 화폐를 제공하였으나 중앙집권적인 중개인에 의존했기 때문에 별다른 주목을 받지 못했다. 1998년 'Wei Dai'의 [b-money](http://www.weidai.com/bmoney.txt)는 분산합의와 계산 퍼즐을 풀게 하는 방식을 통해서 화폐를 발행하게 하는 아이디어를 최초로 제안하였지만 분산 합의를 실제로 어떻게 구현할지에 대한 자세한 방법은 제시하지 못했다. 2005년에 'Hall Finney'는 "재사용 가능한 작업증명(reusable proofs of work)" 개념을 소개했다. 이 시스템은 b-money의 아이디어에 Adam Back의 '계산 난이도 해시캐시 퍼즐(computationally difficult Hashcash puzzles)'을 조합한 것이었다. 그러나 외부의 신뢰를 필요로 하는 컴퓨팅(trusted computing)을 그 기반에 둠으로써, 이상을 구현하는 데에는 또 다시 실패했다. 2009년 '사토시 나카모토'에 의해 처음 실제적으로 구현된 탈중앙화된 화폐는 공개키 암호방식을 통한 소유권 권리를 위해 사용되던 기존의 알고리즘을 '작업 증명(proof of work)'이라고 알려진 합의 알고리즘과 결합함으로써 가능하게 되었다.
작업증명이 기반이 되는 작동방식은 매우 혁신적인 것이었는데, 이것은 두 가지의 문제들을 동시에 해결하기 때문이다. 첫째, 이것은 간단하면서도 상당히 효과적인 합의 알고리즘을 제공해주었다. 즉, 네트워크 상에 있는 모든 '노드(node)'들이 비트코인의 장부상태(state of the Bitcoin ledger)에 일어난 표준 업데이트의 집합(a set of canonical updates)에 공동으로 동의할 수 있도록 해주었다는 것이다. 둘째, 누구나 합의 프로세스에 참여할 수 있도록 허용해줌으로써 합의결정권에 대한 정치적 문제를 해결할 수 있을 뿐만 아니라 동시에 시빌공격(sybil attacks)도 방어해줄 수 있는 메커니즘을 제공했다. 이것은 합의 프로세스에 대한 참여의 조건으로 ‘특정한 리스트에 등록된 주체이어야만 한다’라는 어떤 형식적 장벽대신에, 경제적 장벽 - 각 노드의 결정권의 크기를 그 노드의 계산능력에 직접적으로 비례시키는 방식으로 대체하는 것이었다.
이후로, 지분증명(proof of stake)이라는 새로운 방식의 합의 알고리즘이 등장했는데, 이는 각 노드가 가진 계산능력이 아니라 화폐의 보유량에 따라 각 노드의 결정권 정도를 계산해야 한다는 것이다. 이 두 방식의 상대적인 장점들에 대한 논의는 이 백서에서는 다루지 않겠지만, 두 방법 모두 암호화화폐의 기반으로서 사용될 수 있다는 점은 지적해두고자 한다.
상태변환시스템으로서의 비트코인
상태변환시스템으로서의 비트코인(Bitcoin As A State Transition System)
기술적인 관점에서 보았을 때, 비트코인과 같은 암호화 화폐의 장부는 하나의 상태변환시스템(state transition system)으로 생각해볼 수 있다. 이 시스템은, 현재 모든 비트코인의 소유권 현황으로 이루어진 하나의 "상태(state)"와 이 현재 상태와 트랜잭션을 받아서 그 결과로써 새로운 상태를 출력해주는 "상태변환함수(state transition function)"로 구성되어 있다. 표준 은행 시스템에 비유하자면 상태는 모든 계좌잔고표(balance sheet)이고 트랜잭션은 A 에서 B로 $X 를 송금하라는 요청이며, 상태변환함수에 의해 A의 계좌에서는 $X 가 감소하고 B의 계좌에서는 $X 가 증가한다. 만약 처음에 A의 계좌에 있는 금액이 $X 이하인 경우에는 상태변환함수가 에러를 리턴한다. 이러한 상태변환을 비트코인 장부에서는 다음과 같이 정의할 수 있다.
은행 시스템 예시에서는 다음과 같다.
비트코인에서 "상태(state)"는 생성되었지만 아직 사용되지 ㅇ낳은 모든 코인들의 집합(기술적표현으로는 '소비되지 ㅇ낳은 트랜잭션출력', UTXO(Unspent Transaction Outputs))이다. 각 UTXO 들에는 각자의 코인금액이 표시되어 있고 이 UTXO의 소유자(20byte의 주소로 정의되는 암호화된 공개키(publick key))정보가 들어 있다. 트랜잭션은 하나 이상의 입력(inputs) 및 출력을 포함한다. 각 입력에는 보내는 쪽 지갑주소에서 선택된ㄴ 기존 UTXO에 대한 참조정보와, 해당지갑주소에 대응되는 개인키(private key)가 생성한 암호화된 서명을 담고 있다. 그리고 각 출력들은 상태에 추가될 새로운 UTXO 정보를 가지고 있다.
상태변환함수 APPLY(S,TX) -> S' 는 다음과 같이 정의할 수 있다.
1. TX의 각 입력에 대해 :
* 만약 참조된 UTXO가 'S'에 없다면, 에러를 리턴.
* 만약 서명이 UTXO의 소유자와 매치되지 않으면, 애러를 리턴.
2. 만약 입력에 사용된 UTXO들 금액의 합이 출력 UTXO들 금액의 합보다 작으면, 에러를 리턴.
3. 입력에 사용된 UTXO가 삭제되고 출력 UTXO가 추가된 'S'를 리턴.
여기서 1번의 첫번째 과정은 존재하지 ㅇ낳는 코인이 트랜잭션에 사용되는 것을 막기 위한 것이고 1번의 두번째 과정은 다른 사람의 코인이 트랜잭션에 사용되는 것을 막기 위한 것이다. 위 절차를 실제 비트코인 지불과정에 적용하면 다음과 같다. Alice가 Bob에게 11.7 BTC를 보내고 싶다고 가정하다. 먼저 Alice 지갑주소로부터 표시된 금액의 합이 적어도 11.7 BTC 이상인 UTXO의 집합을 찾는다. 실제 대부분의 경우에는 11.7 BTC를 정확히 바로 선택할 수 없다. Alice의 지갑주소에서 각각 6, 4, 2BTC 가 표시된 3개의 UTXO를 참조할 수 있다고 하자. 이 3개의 UTXO가 트랜잭션의 input이 되고 2개의 output이 생성된다. Output 중 하나는 11.7 BTC가 표시된 새로운 UTXO이며 소유자는 Bob의 지갑주소가 된다. 그리고 다른 하나는 12(6+4+2) - 11.7 = 0.3 BTC의 "잔돈(change)"이 표시된 새로운 UTXO이며 소유자는 Alice 자신의 지갑주소가 된다.
채굴
채굴(Mining)
만일 우리가 위에서 기술한 내용을 신뢰를 기반으로 하는 중앙집권화된 서비스 방식으로 구현하자면 매우 간단일이 될텐데, 왜냐하면 중앙 서버 하드드라이브에 상태변화의 과정을 저장만 하면 되기 때문이다. 그러나 비트코인에서는, 탈중앙화된 통화시스템을 구축하고자 하는 것이며, 이를 위해서는 모든 사람이 수긍할 수 있는 트랜잭션 순서 합의 시스템을 상태변화시스템과 결합해야만 한다. 비트코인의 분산 합의 과정은 네트워크에 "블록(blocks)"이라 불리는 트랜잭션 패키지를 계속적으로 생성하고자 시도하는 노드들을 필요로 한다. 이 네트워크는 약 10 분마다 하나의 블록을 생성하도록 계획되어 있고 각 블록은 타임스탬프, 논스(nonce), 이전 블록에 대한 참조(이전 블록의 해시), 그리고 이전 블록 이후에 발생한 모든 트랜잭션의 목록을 포함한다. 이 과정을 통해서 지속적으로 성장하는 블록체인이 생성되게 되는데, 비트코인 장부의 최신상태(state)를 나타내기 위해 지속적인 업데이트가 이루어진다. 이 체계에서 하나의 블록이 유효한지 아닌지를 확인하기 위한 알고리즘은 다음과 같다. 1. 이 블록에 의해 참조되는 이전 블록이 존재하는지, 유효한지 확인한다. 2. 타임스탬프 값이 이전 블록의 타임스탬프 값보다 크면서 2 시간 이내인지 확인한다. 3. 작업증명(proof of work)이 유효한지 확인한다. 4. `S[0]`를 이전 블록의 마지막 상태(state)가 되도록 설정한다. 5. `TX`를 `n`개의 트랜잭션을 가지는, 블록의 트랜잭션 목록으로 가정한다. 폐구간 `0...n-1`의 모든 i 에 대해, `S[i+1] = APPLY(S[i], TX[i])`집합 중 어느 하나라도 에러를 리턴하면 거짓(false)을 리턴하며 종료한다. 6. 참(true)을 리턴하고, `S[n]`를 이 블록의 마지막 상태로 등록한다.
기본적으로 블록의 각 트랜잭션은 유효한 상태변환을 일으켜야 한다. 여기서 상태가 블록 내에 어떠한 방법으로로 기록되지 않았다는 점에 주목해보자. 상태는 유효성을 검증하는 노드가 매번 계산해서 기억해야 할 완전히 추상적 것(abstraction)인데, 이것은 원시상태(genesis state)부터 해당 블록까지의 모든 트랜잭션을 순차적으로 적용함으로써 계산될 수 있다. 채굴자가 블록에 포함시키는 트랜잭션의 순서에 주목해보자. 만약 어떤 블록에 A 와 B 라는 두 트랜잭션이 있고 B 가 A 의 출력 UTXO 를 소비한다고 하자. 이때 A 가 B 이전의 트랜잭션인 경우 그 블록은 유효하지만, 그렇지 않을 경우 유효하지 않다.
블록 유효성 검증 알고리즘에서 특징적인 부분은 "작업증명(proof of work)"의 조건 즉, 256 비트의 숫자로 표현되는 각 블록의 이중-SHA256 해시값이 동적으로 조정되는 목표값(이더리움 영문 백서를 작성하는 시점에서 대략 2 192)보다 반드시 작아야 된다는 조건이다. 작업증명의 목적은 블록 생성을 계산적으로 어렵게 만들어서 sybil 공격자들이 마음대로 전체 블록체인을 조작하는 것을 방지하는 것이다. SHA256 은 전혀 예측불가능한 유사난수 함수(pseudorandom function)로 설계되었기 때문에 유효 블록을 생성하기 위한 유일한 방법은 블록헤더의 논스(nonce) 값을 계속해서 증가시키면서, 생성되는 새로운 해시값이 위의 조건을 만족하는지 확인하는 과정을 반복하는 것뿐이다.
현재 목표값인 2 192하에서 하나의 유효블록을 발견하기 위해서 평균적으로 2 64번의 시도를 해야만 한다. 일반적으로 이 목표값은 매 2016 개의 블록마다 네트워크에 의해 재조정되어서 네트워크의 현재 노드들이 평균적으로 10 분마다 새로운 블록을 생성할 수 있도록 한다. 이러한 연산작업에 대한 보상으로 현 시점의 각 블록의 채굴자들은 25 BTC 를 획득할 자격을 가진다. 그리고 출력금액보다 입력금액이 큰 트랜잭션이 있다면 그 차액을 "트랜잭션 수수료(transaction fee)"로 얻는다. 이것이 BTC 가 발행되는 유일한 방법이며, 원시상태(genesis state)에는 아무런 코인이 포함되지 않았다.
채굴 목적을 더 잘 이해하기 위해서, 악의적인 공격자가 있을 때 어떤 일이 발생하는지 알아보자. 비트코인 기저를 이루는 암호기법은 안전한 것으로 알려져 있다. 그러므로 공격자는 비트코인 시스템에서 암호기법에 의해 직접 보호되지 않는 부분인 ‘트랜잭션 순서’를 공격 목표로 잡을 것이다. 공격자의 전략은 매우 단순하다.
1. 어떤 상품(가급적이면 바로 전달되는 디지털 상품)을 구매하기 위해 판매자에게 100 BTC 를 지불한다.
2. 상품이 전송되기를 기다린다.
3. 판매자에게 지불한 것과 같은 100 BTC 를 공격자 자신에게 보내는 트랜잭션을 생성한다.(이중지불 시도)
4. 비트코인 네트워크가, 공격자 자신에게 보내는 트랜잭션이 판매자에게 지불하는 트랜잭션보다 먼저 수행된 것으로 인식하도록 한다.
1 번 과정이 발생하고 몇 분 후에 몇몇 채굴자가 그 트랜잭션을 블록에 포함할 것이다. 이 블록 번호를 270000 이라 하자. 대략 1 시간 후에는 이 블록 다음의 체인에 5 개의 블록들이 추가될 것이다. 이 5 개의 블록들은 위 1 번 트랜잭션을 간접적으로 가리킴으로써 "컨펌(confirming)"한다. 이 시점에서 판매자는 지불이 완료된 것으로 판단하고 상품을 전송할 것이다. 디지털 상품으로 가정했으므로 전송은 바로 끝난다. 이제 공격자는 판매자에게 보낸 것과 동일한 100 BTC 를 공격자 자신에게 보내는 다른 트랜잭션을 생성한다. 만약 공격자가 그냥 단순하게 트랜잭션을 시도한다면, 채굴자들이 `APPLY(S,TX)`를 실행하고 이 `TX`는 상태에 더 이상 존재하지 않는 UTXO 를 소비하려 한다는 것을 알아차리므로 이 트랜잭션은 진행되지 않는다. 그러므로 대신에, 같은 부모 블록 269999 을 가리키지만 판매자에게 보낸 것을 대체하는 새로운 트랜잭션이 포함된 다른 버전의 블록 270000 을 채굴함으로서 블록체인 "분기점(fork)"을 생성한다. 이 블록 정보는 원래 것과 다르므로 작업증명(proof of work)이 다시 수행되어야 한다. 그리고 공격자의 새버전 블록 270000 은 기존 270000 과 다른 해시를 가지므로 원래 블록 270001 부터 270005 는 7 공격자의 블록을 가리키지 않는다. 그러므로 원래 체인과 공격자의 새로운 체인은 완전히 분리된다. 이러한 분기점에서 비트코인 네트워크의 규칙은 가장 긴 블록체인을 참으로 인식하는 것이다. 공격자가 자신의 체인에서 혼자 작업을 하는 동안 정당한 채굴자들은 원래의 270005 체인에서 작업할 것이기 때문에 공격자 자신의 체인을 가장 길게 만들기 위해서는 네트워크의 다른 노드들의 계산능력 조합보다 더 큰 계산능력을 가져야 한다.(이를 51% attack 이라 한다.)
머클트리
머클트리(Merkle Trees)
비트코인의 중요한 확장 기능은 블록이 여러 계층 구조(multi-layer data structure)에 저장된다는 것이다. 어떤 블록의 "해시(hash)"란 사실 블록헤더의 해시만을 의미한다. 이 블록헤더에는 타임스탬프, 논스(nonce), 이전 블록 해시, 그리고 블록에 포함된 모든 트랜잭션 정보에 의해 생성되는 Merkle tree 의 루트 해시가 들어있는 200 바이트 정도의 데이터이다. 머클트리(Merkle tree)는 이진트리(binary tree)의 일종으로서 트리의 최하위에 위치하고 기저 데이터가 들어있는 수 많은 잎노드, 자기 자신 바로 하위에 있는 두 자식 노드의 해시로 구성된 중간 노드, 자기 자신 바로 하위에 있는 두 자식 중간노드의 해시로 구성된 트리의 "최상위(top)"에 있는 하나의 루트 노드의 집합이다. 머클트리(Merkle tree)의 목적은 어떤 블록의 데이터가 분리돼서 전달될 수 있도록 하는 것이다. 만약에 비트코인의 어떤 노드가 한 소스로부터 블록헤더만을 다운로드 받고, 이 블록헤더와 관계된 트랜잭션 정보는 다른 소스로부터 다운받아도 이 데이터들이 여전히 정확하다는 것이 보장된다. 이것이 가능한 이유는 머클트리(Merkle tree)에서 하위 노드들의 해시값이 상위 노드에 영향을 주기 때문에 어떤 악의적인 유저가 머클트리 최하위에 있는 트랜잭션 정보를 가짜로 바꿔치기 하면 상위 부모들의 해시값들이 변해서 결국 트리의 루트값이 바뀌므로, 결과적으로 이 블록의 해시가 달라지기 때문이다. 이렇게 되면 이 블록은 완전히 다른 블록으로 인식되게 되며, 이것은 유효하지 않은 작업증명을 가지고 있게 될 것이 확실시된다.
머클트리 프로토콜은 비트코인 네트워크를 장기간 지속가능하게 만드는 기초가 된다. 비트코인 네트워크에서 각 블록의 모든 정보를 저장하고 처리하는 "완전노드(full node)"는 2014 년 4 월 기준으로 거의 15 GB 의 디스크 공간을 8 필요로 하며 매달 1 GB 넘게 증가하고 있다. 현재 데스크탑 컴퓨터 정도에서는 수용할 수 있지만 스마트폰에서는 불가능하다. 그리고 나중에는 소수의 사업체들이나 풀 노드를 유지할 수 있을 것이다. 반면 "단순화된 지불확인(simplified payment verification, SPV)"으로 알려진 프로토콜은 "가벼운 노드(light node)"라고 불리는 또 다른 형태의 노드를 가능하게 해준다. 가벼운 노드는 블록헤더를 다운로드하고 그 블록헤더에서 작업증명을 검증한다. 그리고 관련 트랜잭션들에 대한 "곁가지들(branches)"만을 다운로드 한다. 이렇게 전체 블록체인의 매우 작은 비율만을 다운로드 함에도 불구하고 강한 안전성을 보장하면서도, 임의의 트랜잭션의 상태 및 잔고 상태를 알아낼 수 있게 한다.
블록체인 기술을 이용한 다른 응용 사례
블록체인 기술을 이용한 다른 응용 사례 (Alternative Blockchain Applications)
블록체인의 근본 아이디어를 확장해 다른 개념으로 응용하려는 아이디어 역시 오랜 역사를 가지고 있다. 2005 년 ‘Nick Szabo’)는 "소유주 권한을 통한 재산권 보장"이라는 글을 발표했다. 그는 정주(homesteading), 불법점유, 지공주의(Georgism) 등의 개념을 포함한 정교한 틀을 설계해 누가 어떤 땅을 가지고 있느냐라는 등기 문제를 블록체인 기반 시스템으로 처리할 수 있음을 보였다. 그는 이것이 "데이터베이스 복제 기술의 새로운 발전"덕분에 가능해졌다고 말했다. 하지만, 불행히도 그 당시에는 쓸만한 효과적인 파일 복제 시스템이 없었다. 그래서 Nick Szabo 의 프로토콜은 실현되지 못했다. 하지만 2009 년 이후, 비트코인 분권 합의 시스템이 발전하면서, 수 많은 대안 응용 사례가 빠르게 부각되기 시작했다.
* 네임코인 - 2010 년에 만들어진 네임코인은 '탈중앙화된 명칭 등록 데이터베이스'라고 부르는 것이 가장 좋을 것이다. 토르, 비트코인, 비트메시지와 같은 탈중앙화된 자율조직 프로토콜을 이용할 때, 사용자는 타인과 서로 교류하기 위해 각자의 계정을 구분해내야 한다. 하지만 현존하는 가능한 구별 방법은 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy 와 같은 식의 의사난수 해쉬를 이용하는 방식이었다. 이상적으로는, 사용자가 "george"같은 일상적인 이름을 계정 이름으로 갖는 것이 좋을 것이다. 하지만 이 때 문제는 어떤 사용자가 "george" 라는 이름을 계정을 만들수 있다면, 다른 누구도 똑같이 "george"라는 계정을 등록해 흉내낼 수 있다는 점이다. 유일한 해답은 선출원주의로, 먼저 등록한 사람이 성공하고 두 번째 등록한 사람은 실패하도록 하는 것이다. 이는 이미 비트코인 합의 규약에 완벽히 적용된 문제이기도 하다. 네임코인은 이런 아이디어를 응용한 가장 오래되고 가장 성공적인 명칭 등록 시스템이다.
* 컬러드 코인- 컬러드 코인의 목적은 누구나 비트코인 블록체인 위에서 자신만의 고유한 디지털 화폐를 발행할 수 있는 프로토콜 역할을 하는 것이다. 또는 (그 디지털 화폐의 발행량이 한 단위 밖에 없는 단순한 경우로 볼 수 있는) 자기 자신만의 디지털 토큰을 발행하는 프로토콜 역할을 하는 것이다. 컬러드 코인 프로토콜에서, 사용자는 특정 비트코인 UTXO 에 공개적으로 색깔을 부여함으로써 새 화폐를 "발행"할 수 있다. 다른 UTXO 의 색깔은 이미 소비된(혼합 색깔 입력의 경우에는 몇몇 특별한 규칙이 적용된다) 것으로 간주하는 거래의 입력과 같은 색깔이 되도록 재귀적으로 정의한다. 이 프로토콜은 블록체인을 처음부터 끝까지 역추적해 그들이받은 UTXO 의 색깔을 정함으로써, 사용자가 특정 색깔을 가진 UTXO 만 지갑에 간직하고 그 코인을 보통 비트코인처럼 여기저기 보낼 수 있게 한다.
* 메타코인- 메타코인이 품고 있는 아이디어는, 비트코인 거래를 메타코인 거래 저장에 이용하되, 상태 이동 함수 APPLY' 를 다르게 가짐으로써, 비트코인 시스템 위에서 운영되는 프로토콜을 갖는 것이다. 메타코인 프로토콜만으로는 비트코인 블록체인 속에 무효 메타코인 거래가 나타나는 현상을 예방 수 없기 때문에, 규칙이 하나 더해진다. 즉 만약 APPLY'(S, TX)가 에러를 리턴하면, 프로토콜은 APPLY'(S,TX)=S 로 정해진다. 비트코인 스스로는 내부 실행이 불가능한, 잠재적으로 더 발전된 성질을 가진 무작위 암호화폐 프로토콜을 만드는 쉬운 메커니즘이라고 9 할 수 있다. 반면 이 프로토콜의 개발비용은 적은데 왜냐하면 채굴과 네트워킹의 복잡성 문제가 이미 비트코인 프로토콜에 의해 처리되고 있기 때문이다.
일반적으로 합의 프로토콜을 건설하는 데 두 가지 접근방법이 있다. 하나는 독립적인 네트워크를 세우는 것이고 다른 하나는 비트코인 시스템과 연동되는 프로토콜을 세우는 것이다. 전자의 접근 방법은, 네임코인 같은 응용 사례에서는 상당히 성공적이었지만, 실제 실행하는 데 어려움이 있다; 각 개별 실행주체가 모든 필요한 상태변환과 네트워킹 코드를 건설하고 점검해야 할 뿐만 아니라 독립적인 블록체인을 구동시켜야 한다. 나아가, 분권 합의 기술에 관한 어플리케이션의 집합이 멱함수분포를 따를 것으로 예상된다. 즉, 대다수 어플리케이션은 자기 자신의 블록체인을 보장하기에는 너무 작을 것이다. 그리고 또 거대한 클래스의 분권화된 어플리케이션, 즉 서로 교류를 하기 위한 분권화된 자율 기구(DAO)가 생겨날 것이라고 예상한다.
후자의 접근 방법, 즉, 비트코인에 기반한 접근 방법은 비트코인의 단순 지불 검증(SPV)특징을 물려받지 못한다는 단점이 있다. 단순지불검증은 비트코인에서는 작동한다. 왜냐하면 비트코인은 블록체인 깊이(depth)를 검증 대리 수단으로 이용할 수 있기 때문이다. 한 거래의 근원을 찾아 충분히 뒤로 돌아가보면, 그 상태의 정합성을 증명하는 부분이 있었다고 말해도 무방하다. 반면, 블록체인에 기반한 메타-프로토콜은 무효 거래가 블록체인에 포함되지 않도록 막을 방법이 자기 자신의 프로토콜 자체에는 없다. 그렇기 때문에 완전히 안전보장이 된 단순지불검증 메타프로토콜이라면, 어떤 거래가 유효한지 아닌지를 결정하기위해, 항상 비트코인 블록체인의 원점까지 돌아가 훑어보는 작업이 필요하다. 현재까지 비트코인에 기반한 메타-프로토콜의 모든 "간단한"(light) 클라이언트 구현은 자료를 제공하는 믿을 만한 서버에 의지하고 있는 형편이다. 우리가 암호화폐를 만든 가장 중요한 목적이 제 3 의 신용기구의 필요성을 없애는 것이었다는 걸 특히 되새겨본다면, 이것은 아주 분명하게도, 차선의 결과가 될 뿐이다.
스크립팅
스크립팅(Scripting)
별도의 확장없이도 비트코인 프로토콜은 낮은 수준의 "스마트 계약"의 개념을 가능하게 할 수 있다. 비트코인의 UTXO 는 공개키만으로 획득할 수 있을 뿐만 아니라, 단순 스택-기반 프로그래밍 언어로 표현되는 더 복잡한 스크립트로도 획득할 수 있다. 이런 경우에는, UTXO 를 지출하는 거래는 그 스크립트를 만족하는 데이터를 제공해야만 한다. 사실, 기초적인 공개키 소유권 메커니즘도 스크립트를 통해 실행된다: 그 스크립트는 타원곡선서명을 ‘입력’으로 받아 그 거래와 UTXO 를 가진 주소에 대해 검증을 하고 만약 검증이 성공하면 1 을, 실패하면 0 을 ‘출력’한다. 여러 다른 다양한 사용 사례에 대해 좀 더 복잡한 여러 스크립트들이 있을 수 있다.
예를 들어, 주어진 세 개의 개인 키 가운데 두 개로부터 서명을 받아야만 승인이 되도록 스크립트를 짤 수 있다. 이런 스크립트는 회사 계정, 보안 저축 계정, 상업 공탁 상황 등에 유용하게 쓰일 수 있다. 스크립트는 또한 어떤 계산 문제의 답에 대한 포상금을 지불하는데도 쓰일 수 있다. "만약 당신이 이 액면가의 도기코인 거래를 나에게 보냈다는 SPV 증명을 제공한다면, 이 비트코인 UTXO 는 당신 것이다"라는 식으로 말하는 스크립트를 짤 수도 있다. 즉 근본적으로 탈중앙화된 상호-암호화폐 교환을 가능하게 한다.
하지만 비트코인에 구현된 스크립트 언어는 몇가지 중요한 한계가 있다.
튜링불완전성: 비트코인 스크립트 언어로 할 수 있는 작업이 많긴 하지만, 모든 경우의 프로그래밍을 다 지원하지는 않는다. 특히 while 이나 for 와 같은 순환(loop) 명령 카테고리가 빠져 있다. 순환 명령어를 없앤 이유는 거래 증명을 할 때 무한 순환에 빠지는 것을 막기 위해서였다. 이론적으로는 이건 스크립트 프로그래머가 극복할 수 있는 장애물이기는 하다. .왜냐하면 어떤 순환 명령이든 단순히 하위 코드를 여러 10 차례 if 구문과 함께 반복함으로써 구현이 가능하기 때문이다. 하지만 이것은 아주 공간 비효율적인 프로그램이 된다. 예를 들어 대안 타원곡선서명 알고리즘을 실행하려면 코드 안에 있는 곱셈을 모두 개별적으로 256 번 반복하는 것이 필요하다.
가치 무지: UTXO 스크립트만으로는 인출 액수를 세밀하게 통제할 방법이 없다. 예를 들어, 신탁 계약의 강력한 실용 사례라 할수 있는 헷지 계약을 살펴보자. A 와 B 가 $1000 어치의 BTC 를 공동계좌에 입금했다고 하자. 시간이 지나면 비트코인의 가격이 오를 수가 있다. 두 사람은 30 일 후 자동으로 A 가 $1000 어치 BTC 를 받고 B 는 공동계좌의 나머지 잔액을 받는 그런 계약을 맺고 싶다. 하지만 이 계약은 1BTC 가 미국 달러로 얼마인지 정해줄 제 3 자를 필요로 한다. 만약 이런 계약이 실현가능하다면 지금 현존하는 완전 중앙집권적인 금융 시스템 아래에서도 고도로 발전된 계약 형태라고 볼 수 있다. 하지만 UTXO 는 인출액 전부가 송금되거나 말거나 밖에 선택할 수가 없다. 즉 세부 작은 단위로 나눠질 가능성을 포함할 수 없는 것이다. 위에 예를 든 계약 거래를 실행할 유일한 방법은 변하는 UTXO 의 액면가 단위를 아주 다양하게 양산하고(예를 들어 1 부터 30 까지의 모든 자연수 k 에 대해 2 의 k 승의 1 UTXO 를 만듦) A 가 B 에게 이중에서 필요한 금액에 맞는 것을 선택해서 보내게 하는 방식과 같이 매우 비효율적인 편법을 사용하는 길 뿐이다
상태표현제한: UTXO 가 표현할 수 있는 상태는 사용되었거나 안 되거나 둘 뿐이다. 그렇기 때문에 이 두가지 상태 이외에 다른 어떤 내부적 상태를 가지는 다중 단계 계약이나 스크립트를 만들 수가 없다. 이 점이 분산 환전 거래나 이중 암호 실행 프로토콜(계산 보상금을 보장하기 위해 필요하다)과 같은 다중 조건 계약을 어렵게 한다. 즉 UTXO 은 단순하고 1 회적인 계약에만 이용될 수 있을 뿐, 분산조직과 같은 더 복잡한 "상태적(stateful)" 계약에는 이용될 수 없고 메타프로토콜을 적용하기 어렵게 만든다.
블록체인 무지(Blockchain-blindness): UTXO 는 논스(Nonce), 타임스탬프,이전 블록해시같은 블록체인 자료를 해독하지 못한다. 이 단점으로 인해 스크랩트 언어 속에 잠재적으로 가치있을 무작위성이 빠지게 된다. 그래서 도박이나 여러 다른 분야의 어플리케이션을 만드는 데 한계를 보인다.
정리하자면, 발전된 어플리케이션을 만드는 데 3 가지 접근법이 있다. 첫번째는 독립적인 블록체인을 만드는 것이고 두번째는 비트코인에 이미 내재된 스크립트를 이용하는 것이며, 세번째는 비트코인 상에서 작동되는 메타-규약을 건설하는 것이다. 독립적인 블록체을 쓰면 무한히 자유로운 프로그램을 짤 수 있지만 개발 기간, 초기 셋업 작업, 보안 등의 비용을 치뤄야 한다. 비트코인에 내재된 스크립트를 이용하면 실행이 간단하고 표준화된다는 장점이 있지만, 이용범위가 제한적이다. 메타규약을 쓰는 것은 간단하긴 하지만, 확장성의 결함을 감수해야 한다.
이더리움을 통해 우리는 개발하기도 쉽고 더 강력한 라이트 클라이언트 기능을 가지는 동시에 경제적인 개발 환경과 블록체인 보안을 공유하는 어플리케이션을 만들 수 있는, 대안 프레임워크(alternative framework)를 건설하려고 한다.
참고문헌 및 추가자료
1. Intrinsic value: http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-whybitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/
2. Smart property: https://en.bitcoin.it/wiki/Smart_Property
3. Smart contracts: https://en.bitcoin.it/wiki/Contracts
4. B-money: http://www.weidai.com/bmoney.txt
5. Reusable proofs of work: http://www.finney.org/~hal/rpow/
6. Secure property titles with owner authority: http://szabo.best.vwh.net/securetitle.html
7. Bitcoin whitepaper: http://bitcoin.org/bitcoin.pdf
8. Namecoin: https://namecoin.org/
9. Zooko's triangle: http://en.wikipedia.org/wiki/Zooko's_triangle
10. Colored coins whitepaper: https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1 BE/edit
11. Mastercoin whitepaper: https://github.com/mastercoin-MSC/spec
12. Decentralized autonomous corporations, Bitcoin Magazine:http://bitcoinmagazine.com/7050/bootstrappinga-decentralized-autonomous-corporation-part-i/
13. Simplified payment verification:https://en.bitcoin.it/wiki/Scalability#Simplifiedpaymentverification
14. Merkle trees: http://en.wikipedia.org/wiki/Merkle_tree
15. Patricia trees: http://en.wikipedia.org/wiki/Patricia_tree
16. GHOST: http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full.pdf
17. StorJ and Autonomous Agents, Jeff Garzik: http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoinautonomous-agents.html
18. Mike Hearn on Smart Property at Turing Festival: http://www.youtube.com/watch?v=Pu4PAMFPo5Y
19. Ethereum RLP: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP
20. Ethereum Merkle Patricia trees:https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree
21. Peter Todd on Merkle sum trees:http://sourceforge.net/p/bitcoin/mailman/message/31709140/
'암호화폐' 카테고리의 다른 글
| 비트코인 백서(feat.사토시 나카모토) (0) | 2020.08.10 |
|---|---|
| 이더리움 가격 상승 이유 (feat.이더리움 2.0) (0) | 2020.08.03 |
| 와라코인(WaraCoin) (0) | 2020.07.28 |
| 소다코인(SODA) (0) | 2020.07.28 |
