Remind

'블록'은 크게 헤더와 바디정보로 구성되어있으며, 다음 그림과 같이 버전, 이전 블록 해시, 머클 루트, 타임, 난이도 목표, 논스 정보로 구성됩니다.

1. 버전 : 해당 블록이 생성된 시점의 비트코인 소프트웨어 버전 정보입니다.

2. 이전 블록 해시 : 새로운 블록이 생성된 시점의 이전 블록 해시 정보를 참조하는 정보입니다(이 요소 정보로 인하여 블록이 체인형태로 연결될 수 있었습니다).

3. 머클 루트 : 트랜잭션의 무결성 및 블로 해시의 무결성을 검증하는 역할을 수행하며, 블록 바디에 저장된 TXID 정보를 머클 트리한 결과 값입니다.

4. 타임 : 해당 블록의 대략적인 생성 시간을 의미합니다.

5. bits : 난이도 해시 목표 값을 의미하는 지표입니다.

6. nonce : 블록을 만드는 과정에서 해시 값을 구하기 위한 재료 역할을 수행합니다.

개념만 잡자! 그래서 채굴이 뭔대?

가상화폐 열풍이 불면서 '채굴'에 대한 이야기를 많이 접하셨을거라고 생각합니다. 비트코인뿐만 아니라 암호화폐에서의 채굴(인센티브) 시스템은 아주 중요한 역할을 수행합니다. 그렇다면 도대체  '채굴'은 무엇일까요? 먼저 아래의 질문에 대한 답을 여러분들은 하실 수 있으신가요?

1.중앙에서 관리 감독하는 기관이 없는 탈 중앙화된 비트코인 네트워크에서는 도대체 누가 화폐, 즉 비트코인을 어떻게 발행할까요?

2. 블록체인 기술은 분산되고 독립적인 공통장부 관리기술입니다. 그렇다는 이야기는 누군가는 거래 기록을 기록하고, 관리해야한다는 의미이며, 도대체 누가 거래기록을 기록할까요?

3. 블록은 크게 헤더와 바디정보로 구성됩니다. 블록의 바디정보에는 다수의 거래정보가 담겨져있습니다. 그렇다면 이 블록은 누가 생성할까요?

위의 질문에 대한 답을하기 앞서 먼저 '채굴'에 대한 개념을 이해하기 아주 좋은 동영상을 찾았습니다. 대략 1분 55초 분량의 아주 짧은 영상이니 꼭 시청해 보시면 좋겠습니다. (한글 자막을 지원하니, 아래의 그림과 같이 하단에 있는 자막을 설정하시고 보시면됩니다.)

채굴이란 무엇인가?

영상을 보시고나니 어느 정도 채굴에 대한 감이 잡히셨나요? 그렇다면 채굴(마이닝)이 필요했던 이유가 무엇일까요?

채굴(마이닝)이 왜 필요했을까요?

탈 중앙화된 금융거래 시스템인 비트코인 네트워크에서는 어떤 거래가 발생하고, 발생된 거래 내역이 투명하게 네트워크를 통해 공유되어야합니다. 그렇다면 누군가는 이 거래 내역을 기록하고, 기록된 거래내역을 블록에 담아 사용자들에게 전파하는 역할을 수행해야합니다. 또한, 악의 적인 사용자에 의해 잘못된 거래 기록이 전파되는것을 방지하기 위해 작성된 블록의 유효성을 검증하는 과정이 필요합니다.

앞서 이야기한 작업들을 수행하기 위해서는 서버 자원 및 전력자원이 낭비됩니다. 그렇다면 아무런 보상 없이 이러한 일을 수행하기엔 무리가 있지 않을까요?

안녕하세요. 어미새입니다.

이전 포스팅에서는 머클루트는 무엇이고 어떻게 머클루트 값을 구하는지, 그리고 실제 그렇게 값이 구해지는지 검증까지 해봤습니다. 혹시 이전 글을 읽지 않으신 분은 한 번 읽어보고 오셨으면 좋겠습니다.

• http://withbabybird.tistory.com/9

오늘은 비트코인의 블록 정보 중 블록의 식별자 역할을 수행하는 블록 해시에 관한 정의와, 블록 해시 값을 구하는 과정에 대해 학습하도록 하겠습니다.

블록 해시(Hash of the block)

블록 해시(Block Hash)는 블록의 식별자 역할을 수행하며, 쉽게 블록의 이름 정보라고 생각하시면 될 것 같습니다. 블록 해시는 블록 헤더 정보인 버전, 이전 블록 해시, 머클루트, 타임, bits, Nonce 정보를 모두 합산한 후 SHA256 함수를 통해 해시한 결과 값입니다. 먼저 블록의 구조를 살펴보도록 하겠습니다.

위의 그림과 같이 블록 헤더 정보는 크게 6가지로 구성되며, 블록 해시는 블록의 헤더 정보를 통해 구할 수 있습니다. 우선 블록의 상세 정보를 확인해보기 위해 이전 포스팅에서 소개해드린 '블록체인 인포' 사이트에 접속하여 가장 최근에 생성된 블록 정보를 확인해보겠습니다. (https://blockchain.info/ko)

이 글을 작성하기 시작한 시점에서 가장 최근에 생성된 블록의 높이는 #508217번째 블록입니다. 해당 블록을 선택하여 블록의 상세 정보를 확인해보겠습니다.

위의 정보를 살펴보면 타임 스탬프, Bits, 해시 난수, 이전 차단, Merkle Root 정보를 확인할 수 있습니다. 앞서 설명한 블록 해시를 구하는 공식에는 6가지 요소가 필요하나 여기에는 버전 정보가 누락되어 있습니다. 그리고 타임 스탬프 정보 또한 우리가 보기 편한 형식으로 변형되어 있습니다. 실습을 위해서는 조금더 디테일한 형태의 데이터가 필요하기때문에 블록의 모든 정보를 JSON 형태로 제공 받을 수 있는 형태로 요청해보도록 하겠습니다. 요청하는 방식은 아래의 링크와 같습니다.

(https://blockchain.info/block-height/508217?format=json)

참고로 위의 URL의 /508217? 이 부분에 숫자 부분이 블록 높이 정보입니다. 다른 블록 정보의 Json을 요청하고 싶다면 이 숫자 정보를 해당 블록의 높이 정보로 변경하여 호출하시면 되겠습니다.

Json 데이터로 확인해보니 보다 상세하게 블록 정보를 확인할 수 있었습니다.(개발자라서 그런지 Json 데이터가 더 보기 편하네요..) Json 데이터를 보시면 버전(ver), 이전 블록 해시(prev_block), 머클루트(mrkl_root), 타임(time), bits, 논스(nonce) 정보가 정확하게 출력되어 있습니다.

"ver":536870912
​
"prev_block":"00000000000000000060e66690d8a6646b7f8bb4aeb3fa7be258ae4011e362b5"
​
"mrkl_root":"98f0bb94fc154733f22ac54994e9637981900fcee8a0db7d5880b5b79ca3853d"
​
"time":1518070436
​
"bits":392292856
​
"nonce":2699712111
​

위의 정보를 이용하여 아래의 블록해시 값을 구할 수 있습니다. 그럼 바로 PHP를 활용하여 소스를 작성해보고 실행해보겠습니다.

저번 시간에도 이런 오류가 발생하였습니다.. 당황하지 않고 저번 시간에 해결했던 방법 처럼 엔디안 형태로 변행해 보았습니다. (오랜 시간 끝에 찾아낸 코드는 아래와 같습니다.)

<?
  
function SwapOrder($in){
  $Split = str_split(strrev($in));
  $x='';
  for ($i = 0; $i < count($Split); $i+=2) {
      $x .= $Split[$i+1].$Split[$i];
  } 
  return $x;
}
​
function littleEndian($value){
  return implode (unpack('H*',pack("V*",$value)));
}
​
function hextobin($hexstr) 
{ 
    $n = strlen($hexstr); 
    $sbin="";   
    $i=0; 
    while($i<$n) 
    {       
        $a =substr($hexstr,$i,2);           
        $c = pack("H*",$a); 
        if ($i==0){$sbin=$c;} 
        else {$sbin.=$c;} 
        $i+=2; 
    } 
    return $sbin; 
} 
​
$ver            = 536870912;
$prev_b         = '00000000000000000060e66690d8a6646b7f8bb4aeb3fa7be258ae4011e362b5';
$mrkl_r         = '98f0bb94fc154733f22ac54994e9637981900fcee8a0db7d5880b5b79ca3853d';
$time           = 1518070436;
$bits           = 392292856;
$nonce          = 2699712111;
​
//1. 버전, 타임, bits, nonce 정보를 리틀 엔디안 형태로 변형.
$ver            = littleEndian($ver);
$time           = littleEndian($time);
$bits           = littleEndian($bits); 
$nonce          = littleEndian($nonce); 
​
//2. 이전 블록 해시, 머클루트 결과 값을 모두 반대 순서로 변형
$prev_b         = SwapOrder($prev_b);
$mrkl_r         = SwapOrder($mrkl_r);
​
//3. 블록 헤더 정보를 모두 합산(순서가 꼭 맞아야합니다.)
$header         = $ver . $prev_b . $mrkl_r . $time . $bits . $nonce;
​
//4. 바이너리 형태로 변형
$header_bin     = hextobin($header);
​
//5. SHA 형태로 변형 후 바이너리 형태로 변형
$hasing_1       = hextobin(hash('sha256', $header_bin ));
​
//6. SHA 형태로 변형 
$hasing_2       = hash('sha256', $hasing_1);
​
//7. 결과를 모두 반대 순서로 변형.
$block_hash     = SwapOrder($hasing_2);
​
echo $block_hash;
​
?>

위의 코드 처럼 블록해시 정보는 블록헤더의 정보를 단순히 합산하여 해싱하는 것이 아닙니다. 버전, 타임, bits, 논스정보는 리틀 엔디안 형태로 변형 해야 하며, 이미 해싱된 머클루트와 이전 블록 해시 정보는 반대로 뒤집어 주어야합니다. 다시 정리해보면 아래의 7가지 변환 과정을 거쳐서 블록 해시 정보를 구할 수 있습니다!

1. 버전, 타임, bits, 논스 정보는 리틀 엔디안 형태로 데이터를 변형해야 한다.

2. 이전 블록 해시, 머클루트는 결과 값을 모두 반대 순서로 바꿔주어야 한다.

3. 헤더 정보들을 모두 합산합니다.(이어붙이기)

4. 합산한 헤더 정보를 바이너리 형태로 변형합니다.

5. 다시 SHA 형태로 변형 후 바이너리 형태로 또 변형합니다.

6. 변형한 값을 다시 SHA 형태로 변형합니다. (5~6번 과정은 합산한 정보를 2중 해싱한다고 생각하시면 됩니다.)

7. 이렇게 얻은 결과 값을 다시 뒤집어 놓습니다.

추가적으로 저는 숫자를 문자열로 입력하는 멍청한 실수를 해서 2시간을 허비했습니다.. 개발자로써 자괴감이..

자 그럼 결과가 정상적으로 출력되는지 확인해보겠습니다.

드디어 블록해시 정보를 구할 수 있었습니다. 아래의 링크는 비트코인 블록 해싱 알고리즘에 대한 자세한 설명을 해주고 있는 사이트입니다. 꼭 접속하셔서 해당 내용 확인해보셨으면 좋겠습니다!

(https://en.bitcoin.it/wiki/Block_hashing_algorithm)

자 그럼 오늘 배운내용을 간략하게 정리를 해보겠습니다.

1. 블록해시는 블록의 이름정보를 의미하면 해당 블록의 식별자 역할을 수행한다.

2. 블록해시는 블록 헤더 정보를 7단계의 복잡한 과정을 통하여 구할 수 있다. (아마 인터넷상에서는 자세하게 설명할 경우 오히려 이해하기 어려울 것 같아 7가지 과정을 누락하신 것 같습니다..)

   ​

이상으로 블록 헤더의 구성요소인 머클루트를 구하는 과정, 그리고 블록의 이름정보인 블록해시를 구하는 과정까지 학습하였습니다. 아마도 이 글을 읽으시는 분들 중에서는 왜 이렇게 까지 과정에 대해서 집착하지? 라는 생각을 하실 수 있을 것 같습니다. 하지만 이 과정이 반드시 학습하는데에 큰 도움이 될것이라고 믿습니다!

이상 긴 글 읽어주셔서 감사합니다!

[참고자료]https://en.bitcoin.it/wiki/Block_hashing_algorithmhttps://steemit.com/kr/@loum/how-to-calculate-the-block-hash-in-bitcoinhttps://homoefficio.github.io/2016/01/23/BlockChain-%EA%B8%B0%EC%B4%88-%EA%B0%9C%EB%85%90/http://hanaloum.blogspot.kr/2014/06/block-1_9584.html

안녕하세요. 어미새입니다.

이더리움 백서를 쉽게 이해할 수 있도록 풀어서 설명하는 연재물을 작성하고 있습니다. 어느덧 백서의 중반부를 향해 달려가고 있습니다. 혹시 지난 포스팅을 읽지 못하셨던분들은 먼저 아래의 포스팅을 읽어보시는것을 추천드립니다.

• # 31 - 이더리움 개요
• # 32 - 이더리움 백서(1편)
• # 33 - 이더리움 백서(2편)
• # 34 - 이더리움 백서(3편)
• # 35 - 이더리움 백서(4편)
• # 36 - 이더리움 백서(5편)
• # 37 - 이더리움 백서(6편)

Remind

이더리움에서 메시지는 컨트랙트에 의해 생성되며, 컨트랙트가 실행되는 과정, 그리고 그 과정에서 수수료가 소비되는 과정에 대한 내용을 다뤘습니다. (gas 기억하시죠?)

컨트랙트는 특정 조건이 맞았을때 실행되는 프로그램 코드이며, 해당 코드는 EVM 환경에서 작동됩니다. 지난 시간에서 언급되어듯이 악의적인 프로그램을 막기 위해 코드가 실행되는 바이트의 양에 따라 수수료인 gas가 소모되며, 이러한 과정의 프로세스가 어떻게 흘러가는지에 대한 설명으로 이어졌습니다.

스마트 컨트랙트 코드는 정상적으로 수행이 완료되던지, gas가 부족하여 종료되던지, 혹은 오류가 발생하는 시점에서 종료가되며, 비트코인의 부족한 상태 변화와 달리 이더리움에서는 다양한 상태 변화를 가질 수 있다는 것을 설명하였습니다. 또한, 컨트랙트 코드는 연산을 위해 스택, 메모리, 저장소에 접근할 수 있어야 하며, 블록 헤더 데이터 뿐만 아니라 특정 값이나, 메시지 발송자 및 수신되는 메시지의 데이터에 접근할 수 있으며, 결과 값으로 데이터의 바이트 배열을 반환 할 수도 있었습니다.

블록체인과 채굴(Blockchan and Mining)

[그림 - 이더리움 백서]

이더리움 블록체인은 여러면에서 비트코인 블록체인과 유사하나, 어느정도 차이점들이 있다. 이더리움과 비트코인에서의 각 블록체인 구조에 대한 주요 차이점으로는 비트코인과는 달리 이더리움 블록은 트랜잭션 리스트와 가장 최근의 상태(state) 복사본을 가지고 있다는 것이다. 그것 외에도, 두개의 다른 값 - 블록 넘버와 difficulty - 이 또한 블록내에 저장된다. 기본적인 이더리움 블록 검증 알고리즘은 다음과 같다.

이더리움의 블록체인은 비트코인 블록체인과 유사하지만 차이점이 있습니다. 이더리움과 비트코인의 블록체인 구조에 대한 주요 차이점은 이더리움의 블록에는 트랜잭션 리스트와 가장 최신의 상태(state) 복사본을 가지고 있으며, 블록 넘버와 difficulry 정보도 블록내에 저장됩니다.

이더리움 블록 검증 알고리즘 시나리오.

1. 생성된 블록에 참조되는 이전 블록이 실제 존재하는 블록인지, 유효한지 확인 한다.

2. 타음 스탬프 값이 이전 블록의 타임 스탬프 값보다 큰 값인지 확인한다, 만약 크다면 15분 이내인지 확인한다.

3. 블록 넘버, difficulty, 트랜잭션 루트, 삼촌 루트, gas 리미트등, 기타 다양한 이더리움 로우 레벨 정보가 유효한지 확인 한다.

4. 블록에 포함된 작업 증명이 유효한지 확인한다.

5. S[0] 상태 정보가, 이전 블록의 마지막 상태(state)라고 가정 하고

6. TX를 현재 블록의 n개의 트랜잭션을 가지는 리스트라고 가정했을때 0부터 n-1에 대해, S[i+1] = APPLY(S[i], TX[i])로 설정 한다. 이때 어플리케이션이 오류를 반환 하거나, 블록에서 소모된 총 gas가 GASLIMIT를 초과하면 오류를 반환 한다.

7. 채굴자에게 지불된 보상 블록을 S[n] 추가한 후 이것을 S_FINAL이라고 했을때

8. 상태 S_FINAL의 머클 트리 루트가 블록 헤더가 가지고 있는 최종 상태 루트와 같은지 검증한다. 이 값이 같으면 그 블록은 유효한 블록이며, 다른면 유효하지 않은 것으로 판단한다.

이러한 과정은 모든 상태를 각 블록에 저장해야하기때문에 매우 비효율적인 것처럼 보이지만, 효율성 측면에서는 비트코인과 비교할만 하다(즉 비슷하다는 의미인것 같습니다). 그 이유로는 상태가 트리 구조로 저장되고, 모든 블록 뒤에 트리의 작은 부분만이 변경되기 때문이다. 보통, 인접한 두개의 블록간에는 트리의 대부분의 내용이 같으며, 한 번 데이터가 저장되면 포인터(서브트리의 해쉬)를 사용하여 참조될 수 있습니다.

패트리시아 트리(Patricia tree)로 알려진 트리는 머클트리 개념을 수정하여 노드를 효율적으로 삽입하거나, 삭제할 수 있도록 도와줍니다. 또한, 모든 상태 정보가 마지막 블록에 포함되어 있기떄문에 전체 블록체인 히스토리를 모두 저장할 필요가 없으며, 이러한 방법을 만약 비트코인에 적용한다면 5~20배의 저장 공간 절약 효과가 생길것입니다.

물리적인 하드웨어 관점에서 볼 떄, 컨트랙트 코드는 "어디에서" 실행되는지에 대한 의문이 쉽게 들 수 있습니다. 그에 대한 해답은 다음과 같습니다. 컨트랙트 코드를 실행하는 프로세스는 상태 전환 함수 정의의 한 부분이고, 이것은 블록 검증 알고리즘의 부분입니다. 따라서 트랜잭션이 블록 B에 포함되면 그 트랜잭션에 의해 발생할 코드의 실행은 현재 또는 향후에 블록 B를 다운로드 하고 검증하는 모든 노드들에 의해 실행될 것입니다.

어플리케이션(Applications)

이더리움을 이용하여 제작할 수 있는 어플리케이션은 총 세 가지 카테고리의 어플리케이션으로 분류할 수 있습니다.

첫번째 카테고리는 금융 어플리케이션으로 돈과 직접적으로 연관된 컨트랙트를 계약 참여자로 하여 보다 강력하게 설정-관리하게끔하는 어플리케이션입니다. 금융 어플리케이션의 예로는 하위 화폐, 파생상품, 헷지 컨트랙트, 예금용 전자지갑, 유연장, 최종적으로는 고용계약 수준의 것들을 포함할 수 있습니다.

두번째 카테고리는 준(準) 금융 어플리케이션으로 금전이 관련되어 있지만, 상당 부분 비(非) 화폐적인 면이 존재하는 계약을 위한 어플리케이션이 이에 해당됩니다. 준 금융 어플리케이션의 예로는 어려운 연산 문제를 푸는 자에게 자동적으로 포상금이 지급되는 계약입니다.

마지막으로 온라인 투표와 분권형 버넌스(Governance)와 같이 금융과 관련성이 아예 없는 어플리케이션이 있겠습니다.

토큰 시스템(Token Systems)

블록체인토큰시스템(On-blockchain token system)은 하위 화폐(미화/금등과 연동된), 주식과 스마트 자산(Smart Property : 비트코인의 블록체인 상에서 소유권이 컨트롤/관리되는 자산), 위조 불가능한(secure unforgeable) 쿠폰, 기타 토큰 시스템(예 : 인센티브 부여를 위한 포이튼 제도)등, 다양한 형태의 거래시스템을 네트워크 상에서 구현할 수 있도록 도와주는 어플리케이션들을 갖고 있습니다. 이더리움에서 토큰 시스템은 놀랍도록 쉽게 구현할 수 있으며, 토큰 시스템을 이해하는 데에 핵심은 아래와 같습니다.

• 모든 화폐 혹은 토큰시스템은 근본은 결국 한 가지 오퍼레이션만을 수행하는 데이터베이스이다.

• A가 최소 x 단위의 화폐를 보유하고 있는 상태에서, A로부터 x단위의 화폐/토큰을 차감하고, 차감된 x단위의 화폐/토큰을 B에게 지급한다(A가 최종적으로 이 거래를 승인 한다).

이더리움에서 유저는 바로 위의 로직을 컨트랙트에 반영 시키기만하면 됩니다. 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
​

def send(to, value) : : sender는 명시되어있지 않지만 보내는 사람이며, to는 받는 사람, value는 값이라고 생각하시면 되겠습니다.

if self.storage[msg.sender] >= value: : 만약 저장된 sender의 값이 보내고자하는 value 즉, 값보다 크거나 같으면 (보내는 수량보다 더 많은 값을 가지고 있어야한다는 의미입니다.)

self.storage[msg.sender] = self.storage[msg.sender] - value : sender의 값을 가져와 value 만큼 차감한 후 sender의 값에 저장합니다.

self.storage[to] = self.storage[to] + value : to 즉, 받는 사람의 값을 가져와 value만큼 더한 후 값을 저장합니다.

위의 코드는 본 백서에서 설명한 은행시스템의 상태변환함수(state transition function)를 아무런 가공없이 그대로적용시킨 것입니다.

토큰 시스템을 개발하기 위해서는 통화의 단위를 정의하고 배급하기 위한 최초의 작업, 또는 더 나아가 여타 컨트랙트들이 계좌의 잔금에 대한 정보 요청을 처리하기 위한 추가 코드가 더 필요할 수 있습니다. 하지만, 그 정도가 토큰 시스템을 만드는 데 필요한 전부입니다. 이론적으로, 이더리움에 기반한 하위화폐 체계로서의 토큰 시스템은 비트코인에 기반환 메타 화폐가 갖고 있지 않은 중요한 특성을 지니고 있을 수 있습니다. (거래비용을 거래 시 사용한 화폐로 직접 지불할 수 있다는 점)

컨트랙트을 집행하기 위해서는 발송인에게 지불해야하는 비용 만큼의 이더 잔고를 유지해야합니다. 그리고 컨트랙트 집행 시 수수료로 받는 내부화폐(하위화폐)를 (상시 돌아가고 있는 내부화폐-이더 거래소에서) 즉각 환전하여 이더 잔고로 충전할 수 있습니다. 컨트랙트 집행 시 수수료로 받는 내부화폐(하위화폐)를 내부화폐-이더 거래소에서 즉각 환전하여 이더 잔고로 충전할 수 있습니다. 유저들은 이더로 그들의 계좌들을 "활성화" 시켜야 하지만, 각 컨트랙트를 통해 얻어지는 만큼의 금액을 이더로 매번 환전할 수 있기 때문에, 한 번 충전도니 이더는 재사용이 가능하다고 볼 수 있습니다.

마무리

이더리움 블록체인은 여러면에서 비트코인 블록체인과 비슷하며 가장 큰 차이점은 블록에 더 많은 정보를 담을 수 있다는 점인것 같습니다. 이더리움의 블록체인은 비트코인의 블록체인과 달리 블록에 트랜잭션 리스트와 가장 최신의 상태(state) 복사본을 가지고 있다는 점이며, 추가로 블록 넘버와, difficulty 정보 또한 블록내에 저장됩니다.

블록의 유효성 검증 과정에서도 비트코인의 경우 타임 스탬프 값이 2시간 이내인지 확인했지만, 이더리움에서는 15분 이내인지 확인하는 과정이 있었습니다. 이 의미는 블록의 평균 생성 시간이 비트코인 보다 훨씬 빠르다는것을 의미합니다.

또한, 이더리움에서는 모든 상태를 각 블록에 저장해야 하기 때문에 비효율적인것처럼 보일 수 있지만, 상태가 트리 구조로 저장되고, 모든 블록 뒤에 트리의 작은 부분만이 변경되기 때문에 효율성 측면에서는 비트코인과 비슷한 수준이지만 더 많은 기능을 수행할 수 있다는 내용을 말하고 싶었던것 같습니다.

이더리움을 통해 개발 가능한 어플리케이션은 크게 3가지 카테고리로 분류할 수 있으며, 금융, 준 금융, 비 금융 어플리케이션으로 나누어 설명하고자 하였습니다. 토큰 시스템은 코인 및 토큰의 차이점에 대하여 작성한 포스팅 문서를 참조하시면 이해하시는데 더 큰 도움이 될것이라고 생각합니다.

• # 27 - 코인, 토큰의 차이점, ICO에 대한 개념정리.

어느덧 이더리움 백서 7편입니다. 백서의 흐름으로 이제 중반을 조금 넘은 시점입니다. 대략 11 ~ 12편 정도에서 백서의 내용이 마무리될것 같습니다. 백서의 다음 내용은 파생상품과 가치안전통화, 신원조회 / 평판 시스템(Identity and Reputation Systems), 분산형 파일 저장소(Decentralized File Storage), 탈중앙화된 자율조직(Decentralized Autonomous Organizations), 추가적인 어플리케이션들(Further Applications) 등과 같은 어플리케이션에 대한 설명이 이어집니다.

이더리움에 대한 사전지식 없이 백서를 읽고, 정리하고, 부족한 부분들은 인터넷의 자료를 통해 이해하는 방식으로 백서의 내용을 써가고 있습니다, 그렇다보니 조금 부족한면이 있습니다. 하지만 부족하더라도 이왕 시작한 포스팅 주제이니 끝까지 마무리 해보도록 하겠습니다.

설명을 조금 쉽게 풀어서 해야하는 주제들은 재 포스팅할 예정입니다. 백서편이 빨리 끝나고 조금은 쉬우면서도 재미있게 내용을 풀어보고 싶네요~ (괜히 백서부터 했나..)

이상 긴 글 읽어주셔서 감사합니다!

혹시나 이더리움 백서를 먼저 읽고 싶으신분은 아래의 링크를 통해 이더리움 백서를 먼저 확인해보시는것도 좋을것 같습니다.

• 이더리움 영문 백서 원문

• 이더리움 한글 백서 원문

[참고문헌]

https://github.com/ethereum/wiki/wiki/%5BKorean%5D-White-Paper#%EC%83%81%ED%83%9C%EB%B3%80%ED%99%98%EC%8B%9C%EC%8A%A4%ED%85%9C%EC%9C%BC%EB%A1%9C%EC%84%9C%EC%9D%98-%EB%B9%84%ED%8A%B8%EC%BD%94%EC%9D%B8bitcoin-as-a-state-transition-system

https://github.com/ethereum/wiki/wiki/White-Paper

안녕하세요. 어미새입니다.

이더리움 백서를 쉽게 이해할 수 있도록 풀어서 설명하는 연재물을 작성하고 있습니다. 5편부터는 본격적인 이더리움에 관한 설명이 시작됩니다. 이전 내용들과 연관되어 설명이 진행되니, 혹시 지난 포스팅을 읽지 못하셨던 분들은 먼저 아래의 포스팅을 읽어보시는것을 추천드립니다.

• # 31 - 이더리움 개요
• # 32 - 이더리움 백서(1편)
• # 33 - 이더리움 백서(2편)
• # 34 - 이더리움 백서(3편)
• # 35 - 이더리움 백서(4편)
• # 36 - 이더리움 백서(5편)

Remind

이더리움의 목적은 분산 어플리케이션 제작을 위한 대체 프로토콜을 만드는것입니다. 튜링 완전 언어를 내장하고 있는 블록체인이라는 필수적이고 기본적인 기반을 제공함으로써, 대규모 어플리케이션에 유용한 개발 기법을 제공하고, 개발 시간 단축, 높은 보안성, 다른 어플리케이션과 상호작용할 수 있는 생태계를 만들고자하였습니다.

이더리움에서 상태(state)는 어카운트(account)라고 하는 오브젝트(object)들로 구성되어 있습니다. 어카운트 오브젝트는 20바이트의 주소와, 값과 정보를 전달해주는 상태변화(state transition)을 가지고 있으며, 논스(nonce), 이더(ether), 계약 코드, 저장 공간, 4가지의 필드 정보로 구성되어있습니다.

이더리움에서 화폐는 이더(ether)로 표기되며, EOA와 CA 두가지 타입의 계정으로 분류됩니다. 튜링 완전성을 보장하기 위해 악의적인 공격자가 네트워크 리소스를 소비하는 만큼 강제로 수수료(gas)를 지불하게함으로써 악의 적인 공격을 방지할 수 있다는 개념을 설명하였습니다.

메시지(Message)

컨트랙트는 또 다른 컨트랙트에게 메시지를 보낼 수 있으며, 메시지는 따로 저장될 필요가 없으며, 이더리움의 실행 환경에서만 존재하는 가상의 오브젝트입니다. 이러한 메시지는 아래의 항목들을 포함하고 있습니다.

• 메시지 발신처(암묵적)

• 메시지 수신처

• 메시지와 함께 전달되는 이더

• 선택적 데이터 필드

• STARTGAS 값

메시지는 외부 실행자가 아닌 컨트랙트에 의해 생성된다는 것을 제외하면 트랜잭션과 유사합니다. 현재 코드 수행을 하고 있는 컨트랙트가 메시지를 생성하고 실행하라는 CALL opcode를 만나게 되면 메시지를 생성합니다. 트랜잭션과 마찬가지로, 메시지는 수신자 어카운트에 전달됩니다.

컨트랙트는 외부 실행자가 하는 것과 정확히 같은 방식으로 다른 컨트랙트와 관게를 맺을 수 있으며, 트랜잭션이나 컨트랙트에 의해 할당된 gas 허용치는 그 트랜잭션과 모든 하위의 실행 연산에 적용됩니다.

예를 들어, 외부 실행자 A가 B에게 1000 gas와 함께 트랜잭션을 보내고, B는 600 gas를 소모한뒤 C에게 메시지를 보내고, C의 내부 실행에 300 gas를 소모한 후 반환하면 B는 gas가 모두 소모되기 전에 100 gas를 더 사용할 수 있습니다. (1000 - 600 = 400, 400 -300 = 100)

이더리움 상태 변환 함수(Ethereum State Transition Function)

이더리움 상태 전이 함수 APPLY(S, TX) -> S’ 는 다음처럼 정의될 수 있다.

[그림 - 이더리움 백서]

트랜잭션의 형식이 맞는지(전송하고자 하는 이더의 수량이 맞는지 확인) 체크하고, 서명이 유효한지, 논스가 발신처 어카운트의 논스와 일치하는지를 체크하며, 트랜잭션이 유효하지 않을 경우 오류를 반환합니다.

STARTGAS * GASPRICE의 정보는 트랜잭션 수수료이며, 서명으로 부터 발신처 주소를 결정하게됩니다. 발신처 어카운트에서 수수료를 제외하고 발신자의 논스 정보를 증가 시키며, 발신처 잔고가 충분하지 않을 경우 오류를 반환합니다.

GAS = STARTGAS로 초기화 한후, 트랜잭션에서 사용된 바이트에 대한 값을 지불하기 이해 바이트 양에 비례하여 gas를 차감합니다. 발신처 어카운트 에서 수신처 어카운트로 트랜잭션 값이 전송되며, 수신처 어카운트가 컨트랙트일 경우 컨트랙트의 코드 끝까지 수행 하거나, gas가 모두 소진될 때 까지 수행하게됩니다. (만약 악의적으로 무한 루프를 발생시킬 경우 gas가 다 소모되는 시점에서 종료됩니다.)

만약 발신처의 잔고가 충분하지 않을 경우 트랜잭션 전송이 실패할 수 있으며, 컨트랙트 코드 수행시 gas가 부족할 경우 수수료를 제외한 모든 상태 정보는 원상태로 돌아가며, 해당 수수료는 채굴자의 어카운트에 지급됩니다. 모든 컨트랙트가 정상적으로 수행된 후 남아있는 gas에 대한 수수료는 발신처에 돌려주고, 소모된 gas의 수수료는 채굴자에게 보내지게됩니다.

예를 들어, 아래와 같은 컨트랙트 코드가 있다고 가정해보겠습니다.

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

실제 컨트랙트 코드는 로우-레벨 EVM(이더리움 버츄얼 머신) 코드로 작성되지만, 이해를 돕기 위해 이더리움 하이-레벨 언어중 하나인 Serpent로 작성되었습니다(해당 코드는 EVM 코드로 컴파일 될 수 있습니다).

컨트랙트의 스토리지가 비어있다고 가정하고, 트랙잭션 정보는 10tehr, 2000 gas, 0.001 ether gasprice, 63바이트의 데이터(0-31바이트는 숫자 2를, 32-63 바이트는 문자열 CHARLIE)를 보낸다고 가정했을 경우 상태 변환 함수의 프로세스는 아래와 같이 실행됩니다.

1. 트랜잭션 정보가 유효하고, 형식이 정상적인지 확인 한다.

2. 트랜잭션을 전송하는 발신 자의 이더 잔고가 최소 수수료 정보 만큼(2000 gas * 0.001 ether = 2 ether) 있는지 확인 한다, 만약 잔고가 충분할 경우 발신 자의 어카운트에서 수수료 금액인 2 ether를 차감한다.

3. gas = 2000으로 초기화한다. 트랜잭션 총 길이가 170 바이트, 수수료가 5gas라고 가정했을 경우 170 * 5 = 850의 수수료가 소모되며, 초기 가스 정보인 2000에서 850을 제외한 1150 gas가 남게된다.

4. 발신측 어카운트에서 전송할 ether의 양인 10 ether를 차감하고, 이것을 컨트랙트 어카운트에 더한다.

5. 컨트랙트 코드를 실행 시키며, 컨트랙트의 index 2에 해당하는 스토리지가 사용되었는지 확인하고 index 2에 해당하는 스토리지 값을 CHARLIE로 설정 한다. 이 작업을 통해 187 gas가 소비되었다고 가정했을 경우 남아 있는 gas의 양은 1150 - 187 = 963 gas가 남게된다.

6. 남은 수수료인 963 * 0.001 = 0.963 ether를 발신측 어카운트로 되돌려주고, 결과 상태를 반환한다.

트랜잭션의 수신처에 컨트래트가 없을 경우, 트랜잭션의 총 수수료는 제공된 GASPRICE와 트랜잭션의 바이트 수를 곱한 값만이 수수료로 지출되며, 트랜잭션가 함께 보내진 데이터는 관련이 없어지게됩니다. (실행 할 컨트랙트가 없기 때문입니다.)

메시지는 트랜잭션과 마찬가지 방식으로, 상태 정보를 원래 상태로 되돌린다는 것을 주목해야합니다. 메시지 실행시 gas가 부족할 경우, 메시지 실행에 의해 발생된 다른 모든 실행들은 원래대로 되돌려지게 되지만, 메시지를 실행 시켰던 부모의 상태는 되돌려질 필요가 없습니다. 이것은 컨트랙트가 다른 컨트랙트를 호출하는 것은 안전하다는 것을 의미하며, A가 X 만큼의 gas를 가지고 B를 호출할 경우, A의 실행은 최대 X gas만을 잃는다는 것을 보장 받게됩니다.

코드 실행(Code Exceution)

이더리움 컨트랙트 코드는 "이더리움 버추얼 머신 코드" 또는, "EVM 코드"로 불리는 스택 기반의 바이트 코드 언어로 작성됩니다. 컨트랙트 코드는 연속된 바이트로 구성되어 있고, 각각의 바이트는 연산(operation)을 나타냅니다. 이러한 컨트랙트 코드는 반복적으로 연산을 수행도록 구성된 무한 루프, 혹은 코드의 마지막에 도달될 경우 종료되거나, 오류나 STOP, RETURN과 같은 명령어를 마주했을 경우 종료됩니다. 또한, 연산을 수행하기 위해서는 아래와 같이 데이터를 저장하는 세가지 타입의 공간에 접근할 수 있어야 합니다.

• 스택

• 메모리

• 컨트랙트의 영속적인(long-term) 저장소(storage)

컨트랙트 코드는 블록 헤더 데이터 뿐만 아니라, 특정 값이나, 발송자 및 수신되는 메시지의 데이터에 접근 할 수 있으며, 결과 값으로 데이터의 바이트 배열을 반환할 수도 있습니다.

이러한 EVM 코드의 공식 실행 모델은 놀랍도록 단순합니다. 이더리움 버추얼 머신이 실행되는 동안, block_state, transaction, message, code, memory, stack, pc, gas와 같은 모든 계산 상태는 튜플(tuple)로 정의될 수 있으며, block_state는 모든 어카운트를 포함하는 전역 상태(global state)로서 잔고와 저장소(storage)를 포함합니다.

스마트컨트랙트 code의 pc(프로그램 카운터)번째 바이트의 현재 명령이 실행되고, pc가 코드의 길이보다 크면 (pc>=len(code) pc는 0), 각각의 명령은 튜플이 어떻게 변화되는지 알 수 있습니다.

예를 들어 ADD는 스택에서 두개의 아이템을 꺼내(pop), 그 합을 구한 후 다시 스택에 넣고(push) gas를 1만큼 감소 시키고, pc는 1 증가시킵니다. SSTORE는 스택에서 두개의 아이템을 꺼내 이 아이템의 첫번째 값이 가리키는 컨트랙트 저장소 인덱스에 두번째 아이템을 넣습니다.

이더리움 버추얼 머신 환경을 JIT 컴파일을 통해 최적화 하는 많은 방법이 있지만, 기본적인 이더리움은 수백줄의 코드로 구현될 수 있습니다.

마무리

이더리움에서 메시지는 컨트랙트에 의해 생성되며, 컨트랙트가 실행되는 과정에서 수수료가 발생하는 과정이 어떻게 되는지에 대한 설명으로 시작되었습니다. 컨트랙트는 특정 조건이 맞았을때 실행되는 프로그램 코드이며, 해당 코드는 EVM 환경에서 작동됩니다. 지난 시간에서 언급되어듯이 악의적인 프로그램을 막기 위해 코드가 실행되는 바이트의 양에 따라 수수료인 gas가 소모되는 과정, 그리고 gas가 남았을 경우 발신자에게 반환되는 과정에 대한 설명으로 이어졌습니다.

이러한 스마크 컨트랙트 코드는 정상적으로 수행이 완료되던지, gas가 부족하여 종료되던지, 혹은 오류가 발생하는 시점에서 종료가되며, 비트코인의 부족한 상태 변화와 달리 이더리움에서는 다양한 상태 변화를 가질 수 있다는 것을 설명하였습니다. 또한, 컨트랙트 코드는 연산을 위해 스택, 메모리, 저장소에 접근할 수 있어야 하며, 블록 헤더 데이터 뿐만 아니라 특정 값이나, 메시지 발송자 및 수신되는 메시지의 데이터에 접근할 수 있으며, 결과 값으로 데이터의 바이트 배열을 반환 할 수도 있었습니다.

백서의 내용만으로는 이해하기 어려웠던 부분들은 계속해서 취합하고 있으니, 조금 어려운 부분이 있더라고 꾸준히 계속 읽으시면 좋을것 같습니다. (계속 반복적으로 말하고 있지만, 어려웠던 용어들은 개별 포스팅하겠습니다.)

이상 긴 글 읽어주셔서 감사합니다!

혹시나 이더리움 백서를 먼저 읽고 싶으신분은 아래의 링크를 통해 이더리움 백서를 먼저 확인해보시는것도 좋을것 같습니다.

• 이더리움 영문 백서 원문

• 이더리움 한글 백서 원문

[참고문헌]

https://github.com/ethereum/wiki/wiki/%5BKorean%5D-White-Paper#%EC%83%81%ED%83%9C%EB%B3%80%ED%99%98%EC%8B%9C%EC%8A%A4%ED%85%9C%EC%9C%BC%EB%A1%9C%EC%84%9C%EC%9D%98-%EB%B9%84%ED%8A%B8%EC%BD%94%EC%9D%B8bitcoin-as-a-state-transition-system

https://github.com/ethereum/wiki/wiki/White-Paper

안녕하세요. 어미새입니다.

이더리움 백서를 쉽게 이해할 수 있도록 풀어서 설명하는 연재물을 작성하고 있습니다. 5편부터는 본격적인 이더리움에 관한 설명이 시작됩니다. 이전 내용들과 연관되어 설명이 진행되니, 혹시 지난 포스팅을 읽지 못하셨던 분들은 먼저 아래의 포스팅을 읽어보시는것을 추천드립니다.

• # 31 - 이더리움 개요
• # 32 - 이더리움 백서(1편)
• # 33 - 이더리움 백서(2편)
• # 34 - 이더리움 백서(3편)
• # 35 - 이더리움 백서(4편)

Remind

비트코인 프로토콜은 별도의 확장 없이도 낮은 수준의 "스마트 계약"을 구현할 수있지만, 튜링 불완전성, UTXO의 상태표현의 한계점, 블록체인을 해독할 수 없는 문제점이 있습니다.

비트코인은 while이나 for와 같은 순환(loop) 명령 카테고리를 사용할 수 없으며, 순환 명령어를 없앤 이유는 거래 증명시 무한 루프에 빠지는것을 방지하기 위함입니다.

UTXO 스크립트만으로 인출 액수를 세밀하게 통제할 방법이 없으며, UTXO가 표현할 수 있는 상태는 사용되었거나, 안되었거나 두가지 표현방법만 존재하며, 블록체인을 해독할 방법이 없기때문에 여러 다른 부야의 어플리케이션을 만들기 어려운 한계점들이 존재합니다.

그렇다면 이더리움에서는 위의 문제점들 어떻게 해결했을까요? 본격적으로 이더리움 백서에서 말하는 이더리움이 무엇인지 살펴보도록 하겠습니다.

이더리움

이더리움의 목적은 분산 어플리케이션 제작을 위한 대체 프로토콜을 만드는것이며, 튜링 완전 언어를 내장하고 있는 블록체인이라는 필수적이고 근본적인 기반을 제공함으로써, 대규모 분산 어플리케이션에 유용한 개발 기법을 제공하고, 개발 시간 단축, 높은 보안성, 다른 어플리케이션과 상호작용할 수 있는 생태계를 만들고자합니다.

누구든지 이 언어를 통해 스마트 컨트랙트, 즉 분산 어플리케이션을 작성하고 소유권에 대한 규칙을 생성할 수 있으며, 트랜잭션 형식(transaction format), 상태변한 함수(state transition function)등을 생성할 수 있습니다.

어떤 값을 저장하고, 특정한 조건들을 만족했을 때만 그 값을 얻을 수 있게 하는 일종의 암호 상자인 스마트 컨트랙트 또한 이 플랫폼위에서 만들 수 있으며, 네임코인과 같은 형태는 두 줄정도의 코드 정도로 작성할 수 있고, 통화나 평판 시스템 관련 프로토콜은 스무 줄 내외의 코드로 만들 수 있습니다.

이러한 방법은 비트코인의 스크립팅(scripting)이 제공하지 못했던 튜링-완전(Turing-completeness), 가치 인지능력(value-awareness), 블록체인 인지능력(blockchain-awareness), 상태(state)개념 등을 포함함으로써 가능해졌습니다.

이더리움 어카운트

이더리움에서 상태(state)는 어카운트(account)라고 하는 오브젝트(object)들로 구성되어있습니다. 각각의 어카운트 오브젝트는 20바이트의 주소와, 값과 정보를 직접 전달해 주는 상태변화(state tansition)을 가지고 있으며, 아래와 같이 4개의 필드 정보로 구성됩니다.

• 논스(nonce) : 각 트랜잭션이 오직 한번만 처리되게할 수 있는 일종의 카운터 역할 수행

• 이더(ether) : 어카운트의 현재 잔고

• 계약 코드 : 계약 코드 (존재할수도, 존재하지 않을수도 있음)

• 저장 공간 : 초기 설정 값, 즉 default 상에는 비어있는 정보

이더는 이더리움의 기본 암호-연료(cryto-fuel) 이며, 트랜잭션 수수료를 지불하는데 사용됩니다. 이더리움의 어카운트 정보는 프라이빗 키에 의해 통제되는 외부 소유 어카운트(Externally Owned Accounts)와 컨트랙트 코드에 의해 통제되는 컨트랙트 어카운트(Contract Accounts) 두가지 종류로 구성됩니다.

프라이빗 키에 의해 통제되는 외부 소유 어카운트는 아무런 코드 정보도 가지고 있지 않으며, 외부 소유 어카운트에서 메시지를 보내기 위해서는 새로운 트랜잭션을 생성하고, 서명(signing)을 해야합니다. 컨트랙트 코드에 의해 통제되는 컨트랙트 어카운트는 메시지를 받을 떄마다, 메시지를 읽거나, 내부 저장 공간에 기록 하거나 다른 메시지들을 보내는 컨트랙트들을 차례로 생성하게됩니다.

이더리움에서 컨트랙트는 수행되거나 컴파일 되어져야하는 어떤 것이라기 보다는, 이더리움 프레임워크 환경안에 서 살아있는 일종의 자율 에이전트(autonomous agent)로서, 메시지나 트랜잭션이 도착했을 경우 항상 특정한 코드를 실행하고, 자신의 이더 잔고와, 영속적인 변수들을 추적하기 위해서 자신의 키/값 저장소를 직접적으로 통제하는 역할을 수행하게됩니다.

메시지와 트랜잭션

이더리움에서는 외부 소유 어카운트가 보낼 메시지를 가지고 있는 서명된 데이터 패키지를 트랜잭션(transaction) 이라고 하며, 아래와 같은 구성요소를 포함하고 있습니다.

• 메신지 수신처

• 발신처를 확인할 수 있는 서명

• 선택적(optional) 데이터 필드

• STARTGAS 값, 트랜잭션 실행이 수행되도록 허용된 최대 계산 단계수

• GASPRICE 값, 매 계산마다 발신처가 지불하는 수수료

메신저 수신처, 발신처를 확인할 수 있는 서명, 선택적(optional) 데이터 필드는 암호 화폐에서 거의 표준처럼 사용되는 값입니다. 여기서 데이터 필드는 초기 값으로 설정된 특별한 기능(function)은 가지고 있지 않습니다. 하지만 버추얼 머신(virtual machine)은 컨트랙트가 이 데이터에 접근할 때 사용할 수행코드(opcode)를 가지고있습니다.

예를 들어, 블록체인 위에 도메인 등록 서비스 기능의 컨트랙트가 있다고 가정할 경우 컨트랙트에 보내지는 데이터 필드는 두개의 필드가 있다고 해석할 수 있습니다. 첫번째 필드는 등록하고자 하는 도메인이며, 두번째 필드는 IP 주소 정보 입니다. 컨트랙트는 메시지 데이터로부터 이 값들을 읽어서 저장소 내 적당한 위치에 저장하게됩니다.

STARGAS 와 GASPRICE 필드는 이더리움의 앤티-서비스거부(anti-DoS) 모델에 있어서 매우 중요한 역할을 수행합니다. 코드내의 우연적이거나 악의적인 무한 루프, 또는 계산 낭비를 방지하기 위해 각각의 트랜잭션은 사용할 수 있는 코드 실행의 계산 단계 수를 제한해야합니다.

계산의 기본 단위는 gas이며, 보통의 연산 과정은 1 gas의 비용이 소요되나, 어떤 연산은 더 비싼 계산 비용이 발생할 수 있고, 특히 상태를 저장하는 데이터의 양이 많을 수록 더 많은 gas 비용이 필요하게 됩니다. 또한 트랜잭션 데이터에 있는 모든 바이트는 바이트당 5 gas의 수수료가 소요됩니다.

시스템에서 이러한 수수료의 정책은 어떤 공격자가 계산, 밴드위스, 저장소 등을 포함해 그들이 소비하는 모든 리소스에 비례하여 강제로 수수료를 지불하게 함으로써 악의적인 공격을 방지하기 위한 정책입니다. 따라서 네트워크 자원을 많이 소모하는 트랜잭션은 대략 증가분에 비례한 gas 수수료를 가지고 있어야합니다.

마무리

이더리움 백서 5편에서는 드디어 본격적인 이더리움에 대한 설명이 시작되었습니다. 이더리움의 목적은 분산 어플리케이션 제작을 위한 대체 프로토콜을 만드는 것입니다.

이더리움에서는 튜링-완전(Turing-completeness), 가치 인지능력(value-awareness), 블록체인 인지능력(blockchain-awareness), 상태(state)개념 등을 포함함으로써 분산 어플리케이션 제작을 위한 프로토콜을 만들 수 있다고 설명하고 있습니다. (이더리움 백서 4편에서 비트코인의 한계점으로 지목되었던 부분들을 어떻게 해결한것인지에 대한 내용입니다.)

이더리움 프레임 워크에서 사용할 수 있는 암호화폐의 이름을 흔히 이더리움이라고 알고 있지만, 정확한 암호 화폐의 이름은 이더(ehter)이며, 크게 EOA(Externally Owned Accounts : 외부 소유 계정)와 CA(Contracts Accounts : 컨트랙트 계정) 2가지 타입으로 분류할 수 있습니다.(EOA와, CA가 어떤 역할을 수행하고, 무슨 차이가 있는지에 대한 설명은 하나의 포스팅으로 다뤄야하는 주제이니 만큼 추후 별도의 포스팅으로 다루겠습니다.)

비트코인 스크립트는 거래 증명시 무한 루프에 빠지는것을 방지하고자, while이나 for와 같은 순환(loop) 명령 카테고리를 사용할 수 없지만, 이더리움에서는 이 문제를 gas라는 수수료로 해결할 수 있다고 주장하고 있습니다.

어떤 공격자가 계산, 밴드위스, 저장소 등을 포함해 그들이 소비하는 네트워크의 모든 리소스에 비례하여 강제로 수수료를 지불하게 함으로써 악의적인 공격을 방지할 수 있다는 의미입니다.

최종적으로 조금 정리를 해보자면..

1. 이더리움의 목적은 분산 어플리케이션 제작을 위한 대체 프로토콜을 만드는것이다.

2. 튜링-완전(Turing-completeness), 가치 인지능력(value-awareness), 블록체인 인지능력(blockchain-awareness), 상태(state)개념 등을 가짐으로써 분산 어플리케이션 제작을 위한 프로토콜을 만들 수 있다.

3. 이더리움에서 화폐는 이더(ether)로 표기되며, EOA와 CA 두가지 타입의 계정으로 분류된다.

4. 수수료(gas) 정책이 필요한 이유는 악의적인 공격자가 네트워크 리소스를 소비하는 만큼 강제로 수수료를 지불하게 함으로써 악의적인 공격을 방지할 수 있었다.

5. 이더리움은 수수료 정책을 통해 튜링-완전(Turing-completeness)을 가능하게 하였다.

백서의 내용과, 부족했던 설명을 최대한 이해하기 쉽게 풀어서 작성했지만, 부족한 부분들이 참 많이 있는것 같습니다. 정리를 하면서 어느 정도 완벽히 이해한 부분도 있고, 아직 이해가 완벽히 되지 않은 부분들도 있습니다만.. 이더리움 백서를 계속해서 정리하도록 하겠습니다.(공부는 계속되어야하니간요!)

부족한 부분들은 이더리움 백서 시리즈가 완료되는 시점에서 다시 정리하여 포스팅하도록 하겠습니다. 다음 이더리움 백서 6편에서는 메시지(Message)에 대한 설명, 여력이된다면 코드 실행 부분까지 정리하여 찾아뵙도록 하겠습니다.

이상 긴 글 읽어주셔서 감사합니다!

혹시나 이더리움 백서를 먼저 읽고 싶으신분은 아래의 링크를 통해 이더리움 백서를 먼저 확인해보시는것도 좋을것 같습니다.

• 이더리움 영문 백서 원문

• 이더리움 한글 백서 원문

[참고문헌]

https://github.com/ethereum/wiki/wiki/%5BKorean%5D-White-Paper#%EC%83%81%ED%83%9C%EB%B3%80%ED%99%98%EC%8B%9C%EC%8A%A4%ED%85%9C%EC%9C%BC%EB%A1%9C%EC%84%9C%EC%9D%98-%EB%B9%84%ED%8A%B8%EC%BD%94%EC%9D%B8bitcoin-as-a-state-transition-system

https://github.com/ethereum/wiki/wiki/White-Paper

안녕하세요. 어미새입니다.

이더리움 백서를 쉽게 이해할 수 있도록 풀어서 설명하는 연재물을 작성하고 있습니다. 오늘 포스팅 내용은 비트코인의 스크립팅과 관련된 내용이며, 이번편을 마지막으로 비트코인에 대한 설명이 끝나고, 다음편 부터는 본격적인 이더리움에 대한 설명으로 넘어가게됩니다. 혹시 지난 포스팅을 읽지 못하셨던분은 먼저 아래의 포스팅을 읽어보시는것을 추천드립니다.

• # 31 - 이더리움 개요
• # 32 - 이더리움 백서(1편)
• # 33 - 이더리움 백서(2편)
• # 34 - 이더리움 백서(3편)

Remind

머클 트리는 이진트리의 일종으로 하나의 루트 노드의 집합이며, 블록의 용량을 효율적으로 활용할 수 있는 데이터 구조를 가지고 있습니다. 블록체인 기술을 이용한 응용 사례로는 네임 코드, 컬러드 코인, 메타코인 등 다양한 응용 사례가 있었습니다.

일반적으로 합의 프로토콜을 개발하기 위해서는 독립적인 네트워크를 구현하는 방식, 기존의 시스템인 비트코인과 연동되는 새로운 프로토콜을 만드는 방식으로 나누어볼수 있으며, 전자는 네임 코인과 같은 응용사례에서 상당히 성공적이었지만, 상태 변환과 네트워킹 코드를 직접 개발하고, 독립적인 블록체인을 구동 시켜야 하는 기술적인 어려움이 있으며, 후자의 방식 메타 프로토콜 방식으로, 자체 프로토콜을 지원하지 못하기 때문에 SPV 특징을 사용하지 못한다는 단점이 있으며 비트코인을 기반한 메타-프로토콜의 라이이트(light) 클라이언트 구현은 믿을만한 서버에 의지하는 형편입니다. 우리가 암호화폐를 만든 가장 중요한 목적은 제 3자의 신용기구의 필요성을 없애는것이었다는걸 되새겨본다면, 이것은 아주 분명하게도, 차선의 결과가 될뿐입니다.

스크립팅

비트코인 프로토콜은 별도의 확장 없이도 낮은 수준의 "스마트 계약"을 구현할 수 있습니다. 비트코인의 UTXO는 공개키로 획득할 수 있지만, 추가적으로 단순 스택-기반 프로그래밍 언어로 표현되는 더 복잡한 스크립트로도 획득할 수 있습니다. 공개키 소유권 메커니즘도 스크립트를 통해 실행되며, 스크립트는 타원곡선서명을 '입력'으로 받아 그 거래와 UTXO를 가진 주소에 대한 검증을 하게되며, 검증에 성공했을 경우 1을, 실패했을 경우 0을 출력하게됩니다. 즉 다양한 사용 사례에 대해 좀 더 복잡한 스크립트들을 만들 수 있다는 의미입니다.

예를들어, 주어진 세개의 개인 키 가운데 두 개로부터 서명을 받아야만 승인이 되도록 스크립트를 구성할 수 있으며, 이런 스크립트는 회사 계정, 보안 저축 계정, 상업 공탁 상황등에 유용하게 쓰일 수 있습니다. 또한 스크립트를 통해 어떤 조건, 즉 특정 계산 문제의 답에 대한 포상금을 지불하는 방식으로 쓰일 수 있습니다.

만약 비트코인에 상응하는 도기 코인을 나에게 보냈다는 SPV 증명을 제공한다면, 해당 비트코인의 UTXO를 보낸 사람의것으로 만들 수 있는 스크립트를 구현할 수 있습니다. 즉 근본적인 탈중앙화된 상호-암호화폐 교환을 가능하게할 수 있다는 의미입니다.

비트코인의 스크립트 언어는 한계점이 있다.

비트코인 스크립트의 한계점

튜링불완전성

비트코인 스크립트 언어로 할 수 있는 작업은 많지만, 모든 경우의 프로그래밍을 지원할 수 없습니다. 특히나 while이나 for와 같은 순환(loop) 명령 카테고리를 사용할 수 없으며, 순환 명령어를 없앤 이유는 거래 증명시 무한 루프에 빠지는것을 방지하기 위함입니다.

이론적으로 튜링 불완전성은 프로그래머가 극복할 수 있는 장애물이기는합니다. 그 이유는 어떤 순환 명령이든 여러 차례 if 구문을 사용함으로써 구현이 가능하기 때문입니다. 하지만 이러한 방법은 공간 비효율적인 프로그램이 되며, 타원곡선 서명 알고리즘을 실행할 경우 코드 안에 있는 곱셈을 모두 개별적으로 256번 반복하는 작업이 필요함으로 아주 비효율적인 프로그램이됩니다.

Value-blindness

UTXO 스크립트만으로 인출 액수를 세밀하게 통제할 방법이 없습니다. 신탁 계약의 강력한 실용 사례라 할 수 있는 헷지 계약으로 예를 들어보겠습니다. 만약 A와 B가 $1000의 금액만큼의 BTC를 공동 계좌에 입금하고, 30일 후 BTC의 가격이 상승하게될 경우 자동으로 A에게는 원금인 $1000의 금액에 해당하는 BTC를 돌려 받고, B에게는 이익금인 공동계좌의 나머지 잔금을 입금 받을 수 있는 그런 계약을 맺고 싶다고 가정해보겠습니다.

이러한 계약에는 1 BTC가 미국 달러로 얼마인지 정해줄 제 3자가 필요합니다. 하지만 이런 계약이 실현 가능하다면 지금 현존 하는 중앙 집권적인 금융 시스템 아래에서도 고도로 발전된 계약 형태라고 볼 수 있을 것입니다. 현재 비트코인의 UTXO는 인출액 전부가 송금되거나, 말거나 밖에 선택할 수 없으며, 즉 세부 작은 단위로 나눠질 가능성을 포함할 수 없다는 의미입니다.

앞선 헷지 계약의 거래를 실행할 유일한 방법은 UTXO의 액면가 단위를 아주 다양하게 양산하고 (예를 들어 1부터 30까지의 모든 자연수 k에 대해 2의 k승의 1 UTXO를 만듦) A가 B에게 이중에서 필요한 금액에 맞는 것을 선택해서 보내게 하는 방식과 같이 매우 비효율적인 편법을 사용하는 길 뿐입니다.

상태 표현의 한계점(다양한 상태를 표현할 수 없음)

UTXO가 표현할 수 있는 상태는 사용되었거나, 안되었거나 두가지 방법만 존재합니다. 이 두가지 상태 이외으ㅔ 다른 어떤 내부적 상태를 가지는 다중 계약이나 스크립트를 생성할 수 없으며, 이러한 환경은 분산 환전 거래나 이중 암호 실행 프로토콜과 같은 다중 계약을 어렵게 만듭니다. 즉, UTXO는 단순하고 1회적인 계약에만 이용될 수 있으며, 분산조직과 같은 더 복잡한 "상태적(stateful)" 계약에는 활용될 수 없으며, 나아가 메타 프로토콜을 적용하기 어렵게 만듭니다.

블록체인을 해독할 방법이 없다(Blockchain-blindness)

UTXO는 논스(Nonce), 타임스탬프, 이전 블록해시 같은 블록체인 자료를 해독하지 못합니다. 이 단점으로 인해 스크립트 언어 속에 잠재적으로 가치있을 무작위성이 빠지게됩니다. 그래서 도박이나 여러 다른 분야의 어플리케이션을 만들기 어려운 한계점이 있습니다.

정리하자면, 발전된 어플리케이션을 만드는 방법은 3가지 접근 방법이 있습니다. 첫번째는 독립적인 블록체인을 만드는 것이고 두번째는 비트코인에 이미 내재된 스크립트를 이용하는 것이며 세번째는 비트코인상에서 작동되는 메타-규약을 건설하는 것입니다. 독립적인 블록체인을 만들 경우 무한히 자유로운 프로그램을 만들 수 있겠지만 개발 기간, 초기 셋업 자원, 보안 등의 비용이 발생하며, 비트코인에 내재된 스크립트를 이용하면 실행이 간단하고 표준화된 장점이 있지만, 이용범위가 제한적입니다. 또한, 메타 규약을 쓰는 것은 간단하긴 하지만, 확정성의 결함을 감수해야하는 문제점이 있습니다.

이더리움을 통해 우리는 개발하기 쉽고, 더 강력한 라이트 클라이언트 기능을 가지면서 경제적인 개발 환경과 블록체인 보안을 공유할 수 있는 어플리케이션을 만들 수 있도록 지원하는 alternative framework를 건설하고자 합니다.

마무리

본격적인 이더리움에 대한 설명의 시작부에서 이더리움의 목적은 분산 어플리케이션 제작을 위한 대체 프로토콜을 만드는것이라고 명시되어있습니다. 오늘 학습한 백서의 내용에서는 비트코인의 스크립트의 한계점인, 튜링 불완전성, UTXO의 상태표현의 한계점, 블록체인을 해독할 수 없는 문제점 등을 설명하면서 비트코인의 스마트 계약의 한계점에 대한 문제점을 지적하였습니다. 그리고 이더리움에서는 이제 이러한 문제점을 어떻게 해결하여, 분산 어플리케이션 제작을 위한 대체 프로토콜을 개발할것인지에 대한 내용이 나올것으로 예상됩니다.

백서의 내용중 부연설명이 더 필요해보이는 단어들은 따로 취합하고 있습니다(예를 들어, 네임 코인, 컬러드 코인, 메타 코인, 사이드 체인, 튜링 불완전성 등) 이런 부분은 이더리움 백서 포스팅이 끝나는 시점에서, 개별 포스팅으로 진행할 예정입니다.

드디어 비트코인, 그리고 비트코인 응용 사례를 통해 왜 이더리움 개발이 필요했는지에 대한 서술이 끝났으며, 다음 시간부터는 본격적인 이더리움에 관한 설명으로 이어지게됩니다. 앞서 작성한 이더리움 백서 1~3편을 보지 않으셨던 분들은 꼭 정독해보시는것을 추천드립니다. (오랜시간이 소요되지 않습니다!)

혹시나 이더리움 백서를 먼저 읽고 싶으신분은 아래의 링크를 통해 이더리움 백서를 먼저 확인해보시는것도 좋을것 같습니다.

• 이더리움 영문 백서 원문

• 이더리움 한글 백서 원문

이상 긴 글 읽어주셔서 감사합니다!(보팅, 리스팀, 팔로워는 제게 큰 힘이됩니다!)

[참고문헌]

https://github.com/ethereum/wiki/wiki/%5BKorean%5D-White-Paper#%EC%83%81%ED%83%9C%EB%B3%80%ED%99%98%EC%8B%9C%EC%8A%A4%ED%85%9C%EC%9C%BC%EB%A1%9C%EC%84%9C%EC%9D%98-%EB%B9%84%ED%8A%B8%EC%BD%94%EC%9D%B8bitcoin-as-a-state-transition-system

https://github.com/ethereum/wiki/wiki/White-Paper

안녕하세요. 어미새입니다.

이더리움 백서를 쉽게 이해할 수 있도록 풀어서 설명하는 연재물을 작성하고 있습니다. 지난 포스팅을 읽지 못하셨던분은 먼저 아래의 포스팅을 읽어보시는것을 추천드립니다.

• # 31 - 이더리움 개요
• # 32 - 이더리움 백서(1편)
• # 33 - 이더리움 백서(2편)

Remind

탈 중앙화된 통화 시스템을 유지하기 위해서는 분산 합의 과정이 필요하고, 네트워크가 정상적으로 유지될 수 있도록 도와주는 노드들이 필요하며, 이 노드들은 "블록(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년 이후 비트코인 분권 합의 시스템이 발전하면서 수 많은 응용 사례가 빠르게 부각되기 시작하였습니다.

• 네임 코인은 비트코인의 저장기술과, 전송 시스템 기술을 기반으로 만들어진 시스템이며, '탈중앙화된 명칭 등록 데이터베이스(decentralized name registration database)'라고 부르는것이 가장 좋은 표현일것입니다. 네임코인은 기존의 국제 인터넷 주소 관리기구에의해 중앙에서 관리되는 DNS 정보를 블록체인 기술 기반으로 관리할 수 있도록 구현되었습니다. 네임코인 기반의 도메인은 .bit로 끝나며, DNS 주소 등록과, 거래 정보의 익명성을 보장합니다. 이러한 네임코인은 인터넷 주소를 관리하며, 네트워크에 참여한 노드의 컴퓨터 자원을 활용하여 인터넷 주소를 관리하고 보상으로 코인을 지급하고 있습니다.

• 컬러드 코인의 목적은 누구나 비트코인의 블록체인 위에서 자신만의 고유한 디지털 화폐를 발행허가나, 자신만의 디지털 토큰을 발행할 수 있는 프로토콜 역할을 수행하는것입니다. 컬러드 프로토콜에서, 사용자는 특정 비트코인의 UTXO에 공개적으로 색깔을 부여함으로써 새 화폐를 발행할 수 있습니다.

• 메타코인이 품고 있는 아이디어는, 비트코인 거래를 메타코인 거래 저장에 이용하되, 상태 이동함수 APPLY를 다르게 가짐으로써, 비트코인 시스템 위에서 운영될 수 있는 프로토콜을 갖는것입니다. 메타코인은 비트코인 블록체인 위의 자산 발행 레이어를 제공하며, 컬러드 코인이 특정 UTXO와 연결된다면, 메타코인은 주소(address)에 입력된 메시지입니다. 컬러드 코인과 같이 메타코인 시스템은 채굴과 네트워킹의 복잡성을 비트코인 프로토콜에 의해 처리함으로써 적은 개발비용으로 쉬운 암호화폐 발행을 가능하게하였습니다.

일반적으로 합의 프로토콜을 개발하기 위한 방법은 두 가지 접근 방법이 있으며, 하나는 독립적인 네트워크를 만들어내는것이며, 또 다른 하나는 비트코인 시스템과 연동되는 새로운 프로토콜을 만들어내는것입니다.

전자의 접근 방법은 네임코인과 같은 응용 사례에서 상당히 성공적이었지만, 실제 개발하기에는 어려움이 있습니다. 상태 변환과 네트워킹 코드를 개발하고, 점검해야 할 뿐만 아니라 독립적인 블록체인을 구동 시켜야 하며, 나아가 분권 합의 기술에 관한 어플리케이션의 집합이 멱함수분포를 따를 것으로 예상됩니다. 즉, 대다수의 어플리케이션은 자기 자신의 블록체인을 보장하기에는 너무 작을 것이고, 서로 교류를 하기 위한 분권화된 자율 기구(DAO)가 생겨날 것이라고 예상됩니다.

후자의 접근 장법은 비트코인에 기반한 접근 방법입니다. 비트코인은 블록체인 깊이(depth)를 검증 대리 수단으로 이용하여 단순 지불 검증(SPV)을 사용할 수 있지만, 후자의 접근 방법은 SPV 특징을 사용하지 못하는 단점이 있습니다. 메타 프로토콜은 무효 거래가 블록체인에 포함되지 않도록 막을 방법이 자기 자신의 프로토콜 자체에는 없습니다. 그렇기 때문에 안전을 보장하기 윟나 단순지불검증 메타-프로토콜이라면, 어떤 거래가 유효한지 아닌지를 결정하기 위해 항상 비트코인 블록체인의 원점까지 돌아가 확인하는 작업이 필요합니다. 현재까지 비트코인을 기반한 메타-프로토콜의 모든 라이트(light) 클라이언트 구현은 믿을만한 서버에 의지하는 형편입니다. 우리가 암호화폐를 만든 가장 중요한 목적이 제 3자의 신용기구의 필요성을 없애는 것이었다는걸 특히 되새겨본다면, 이것은 아주 분명하게도, 차선의 결과가 될 뿐입니다.

마무리

오늘은 이렇게 이더리움 백서 도입부에 기록된, 머클트리와 블록체인 기술을 이용한 다른 응용 사례에 대한 내용을 다뤄봤습니다. 오늘 학습한 이더리움 백서의 내용은 블록체인 기술을 활용한 시스템을 만들기에는 많은 비용이 발생하고, 개발적 난제들이 있다는 사실을 부각한것 같습니다. 그리고 기존의 블록체인 활용방법은 비트코인에 의지하였고, 비트코인에 의지할 경우 라이트 노드를 만들기 어렵다는 문제점을 제기하며, 이더리움에서는 어떻게 이 방법을 해결할것인지에 대한 내용이 나올것으로 예상됩니다.

백서의 내용중 설명이 조금 부족했던, 네임 코인, 컬러드 코인, 메타코인에 대한 자세한 정보를 원하시는 분들을 위해 자료를 모아봤습니다. 네임코인은 @jruit님께서 작성해주셨고, 컬러드 코인은 @coolzero님께서 작성해주셨습니다. 메타코인의 자료는 피넥터 보고서, 블록체인 기술의 발전과정과 이해 자료의 자산 발행기술 챕터(25 Page)에 명시되어 있습니다. (추후 시간이 허락된다면 네임 코인, 컬러드 코인, 메타 코인에 대한 자료를 모두 취합하여 하나의 포스팅으로 만들보도록하겠습니다.)

• 네임코인(Namecoin)에 대해 알아보자

• 다시한번 정리해 보는 BCH의 컬러드 코인

• 피넥터 보고서, 블록체인 기술의 발전과정과 이해

다음 포스팅에서는 비트코인의 스크립트 부분에 대한 포스팅을 할 계획이며, 그 다음 포스팅인 이더리움 백서 5편에서는 본격적인 이더리움에 대한 설명으로 이어질것 같습니다. 혹시나 이더리움 백서를 먼저 읽고 싶으신분은 아래의 링크를 통해 백서를 먼저 확인해보셔도 좋을것 같습니다.

• 이더리움 영문 백서 원문

• 이더리움 한글 백서 원문

이상 긴 글 읽어주셔서 감사합니다!

[참고문헌]

https://github.com/ethereum/wiki/wiki/%5BKorean%5D-White-Paper#%EC%83%81%ED%83%9C%EB%B3%80%ED%99%98%EC%8B%9C%EC%8A%A4%ED%85%9C%EC%9C%BC%EB%A1%9C%EC%84%9C%EC%9D%98-%EB%B9%84%ED%8A%B8%EC%BD%94%EC%9D%B8bitcoin-as-a-state-transition-system

https://github.com/ethereum/wiki/wiki/White-Paper