이더리움 백서

해당 백서는 이더리움 프로젝트가 발표되기(2015) 전, 창시자 비탈릭 부테린에 의해 발간되었습니다(2014). 대다수의 커뮤니티 중심 오픈 소스 소프트웨어 프로젝트와 마찬가지로 이더리움 또한 첫 등장 이후로 지금까지 계속 수정, 개선돼 왔다는 점을 참고 부탁드립니다.

발간된 지 몇 년이 지났음에도, 여전히 이더리움과 그 비전이 정확히 무엇인지에 대한 설명을 제공하고, 또 유용한 참고 문헌이 되기 때문에 우리는 본 백서를 지금도 제공하고 있습니다. 이더리움의 최신 개발 동향과 프로토콜이 어떻게 바뀌었는지에 대해 알고 싶으시다면 본 가이드를 확인하세요.

백서의 정식 원본(2014년 12월 버전)이 필요한 연구자 혹은 학회 분들은 본 PDF를 사용해 주세요.

차세대 스마트 컨트랙트 & 탈중앙화 어플리케이션 플랫폼

사토시 나카모토는 2009년, 흔히 화폐 시스템의 혁명적 발전이라고 인정받고 있는 비트코인을 개발했다. 이는 지지 또는 내재가치(opens in a new tab)가 없는 동시에 중앙화된 발행자 또는 관리자가 없는 디지털 자산의 첫 사례다. 그러나 비트코인에 있어 보다 더 중요하다고 여겨질 수 있었던 또다른 부분은 기술적 배경이었으며, 분산 컨센서스를 위한 도구로써의 블록체인 기술은 곧 세간의 관심을 받게 되었다. 블록체인 기술의 또다른 응용 예시로 종종 인용되는 것들로는 독자적 화폐 및 금융상품(컬러 코인(opens in a new tab)), 실제 기기의 소유권(스마트 프로퍼티(opens in a new tab)), 도메인 이름과 같은 대체불가능 자산(네임코인(opens in a new tab)) 등이 있으며, 더 복잡한 예시로는 임의의 코드가 적용되어 직접 컨트롤되는 디지털 자산(스마트 컨트랙트(opens in a new tab)), 심지어는 블록체인 기반의 탈중앙화 및 자동화된 조직(opens in a new tab)(DAO)도 있다. 이더리움이 제공하고자 하는 것은 "컨트랙트(계약)"를 만드는 데 사용될 수 있는 튜링완전 프로그래밍 언어가 내장된 완성형 블록체인이다. 이 "컨트랙트"에서 사용되는 임의의 상태전환 함수를 통해 사용자들은 위에서 언급된 모든 시스템 뿐 아니라 아직 우리가 모르는 다양한 로직들 또한 몇 줄의 코드를 통해 만들어낼 수 있다.

비트코인 및 기존 개념들에 대한 소개

히스토리

탈중앙화된 디지털 화폐 개념은 부동산 등기소와 같은 대체 응용 프로그램과 마찬가지로 수십 년 동안 존재해왔다. Chaumian Blinding으로 알려진 원시적 암호화 기술에 기반한 1980~90년대 익명 전자화폐 프로토콜은 높은 수준의 프라이버시를 제공했지만, 중앙화된 중개자에게 의존했기 때문에 거래량을 확보하는 것에는 크게 실패했다. 1998년, Wei Dai의 b-머니(opens in a new tab)는 탈중앙화된 합의 뿐만 아니라 계산 퍼즐을 해결함으로써 돈을 만들어내는 아이디어를 처음으로 제시했지만, 실제로 어떻게 탈중앙화를 가능하게 하는지에 대한 자세한 설명은 부족했다. 2005년 Hal Finney는 "재사용 가능한 작업 증명(opens in a new tab)"이라는 개념을 소개했다. 이 시스템은 b-money의 아이디어와 함께 Adam Back의 계산적으로 어려운 해시캐시 퍼즐을 사용하여 암호화폐에 대한 개념을 만들었다. 하지만 신뢰할 수 있는 컴퓨팅을 백엔드로 사용한다는 점에서 한계를 가졌다. 2009년 사토시 나카모토는 공개키 암호화를 기반으로 하는 소유권 관리와 '작업증명'이라고 알려진 소유자 추적을 위한 합의 알고리즘을 결합해 탈중앙화 화폐를 최초로 구현했다.

작업 증명을 가능하게 하는 메커니즘은 혁신이었는데, 이는 두 가지 문제를 동시에 해결했기 때문이다. 첫 번째로, 네트워크를 구성하는 노드들이 비트코인 원장의 상태에 대한 정식 업데이트들에 동의하는 방식의, 간단하고 효과적인 합의 알고리즘을 제공하였다. 두 번째로, 누구나 합의 프로세스의 참여할 수 있게 함으로써 합의 참여자를 결정하는 정치적 문제를 해결하면서도, 동시에 시빌 공격(sybil attacks)을 예방하였다. 이는 특정 리스트에 고유기관으로 등재되어 있어야 한다거나 하는 공식 참여 장벽을 경제 장벽(합의 프로세스에 있어 하나의 노드가 가지는 투표권의 수는 해당 노드가 제공하는 컴퓨팅 파워에 정비례한다는, 즉 돈으로 살 수 있는 컴퓨팅 파워만 있으면 누구나 참여할 수 있다는 뜻이다)으로 대체하였기에 가능하였다. 이후 작업 증명 방식의 대안으로 지분 증명방식이 제안되었는데, 이는 투표권이 컴퓨팅 파워가 아닌 현재의 가상화폐 지분에 비례하도록 하는 방식이다. 각 방식의 장단점 비교는 본 백서에서는 다루지 않으나, 본 두 방식이 각각 암호 화폐의 근간이 될 수 있다는 점은 알아두면 좋을 것이다.

상태 전환 시스템으로써의 비트코인

기술적 관점에서 비트코인과 같은 암호화폐의 원장(ledger)은, 현존하는 모든 비트코인의 소유권을 나타내는 "상태"와, 상태 및 거래를 입력으로 하고 새로운 상태, 즉 결과를 출력으로 하는 "상태전환 함수"로 구성된 상태전환 시스템으로 생각할 수 있다. 일반적인 은행 시스템을 예를 들면, 상태는 대차대조표, 거래는 $X를 A에서 B로 이동하기 위한 요청이며, 이들로 구성된 상태 변환 함수는 A의 계좌에 예치된 금액을 $X만큼 줄이고 B의 계좌에 예치된 금액을 $X만큼 증가시킨다. 만약 A의 계좌에 예치된 금액이 $X 미만이면 상태 변환 함수는 에러를 반환한다. 따라서, 다음와 같이 정의할 수 있다:

APPLY(S,TX) -> S' 또는 ERROR

이를 은행 시스템으로 나타내면 다음과 같다:

APPLY({ Alice: $50, Bob: $50 },"앨리스로부터 밥에게 $20를 보냄") = { Alice: $30, Bob: $70 }

그러나

APPLY({ Alice: $50, Bob: $50 },"앨리스로부터 밥에게 $70달러를 보냄") = ERROR

비트코인의 "상태"는 코인(이론적으로는, "소비되지 않은 거래 출력값" 혹은 UTXO라 불린다)의 집합체를 의미하는데, 이 때 UTXO란 소유자(20byte의 주소로 나타내어지는데, 이는 결국 암호 공개 키^(참고1)이다)와 액면가 정보가 담긴 거래 정보로, 민팅(블록체인에 등록됨)은 되었으나 아직 쓰이지는 않았음을 의미한다. 하나의 거래는 1개 이상의 입력 및 1개 이상의 출력으로 이루어지는데, 각 입력은 현재의 UTXO들 중 하나와 그 소유자 주소의 개인 키로부터 생성된 암호 서명을 포함하며, 각 출력은 "상태"에 추가될 새로운 UTXO를 포함한다.

이 때 상태전환 함수 APPLY(S,TX) -> S' 는 대략적으로 다음과 같이 정의된다.

TX의 각 입력에 대해:
- 참조된 UTXO가 기존 상태 S에 없으면 에러를 반환한다.
- 암호서명이 소유자의 UTXO와 일치하지 않으면 에러를 반환한다.
모든 입력 UTXO의 액면가의 총합이 모든 출력 UTXO의 액면가의 총합보다 낮은 경우 에러를 반환한다.
모든 입력 UTXO가 제거되고 모든 출력 UTXO가 추가된 새로운 상태 S를 반환한다.

1-1단계는 트랜잭션 발송자가 존재하지 않는 코인을 쓰는 것을 방지하고, 1-2단계는 타인의 코인을 쓰는 것을 방지하며, 2단계는 가치의 보존을 강제한다. 위 조건을 실제 지불 과정에 적용해 보면 다음과 같다. 앨리스가 밥에게 11.7 BTC를 보내고 싶어한다고 가정하자. 먼저 앨리스는 자신이 소유하고 있는 UTXO들 중 총합이 최소 11.7BTC이 되는 조합을 찾을 것이다. 실제로, 앨리스는 정확히 11.7 BTC를 얻을 수 없을 것이다; 획득가능한 최소값은 6+4+2=12이다. 그녀는 이제 세 개의 입력과 두 개의 출력으로 이루어진 거래를 생성하게 된다. 첫 번째 출력은 밥의 주소를 소유자로 하는 11.7 BTC가 되고, 두 번째 출력은 나머지 0.3 BTC (거스름돈)이 되며 소유자는 물론 앨리스가 된다.

채굴

만약 우리가 신뢰할 수 있는 중앙화된 서비스에 액세스할 수 있다면, 이 시스템은 구현하기가 매우 쉽다. 거래 상태를 추적하는 중앙화된 서버의 하드 드라이브를 사용하여 설명된 대로 정확하게 간단히 코딩할 수 있다. 하지만 우리의 비트코인은 이를 탈중앙화된 화폐 시스템으로써 구현하고자 하였으며, 참여자 모두가 서로의 거래에 대해 동의하고 신뢰할 수 있도록 하기 위해 위 상태전환함수를 새로운 합의 매커니즘과 결합시킬 필요가 있었다. 비트코인의 탈중앙화된 합의 프로세스는 네트워크 상의 노드들이 "블록"이라고 불리는 거래 패키지 생성을 지속적으로 시도하도록 함으로써 이루어진다. 이 네트워크는 대략 10분마다 하나의 블록을 생성하도록 되어 있으며, 각 블록은 타임스탬프, 논스, 앞선 블록의 해시 정보, 그리고 앞선 블록 이후에 발생한 모든 거래 목록을 담게 된다. 시간이 지남에 따라 블록이 쌓이면서, 비트 코인 원장의 최신 상태를 나타내기 위해 끊임없이 업데이트되는, 지속적으로 성장하는 "블록체인"이 만들어지게 된다.

이러한 맥락에서, 특정 블록이 유효한지를 검증하는 알고리즘은 다음과 같다:

해당 블록이 참조하고 있는 앞선 블록이 실제로 존재하고, 또 유효하다.
타임스탬프는 앞선 블록의 타임스탬프 이후의 시간^{참고 2}을 나타내야 하며, 그 차이는 최대 2시간 이내여야 한다.
해당 블록의 작업 증명이 유효하다.
S[0]은 이전 블록의 마지막 상태이다.
해당 블록이 가진 총 n개의 거래 리스트를 TX라고 한다. 0...n-1의 모든 i에 대하여, S[i+1] = APPLY(S[i],TX[i])를 적용한다. 어플리케이션이 오류를 반환하는 경우 종료하고 거짓을 반환한다.
참을 반환하고, S[n]는 이 블록의 끝에 있는 상태로 등록한다.

중요한 점은, 블록에 포함된 각 거래는 거래가 실행되기 전의 표준 상태에서 새로운 상태로의 유효한 상태 전환을 제공해야 한다는 점이다. 이 때 상태 정보는 블록에 어떠한 형태로도 저장되지 않는다는 점을 기억해야 한다. 상태 정보는 각 검증 노드에 의해 기억되어야 하는 순수한 추상화이며, 모든 블록에 대해 제네시스 상태(발생 상태)에서 시작해 모든 블록의 모든 거래를 순차적으로 적용해야만 (안전하게) 계산할 수 있다. 또한, 채굴자가 거래를 블록에 추가하는 순서 또한 중요하다는 점을 알아 두어야 한다. 블록에 거래 A와 B 두 개가 있어서 B가 A로 인해 생성된 UTXO를 사용한다면, 블록은 A가 B보다 먼저 실행되는 경우 유효하지만 반대 순서로 실행된다면 유효하지 않을 것이다.

여타 시스템에서는 찾을 수 없지만 상기 목록에 존재하는 단 한 개의 유효한 조건은 "작업 증명"에 대한 요구이다. 정확한 조건은, 256비트 숫자로 처리되는 모든 블록의 이중 SHA256 해시 값이 동적으로 조정되는 대상 값보다 반드시 작아야 한다는 것이며, 이 글을 쓰고 있는 현재 그 값은 대략적으로 2¹⁸⁷이다. 이러한 방식의 목적은 블록 생성을 수학적으로 "어렵게" 하는 데 있는데, 이를 통해 시빌 공격자들(sybil attackers)이 전체 블록체인을 본인들에게 유리하도록 새로 만다는 것을 방지하는 것이다. SHA256은 완전히 예측불가능한 랜덤생성 함수이기 때문에, 유효한 블록을 만드는 유일한 방법은 결국 논스(nonce) 값을 증가시키면서 해시 값이 일치하는지 단순 반복하는 것밖에 없다.

현재의 대상 값인 ~2¹⁸⁷의 경우, 네트워크는 유효한 블록을 찾을 때까지 평균적으로 ~2⁶⁹ 번의 시도를 하여야 하며, 일반적으로 이 대상 값은 2016개 블록이 생성될 때마다 네트워크에 의해 재조정되는데, 이로 인해 평균적으로 10분마다 네트워크의 어떤 노드에 의해 새로운 블록이 생성된다. 이러한 연산 작업에 대해 채굴자에게 보상하기 위해 모든 블록의 채굴자에게는 신규 생성된 25 BTC을 받게 되며, 이 또한 하나의 거래로써 블록에 포함되게 된다. 또한, 만약 전체 액면가를 따졌을 때 입력이 출력보다 많다면, 그 차액 또한 채굴자에게 "거래 수수료"로써 제공되게 된다. 참고 사항으로, 이 방법이 BTC이 발행되는 유일한 방법이다. 비트코인의 첫 상태 때는 아무 코인도 존재하지 않았다.

이 채굴의 목적을 보다 더 잘 이해하기 위해, 악의적인 해커가 존재하는 경우를 예로 들어 보겠다. 비트코인의 기반인 암호화 과정 자체는 안전하다는 것이 알려져 있으므로, 해커는 직접적인 암호화를 통해 보호되고는 있지 않은 부분, 즉 거래의 순서를 타겟으로 할 것이다. 해커의 전략은 하기와 같을 것이다:

한 상점에 100 BTC을 결제하고 물건(가능하다면 빠르게 받을 수 있는 디지털 제품)을 산다
해당 물건을 받는다
기존의 100 BTC을 이번에는 자기 자신에게 이체하는 거래를 생성한다.
자신에 대한 그의 거래가 먼저 일어난 것이라고 네트워크가 믿도록 시킨다.

(1) 단계가 취해진 후, 몇몇 채굴자가 거래를 블록에 포함시키고 몇 분 후에, 블록 숫자가 270000이라고 해보자. 약 1시간 후에, 다섯 개의 블록이 해당 블록 이후에 체인에 추가될 것이며, 각각의 블록들은 간접적으로 거래를 가리키며 승인하게 된다. 이 시점에서, 판매자는 최종적으로 결제를 승인하며, 상품을 배송한다. 우리는 이것이 디지털의 이점이라고 가정하므로, 배송은 즉각적이다. 이제 해커는 해당 100 BTC을 자신에게 보내는 또다른 거래를 생성한다. 만약 해커가 이 거래를 단순히 네트워크에 내보낸다면, 당연히 승인되지 않을 것이다. 채굴자들은 APPLY(S,TX)의 실행을 시도할 것이고 TX가 더 이상 존재하지 않는 UTXO을 소비한다는 것을 알게 된다. 따라서, 해커는 대신 이 블록체인의 "포크(fork)"를 생성하여, 동일한 블록 269999를 가리키는, 부모 블록이지만 이전 거래 대신 새로운 거래를 사용하는 또 다른 버전의 블록 270000을 채굴하는 것으로 시작한다. 물론 블록 데이터가 바뀌었으므로 작업 증명은 다시 이루어져야 한다. 또한, 해커가 만든 새로운 270000번 블록은 해시 또한 달라지므로, 기존의 5개(270001~270005번) 블록 또한 이를 "가리키지" 않게 된다. 결국, 기존의 체인과 해커의 새로운 체인이 완전하게 분리된다. 이 때 적용되는 규칙은 포크의 경우 가장 긴 블록체인이 정식 체인으로 간주된다는 것이므로, 정당한 채굴자들은 그대로 270005 체인에서 작업을 진행할 것이고, 오직 해커만이 270000 체인에서 작업을 진행할 것이다. 이 상황에서 해커는 자신의 블록체인이 5개 블록 길이 차이를 따라잡고 가장 길어지도록 하기 위해, 다른 모든 네트워크보다 더 많은 연산을 진행해야 한다(즉, "51% 공격").

머클 트리

왼쪽: 가지 한 개의 검증에는 머클 트리의 일부 노드만 있으면 충분하다.

오른쪽: 머클 트리의 어느 일부분이라도 바뀌게 되면, 체인 위쪽 어느 한 곳에서 결국 불일치가 생기게 된다.

비트코인의 확정성에 있어 중요한 특징 중 하나는 각 블록들이 다중레벨 자료구조로 저장된다는 점이다. 블록의 "해시"는 사실 약 200바이트 크기의 정보를 담은 블록 헤더의 해시인데, 여기에는 타임스탬프, 논스(Nonce), 앞선 블록의 해시, 그리고 해당 블록의 모든 거래들이 있는 머클 트리라 부르는 자료구조의 루트 해시가 담겨진다. 머클 트리는 이진트리의 일종으로, 트리 아래쪽에 데이터를 담고 있는 리프노드, 2개의 자식노드의 해시로 만들어지는 중간노드, 그리고 또한 2개의 자식 노드의 해시에서 형성되어 트리의 "제일 위"에 존재하는 1개의 루트 노드로 이루어져 있다. 머클트리의 목적은 블록의 데이터가 부분적으로만 제공되어도 충분하도록 하는데 있다. 네트워크의 노드는 한 출처로부터는 블록의 헤더를, 또다른 출처로부터는 그 블록과 관련된 트리의 작은 일부분을 받는 것만으로도 충분히 그 데이터의 신뢰성을 검증할 수 있게 된다. 이것이 가능한 이유는 데이터의 해시값들이 위를 향해 나아가기 때문이다. 만약 악의적인 사용자가 가짜 거래를 머클트리의 아래쪽에서 교환하려고 시도한다면, 이 변화는 그 위의 노드를, 그리고 다시 그 위의 노드를 차례대로 바꾸게 되고, 결국 루트노드의 해시, 나아가 전체 블록의 해시를 바꾸게 된다. 결국 프로토콜 상에서 완전히 다른 블록이 만들어지게 되는 것이다(그리고 거의 확실하게, 이 블록은 작업 증명 검증으로 인해 무효화된다)

이러한 머클트리 데이터 구조는 장기적 지속성 관점에서 반드시 필요한 프로토콜이라고 할 수 있다. 모든 블록을 저장하고 처리하는 비트코인 네트워크의 "전체 노드"는, 2014년 4월 시점에 비트 코인 네트워크에서 이미 약 15 GB 크기이며, 1달에 1 GB씩 증가하고 있다. 이 크기는 현재 기준에서 휴대폰으로는 어려워도 일반 컴퓨터로는 어렵지 않게 처리 가능하다고 할 수 있지만, 미래에는 기업 단위 혹은 일부 사람들만 참여할 수 있게 될 것이다. "간략화된 결제 검증", 이른바 SPV(Simplified Payment Verification) 프로토콜은 "라이트 노드"라고 불리는 다른 형태의 노드로 이루어지는데, 이 노드는 블록 헤더만 다운로드하여 작업 증명을 진행하고, 이후 관심 있는 특정 거래와만 관련된 일부 "가지" 데이터만 다운로드함으로써 이루어진다. 이 방식은 라이트 노드가 전체 블록체인의 일부만을 다운로드하면서도 특정 비트코인 거래의 상태, 그리고 현재 잔액을 안전하게 검증할 수 있게 만든다.

다양한 블록체인 응용 예시들

블록체인 기술을 다른 분야에 적용하는 것은 긴 역사를 가지고 있다. 2005년에 Nick Szabo는 안전한 자산 타이틀과 소유자 권한(opens in a new tab) 개념을 제안하며, 토지 소유 정보 데이터를 저장하기 위한 블록체인 기반 시스템을 "데이터베이스 복제 기술의 발전"이 어떻게 실현 가능하도록 만드는지에 대한 문서를 발행하였고, 홈스테딩, 적대적 소유, 조지안 토지세와 같은 개념을 포함하는 정교한 프레임워크를 만들어냈다. 하지만 당시에는 이를 위한 효과적인 데이터베이스 복제 시스템이 없었고, 따라서 해당 프로토콜은 실현되지 못하였다. 그러나 2009년 비트코인의 탈중앙화된 합의 매커니즘이 발표된 이후 수 많은 응용 프로그램들이 나타나기 시작했다.

네임코인 - 2010년에 만들어진 네임코인(opens in a new tab)은 탈중앙화 이름 등록 데이터베이스로 가장 잘 설명된다. 토르, 비트코인, 비트메시지와 같은 탈중앙화된 프로토콜에서는 다른 사람과 상호작용하기 위한 계정이 필요한데, 지금까지는 계정이 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy와 같은 랜덤생성 해시로만 나타내어졌었다. 이상적으로는, 이러한 랜덤 해시보다는 "조지"와 같은 이름으로 계정이 있다면 좋을 것이다. 다만 문제는, 누군가가 "조지"라는 이름으로 계정을 만들었어도 또 다른 사람이 "조지"라는 계정을 똑같이 만들고 자기가 "조지"리고 주장할 수 있다는 점이다. 이를 위한 유일한 해결책은 선착순 방식으로 첫 번째 계정 등록자만 성공하도록 하는 것인데, 이는 비트 코인 합의 프로토콜로 쉽게 구현이 가능하다. 네임코인은 이러한 아이디어를 사용하며 이름 등록 시스템을 가장 먼저, 가장 성공적으로 구현하였다.
컬러코인: 컬러코인(opens in a new tab)의 목적은 사람들이 자신만의 디지털 화폐(토큰)를 비트코인 블록체인 상에서 만들 수 있도록 하는데 있다. 컬러코인 프로토콜에는 특정 비트 코인 UTXO에 공개적으로 색상을 부여함으로써 새로운 화폐가 "발행"되며, 이후 이 UTXO가 소비됨으로써 만들어지는 다른 UTXO들도 동일한 색상을 가지게 된다(입력 UTXO들이 여러 색상을 가질 때에는 특별한 규칙이 적용된다). 이는 사용자들이 자신이 원하는 특정한 색상의 UTXO만 지갑에 보유하면서 일반 비트 코인처럼 사용하고, 또 자신이 받은 UTXO의 색상을 블록체인에서 백트래킹할 수 있게 해준다.
메타코인 - 메타코인의 아이디어는 다른 형태의 상태전환 함수, 이른바 APPLY'가 적용되는 메타코인의 거래들로 이루어진 새로운 프로토콜을 비트코인 프로토콜 위에 만드는 데 있다. 메타코인 프로토콜은 비트 코인 프로토콜에서 잘못된 메타코인 거래가 일어나는 것 자체는 방지할 수 없기 때문에, 새로운 규칙을 추가하여 만약 APPLY'(S,TX)가 에러를 반환하는 경우 프로토콜은 기본 값으로 APPLY'(S,TX) = S가 되도록 하였다. 이는 비트 코인 자체적으로는 구축하기 어려운 발전된 기능을 포함한 임의의 암호화폐 프로토콜을 매우 낮은 비용으로도 개발(채굴 및 네트워캉 등 복잡한 로직은 비트 코인 프로토콜이 해결하므로)할 수 있게 하였다. 메타코인은 몇몇 금융계약들, 이름 등록, 탈중앙화된 거래를 시행하기 위하여 사용되고 있다.

따라서 일반적으로 합의 프로토콜을 만드는 방법은 크게 두 가지라고 할 수 있는데, 독자적인 네트워크를 만들거나, 혹은 비트 코인 프로토콜 위에 프로토콜을 세우는 것이다. 전자의 방식은, 물론 네임코인 등 꽤 성공적인 예시도 있지만, 보통은 구축하기 어렵다. 독자적인 블록체인, 네트워크, 상태전환 코드 등을 모두 새롭게 구축하면서 테스트해 나가는 부트스트랩이 필요하기 때문이다. 또한, 우리가 예상하기에 탈중앙화된 합의 기술을 활용한 프로그램들은 멱법칙을 따르게 되는데, 대다수는 자신들만으로는 참여자가 적어 블록체인을 보증하는 데 어려움을 겪을 것이며, 이에 많은 수의 탈중앙화된 프로그램들, 특히 탈중앙화된 자율적인 조직들은 서로 상호작용할 필요가 생기게 될 것이다.

그러나 비트 코인 기반의 방식은 결점이 있는 것이, 간략화된 방식의 비트 코인 결제 검증 기능을 내재하지 않고 있다. SPV 방식이 비트 코인에서 가능한 이유는 체인의 길이가 곧 신뢰도로 이어지기 때문이다. 한 거래가 있을 때 그 앞선 거래들을 충분히 백트래킹할 수 있다면, 그 거래들은 상태에 안전하게 정상적으로 포함되었다고 말할 수 있다. 그러나 비트 코인 블록체인 위에 만들어진 메타 프로토콜들은, 자신들의 프로토콜 상에서는 유효하지 않은 거래를 해당 블록체인이 포함하지 않도록 강제할 수는 없다는 단점이 있다. 따라서, 완전히 안전한 SPV 메타 프로토콜을 만들고자 한다면, 특정 거래의 유효성을 검증하기 위해서는 해당 거래에서 비트 코인 블로체인의 맨 처음까지 역으로 모두 확인해야 한다. 현재, 모든 "라이트한" 비트코인 기반 메타 프로토콜은 데이터 검증을 위한 특정 서버를 두고 있는데, 이러한 방식은 암호 화폐의 최우선 목표가 탈중앙화라는 점을 고려하였을 때 가장 좋은 방식이라고는 보기 어려울 것이다.

스크립팅

특별한 익스텐션 없이도, 비트코인은 "스마트 컨트랙트" 기능을 조금이지만 지원하고는 있다. 비트코인의 UTXO는 공개 키 뿐 아니라, 간단한 스택 기반의 프로그래밍 언어로 구현되는 조금 더 복잡한 스크립트에 의해서도 소유되고 있다. 이 패러다임에서, 해당 UTXO를 소비하는 거래는 해당 스크립트를 만족시키는 데이터를 반드시 제공해야 한다. 실제로, 기본적인 공개 키 소유권 메커니즘 또한 스크립트에 의해 구현되어 있다. 해당 스크립트는 타원곡선의 서명을 입력으로 하고, 이를 거래와 UTXO의 소유자의 주소를 대상으로 검증한 후, 검증에 성공할 시 1을, 실패할 시 0을 반환한다. 이외에도 보다 더 복잡한 스크립트들이 적용된 응용 사례들이 있다. 예를 들어 3개의 개인 키 중 2개의 서명을 가지고 검증을 진행("멀티징")하는 스크립트를 만들 수 있는데, 이러한 방식은 기업 계좌와 저축 예금 계좌, 상점 간 에스크로(제3자위탁) 거래 등에서 유용할 수 있다. 스크립트는 특정 계산 문제를 해결했을 때에 보상금을 제공할 때에도 사용될 수 있는데, 예를 들어 "당신이 이만큼의 액면가를 지닌 도지코인을 나에게 보냈다는 SPV 증명을 할 수 있다면 이 비트 코인 UTXO는 당신의 것이 된다"와 같은 스크립트도 가능하다. 즉, 탈중앙화된 암호화폐 상호 교환이 가능해진다.

그러나, 비트코인 상에서 구현된 스크립트 언어에는 몇 가지 치명적인 단점이 있다.

튜링 완전의 부재: 물론 비트 코인 스크립팅 언어는 다양한 로직 연산을 지원하지만, 모든 연산이 가능한 것은 아니다. 예를 들어, 루프 처리가 불가능하다. 이는 거래 검증 과정에서 무한루프를 피하기 위함이다. 물론 이 단점은 어떠한 루프라도 if문을 사용해 기본 코드를 여러 번 반복함으로써 극복 가능하다는 것을 스크랩트 개발자라면 알겠지만, 이 방식은 불필요하게 길어진, 비효율적인 스크립트를 만들어낸다. 예를 들어, 타원곡선 서명 알고리즘을 적용하고자 한다면 스크립트에 총 256개의 반복 곱셈 코드를 하나하나 쓰게 될 것이다.
Value-blindness - 하나의 UTXO 스크립트가 얼마를 인출할 수 있는지에 대한 세세한 제어를 제공하는 것은 불가능하다. 예를 들어 오라클 계약의 대표적인 사용 예시로 헤징 계약이 있다. A가 B에게 1000달러 가치의 BTC을 맡기고, 30일 후에 1000달러 가치의 BTC을 되찾아 A가 가지고 차액은 B가 가지도록 계약했다고 하자. 이는 오라클이 BTC의 가치를 달러로 환산하도록 요구하는데, 물론 이것만으로도 현재 가능한 중앙화된 진행 방식에 비하면 많이 탈중앙화된 방식이라고 할 수 있다. 하지만, UTXO는 결국 모 아니면 도(쓰이거나 안쓰이거나) 방식이기 때문에, 위 계약을 처리하기 위해서는 다양한 액면가의 수 많은 UTXO들(30까지의 모든 k에 대해 2^k에 해당하는 UTXO들)이 쓰이고 O가 어떤 UTXO를 A에게 보내고 어떤 UTXO를 B에게 보낼지 선택하게 되어서 매우 비효율적이게 된다.
상태의 부재 - UTXO는 소비되거나 소비 안되거나의 둘 중 하나이기에, 이외의 다른 내부적인 상태를 가지도록 하는 멀티 스테이지 계약이나 스크립트를 만드는 것이 불가능하다. 이는 멀티스테이지 옵션 계약, 탈중앙화된 거래 오퍼 또는 2단계 암호화 프로토콜(보안 연산 보상에 필요) 등을 도입하기 어렵게 만든다. 이는 또한 UTXO가 단순한 1단계 계약에만 사용될 수 있고, 탈중앙화된 조직 등 보다 더 복잡하고 "스테이트풀"한 계약이나 메타 프로토콜에는 쓰이기 어렵다는 것을 나타낸다. UTXO의 이러한 모 아니면 도 특성, 가치 불분명성 특성은 인출 제한과 같은 또 다른 중요한 응용 방식도 불가능하게 만든다.
Blockchain-blindness - UTXO는 논스, 타임스탬프, 앞선 블록 해시와 같은 정보를 담고 있지 않다. 이는 잠재적으로 유용하게 쓰일 수 있는 랜덤성이라는 가치를 스크립팅 언어로부터 제외시키기에, 갬블과 같은 몇몇 카테고리에서 쓰임이 제한되게 된다.

지금까지 우리는 암호 화폐 상에서 고도화된 어플리케이션을 만드는 3가지 방법을 알아보았다. 새로운 블록체인을 만들거나, 비트 코인 위에 스크립팅을 하거나, 비트 코인 위에 메타 프로토콜을 만들거나이다. 새로운 블록체인을 만드는 것은 기능을 제한 없이 자유롭게 만들 수 있다는 장점이 있지만, 개발 시간과 많은 노력 및 보안을 필요로 한다. 스크립팅 사용은 구축 및 표준화가 용이하지만 기능에 제한이 있고, 메타 프로토콜은 간단하지만 확장성에 오류가 있다. 이더리움을 통해, 우리는 어플리케이션들이 경제 생태계와 블록체인 보안을 공유하면서도, 개발하기 용이하고 라이트 클라이언트 특성이 강화된 대체 프레임워크를 구축하고자 한다.

이더리움

이더리움의 목적은 탈중앙화된 어플리케이션을 만들기 위한 대체 프로토콜을 만드는 데 있으며, 이는 특히 짧은 개발 시간, 규모가 작고 많이 사용되지는 않는 어플리케이션에서의 보안, 다른 어플리케이션과의 효율적인 연결이 중요한 다양한 탈중앙화 어플리케이션들에게 유용한 다른 형태의 트레이드오프를 제공할 것이다. 이더리움은 이를 튜링 완전의 프로그래밍 언어가 내장된 블록체인이라는 궁극적인 추상화 기반 레이어를 만듦으로써 가능케 하였는데, 누구든지 스마트 컨트랙트와 탈중앙화된 어플리케이션을 만들고 그들만의 소유권 규칙, 거래 형태, 상태 전환 함수를 적용할 수 있다. 네임코인의 기본 버전은 단 두 줄의 코드로 구현이 가능하고, 화폐나 평가 시스템 등도 20줄 이하로 가능하다. 특정 조건을 만족해야만 풀 수 있는 암호화된 "박스"를 의미하는 스마트 계약 또한 이 플랫폼 위에서 만들어질 수 있으며, 튜링 완전성, 가치의 분명성, 블록체인 정보 보유, 그리고 상태의 힘에 의해 비트 코인 스크립팅보다 더 많고 다양한 응용이 가능하다.

이더리움 계정

이더리움에서 상태는 "계정"이라고 부리는 객체들로 이루어지며, 각 계정은 20바이트 크기의 주소 그리고 계정들 간에 이루어지는 가치 및 정보의 직접적인 거래를 뜻하는 상태 전환을 담고 있다. 이더리움 계정은 하기의 4개 프로퍼티를 지닌다.

논스: 각 거래가 정확히 한 번만 처리되도록 하기 위한 카운터
해당 계정의 현재 이더 잔액
해당 계정의 컨트랙트 코드, 존재하는 경우
해당 계정의 저장소 (디폴트로는 비어있음)

"이더"는 이더리움의 주요한 내부 크립토-연료이며, 거래 수수료를 지불하기 위해 쓰인다. 일반적으로 계정은 개인 키로 관리되는 외부에서 소유한 계정과 계약 코드로 관리되는 계약 계정의 두 가지 형태가 있다. 외부에서 소유한 계정은 코드가 없으며, 거래를 생성하고 서명함으로써 메시지를 보낼 수 있다. 계약 계정은, 메시지를 받을 때마다 자신의 코드를 실행하여 내부 저장 공간의 데이터를 읽거나 쓰고, 다른 메시지를 보내고, 새로운 계약을 생성할 수 있다.

알아두어야 할 점은, 이더리움에 있어 "계약"은 "이루어지는 것" 또는 "따라야 하는 것"이라고 받아들여져서는 안 된다는 점이다. 대신, 계약은 이더리움 실행 환경에 존재하면서 특정 메시지나 거래가 이루어지면 미리 정해진 코드를 실행하고, 또한 이더 잔액이나 혹은 키/밸류 스토리지의 값들에 대한 관리를 행하는 "자율 에이전트"로 여겨져야 할 것이다.

메시지와 거래

이더리움에서 "거래"란 외부에서 소유한 계정으로부터 보내진 메시지를 저장하는 서명된 데이터패키지를 의미한다. 거래는 하기를 포함하고 있다:

메시지 수신자
발신자를 나타내는 서명
발신자로부터 수신자에 보내지는 이더의 총액
추가 데이터 필드
거래 실행 시에 가능한 최대 연산 횟수를 나타내는 STARTGAS 값
각 연산 단계마다 발신자가 부담하는 수수료를 나타내는 GASPRICE 값

첫 3개는 다른 암호화폐에서도 볼 수 있는 표준 필드이다. 데이트 필드는 기본적으로는 아무 기능을 가지지 않지만, 가상 머신은 필요 시 데이터에 접근하기 위한 계약을 사용하는 명령 코드를 지니고 있다. 예를 들어 만약 블록체인 기반의 도메인 등록 서비스를 위한 계약이 있다고 한다면, 이 계약은 2개의 "필드"를 가진 데이터를 필요로 하게 될 것이다. 첫 번째 필드는 등록하고자 하는 도메인, 그리고 두 번째 필드는 등록에 사용할 IP 주소이다. 계약은 메시지 데이터로부터 읽어온 이 값들을 저장소에 적절하게 저장할 것이다.

스타트가스와 가스프라이스 필드는 이더리움이 DOS 공격을 막는데 있어 매우 중요하다. 코드 상에 우연 혹은 나쁜 의도에 의한 무한 루프나 연산 낭비가 생기지 않도록 하기 위해, 각 거래는 코드 실행 시 얼마나 많은 연산이 가능한지 제한을 두어야 한다. 연산의 기본 단위는 "가스"이다. 통상 연산 당 1 가스가 쓰이는데, 간혹 더 무거운 연산이 필요하거나 상태에 더 많은 양의 데이터를 저장해야 하는 경우에는 더 많은 가스가 쓰일 수 있다. 거래 데이터의 경우 1바이트마다 5 가스의 수수료를 내게 된다. 이 수수료 시스템의 목적은, 악의적인 해커가 있을 때 그들이 소비하는 연산, 대역폭 및 저장 공간 등 모든 리소스의 양에 비례하여 비용을 지불하도록 함에 있다. 즉, 네트워크에서 더 많은 리소스를 쓰는 경우 그 어떠한 거래라 할지라도 그 증가한 양에 비례하여 더 많은 가스 수수료를 내도록 하는 것이다.

메시지

계약은 다른 계약에 "메시지"를 보낼 수 있다. 메시지는 절대 연속화되지 않으며 오직 이더리움 실행 환경에서만 존재하는 가상의 목적물이다. 메시지는 하기를 포함하게 된다.

메시지 발신자 (암묵적)
메시지 수신자
메시지와 함께 전송될 이더의 총액
추가 데이터 필드
스타트가스 값

본질적으로 메시지는 거래와 같다고 할 수 있다. 단, 외부 요소가 아닌 계약에 의해 만들어진다는 점이 다르다. 메시지는 현재 코드를 실행중인 계약이 메시지를 생성하고 실행하는 CALL 명령어를 실행할 때 생성된다. 거래처럼 메시지 또한 그 코드를 실행하고 있는 수신자 계정으로 전송된다. 따라서, 계약은 외부 요소들이 하는 것과 같은 방식으로 다른 계약들과 관계를 맺을 수 있다.

거래 혹은 계약에 할당된 가스 허용량은, 해당 거래 뿐 아니라 그 하위 거래 및 실행에 의한 가스 소비까지 모두 고려하여 적용된다. 예를 들어, 외부 요소 A가 B에 거래를 보내며 1000가스를 사용하였는데, B가 C에 메시지를 보내기까지 600가스를 사용하고, C의 내부적인 실행이 반환 전 300가스를 사용하였다면, B는 아직 100가스를 더 사용할 수 있는 것이다.

이더리움의 상태전환 함수

이더리움 상태 전환 함수, APPLY(S,TX) -> S'는 아래와 같이 정의된다.

거래가 올바르게 구성되어 있는지(알맞은 수의 값들을 가지고 있는지 등), 서명이 유효한지, 논스(Nonce) 값이 발신자의 계정에 있는 논스(Nonce) 값과 일치하는지를 확인한다. 아닌 경우, 에러를 반환한다.
STARTGAS * GASPRICE 값을 거래 수수료로 하고, 서명으로부터 발신자 주소를 확인한다. 발신자 계정의 잔고는 수수료만큼 줄이고 논스(Nonce) 값은 1 증가시킨다. 만약 잔고가 충분하지 않다면 에러를 반환한다.
GAS = STARTGAS를 초기화하고 트랜잭션의 바이트에 대해 지불하기 위해 바이트당 일정량의 가스를 제거한다.
발신자 계정에서 수신자 계정에 거래 값을 전송한다. 만약 수신자 계정이 존재하지 않는 경우, 신규 생성한다. 만약 수신 계정이 계약 계정이라면 해당 계약의 코드에 대해 실행 완료될 때까지 또는 가스를 모두 사용할 때까지 실행한다.
만약 발신자가 충분한 잔고가 없어서 값 전송에 실패하거나, 혹은 가스 부족으로 코드 실행이 중지된다면, 그 때까지 이루어진 모든 상태 전환(단, 수수료 제외)을 다시 되돌리고, 수수료는 채굴자의 계정에 추가한다.
그렇지 않으면, 가스 잔액은 발신자에 다시 되돌리고, 수수료는 채굴자에 전송한다.

예를 들어, 아래와 같은 계약 코드가 있다고 하자.

if !self.storage[calldataload(0)]:
  self.storage[calldataload(0)] = calldataload(32)

참고할 점은 실제 계약 코드가 로우 레벨의 EVM 코드로 작성된다는 것이다. 이 예시는 우리가 사용하는 하이 레벨 언어 중 하나인 Serpent로 쓰여졌으며, 이는 EVM 코드로 컴파일할 수 있다. 계약의 저장 공간은 비어있는 채로 시작되었고, 여기에 10 이더, 2000 가스, 0.001 이더 가스프라이스, 그리고 64바이트의 데이터(0~31바이트는 숫자 2를, 32~63바이트는 문자열 CHARLIE를 나타냄)로 이루어진 거래가 전송된다고 가정하자. 이 경우 상태전환 함수의 프로세스는 아래와 같을 것이다.

거래가 유효하고 잘 구성되었는지 확인한다.
발신자가 최소한 2000 * 0.0001 = 2 이더를 소유하고 있는지 확인한다. 소유하고 있다면, 해당 잔고를 2 이더만큼 감소시킨다.
가스 = 2000으로 초기화한다. 거래 길이가 170바이트이고 바이트 수수료가 5라고 가정한다면, 850이 빠지고 1150가스가 남게 된다.
10 이더를 발신자 잔고에서 빼고 계약 계정에 추가한다.
코드를 실행한다. 이 경우에는 간단하다. 인덱스 2에 있는 계약의 저장 공간이 사용되는지 확인하여 사용되지 않음을 확인하고, 인덱스 2의 저장 공간을 값 CHARLIE로 설정한다. 여기에 187 가스가 사용된다고 가정하면, 이제 남은 가스는 1150 - 187 = 963 가스이다.
963 * 0.001 = 0.963 이더를 발신자 계정에 추가하고, 최종 상태를 반환한다.

거래가 다른 계약을 수반하지는 않는다면, 전체 거래 수수료는 단순히 GASPRICE에 거래의 길이를 곱한 만큼이 될 것이고, 이는 거래와 함께 전송된 데이터와는 무관하게 된다.

참고할 점은, 되돌리는 경우에는 메시지가 거래와 동일한 방식으로 이루어진다는 점이다. 만약 메시지 실행이 가스 부족으로 인해 중지된다면, 그 메시지의 실행과 거기서 수반된 모든 하위 실행 또한 되돌려지지만, 앞선 상위 실행의 경우에는 되돌려질 필요가 없다. 이는 계약이 다른 계약을 호출해도 "안전"함을 의미한다. 예를 들어 만약 계약 A가 계약 B를 G가스로 실행한다면, 계약 A가 잃을 수 있는 가스 양은 최대 G 가스로 제한된다. 마지막으로, 계약을 신규 생성하는 CREATE라는 명령 코드가 있는데, 실행 원리는 일반적으로 CALL과 동일하지만, 실행의 결과가 새롭게 만들어질 계약의 코드를 결정한다는 점에서 차이가 있다.

코드 실행

이더리움 계약의 코드는 "이더리움 가상 머신 코드" 혹은 "EVM 코드"로 불리며, 로우 레벨의 스택 기반 바이트코드 언어로 쓰여진다. 이 코드는 여러 개의 바이트들로 구성되며, 각 바이트는 작업을 의미한다. 일반적으로 코드 실행이란 현재의 프로그램 카운터(0에서 시작한다)에서 연산을 지속적으로 실행하는 무한 루프를 의미하며, 코드의 마지막 줄에 다다르거나, 오류가 발생하거나, STOP 또는 RETURN 지시가 탐지될 때까지, 프로그램 카운터를 1씩 증가시킨다. 이 작업은 데이터를 저장하기 위해 3가지 유형의 공간에 접근한다.

값을 넣고 꺼낼 수 있는 후입선출 컨테이너인 스택
메모리: 무한히 확장 가능한 바이트 배열
해당 계약의 장기저장공간, 키/밸류 스토어. 연산이 끝났을 때 리셋되는 스택 및 메모리와 다르게, 저장공간은 장기간 유지된다.

코드는 각 값들, 발신자와 수신된 메시지의 데이터는 물론 블록 헤더 데이터에 접근할 수 있으며, 필요 시 데이터의 바이트 배열을 출력으로써 반환할 수 있다.

EVM 코드의 공식 실행 모델은 놀랍게도 매우 간단하다. 이더리움 가상 머신이 실행 중인 경우, 그 완전한 연산 상태는 튜플(block_state, transaction, message, code, memory, stack, pc, gas)로 정의될 수 있으며, 이 때 block_state는 모든 계정을 포함하는 글로벌 상태이며 여기에는 잔고 및 저장 공간이 포함된다. 매 실행 라운드의 실행이 시작될 때 현재 명령어는 code의 pc번째 바이트에서 불러와지며(또는 pc >= len(code)인 경우 0), 각 명령어는 튜플에 어떤 영향을 미치는지에 따라 고유한 정의가 있다. 예를 들어, ADD는 스택에서 2개 요소를 가져와 더한 후 그 값을 넣고, 이 때 gas는 1이 줄어들고 pc는 1이 늘어나며, SSTORE의 경우는 스택에서 상위 2개 요소를 밀어낸 후 첫 번째 요소를 인덱스로, 두 번째 요소를 값으로 하여 계약 저장 공간의 인덱스에 값을 삽입한다. JIT 컴파일링을 적용하여 이더리움 가상 머신의 실행을 최적화하는 방법은 물론 많이 있겠지만, 이더리움의 기본적인 구현은 수백 줄 정도의 코드로 가능하다.

블록체인과 채굴

이더리움의 블록체인은 많은 면에서 비트 코인과 유사하지만, 몇 몇 다른 점이 있다. 블록체인 구조에 있어서의 가장 큰 차이는, 비트 코인과 다르게 이더리움의 블록은 거래 리스트 뿐 아니라 가장 최근의 상태 또한 담고 있다는 점이다. 그 뿐 아니라, 다른 두 개의 값인 블록 번호와 난이도 또한 블록에 저장된다. 이더리움의 기본적인 블록 검증 알고리즘은 하기와 같다.

참조된 이전 블록이 존재하고 유효한지 확인한다.
해당 블록의 타임스탬프가 앞선 블록의 타임스탬프보다 크고(나중이고), 그 이후로 15분 이내인지 확인한다.
블록 번호, 난이도, 거래 루트, 삼촌 루트, 가스 리밋(이더리움만의 다양한 로우 레벨 개념들)이 유효한지 확인한다.
해당 블록의 작업 증명이 유효한지 확인한다.
S[0]를 앞선 블록의 마지막에 있는 상태라고 하자.
TX는 블록의 거래 리스트, n는 거래라고 하자. 모든 i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]) 대하여. 만약 어느 애플리케이션이라도 오류를 반환한다거나, 소비된 가스 양이 GASLIMIT을 초과하는 경우 에러를 반환한다.
S_FINAL를 S[n]로 하자, 다만 채굴자에게 지불되는 블록 보상을 추가한다.
S_FINAL의 머클트리 루트의 상태가 블록 헤더에 저장된 최종 상태와 일치하는지 확인한다. 그렇다면, 블록은 유효하다; 그렇지 않다면, 블록은 유효하지 않다.

이 방식은 처음 보기에는 각 블록에 전체 상태를 저장하므로 매우 비효율적이라고 보여질 수 있지만, 실제로는 비트 코인의 방식에 비해 더 효율적이게 된다. 그 이유는 상태가 트리 구조로 저장되고, 또 각 블록이 만들어질 때마다 트리의 작은 일부분만 바뀌면 되기 때문이다. 따라서, 일반적으로 인접한 블록들은 트리가 대부분 일치하게 되며, 이에 데이터가 한 번만 저장되고 나면 이후는 포인터(즉, 서브트리의 해시)를 사용해 두 번 참조될 수 있다. "패트리시아 트리"로 불리는 특별한 트리 구조가 이를 위해 사용되는데, 여기에는 노드의 삽입, 삭제, 수정이 더 효율적으로 이루어지는 머클트리 개념에 대한 변형이 포함된다. 또한 모든 상태 정보가 앞선 블록의 데이터에 포함되어 있기 때문에, 블록체인의 전체 히스토리를 저장할 필요가 없다. 이 전략은 만약 비트 코인에 적용된다면 5~20배 정도로 저장 공간을 효율화시킬 수 있다.

종종 궁금해하는 점은 이 계약 코드가 실제 하드웨어의 "어디서" 실행되느냐 하는 점이다. 이에 대한 답은 간단하다. 코드 실행 과정은 상태전환 함수의 정의의 일부분이고, 이는 다시 블록 검증 알고리즘의 일부이기 때문에, 예를 들어 블록 B에 거래가 추가됨으로써 코드 실행이 필요하게 된다면, 현재 혹은 미래에 해당 블록 B를 다운로드하고 검증하는 모든 노드에서 실행이 이루어지게 될 것이다.

어플리케이션

일반적으로 이더리움 상에서 어플리케이션은 총 3가지 타입이 있다. 첫 번째는 금융 어플리케이션으로, 사용자들은 그들의 돈을 관리하고 계약을 진행하는 보다 더 강력한 방법을 얻게 된다. 여기에는 서브화폐, 금융 파생상품, 헷지 계약, 저축 지갑, 유서, 심지어는 근로 계약도 포함된다. 두 번째는 반금융 어플리케이션으로, 돈이 얽혀 있기는 하지만 돈만으로는 이루어지지는 않은 것들이다. 가장 좋은 예시는 연산 문제의 해결에 대한 강제적 보상 지급일 것이다. 마지막으로, 온라인 투표와 탈중앙화된 운영 방식과 같이 전혀 금융과 관련이 없는 어플리케이션이 있다.

토큰 시스템

온 블록체인(On-blockchain) 토큰 시스템은 USD나 금과 같은 기존 화폐와 연관된 서브화폐 자산 뿐 아니라, 회사 주식, 스마트 자산을 나타내는 개인 토큰, 안전하고 위조 불가능한 쿠폰, 포인트 및 인센티브로서의 토큰 시스템 등 다양한 애플리케이션을 갖추고 있다. 토큰 시스템의 경우 이더리움에서는 구현하기가 매우 쉽다. 왜냐하면 모든 화폐 혹은 토큰 시스템이 본질적으로는 결국 (1) 거래 이전에 A가 최소한 X 단위만큼을 보유하고 있고 (2) 거래가 A에 의해 승인되었다는 조건 하에, A에서 X 단위만큼 빼고 B에 X 단위만큼 더한다는 형태의 활동이 모여서 만들어진 데이터베이스라고 할 수 있기 때문이다. 토큰 시스템을 만들고 싶다면 이 유일한 로직만 계약으로 구현하면 되는 것이다.

Serpent에서 토큰 시스템을 구현하기 위한 기본 코드는 다음과 같다.

def send(to, value):
  if self.storage[msg.sender] >= value:
    self.storage[msg.sender] = self.storage[msg.sender] - value
    self.storage[to] = self.storage[to] + value

이는 본질적으로, 위에서 언급한 "은행 시스템"의 구현을 위한 상태전환 함수를 코드로 작성한 것이라고 할 수 있다. 물론, 실제로는 초기에 화폐를 분배하거나 하는 등의 몇몇 다른 엣지 케이스들을 처리하기 위한 코드, 다른 계약이 해당 주소의 잔고를 확인하기 위해 사용할 함수 등이 추가되어야 하기는 한다. 하지만, 이것이 전부이다. 이론적으로, 서브화폐로써 동작하는 이더리움 기반의 토큰 시스템은 비트 코인 기반의 메타 화폐들에서는 불가능한 기능을 갖출 수 있다. 즉, 해당 화폐로 거래 수수료를 직접 낼 수 있다. 이를 위해, 계약은 수수료를 위해 사용었을 이더 잔고를 발송자에게 되돌리고, 그만큼을 해당 서브화폐로 채우고, 이를 다시 지속적인 경매를 통해 되팔게 된다. 사용자들은 따라서 자신의 계정에서 이더를 "활성화"하기는 해야 하지만, 계약이 매번 환불되기 때문에 이더가 일단 존재하면 재사용할 수 있게 되는 것이다.

금융 파생상품과 스테이블-밸류 화폐

금융 파생상품은 "스마트 컨트랙트"의 가장 흔한 응용 방식인 동시에 코드로 구현하기 가장 쉬운 방식 중 하나이다. 금융 계약은 구현함에 있어 가장 어려운 점이 있다면, 대부분의 경우에 외부 가격 티커를 필요로 하게 된다는 점일 것이다. 예를 들어, 가장 수요가 많을 응용으로 이더(혹은 다른 암호화폐)의 가격 변동성에 대한 헤징을 위한 스마트 계약이 있을텐데, 이를 위해서는 계약이 ETH/USD 값을 알아야 한다는 조건이 충족되어야 한다. 이를 위한 가장 쉬운 방법은, 특정 그룹(나스닥 등)이 "데이터 제공" 계약을 관리하고, 필요에 따라 해당 값을 업데이트하며, 다른 계약이 메시지를 송부했을 때 해당 값을 응답으로써 반환하는 인터페이스를 제공하도록 하는 것이다.

이러한 조건이 충족된다고 한다면, 헤징 계약은 하기와 같을 것이다.

A 그룹이 1000 이더를 입력할 때까지 기다린다.
B 그룹이 1000 이더를 입력할 때까지 기다린다.
"데이터 제공" 계약을 통해 확인 후, 1000이더의 USD 가치를 저장 공간에 기록한다. 이를 $x라고 하자.
30일 후, 이더의 $x 가치(다시 해당 데이터 제공 계약을 쿼리하여 새 가격을 구함으로써 계산됨)를 A에 보내고 차액은 B에 보내도록 A 또는 B에 대해 계약을 "재활성화"한다.

이러한 계약은 암호화폐 상거래에서 엄청난 잠재성을 지니게 된다. 본래 암호 화폐의 가장 큰 문제라고 일컬어지던 것은 가격 변동성이다. 많은 사용자와 상인들은 암호 화폐 자산의 편리성과 보안성을 좋게 평가하지만, 그들 중에 하루 만에 23%의 가치가 하락하는 것을 반기는 사람은 없을 것이다. 지금까지, 가장 흔하게 제시되었던 해결책은 발행자 보증 자산 방식이다. 서브화폐의 발행자는 발행 및 소각 권한을 지니고, 1단위의 기반 화폐(예를 들어, 금, USD)가 주어졌을 때 언제든지 1단위의 서브화폐를 제공하도록 만드는 것이다. 그런 다음 발행자는 누군가가 1단위의 해당 서브화폐를 돌려주었을 때 다시 1단위의 기반 화폐를 제공할 것을 약속한다. 이 매커니즘은 발행자가 신뢰 가능하다는 가정 하에, 어떤 비 암호 화폐 자산이라도 암호 화폐 자산으로 "승격"될 수 있도록 한다.

그러나 현실적으로는, 모든 발행자를 신뢰할 수 있는 것은 아니며, 금융 인프라가 너무 취약하거나 해당 서비스가 존재하기에는 너무 적대적인 경우도 있다. 금융 파생상품이 여기에서 대안이 될 수 있다. 여기서 단일 발행자가 자산을 지지하기 위해 자금을 제공하는 대신, 암호 화폐 관련 자산(예: ETH)의 가격이 올라갈 것에 배팅한 탈중앙화된 금융시장의 참여자들이 해당 역할을 한다. 헤징 계약은 자산을 에스크로로 가지고 있기 때문에 발행자와 다르게 참여자들은 사익을 추구할 방법이 없다. 물론 이를 위해서는 가격 티커라는 외부의 신뢰할 만한 요소가 필요하기 때문에 완전한 탈중앙화를 이루었다라고는 할 수 없지만, 이것만으로도, 필요한 금융 인프라 및 사기의 가능성을 줄이는 면에서는 매우 큰 발전이라고 여겨진다(가격 정보를 제공하는 것은 발행자가 되는 것과는 다르게 특별한 라이센스를 필요로 하지 않고, 또 무료 서비스로 이루어질 수 있다).

정체성과 평가 시스템

최초의 대안 암호 화폐였던 네임코인(opens in a new tab)은 사용자가 자신의 이름과 같은 몇몇 데이터를 공개된 데이터베이스에 저장하는 방식의 이름 등록 시스템을 구축하기 위해 비트 코인과 비슷한 블록체인 기술을 시도하였다. 가장 대표적인 사용 예시는 DNS(opens in a new tab) 시스템으로, 예를 들어 "bitcoin.org" (혹은 네임코인으로 나타내면 "bitcoin.bit")라는 도메인 이름과 IP 주소를 연결하는 것이었다. 다른 사용 예시로는 이메일 인증이나, 잠재적으로 더 발전된 평가 시스템이 있었다. 이러한 네임코인과 같은 등록 시스템을 이더리움 상에서 간단한 계약으로 만들어 보면 다음과 같다.

def register(name, value):
  if !self.storage[name]:
    self.storage[name] = value

계약 자체는 매우 간단한데, 결국에는 추가는 가능하되 수정 및 삭제는 불가능한 이더리움 네트워크 안에 있는 데이터베이스이면 되는 것이다. 누구든지 원하는 이름을 등록할 수 있고, 그 등록은 영원히 불변한다. 더 정교한 이름 등록 계약의 경우에는 "함수 조항"이 있어서 다른 계약의 요청을 수행할 수도 있게 되는데, 예를 들어 해당 이름의 "소유자"(즉, 첫 등록자)가 데이터나 소유권을 이전할 수 있도록 하는 매커니즘 등을 수행할 수 있다. 여기에 평가나 신뢰도 기능이 있는 웹도 추가할 수 있다.

탈중앙화된 파일 스토리지

과거 몇 년 동안 수 많은 온라인 파일 스토리지 스타트업들이 생겨났으며, 이 중 가장 유명한 Dropbox의 경우는 사용자가 매월 수수료를 내면 하드 드라이브의 백업 데이터를 업로드하여 백업을 보관하는 서비스를 제공하고 사용자가 액세스할 수 있도록 하였다. 하지만, 현재의 파일 스토리지 시장은 상대적으로 비효율적이라고 할 수 있다. 현존하는 솔루션들에서 특히 무료 할당량이나 엔터프라이즈 수준의 할인이 적용되지 않는 20~200 GB에 해당하는 "불쾌한 골짜기"인 중간 용량의 경우를 살펴보면 비용이 특히 높아서, 1개월 비용이 이미 스토리지를 그냥 사는 것보다 더 비싸게 책정되어 있다. 이더리움 계약을 활용하면 사용자들이 자신의 하드디스크 중 미사용 중인 부분을 빌려주고 보상으로 돈을 받는 형태의 탈중앙화된 저장 공간 생태계를 만들 수 있으며, 이러한 방식은 가격을 크게 낮출 수 있을 것이다.

이를 구현함에 있어 핵심적인 부분을 우리는 "탈중앙화된 Dropbox 계약"이라고 부르기로 하였다. 이 계약은 다음과 같이 작동한다. 우선, 데이터를 여러 개의 블록으로 쪼개고, 프라이버시를 위해 각 블록을 암호화하고, 이들 블록들로 머클 트리를 만든다. 이후 다음의 규칙, 즉 머클 트리에서 매 N개의 블록들마다 랜덤 인덱스를 정하고(계약 코드에서 확인 가능한 앞선 블록 해시를 이용하여 랜덤 함수를 구현할 수 있다), 해당 인덱스에 해당하는 블록의 소유권에 대해 간단한 결제 검증 증명을 제공하는 첫 번째 참여자에게 X 이더를 제공한다는 규칙을 담은 계약을 만들게 된다. 나중에 사용자가 해당 파일을 다시 다운로드하고 싶을 때에는 마이크로 결제 프로토콜(32킬로바이트당 1 szabo 등)을 활용하여 해당 파일을 복구할 수 있다. 이 때 수수료를 가장 많이 낮추는 방법은 지불을 위한 거래를 최대한 늦추면서, 매 32킬로바이트마다 더 낮은 가스 값의 거래가 있는지 확인하고, 있을 시 논스(Nonce) 값을 유지한 채 이 거래로 대체하는 방법일 것이다.

이 프로토콜의 중요한 특징은, 비록 하나의 파일 저장을 위해 여러 개의 랜덤 노드를 신뢰해야 하는 것으로 보일 수 있지만, 실제로는 파일을 여러 개의 조각으로 쪼개서 나누어 저장하고, 이후 조각들이 각 노드에 잘 저장돼 있는지 계약으로 확인하는 방식이기 때문에 리스크를 거의 0으로 만들게 된다는 점이다. 만약 계약이 계속 비용을 지불하고 있다면, 해당 파일은 아직 누군가가 잘 저장하고 있다는 것을 의미하며, 이는 암호학적으로 증명이 가능하다.

DAO (탈중앙화, 자동화된 조직)

"탈중앙화된 자율 조직"은 67% 이상의 대다수가 모일 시 조직의 자금을 소비하고 코드를 수정할 수 있는 권리를 가지게 되는, 특정 구성원들 혹은 주주들로 이루어진 가상의 조직을 말한다. 구성원들이 모여서 조직이 자금을 어떻게 배분해야 하는지 결정하게 된다. 탈중앙화 자율 조직(DAO)의 자금을 분배하는 방법은 보상, 급여 등이 가능하고, 더 특별한 매커니즘이 있다고 한다면 보상을 위한 내부 화폐 이용 등이 있을 것이다. 이 방법 자체는 전통적인 기업 혹은 비영리 단체가 했던 방법이지만, 이를 집행하기 위해 암호화된 블록체인 기술을 사용한다는 점이 다르다. 지금까지의 DAO는 "탈중앙화된 자율 기업"(DAC)과 배당, 주식 및 주주에 관한, 즉 "자본주의" 모델에 관한 얘기가 대부분이었지만, 이외에도 "탈중앙화된 자율 커뮤니티" 개념이 존재한다. 여기서는 의사 결정에 관해 모든 구성원이 동등한 결정권을 가지고 있고, 67% 이상의 구성원이 모여야 특정 구성원을 추가 혹은 제외할 수 있는 권리를 가지게 된다. 따라서 1명당 1개의 멤버십을 가져야 한다는 조항 또한 구성원들이 모임에 따라 강제되는 것이다.

DAO를 코드화 하는 대략적인 방법은 다음과 같다. 가장 단순한 설계는 전체의 2/3 이상이 수정에 동의할 경우 자체 수정되는 코드 조각을 작성하는 것이다. 물론 정확히는 코드 자체는 수정이 불가하지만, 수정이 가능한 저장 공간에 특정 주소를 저장해 놓고, 이 주소에 접근할 수 있는 코드를 별도의 계약에 삽입해 놓음으로써 구현이 가능하다. 이러한 기본적인 DAO 계약에는 거래에 사용되는 데이터 형태에 따라 다음과 같은 3가지 거래 유형이 존재할 것이다.

인덱스 i로 제안을 등록하여 저장 공간 인덱스 K의 주소를 값 V로 변경하기 위한 [0,i,K,V]
[1,i] 제안에 찬성하는 표를 던진다 i
[2,i] 제안 완료하기 i 충분한 표가 모아지면

그런 다음 계약은 이들 각각에 대한 조항을 담게 될 것이다. 또한 모든 공개된 저장 공간 변화 이력, 투표자 목록 등을 기록해 나갈 것이다. 전체 구성원 명단도 가지고 있게 된다. 저장 공간 수정 제안에 대해 2/3 이상의 구성원이 투표할 경우, 최종 집행을 위한 거래가 실행되어 해당 수정 사항을 수행할 것이다. 더 발전된 방식으로는 거래를 발생시키거나, 구성원을 추가 혹은 제외하는 등의 기능을 위한 투표 시스템, 혹은 유동 민주주의(opens in a new tab) 기반 투표 시스템(누구든지 투표권을 위임할 수 있으며, 투표권은 전이가 이루어지기 때문에, A가 B에 그리고 B가 C에 위임할 시 결국 C가 A의 투표권을 행사할 수 있음) 등이 있을 것이다. 이러한 설계는 DAO가 탈중앙화된 커뮤니티로서 유기적으로 성장할 수 있도록 할 것이며, 나중에는 누가 구성원인가를 알아내는 작업을 전문가가 맡게 될 것이다. 물론 여기서의 전문가는 오늘날의 전문가 개념과는 달라서, 각 커뮤니티 구성원 개인이 교체됨에 따라 언제든지 쉽게 추가 혹은 제외될 수 있다.

또 다른 모델은 탈중앙화된 기업으로, 어떤 계정이든 0 혹은 일정 수준의 주식을 소유할 수 있고, 의사결정을 위해 2/3 이상의 주식이 필요하게 된다. 완전한 뼈대는 주식을 매매하고, 주문 및 거래를 성사시키는(종종 계약 자체에 거래 관련 로직을 담고 있게 된다) 등의 역할을 지닌 자산 관리 기능을 가지게 될 것이다. 위임은 유동 민주주의 형태에서도 존재하며, "이사회" 개념을 형성할 것이다.

추가 어플리케이션

1. 저축 지갑. 예를 들어 Alice가 자신의 돈을 안전하게 보관하고 싶지만 개인 키를 잃어버리거나 누군가 그녀의 개인 키를 해킹할까봐 걱정한다고 하자. 그녀는 아래와 같이 Bob이라는 은행과 이더에 대한 계약을 진행한다.

Alice 혼자서는 하루에 최대로 전체의 1%에 해당하는 금액만 인출할 수 있다.
Bob 또한 혼자서는 하루에 최대 1%만 인출할 수 있다. 단, Alice는 Bob의 이 1% 인출권 조차도 박탈할 수 있는 거래를 생성할 수 있다.
Alice와 Bob이 함께라면 한도 없이 인출할 수 있다.

통상, Alice에게는 하루 1%의 인출만으로도 충분할 것이고, 더 많은 인출이 필요할 경우 그녀는 Bob에게 요청하여 도움을 구할 수 있다. 만약 Alice의 키가 해킹당한다면, 그녀는 바로 Bob에게 가서 돈을 다른 새로운 계약에 옮기도록 할 수 있다. 만약 그녀가 키를 잃어버린 경우에는, Bob은 돈을 인출할 수 있다. 만약 오히려 Bob이 악의가 있다고 판명하는 경우, 그녀는 단순히 Bob의 인출 능력을 박탈하기만 하면 된다.

2. 농작물 보험. 금융 파생상품은 반드시 화폐나 가격 인덱스로만 만들 수 있는 것은 아니고, 날씨 데이터 피드로부터도 만들 수 있다. 아이오와주의 한 농부가 강수량에 반비례하여 작동하는 파생상품을 구매하였다면, 가뭄이 왔을 때 파생상품으로부터 금융 이익을 볼 수 있으므로 좋을 것이고, 물론 비가 충분히 온 경우에도 추수가 잘 될 것이므로 또한 좋을 것이다. 이는 일반적으로 자연 재해 보험에도 적용이 가능하다.

3. 탈중앙화된 데이터 피드: 차액에 대한 금융 계약의 경우 쉴링코인(opens in a new tab)이라 부르는 프로토콜을 통해 데이터 피드를 탈중앙화하는 것이 실제로 가능할 수 있을 것이다. 쉴링코인은 기본적으로 다음과 같이 작동한다. N개의 그룹이 각각 특정 값(ETH/USD 등)을 제시하면 이를 오름차순으로 나열한 후, 25~75번째 백분위수 구간에 있는 값을 제시한 그룹에 보상으로 하나의 토큰이 주어지게 된다. 모든 사람은 다른 모두가 제시하는 답을 제시할 동기를 가지고 있으며, 많은 수의 참가자가 현실적으로 동의할 수 있는 유일한 가치는 명백한 기본값인 진실이다. 이는 이론적으로 ETH/USD 값 뿐 아니라, 베를린의 기온, 심지어는 특정한 힘든 연산의 결과물 등의 데이터도 제공할 수 있는 탈중앙화된 프로토콜을 생성한다.

4. 스마트 다중서명 에스크로. 비트코인에서는 다중서명 거래 계약을 만들 수 있는데, 예를 들어 5개의 키 중 3개가 모이면 자금을 소비하도록 할 수 있다. 이더리움은 이를 더 세분화할 수 있다. 예를 들어 5개 중 4개가 모일 경우는 모든 자금을, 3개일 경우는 하루 최대 10%까지, 2개일 경우는 0.5%까지 소비 가능하도록 할 수 있다. 추가로, 이더리움 다중서명은 비동기이다 - 두 당사자가 다른 시간에 블록체인에 서명을 등록하며 마지막 서명이 자동적으로 거래를 전송시킬 수 있다.

5. 클라우드 컴퓨팅. EVM 기술은 검증 가능한 연산 환경을 만드는 데에도 쓰일 수 있으며, 사용자는 다른 참여자에게 연산 수행을 요청할 수 있고, 필요에 따라 랜덤하게 체크포인트를 선택하여 연산 작업이 올바르게 이루어졌었는지 증명을 요청할 수도 있다. 이는 클라우드 컴퓨팅을 가능케 한다. 어떤 사용자라도 자신의 데스크탑, 노트북 혹은 특수한 서버를 이용하여 참여할 수 있고, 보증금 제도와 위 랜덤 증명 시스템을 통해 이 네트워크를 신뢰 가능하도록 만들 수 있다(노드는 가짜 연산을 통해 사익을 추구할 수 없다). 물론 이러한 시스템이 모든 작업에 적합한 것은 아니다. 예를 들어 고도화된 프로세스 간 통신(IPC)이 필요한 작업의 경우에는 수 많은 노드로 이루어진 클라우드 환경에서 수행하기가 어렵다. 하지만 이외의 작업들(SETI@home, folding@home, 유전자 알고리즘 등)의 병렬 연산은 플랫폼 상에서 쉽게 구현될 수 있다.

6. 개인 간 갬블링. Frank Stajano, Richard Clayton의 사이버다이스(opens in a new tab) 등 다양한 개인 간 갬블링 프로토콜을 이더리움 블록체인 상에서 구현할 수 있다. 가장 단순한 갬블링 프로토콜은 다음 블록의 해시 값 차이에 대한 계약이 될 것이고, 여기서 더 발전한다면 조작이 불가능하고 수수료가 0에 가까운 갬블링 서비스를 만들 수 있을 것이다.

7. 예측 시장: 오라클이나 쉴링코인 등이 있다면 예측 시장은 쉽게 구현할 수 있으며, 실제로 쉴링코인을 통한 예측 시장은 탈중앙화된 조직의 거버넌스 프로토콜로 퓨타키(futarchy)(opens in a new tab)를 적용한 첫 번째 메인 어플리케이션으로 알려져 있다.

8. 정체성과 평가 시스템을 기반으로 사용하는 온체인 탈중앙화된 마켓플레이스

기타 참고 사항

변형 GHOST 구현

"Greedy Heaviest Observed Subtree" (GHOST) 프로토콜은 Yonatan Sompolinsky과 Aviv Zohar가 December 2013(opens in a new tab)에서 처음으로 소개한 혁신이다. GHOST는 짧은 승인 소요 시간을 지닌 블록체인 프로토콜의 공통적 단점이었던 낮은 보안성과 높은 부실 블록률을 해결하기 위해 만들어졌다. 신규 생성된 블록이 네트워크를 통해 다른 노드로 퍼져나가기 까지는 일정 시간이 소요되는데, 그 동안 다른 노드들 중에서 부실 블록이 발생할 수 있고, 이는 낭비로 이어지게 된다. 예를 들어 채굴자 A가 블록을 채굴하였는데 이를 채굴자 B에게 전달하는 동안 B도 늦게나마 블록을 채굴하였다고 한다면, 채굴자 B의 블록은 결국 낭비였던 것이고, 네트워크의 보안성에 기여를 못 한 것이 된다. 또한 중앙화 문제가 있다. 채굴자 A가 30%의 해시 파워를 가진 채굴 풀이고 B가 10%의 해시 파워를 가진 경우 A는 70%의 시간 동안(나머지 30%의 시간 동안 A는 마지막 블록을 생성하므로 즉시 채굴 데이터를 얻을 것이기 때문) 부실 블록을 생성할 위험이 있는 반면 B는 90%의 시간 동안 부실 블록을 생성할 위험이 있다. 따라서, 블록 인터벌이 짧아서 부실률이 높게 나오는 경우, 블록의 길이 측면에서 A가 더 효율적이게 된다. 이 경우, 블록을 더 빨리 만드는 블록체인은 네트워크 해시파워의 점유율을 더 높이면서 결국은 전체 채굴 프로세스를 지배하게 될 가능성이 큰 하나의 채굴 풀로 이어질 가능성이 매우 높다.

이러한 네트워크 보안에 있어서의 첫 번째 문제를 GHOST는 어떤 체인이 가장 긴 지 정할 때 부실 블록도 고려하여 비교하도록 함으로써 해결하였다고 Sompolinsky와 Zohar는 설명한다. 즉, 마지막 공식 블록과 그 앞선 블록들(부모 및 조상) 뿐 아니라, 마지막 공식 블록 뒤로 이어진 부실 블록(이더리움에서는 삼촌이라고 부른다)들 또한 체인 길이 계산 식에 포함하여서, 가장 긴 작업 증명을 결정하도록 한 것이다. 두 번째 문제였던 해시파워 중앙화 문제 해결을 위해 우리는 Sompolinsky 및 Zohar의 방식에 추가로, 부실 블록에 리워드도 제공하기로 하였다. 하나의 부실 블록은 기본 보상의 87.5%를, 해당 부실 블록의 앞선 조카 블록은 나머지 12.5%를 받도록 하였다. 다만 거래 수수료는 삼촌 블록들에게는 주어지지 않는다.

이더리움은 7단계까지 내려가는 GHOST의 간소화 버전을 구현한다. 상세 방식은 아래와 같다.

하나의 블록은 반드시 1개의 부모 블록 및 0개 이상의 삼촌 블록을 가리켜야 한다.
블록 B의 삼촌 블록은 반드시 아래 특성을 만족해야 한다.
- B의 k세대 조상의 직계 자식이어야 하며, 반면 2 <= k <= 7 이다.
- B의 조상이 아니다.
- 삼촌 블록은 반드시 유효한 블록 헤더여야 하지만, 앞서 검증을 받았거나 혹은 유효한 블록일 필요는 없다.
- 삼촌 블록은 이전 블록들에 포함된 모든 삼촌 블록 및 같은 블록에 포함된 모든 다른 삼촌 블록과 달라야한다. (비 이중 포함)
블록 B에 있는 모든 삼촌 블록 U에 대하여, 블록 B의 채굴자는 코인베이스 보상에 추가로 3.125%를 얻고, 블록 U의 채굴자는 표준 코인베이스 보상의 93.75%를 얻는다.

이렇게 7세대까지만 포함가능한 삼촌 블록과 함께, GHOST의 제한 버젼은 2가지 이유로 사용됐다. 첫 번째로, 무제한적인 GHOST는 특정 블록의 유효한 삼촌 블록을 정하기 위한 계산을 지나치게 복잡하게 만든다. 두 번째로, 제한 없는 GHOST 방식을 이더리움 보상 시스템에 적용한다면, 채굴자들이 공개적 해커의 체인이 아닌 메인 체인에서 채굴을 진행해야 할 이유, 즉 인센티브가 사라지게 된다.

수수료

블록체인에 추가되는 모든 거래는 해당 거래 정보를 다운로드하고 검증함에 따른 네트워크 비용을 유발하기 때문에, 거래 남용을 막기 위해 일반적으로 거래 수수료와 관련된 규제 매커니즘이 필요하다. 비트 코인에 사용되는 기본 접근법은 순수하게 자발적인 수수료가 있고 채굴자가 문지기로서의 역할을 하며 동적인 최소값을 설정하는 데 의존한다. 이 접근법은 채굴자와 거래 생성자 간 수요와 공급 법칙에 의해 가격이 결정되도록 하는 "시장 기반" 방식이라는 이유로 비트 코인 커뮤니티에서 매우 우호적으로 받아들여지고 있다. 다만 이 방식은 문제점이 있는데, 거래가 처리되는 전체 과정에는 시장 원리가 적용되지 않는다는 점이다. 언뜻 거래 처리를 채굴자가 거래 생성자에게 제공하는 서비스라고 볼 수 있지만, 사실 거래는 결국 한 명의 채굴자가 블록으로 포함한 이후에 네트워크 상의 모든 노드로 퍼지며 연이어 처리되는 방식이기 때문에, 거래 처리에 소요되는 비용의 대부분은 해당 거래를 블록에 포함하느냐 안하냐를 결정하는 해당 한 명의 처리자가 아닌 나머지 네트워크, 즉 제 3자에 의해 발생된다고 보아야 한다. 따라서, 공유지의 비극 문제가 일어나기 쉬워진다.

물론, 시장 기반 매커니즘의 이러한 결점은 특히 부정확한 가정이 적용되면 마법처럼 상쇄될 수 있다. 해당 가정은 다음과 같다. 다음을 생각해 본다면

거래를 처리하는 데 k번의 연산이 소요되고, 이를 포함한 채굴자에게는 kR만큼 보상이 주어지는데, R은 발신자가 정하고, 채굴자는 k 및 R 값을 사전에 (대략적으로) 볼 수 있다.
운영은 모든 노드에 대하여 C의 처리 비용을 갖고 있다 (곧, 모든 노드는 동일한 효율성을 가진다)
총 N개의 채굴 노드가 있으며, 각 노드의 처리 능력은 동일하다 (곧, 전체의 1/N)
모든 노드가 채굴에 참여하고 있다.

채굴자는 보상이 비용보다 큰 경우에만 거래를 진행할 것이다. 따라서 채굴자가 다음 블록을 처리할 확률이 1/N이므로 예상 보상은 kR/N이고, 채굴자의 처리 비용은 단순히 kC이다. 따라서 채굴자는 kR/N > kC, 또는 R > NC인 경우에만 거래를 포함한다. R은 발신자가 제공하는 연산당 수수료 값인데, 이는 해당 거래에 의해 만들어지는 최소한의 이득이라고 볼 수 있으며, NC는 연산당 전체 네트워크가 소비해야 하는 비용이라고 볼 수 있다. 따라서, 채굴자는 전체 공공의 이익이 비용보다 큰 거래만 포함시키는 인센티브를 갖는다.

하지만 실제로는 위 가정들은 몇 가지 중요한 점에서 차이점이 있다.

블록이 다른 노드로 퍼져 나가는 과정에는 검증 시간이 소요되며 이는 기껏 만든 블록이 부실 블록이 될 가능성을 높이기 때문에, 채굴자는 다른 검증 노드에 비해서 더 많은 비용을 지불하게 된다.
채굴에 참여하지 않는 노드도 있다.
사실상 채굴력 분배는 급진적으로 불평등하게 될 수도 있다.
네트워크에 위해를 가하려는 투기자들, 정적들, 혹은 그냥 이상한 사람들이 존재하며, 이들은 자신들의 비용에 비해 전체 네트워크 검증 비용이 훨씬 높게 나오는 계약을 생성할 수 있다.

(1)은 채굴자들이 블록에 포함하는 거래의 수를 줄이도록 유도하고, (2)는 NC를 증가시킨다. 따라서 이들 두 효과는 적어도 부분적으로 서로를 상쇄한다.^{방법 알아보기(opens in a new tab)} (3)과 (4)가 주요한 문제이다. 이 문제들을 해결하기 우리는 단순하게 상한을 도입하였다. 즉, 어떠한 블록도 장기적인 지수이동평균의 BLK_LIMIT_FACTOR배 이상 연산을 수행할 수 없도록 하였다. 구체적으로

blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +
floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)

BLK_LIMIT_FACTOR와 EMA_FACTOR는 65536과 1.5로 설정될 상수이지만, 추가 분석 후에 변경될 수 있다.

비트 코인에는 데이터가 많이 담긴 블록을 만들지 않도록 유도하는 또 다른 요소도 있다. 크기가 큰 블록은 네트워크로 퍼져 나가는 데 시간이 오래 걸려서 결국 부실 블록 처리될 가능성이 높아진다는 점이다. 이더리움에서는, 가스를 많이 소비하는 블록의 경우 용량이 커서이기도 하지만 블록에 담긴 각 상태전환 함수를 검증하기 위한 시간도 더 많이 걸리기 때문에 퍼져 나가는 데 시간이 더 오래 걸린다. 이러한 지연이 일으키는 부정적인 효과는 비트 코인에서 큰 문제이지만, 이더리움에서는 GHOST 프로토콜 덕분에 덜하다. 즉, 블록에 한도를 부여하는 방식이 더 안정적인 기준선을 제공하는 것이다.

연산과 튜링-완전

중요한 점은 이더리움 가상 머신이 튜링 완전하다는 것이다. 이는 EVM 코드가 수행 가능한 어떠한 형태의 연산이라도 코드로 작성될 수 있다는 점이며, 여기에는 무한루프도 포함된다. EVM 코드는 루프를 다음의 2가지 방식으로 지원한다. 첫 번째로, JUMP 명령어는 프로그램이 코드의 이전 부분으로 돌아갈 수 있도록 하고, JUMPI 명령어는 조건부로 되돌아갈 수 있도록 하며, 예를 들어 while x < 27: x = x * 2와 같은 코드를 허용한다. 두 번째로, 계약은 다른 계약을 실행할 수 있어서 필요 시 재귀 방식의 루프를 만들 수 있다. 물론 이는 악의적인 사용자가 채굴자와 전체 노드를 무한 루프에 빠지게 하여 불능으로 만들 수 있다는 문제를 수반한다. 이 문제가 생기는 이유는 컴퓨터 공학에서 정지 문제로 부르는 현상 때문인데, 프로그램이 있을 때 이것이 언젠가 멈출지 혹은 영원히 멈추지 않을지 미리 알 수 있는 방법이 일반적으로 없다는 것이다.

이에 대해서는 앞서 상태전환 섹션에서 설명하였듯이, 거래에 쓰이는 연산 수에 대해 최대값을 설정하게 함으로써 해결할 수 있었으며, 만약 더 많은 연산이 쓰일 시 거래는 되돌려지는 반면 수수료는 그대로 지불된다. 메시지는 같은 방식으로 작동한다. 우리의 해결책에 숨어있는 유인을 보기 위해 다음의 4가지 예시를 고려한다.

한 해커가 무한루프를 일으키는 계약을 생성하고, 이 루프를 활성화하는 거래를 채굴자에게 전송한다. 채굴자는 거래를 처리하며 무한루프를 실행하고, 가스가 다할 때까지 기다린다. 중간에 가스가 다하여 실행이 멈추는 경우에도, 거래 자체는 유효하기 때문에 채굴자는 해당 해커에게 이 때까지의 연산에 대한 수수료를 청구할 수 있다.
해커가 매우 긴 무한루프를 채굴자에게 주어서 연산이 끝나기까지 매우 오랜 시간이 걸리도록 할 수 있고 연산이 끝났을 시에는 다른 몇 개의 신규 블록이 만들어져 있는 상태가 되기에 채굴자는 수수료를 청구하기 위한 거래를 블록에 담을 수 없게 된다. 하지만, 해커는 실행이 수행할 수 있는 연산 단계의 수를 제한하는 STARTGAS 값을 제출해야 하므로, 채굴자는 사전에 과도한 연산 단계가 이루어질 것임을 알 수 있다.
해커는 send(A,contract.storage[A]); contract.storage[A] = 0와 같은 코드를 본 후 첫 번째 단계까지만 실행되도록 가스 양을 조절하여 거래를 생성할 수 있다(즉, 잔고를 줄이는 단계가 가스 부족으로 실행되지 않도록 하여, 인출만 계속 한다는 것이다). 계약 생성자는 자신의 계약이 이렇게 악용될 수 있다는 점을 걱정하지 않아도 되는데, 가스 부족으로 실행이 중단된 위와 같은 경우, 이전까지의 거래는 다시 되돌려지기 때문이다.
금융 계약은 위험성을 줄이기 위해 9개의 소유권 데이터 피드의 중간값을 취하여 작동한다. 해커는 DAO 섹션에서 설명되었던 변수-주소 호출 매커니즘을 통해 수정되도록 설계된 데이터 피드 중 하나를 넘겨받은 후 이를 무한 루프로 변경함으로써, 자금 관련한 작업을 진행할 때마다 가스 부족 현상이 일어나도록 시도한다. 하지만, 금융 계약은 이러한 문제를 막기 위해 메시지에 있어 가스 한도를 설정할 수 있다.

튜링 완전의 반의어는 튜링 불완전으로, JUMP와 JUMPI 명령어가 존재하지 않고 콜스택에는 한 번에 한 개의 계약만 존재할 수 있다. 이 시스템을 사용하는 경우, 계약 실행 시의 비용이 해당 계약의 크기에 의해 결정될 것이기에, 위에서 설명되었던 수수료 시스템이나 우리가 제시한 해결책의 유효성에 대한 불확실성은 고려하지 않아도 될 수 있다. 또한, 사실 튜링 불완전은 그렇게 큰 제한점이 되지는 않는다. 우리가 내부적으로 살펴 본 모든 계약 시뮬레이션들 중 루프가 필요한 경우는 단 1건 뿐이었으며, 그 1건조차도 단 한 줄의 코드 조각을 26번 반복시킴으로써 대체할 수 있었기 때문이다. 그렇다면 그렇게 큰 유용성이 없어 보이는 튜링 완전을 위해 이렇게 많은 것을 고려하기보다는, 처음부터 튜링 불완전으로 하면 좋지 않을까? 그러나 사실상, 튜링-불완전은 해당 문제에 대한 좋은 해결책과는 거리가 멀다. 왜 그런지, 아래 계약을 통해 알아보자.

C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (run one step of a program and record the change in storage)

이제 A에게 거래를 전송한다. 따라서 총 51번의 거래에서 연산 단계가 최대 2⁵⁰번 이루어지는 계약을 갖게 된다. 채굴자들은 특정 계약과 거기서 재귀적으로 실행되는 다음 계약들에서 소요될 수 있는 최대 연산 횟수를 미리 확인함으로써 이러한 연산 폭탄을 사전에 탐지할 수 있겠지만, 이 경우 채굴자들은 아예 계약이 다른 계약을 생성하는 것 자체를 막도록 할 것이다(26개 계약을 생성하고 실행하는 것이 한 개의 계약에서 모두 이루어지도록 할 수 있기 때문이다). 또 다른 문제는 메시지의 주소 필드가 변수라는 점인데, 주어진 계약이 어떤 다른 계약을 호출할 지 미리 알 수 없다. 따라서 우리는 놀라운 결론에 도달하게 된다. 튜링 완전은 처음에 만들기는 어려워도 이후 관리하기가 용이하고, 튜링 불완전은 만들기는 쉬워도 결국 여러 가지 상황을 고려하며 관리해야 한다는 점이다. 그렇다면, 그냥 튜링 완전으로 하는 것이 더 낫지 않겠는가?

통화와 발행

이더리움 네트워크는 자체 내장 통화인 이더를 포함하며, 이더는 다양한 형태의 디지틸 자산들 간에 효율적인 거래가 이루어지기 위한 유동성을 제공하고, 더 중요하게는, 거래 수수료를 지불하기 위한 매커니즘을 제공하는 두 가지 역할을 맡고 있다. 추후의 혼란을 방지하고 편의를 위해(비트 코인에서 현재 이루어지고 있는 mBTC/uBTC/사토시의 토론 참조), 아래 단위를 미리 적어놓겠다.

1: wei
10¹²: szabo
10¹⁵: finney
10¹⁸: ether

이는 "달러"와 "센트", 혹은 "BTC"과 "satoshi"와 같은 개념의 확장판이라고 보면 된다. 가까운 미래에는, "이더"는 일반 거래에서, "핀니"는 마이크로거래에서, "szabo" 와 "wei"는 수수료와 프로토콜 도입에 관한 기술적 논의 과정에서 사용될 것이다. 이외의 단위들은 나중에 유용한 부분이 있겠지만 현재는 클라이언트에 포함하지 않아야 한다.

발행 모델은 하기와 같다.

이더는 BTC당 1000~2000 이더 가격으로 판매될 것이며, 이는 마스터코인이나 NXT 플랫폼에서 성공적으로 도입되었던 방식으로 이더리움 유지 및 개발 비용을 지원하기 위한 매커니즘이다. 초기 구매자들은 큰 할인 혜택을 받을 것이다. 판매 과정에서 얻은 BTC은 모두 개발자들의 보상 및 보수, 이더리움 및 암호 화폐 생태계의 다양한 영리 및 비영리 프로젝트에 투자하기 위해 쓰일 것이다.
전체 판매량(60102216 ETH)의 0.099x는 초기 기여자들에게 보상하기 위해 기관에 배정하거나 제발생 블록 이전의 ETH 기반 비용을 지불하기 위해 쓰일 것이다.
0.099x 전체 판매량은 장기 적립금으로 보관될 것이다.
0.26x 전체 판매량은 이후 계속 매년마다 채굴자들에게 배정될 것이다.

구분	발행 직후	1년 후	5년 후
통화 단위	1.198X	1.458X	2.498X
구매자	83.5%	68.6%	40.0%
발행 전 사용된 적립금	8.26%	6.79%	3.96%
발행 후 사용된 적립금	8.26%	6.79%	3.96%
채굴자	0%	17.8%	52.0%

장기 공급 증가율 (퍼센트)

연속적인 통화 발행에도 불구하고, 공급 증가율은 비트코인과 마찬가지로 시간이 흐르면서 0으로 수렴하게 된다.

이러한 모델을 택한 이유는 2가지이다. 첫 번째는 적립금의 존재와 그 규모이고, 두 번째는 비트코인에 존재하는 한계 있는 공급과는 다르게, 지속적으로 증가하는 연속 공급의 존재이다. 적립금의 정당성을 설명하자면 다음과 같다. 만약 적립금 제도가 없고, 연속 발행이 0.217x로 감소해서 동일한 인플레이션율을 제공한다면, 전체 ether 수는 16.5% 감소할 것이고, 따라서 각 단위의 가치는 19.8% 증가하게 된다. 그리고 균일하게 각 단위가 이전처럼 가치를 갖기 위해, 19.8% 더 많은 양의 ether가 판매 된다. 조직은 또한 1.198배의 BTC를 갖게 되는데, 이는 원래의 BTC와 추가적인 0.198x의 두 조각으로 분할되는 것으로 간주할 수 있다. 이 상황은 결국, 적립금 제도를 두었을 때와 정확히 동일한 양의 적립금을 설정한 것이라고 볼 수 있는데, 다른 점은 이 적립금이 이더 단위가 아닌 BTC이라는 점이다. 즉, 이더의 가치에 도움이 되는 유형의 적립금은 아니라는 것이다.

영구적인 공급량 선형 증가 모델은 비트 코인에서의 이른바 과도한 부의 집중화 현상이 생길 가능성을 줄이고, 개인이 이더를 얻을 기회를 지속적으로 제공하며, 동시에 이더를 계속 보유하고 있도록 유도하는데, 이는 공급 증가율이 시간이 지남에 따라 0으로 수렴하기 때문이다. 또한 우리들의 이론에 따르면, 일부 코인은 시간에 따라 소유자의 부주의, 사망 등의 사유로 시장에서 사라지게 되고, 그 소실률은 1년 동안의 총 공급량에 대한 특정 비율로 모델화할 수 있으며, 이 때 총 공급량은 연간 추가 발행량을 소실률로 나눈 값에 가까워질 것이다(예를 들어, 전체 공급량이 26배이고 소실률이 1%라면, 매년 0.26배가 소실되지만 다시 0.26배가 채굴되기 때문에 균형을 이루게 된다).

주목할 점은 앞으로 이더리움은 보안성을 위해 지분 증명 모델로 전환할 것이며, 이 경우 발행량은 매년 0~0.05배 사이로 줄어들게 될 것이라는 점이다. 만약 이더리움이 자금 부족 혹은 이외의 어떠한 이유에 의해서든 사라지게 되는 경우, 우리는 "사회적 계약"을 열어 둠으로써 누구라도 후속 버전의 이더리움을 만들 수 있도록 기회를 제공할 것이다. 이 때의 유일한 조건은 이더의 양이 가능한 한 60102216 * (1.198 + 0.26 * n)에 근접해야 한다는 점이다(여기에서 n은 발생 블록 이후의 총 년수를 말함). 창작자는 개발비용을 충당하기 위해 코인을 공개판매하거나 최대 허용 공급량과 지분증명으로 인한 공급량의 차액의 일부 혹은 전부를 할당할 수 있을 것이다. 사회적 계약에 따르지 않은 후속 버전 업그레이드는 정당하게 호환 버전으로 분기될 것이다.

채굴 중앙집중화

비트 코인 채굴 알고리즘은 한 노드가 특정 타겟 숫자(현재 약 2¹⁹²)보다 작은 해시 값을 얻을 때까지 채굴자가 조금씩 다른 블록 헤더들의 SHA256 해시 값을 계속해서 연산하는 방식으로 이루어진다. 그러나, 이러한 채굴 알고리즘은 두 가지 형태의 중앙집중화에 취약하다. 첫 번째로, 채굴 생태계는 현재 오로지 비트 코인 채굴만을 위해 설계되어 수천 배 더 효율적인 연산 효과를 가지는 ASIC에 의해 지배되고 있다. 이는 비트코인 채굴이 더 이상 이전처럼 탈중앙화, 평등주의적이지 않고, 참여하기 위해서는 수많은 자본을 투입해야 하는 분야가 되었음을 의미한다. 두 번째로, 대부분의 비트 코인 채굴자들은 직접 블록 검증을 행하지는 않으며, 대신 중앙집중화된 채굴 풀에 소속되어 블록 헤더를 제공한다. 이 문제는 심각하다고 볼 수 있는데, 이 글을 작성하는 시점에 3곳의 채굴 풀이 이미 비트 코인 네트워크 전체 처리 능력의 50%를 차지하고 있기 때문이다. 물론 풀이나 연합이 51% 공격을 시도할 시 채굴자들이 다른 채굴 풀로 이동할 수 있기는 하지만 말이다.

이더리움의 현재 의도는 채굴자가 상태로부터 무작위 데이터를 가져와 블록체인의 마지막 N 블록에서 무작위로 선택한 일부 거래를 연산하고, 결과의 해시를 반환해야 하는 채굴 알고리즘을 사용하는 것이다. 이는 두 가지 장점이 있다. 첫 번째로, 이더리움 계약은 어떠한 형태의 연산도 포함하므로, 이더리움 ASIC는 근본적으로 일반 연산을 위한 ASIC, 결국 더 나은 CPU와 같아질 것이다. 두 번째로, 채굴은 전체 블록체인에 대한 접근을 요구하므로, 채굴자들이 전체 블록체인을 저장하고 적어도 모든 거래를 증명할 수 있도록 강제한다. 이는 중앙집중화된 채굴 풀을 필요 없게 만든다. 물론, 채굴 풀은 보상 배분의 무작위성을 완화하는 기능 또한 가지고 있지만, 이 기능 또한 굳이 중앙화된 관리 없이 개인 간 풀로도 충분히 이루어질 수 있다.

이 모델은 아직 테스트 전이고, 계약 실행을 채굴 알고리즘으로 사용하는 경우 영리한 최적화(ASIC에 의한)를 방지하는데 어려움이 있을 수 있다. 다만 이 알고리즘의 재밌는 특징 중 하나는, 누구나 특정 ASIC를 만족시키기 위해 만들어진 계약을 블록체인에 다수 등록함으로써 "물을 흐릴" 수 있다는 점이다. ASIC 제조사들이 타인을 공격하기 위하여 이러한 방식을 사용할 경제적 이점이 존재한다. 따라서, 우리가 개발 중인 해결책은 완전히 기술적인 해결책이라기보다는 순응적이며 경제적이고 인간적인 해결책이다.

확장성

이더리움에서 확장성은 종종 문제점으로 거론된다. 비트코인과 같이 이더리움 또한, 모든 거래가 네트워크 상의 모든 노드에 의해 처리되어야 한다는 결점을 지니고 있다. 비트코인에 대하여, 현재 블록체인의 크기는 약 15GB이며, 1시간마다 약 1MB씩 증가하고 있다. 만약 비트코인 네트워크가 초당 Visa의 2000개의 거래를 처리한다면, 3초당 1MB씩 증가하게된다. (1시간에 1GB, 1년에 8TB). 이더리움의 경우도 유사한 문제를 겪을 가능성이 높은데, 이더리움은 전체 블록체인 히스토리가 아니라 상태만 저장하면 되므로 더 낫다고 볼 수 있지만, 비트 코인과 다르게 화폐 뿐 아니라 다양한 어플리케이션들까지 블록체인에서 처리되어야 하기 때문에 안 좋을 수 있다.

블록체인 사이즈가 커질 경우 중앙집중화 리스크가 생긴다. 예를 들어 사이즈가 100TB가 될 경우, 대부분의 일반 사용자들은 부담이 적은 SPV 노드를 사용할 것이고, 규모를 갖춘 몇몇 사업체만 풀 노드를 돌릴 수 있게 될 것이다. 이 경우, 해당 몇몇 사업체들이 손을 잡고 이익을 편취할 수 있게 된다(예: 블록 보상 바꾸기, 스스로에게 BTC 보내기). 라이트 노드는 이를 즉시 탐지할 방법이 없다. 물론 정직하게 풀 노드를 운영하는 곳이 1곳은 있어서 몇 시간 후에 Reddit 등의 커뮤니티에 해당 사기 거래 정보가 퍼져나갈 가능성은 있지만, 이는 너무 늦다. 이 시점에 일반 사용자들이 해당 거래가 담긴 블록을 블랙리스트화 하려고 해도, 이는 성공적인 51% 공격을 막으려고 하는 것과 같이 비현실적이다. 이는 비트코인의 경우 이미 발생하고 있는 문제이며, 이러한 문제를 경감시킬 수 있는 블록체인 변형suggested by Peter Todd(opens in a new tab)이 있다.

가까운 미래에 이더리움은 이 문제에 대처하기 위해 2개 전략을 추가로 구사할 것이다. 첫 번째로, 블록체인 기반 채굴 알고리즘 때문에, 최소한 모든 채굴자는 풀 노드가 되면서, 풀 노드 수의 하한선을 구성하는 것이다. 그러나 두 번째로, 그리고 더 중요하게, 각 거래가 처리된 이후 블록체인에 중간 상태의 트리 루트를 포함시킬 것이다. 블록 검증이 중앙집중화된 경우에도, 정직한 검증 노드가 단 하나라도 존재한다면, 검증 포로토콜을 통해 중앙집중화 문제가 해소될 수 있다. 만약 채굴자가 유효하지 않은 블록을 생성한다면, 해당 블록은 잘못된 형식이 되거나 혹은 상태 S[n]가 옳바르지 않다. S[0]는 옳다고 알려져 있으므로, 상태에는 S[i-1]는 참값인데 반해, 거짓인 첫 번째 상태 S[i]가 존재할 것이다. 검증 노드는 해당 인덱스 i를 "비유효성 증명", 즉 APPLY(S[i-1],TX[i]) -> S[i]를 처리하기 위한 패트리시아 트리의 일부와 함께 제시할 것이다. 노드들은 연산의 일부를 수행하기 위하여 이러한 노드들을 사용할 수 있고, 생성된 S[i]는 제공된 S[i]와 일치하지 않는 것을 보게된다.

또 다른 더욱 정교화된 공격에는 불완전한 블록을 생성하는 악의적인 채굴자들이 포함되므로, 블록이 유효한지 아닌지를 판단하기 위한 정보조차도 존재하지 않는다. 이에 대한 해결책은 챌린지-응답 프로토콜이다. 검증 노드들은 타겟 거래 인덱스 값들로 "챌린지"를 하고, 이후 라이트 노드들은 다른 채굴자 혹은 검증자들이 유효성의 증거로 패트리시아 트리의 일부를 제공하기 전까지 해당 블록을 신뢰하지 않는 방식이다.

결론

이더리움은 본래 범용 프로그래밍 언어를 통해 블록체인 기반 에스크로 거래, 인출 제한, 금융 계약, 갬블링 시장 등 다양한 가능을 만들 수 있도록 하는 암호 화폐의 업그레이드 버전으로서 고안되었다. 이더리움 자체는 특정한 어플리케이션을 직접 "지원"하지는 않지만, 튜링 완전한 프로그래밍 언어를 가능하게 함으로써 어떠한 형태의 거래나 기능이라도 임의의 계약을 통해 구현될 수 있도록 하였다. 그러나, 이더리움의 더욱 흥미로운 점은 이더리움 프로토콜은 단순한 화폐 그 이상을 보여준다는 점이다. 다양한 응용 방식들 중에서도 특히 탈중앙화된 파일 저장 공간, 연산 및 예측 시장과 같은 개념은 분산 컴퓨팅 산업의 효율성을 크게 개선할 잠재력을 지니고 있으며, 경제적 층을 처음으로 추가함으로써 개인 간 프로토콜에도 혁신을 가져올 것이다. 마지막으로, 돈과 전혀 관련이 없는 다양한 어플리케이션들도 있다.

임의의 상태 변환 함수를 적용한 이더리움 프로토콜은 고유한 잠재력을 지니고 있다. 즉, 데이터 저장 공간, 갬블링 혹은 금융 등 특정 분야를 위한 폐쇄형, 단일목적형 프로토콜이 아닌 개방형 프로토콜로서 작동하도록 설계되었으며, 향후 수 많은 금융 혹은 비금융 프로토콜들의 기반 역할을 하게 될 것이다.

참고 사항 및 추가 읽을거리

참고사항

관찰력이 좋은 독자라면, 비트코인 주소는 공개 키가 아니라, 타원곡선공개키의 해시로 이루어져 있다는 것은 눈치챘을 것이다. 그러나, 사실상 공개 키 해시를 공개 키 자체로써 의미하는 것은 암호학적으로 완벽히 무방하다. 이는 비트 코인의 고유한 디지털 서명 알고리즘 방식 때문인데, 공개 키는 ECC 공개 키의 해시 값이고, 서명은 ECC 공개 키와 ECC 서명을 결합한 값이며, 검증 알고리즘은 서명의 ECC 공개 키를 공개 키로써 제공된 ECC 공개 키의 해시 값을 통해 확인한 후 다시 ECC 서명을 ECC 공개 키를 통해 검증하는 방식으로 이루어진다.
기술적으로는, 앞선 11개 블록들의 중간값이다.
내부적으로는 2와 "CHARLIE" 모두 숫자^fn3이며, 다만 후자의 경우 빅 엔디안 기반의 256비트 표현이다. 숫자는 최소 0이며 최대 2²⁵⁶-1일 수 있다.

추가 읽을거리

본 백서의 역사를 알고 싶으면, this wiki(opens in a new tab)를 참조하십시오.

여러가지의 커뮤니티 기반 오픈소스 소프트웨어 프로젝트와 마찬가지로, 이더리움은 초기 등장 이후로 발전해왔습니다. 이더리움의 최신 개발 동향과 프로토콜이 어떻게 바뀌었는지에 대해 알고 싶으시다면, this guide를 추천드립니다.