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


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





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


어느덧 이더리움 백서 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

'이더리움 > 이더리움(백서)' 카테고리의 다른 글

이더리움 백서(6편)  (0) 2018.04.12
이더리움 백서(5편)  (0) 2018.04.11
이더리움 백서(3편)  (0) 2018.04.10
이더리움 백서(2편)  (0) 2018.04.06
이더리움 백서(1편)  (0) 2018.04.06







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


이더리움 백서를 쉽게 이해할 수 있도록 풀어서 설명하는 연재물을 작성하고 있습니다. 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

'이더리움 > 이더리움(백서)' 카테고리의 다른 글

이더리움 백서(7편)  (0) 2018.04.13
이더리움 백서(5편)  (0) 2018.04.11
이더리움 백서(3편)  (0) 2018.04.10
이더리움 백서(2편)  (0) 2018.04.06
이더리움 백서(1편)  (0) 2018.04.06






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


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






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

'이더리움 > 이더리움(백서)' 카테고리의 다른 글

이더리움 백서(7편)  (0) 2018.04.13
이더리움 백서(6편)  (0) 2018.04.12
이더리움 백서(3편)  (0) 2018.04.10
이더리움 백서(2편)  (0) 2018.04.06
이더리움 백서(1편)  (0) 2018.04.06





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


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


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)에 명시되어 있습니다. (추후 시간이 허락된다면 네임 코인, 컬러드 코인, 메타 코인에 대한 자료를 모두 취합하여 하나의 포스팅으로 만들보도록하겠습니다.)



다음 포스팅에서는 비트코인의 스크립트 부분에 대한 포스팅을 할 계획이며, 그 다음 포스팅인 이더리움 백서 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

'이더리움 > 이더리움(백서)' 카테고리의 다른 글

이더리움 백서(6편)  (0) 2018.04.12
이더리움 백서(5편)  (0) 2018.04.11
이더리움 백서(2편)  (0) 2018.04.06
이더리움 백서(1편)  (0) 2018.04.06
이더리움 개요  (0) 2018.04.05



 


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


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



Remind


비트코인 시스템은 이세상에 없던 기술들을 총 집합하여 탄생한것이 아니라 아주 오래전부터 그와 관련된 이론들과 논의들이 있었다는 내용과, 비트코인이 어떤 의미에서 혁신적이었는지에 대한 내용을 다뤘으며, 작업 증명 방식, 지분 증명 방식의 두가지 합의 알고리즘을 언급함으로써 이더리움에 시작은 작업 증명 방식으로 이루어지나 추후 지분 증명 방식으로 변화할것을 암시하였습니다.

또한, 기존의 비트코인 시스템에서 사용되는 '상태(State)'와 '상태 변환 함수(state transition function)'에 대한 개념에 대하여 먼저 설명한 후 이더리움에서는 이 부분을 어떻게 수정할지에 대한 내용을 다루게됩니다.


채굴


[출처 : 이더리움 백서(링크)]


앞서 언급한 내용들을 중앙 집권화된 서비스 방식으로 구현하자면 매우 간단한 일입니다. 그 이유는 중앙 서버에 상태 변화과정을 저장하고 관리하면 어렵지 않게 구현할 수 있습니다.

하지만 탈 중앙화된 통화 시스템을 구축하기 위해서는 분산 합의 과정이 필요하고, 네트워크가 정상적으로 유지될 수 있도록 도와주는 노드들이 필요합니다. 또한, 이 노드들은 "블록(blocks)"이라 불리는 트랜잭션 패키지를 계속적으로 생성하고 합의하는 역할을 수행해야합니다.

비트코인 네트워크는 약 10분에 한번식 하나의 블록을 생성하도록 계획되었고, 각 블록은 타임스탬프, 논스(nonce), 이전 블록에 대한 참조(이전 블록의 해시), 그리고 이전 블록 이후에 발생한 모든 트랜잭션의 목록을 포함합니다. 이 과정을 통해서 지속적으로 성장하는 블록체인이 생성되며, 비트코인 장부의 최신상태(state)를 나타내기 위해 지속적인 업데이트가 이루어져야합니다.


생성된 블록이 유효한지 아닌지를 확인하기 위한 알고리즘은 아래와 같습니다.


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

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

  3. 작업증명(proof of work)이 유효한지 확인한다. (새로운 블록을 찾는 과정이 유효했는지에 대한 검증)

  4. S[0]를 이전 블록의 마지막 상태(state)가 되도록 설정한다.

  5. TXn개의 트랜잭션을 가지는, 블록의 트랜잭션 목록으로 가정한다. 폐구간 0...n-1의 모든 i에 대해, S[i+1] = APPLY(S[i], TX[i])집합 중 어느 하나라도 에러를 리턴하면 거짓(false)을 리턴하며 종료한다.

  6. 참(true)을 리턴하고, S[n]를 이 블록의 마지막 상태로 등록한다.


1 ~ 3번 과정은 새로운 블록에 대한 유효성 검증이며, 4 ~ 6번 과정은 지난 이더리움 백서 1편에서 언급한 비트코인의 상태 변화 시스템에 대한 내용입니다.

가장 최근의 블록의 상태 정보를 가져오고, 현재 블록에 있는 트랜잭션 목록들에 대한 유효성을 점검한 후 상태 정보를 업데이트한다고 생각하시면 쉬울것 같습니다. 이 과정이 이해가 되지 않으시다면 1편에서 설명한 상태 변화 시스템에 대한 내용을 다시 읽어보시면 좋을것 같습니다.


기본적으로 블록의 트랜잭션들은 유효한 상태변환을 진행해야합니다. 여기서 유심있게 살펴봐야하는점은 블록내에 어떠한 방법으로도 상태정보가 기록되지 않았다는 점을 주목해야합니다. 상태는 유효성을 검증하는 노드가 매번 계산해서 기억해야 하는 추상적(abstaction)인 개념이며, 이것은 원시 상태(genesis state), 즉 제네시스 블록으로 부터 현재 블록까지의 모든 트랜잭션을 순차적으로 적용함으로 계산할 수 있습니다.

채굴자(마이너)가 블록에 포함시키는 트랜잭션의 순서를 주목해보겠습니다. 만약 어떤 블록에 A와 B라는 트랜잭션이 있다고 가정해보겠습니다. 그리고 B의 트랜잭션은 A의 UTXO를 소비한다고 가정했을 경우 B는 A의 UTXO 정보가 필요하기 때문에 반드시 A의 트랜잭션이 먼저 블록에 담겨 있어야합니다. 만약 트랜잭션 A가 먼저 블록에 담겨 있지 않을 경우 B는 존재하지 않은 트랜잭션 A의 UTXO 정보를 사용하게됨으로 해당 블록의 유효성이 보장되지 않습니다. (즉 블록의 트랜잭션을 어떤순서로 담느냐에 따라 블록이 유효할수도, 유효하지 않을수도 있다는 의미입니다.)



 


블록 유효성 검증 알고리즘에서 "작업증명(proof of work)"의 조건은 256비트 숫자로 표현되는 블록의 이중-SHA256 해시 값이 동적으로 조정되는 목표값 보다 반드시 작아야 된다는 조건입니다. (비트코인 마이닝편 참조)

작업 증명의 목적은 블록 생성을 계산적으로 어렵게 만들어서 sybil 공격자들이 마음대로 전체 블록체인을 조작하는 것을 방지하기 위함입니다. SHA256 함수는 예측 불가능한 유사난수 함수(pseudorandom function)로 설계되어 있기 때문에 유효 블록을 생성하기 위한 유일한 방법은 블록 헤더의 논스(nonce) 값을 계속 증가시키면 블록 해시 값이 목표값 보다 작은지에 대한 검증을 반복하는 방법밖에 없습니다.

현재 목표 값인 2187(이더리움 백서 작성 시간 기준)에서 하나의 유효블록을 발견하기 위해서는 평균적으로 264번의 시도를 해야합니다. 네트워크는 평균적으로 10분마다 새로운 블록이 생성될 수 있도록 2016개의 블록마다 목표 값을 변경하게됩니다.

채굴자들은 이러한 연산 작업에 대한 보상으로 25 BTC(이더리움 백서 작성 시간 기준)를 획득할 자격을 가지게 되며, 출력 금액보다 입력 금액이 큰 트랜잭션이 있다면 그 차액을 "트랜잭션 수수료(transaction fee)"로 얻게 됩니다. 이러한 과정이 비트코인이 발행되는 유일한 방법이며, 원시 상태(genesis state)에는 아무런 코인이 포함되어 있지 않습니다.

채굴 목적에 대한 이해를 위해 악의적인 공격자가 있을 떄 어떤 일이 발생하는지 생각해보겠습니다. 일반적으로 비트코인의 뼈대를 이루는 암호기법은 안전한 것으로 알려져 있습니다. 그렇기 때문에 공격자는 비트코인 시스템에서 암호 기법에 의해 직접적으로 보호되지 않는 부분인 '트랜잭션 순서'를 공격 목표로 잡을것입니다.


  1. 어떤 상품(가급적이면 바로 전달되는 디지털 상품)을 구매하기 위해 판매자에게 100 BTC를 지불한다.

  2. 상품이 전송되기를 기다린다.

  3. 판매자에게 지불한 것과 같은 100 BTC를 공격자 자신에게 보내는 트랜잭션을 생성한다.(이중지불 시도)

  4. 비트코인 네트워크가, 공격자 자신에게 보내는 트랜잭션이 판매자에게 지불하는 트랜잭션보다 먼저 수행된 것으로 인식하도록 한다.


1번 과정이 발생하고 몇 분 후에 몇몇 채굴자들이 해당 트랜잭션을 블록에 포함하게됩니다. 그리고 이 블록 번호를 270000 이라고 가정해보겠습니다. 블록은 10분에 한번식 생성되기 때문에 대략 1시간 후에는 이 블록 다음의 체인에 5개의 블록들이 추가될 것입니다. 트랜잭션이 포함된 블록 이후 5개의 블록들이 연결되었기 때문에 컨펌(confriming)되었다고 생각할 수 있으며, 이 시점에서 판매자는 BTC 지불이 완료된 것으로 판단하고 상품을 전송하게됩니다. (상품은 디지털 상품으로 가정하에 전송하는 순간 상품을 받았다고 가정합니다.)

이제 공격자는 판매자에게 보낸 것과 동일한 100 BTC를 공격자 자신에게 보내는 트랜잭션을 생성합니다. 이때 만약 공격자가 그냥 단순하게 트랜잭션을 시도한다면, 채굴자들이 채굴자들이 APPLY(S,TX)를 실행하여 해당 트랜잭션(TX)은 더이상 존재하지 않는 UTXO를 소비하는 행위인것을 알게되고, 해당 트랜잭션은 진행되지 않습니다.

그렇기 때문에, 공격자는 판매자에게 보낸 시점의 이전 블록인 269999 블록으로 되돌아가 공격자 자신에게 보내는 트랜잭션을 포함한 270000 블록을 생성하여, 블록체인 "분기점(fork)"을 생성합니다.

비트코인 네트워크는 가장 긴 블록체인을 참으로 인식하기 때문에 메인 블록체인에 이미 연결된 270005번 블록까지 조작해야합니다. 그렇기 때문에 공격자는 자신의 체인을 가장 길게 만들기 위해서 네트워크에 연결된 다른 노드들의 계산능력 조합보다 더 큰 계산 능력을 가져야합니다. (이를 51% attack이라 한다.)


Think


오늘 이더리움 백서 번역본에서는 비트코인의 채굴 방식과, 공격 방식에 대한 설명 부분에 대해서 다뤘으며, 백서 후반부에서 이더리움에서는 어떠한 방식의 채굴 방식을 선택할 것이고 공격자의 공격을 어떻게 막을것인지에 대한 이야기가 진행됩니다.

지난 포스팅에서도 잠간 언급되었지만, 탈 중앙화된 암호화폐는 어느 한순간에 나온 개념이 아니며, 아주 오래전부터 연구되어왔던 내용들을 비트코인에서 처음으로 구현하게된것입니다. 그렇기 때문에 블록체인의 개념을 한단어로 정의하기 어렵고, 내용이 방대하여 학습에 어려움이 있는것 같습니다.

하지만 하나식 천천히 반복적으로 뜯어서 학습을 진행하게되면 이해하는데 어려움이 없을것이라고 생각합니다. 이더리움에 대한 명확한 이해를 하기 위해서는 필수적으로 비트코인에 대한 이해가 선행되어야한다고 생각합니다. 오늘 포스팅에서 언급된 내용들에 대한 내용들은 비트코인 포스팅에서 설명한 내용들과 상당히 겹치는 부분들이 많습니다. 혹시 오늘 포스팅이 이해가 되지 않으셨던분들은 비트코인 마이닝 과정, UTXO, 51% acttact에 대한 내용들을 읽어보시면 좋을것 같아서 링크를 남겨두도록 하겠습니다.




오늘은 이더리움 백서부분에 대한 해석을 여기까지만 하도록 하겠습니다, 본격적인 이더리움에 대한 설명은 머클트리, 블록체인 기술을 이용한 사례, 스크립팅에 대한 챕터 이후 설명이 시작됩니다.

조금은 이전 비트코인 포스팅과 겹치는 부분이 있어서 이더리움을 공부하기 위해 들어오신분들에겐 답답한 마음이 생길 수 있을것 같으나, 비트코인을 변형하여 만들어진 플랫폼이다보니 그 만큼 비트코인에 대한 설명이 중요하다고 생각합니다. (백서의 흐름대로 학습해야지 나중에 더욱더 이해하기 쉽다고 생각합니다.)

혹시 이더리움 백서를 먼저 읽어보고 싶은 분을 위해 이더리움 백서 링크를 첨부해 드립니다.



 

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



[참고문헌]

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

'이더리움 > 이더리움(백서)' 카테고리의 다른 글

이더리움 백서(6편)  (0) 2018.04.12
이더리움 백서(5편)  (0) 2018.04.11
이더리움 백서(3편)  (0) 2018.04.10
이더리움 백서(1편)  (0) 2018.04.06
이더리움 개요  (0) 2018.04.05





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


지난 이더리움 포스팅에서는 비탈릭 부테린에 대한 인물 소개와 이더리움에 대한 간략한 개요를 살펴봤습니다. 혹시 못보셨던분들은 아래의 링크를 통해 지난 포스팅을 먼저 읽어보시는것을 추천드립니다.



이번 포스팅에서는 지난시간에 예고해 드린것처럼 이더리움의 백서 도입부인 역사파트의 내용을 재해석 하는 시간을 가지도록 하겠습니다. 원문 내용을 축약하여 쉽게 풀어서 설명하고, 이해를 돕기 위해 보충해야되는 부분을 채워가는 형식으로 진행하도록하겠습니다. 만약 이더리움 백서의 원본을 읽고 싶으신분들은 아래의 링크를 통해 원문을 읽어보시길 추천드립니다.


이더리움의 백서의 시작은 비트코인에 대한 이야기로 시작됩니다.


A Next-Generation Smart Contract and Decentralized Application Platform


사토시 나카모토가 2008년~2009년에 개발한 비트코인은 중앙화된 발행기관이나 통제기관 없이 상용화된 디지털 자산의 첫번째 사례였기 때문에 화폐와 통화분야에 매우 근본적인 혁신으로 묘사되어왔다. 하지만 더 중요한 요소는 분산합의 수단으로서의 블록체인 기술이며, 이에 대한 관심이 급격하게 늘어나고있다.

이더리움은 완벽한 튜링완전(turing-complete) 프로그래밍 언어가 심어진 블록체인이며, 이 프로그래밍 언어는 코딩된 규칙에 따라 '어떤 상태'를 다르게 변환시키는 기능이 포함된 계약(contracts)을 유저들이 작성할 수 있게 함으로써 우리가 아직 상상하지 못한 다른 많은 어플리케이션도 매우 쉽게 만들 수 있도록 도와주는것이다.


Introduction to Bitcoin and Existing Concepts


History

분산화된 디지털 통화의 개념은 이미 오래전부터 우리 주변에 있었습니다. 1980~1990년대에 암호 알고리즘(cyptographic primitve)을 기반한 e-cash 프로토콜은 개인정보를 강력하게 보호하는 화폐를 제공하였으나 중앙집권적인 중개인 방식에 의존했기 때문에 주목받지 못했습니다.

1998년 'Wei Dai'의 b-money는 작업 증명 방식의 방식으로, 분산 합의와 계산 퍼즐을 풀게하는 방식을 통해서 화폐를 발행하게 하는 아이디어를 최초로 제안하였지만 분산 합의를 실제로 어떻게 구현할지에 대한 자세한 방법을 제시하지 못했습니다.

2005년 'Hall Finney'는 b-money의 아이디어에 Adam Back의 계산 난이도 해시캐시 퍼즐을 조합하여 재사용 가능한 작업증명 개념을 소개하였습니다만, 이 방법도 외부의 신뢰를 필요로 하는 컴퓨팅(trsuted computing)을 기반에 둠으로써 또 다시 구현하는데에 실패하였습니다.

2009년 나가모토 사토시에 의해 비트코인이 개발되었으며, 비트코인은 공개키 암호방식을 통한 소유권 관리를 위해 사용되었던 기존의 알고리즘과 '작업 증명(proof of wokr)' 합의 알고리즘을 결합함으로써 실제적으로 탈 중앙화된 화폐를 처음 구현하게되었습니다.

작업 증명 방식은 네트워크 상에 있는 모든 노드들이 비트코인 장부 상태에 일어난 업데이트를 공동으로 관리할 수 있게 하였으며, 누구나 합의 프로세스에 참여할 수 있도록 허용함으로써 합의 결정권에 대한 정치적 문제를 해결할 수 있었습니다. 또한 시빌 공격(sybile attacks)을 방어할 수 있는 메커니즘을 제공하였으며 각 노드의 결정권의 크기를 그 노드의 계산 능력에 직접적으로 비례시키는 방식으로 어떤 형식적 장벽대신, 경제적 장벽으로 대처함으로써 매우 혁식적인 알고리즘을 제안하였습니다.

작업 증명 방식 이후, 지분 증명(proof of stake)라는 새로운 방식의 합의 알고리즘이 등장하였고, 이는 각 노드가 가진 계산 능력이 아니라 화폐의 보유량에 따라 각 노드의 결정권 정도를 계산한다는 개념입니다.

이 두 방식의 상대적인 장점들에 대한 논의는 이 백서에서는 다루지 않겠지만, 두 방법 모두 암호화화폐의 기반으로서 사용될 수 있다는 점은 지적해두고자 한다.


상태변환시스템으로서의 비트코인(Bitcoin As A State Transition System)


비트코인의 장부는 하나의 상태변환 시스템(state transation system)으로 생각해볼 수 있습니다. 이 시스템은 현재 모든 비트코인의 소유권 현황을 관리하기 위한 "상태(state)"와 트랜잭션(거래 기록)을 처리하고 새로운 "상태(state)"정보를 만들어주기 위한 "상태변환함수(state transition function)"로 구성되어있습니다.

예를 들어 표준 은행 시스템이 비유하자면 상태는 모든 계좌 잔고표(balance sheet)와 같고, 트랜잭션은 거래 내역으로 A에서 B로 X(금액)를 송금하라는 요청입니다. 상태 변환 함수에 의해 A의 계좌의 잔고는 송금한 X만큼 감소하고, B의 계좌의 잔고는 송금 받은 X만큼 증가하게되는것입니다. 만약 A의 계좌에 있는 잔고가 송금하고자 했던 금액 보다 작을 경우 상태 변환 함수는 에러를 리턴하게됩니다.

백서에 있는 그림을 조금더 보기 쉽게 변경한 그림은 1번과 같으며, 백서 본문에 기록된 원본 이미지는 2번과 같습니다.


1. 백서 변경 그림


2. 백서 원본 그림

[출처 : 이더리움 백서(링크)]


이러한 상태변환을 비트코인 장부에서는 아래와 같이 정의할 수 있습니다.

APPLY(S,TX) -> S' or ERROR


만약 은행 시스템에서 사용한다면 아래와 같습니다.

APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR


UTXO집합에는 각자의 코인 금액이 표시되어 있고, 이 UTXO의 소유자(20byte의 주소로 정의되는 암호화된 공개키)의 정보가 들어있습니다. 트랜잭션에는 하나 이상의 입력(inputs) 및 출력(outputs)이 포함되며, 입력에는 보내는 사람의 UTXO에 대한 참조 정보와, 개인 키로 암호화된 서명을 포함하고있습니다. 또한, 출력에는 새롭게 추가될 UTXO 정보가 포함됩니다.


위에서 언급된 상태 변환 함수APPLY(S,TX) -> S를 풀어서 설명하면 아래와 같습니다.

  1. TX(트랜잭션)의 입력 값 검증

    • 만약 S에 참조된 UTXO 정보가 없다면, 에러를 리턴

    • 만약 서명 정보가 UTXO 의 소유자와 같지 않으면, 에러를 리턴(다른 사용자의 예치금)

  2. 만약 입력에 사용된 UTXO 들의 총합이, 출력 UTXO 의 합보다 작으면, 에러를 리턴.(잔고 부족)

  3. 위의 모든 정보가 정상적이라면, 입력에 사용된 UTXO 정보를 더이상 사용하지 못하도록 삭제하고, 출력 UTXO 정보를 추가하여 새로운 "상태(state)"인 S'를 리턴.


1번의 첫번째 과정은 존재하지 않은 비트 코인이 트랜잭션에 사용되는 것을 막기 위한것이며, 1번의 두번째 과정은 다른 사람의 코인이 트랜잭션에 사용되는 것을 막기 위한 방법입니다.

만약 Alice가 Bob에게 11.7 BTC를 보내고 싶을 경우 먼저 Alice 지갑주소에 표시된 금액의 합이 최소 11.7 BTC 이상인 UTXO의 집합 정보가 필요합니다. 거의 대부분의 경우 11.7 BTC를 가지고 있는 UTXO 정보를 바로 선택하는 경우는 드물며, 6.0 BTC, 4.0 BTC, 2.0 BTC 처럼 금액이 분산된 여러가지 UTXO 정보를 참조하게됩니다.

보내고자 하는 금액은 11.7 BTC이지만, 실제 참조하게되는 UTXO 총합은 12.0 BTC이기 때문에 다음과 같이 12(6+4+2) - 11.7 = 0.3 BTC 잔돈이 발생하게됩니다.

트랜잭션에는 위의 3가지 UTXO 정보가 input으로 설정되며, output에는 송금하고자 하는 금액 11.7 BTC의 새로운 UTXO 정보와, 소유자 Bob이 잔돈을 받게되는 UTXO 정보 2가지 정보로 구성됩니다.



Think

본 포스팅 문서는 이더리움 백서를 보다 이해하기 쉽도록 재 해석하였으며, 너무 많은 양을 한번에 포스팅할 경우 읽는 사람도 지치고, 작성하는 사람도 지칠것 같아서 조금씩 꾸준히 포스팅하기로 결정하였습니다.

모든 백서의 도입부는 기존의 시스템이 무엇인지에 대한 설명과, 부족한 부분이 무엇인지를 지적하고 새로운 방식을 어떻게 구현할것인지에 대한 내용으로 채워지게됩니다.

오늘 포스팅한 백서에서는 비트코인이 이세상에 없던 기술들을 총집합하여 탄생한것이 아니라 아주 오래전부터 그와 관련된 이론들과 논의들이 있었다는 내용과, 비트코인이 어떤 의미에서 혁신적이었는지에 대한 내용으로 시작하였으며, 작업 증명 방식, 지분 증명 방식의 두가지 합의 알고리즘을 언급함으로써 이더리움에 시작은 작업 증명 방식으로 이루어지나 추후 지분 증명 방식으로 변화할것을 예고한 느낌입니다.

또한, 기존의 비트코인 시스템에서 사용되는 '상태(State)'와 '상태 변환 함수(state transition function)'에 대한 개념에 대하여 먼저 설명한 후 이더리움에서는 이 부분을 어떻게 수정할지에 대한 내용을 다루게됩니다.

오늘은 이더리움 백서의 도입부에 대한 내용을 해석하였으며, 다음 포스팅에서 이어서 계속해서 백서를 이해하기 쉽게 풀어서 정리해보도록 하겠습니다.


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


[참고문헌]


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

'이더리움 > 이더리움(백서)' 카테고리의 다른 글

이더리움 백서(6편)  (0) 2018.04.12
이더리움 백서(5편)  (0) 2018.04.11
이더리움 백서(3편)  (0) 2018.04.10
이더리움 백서(2편)  (0) 2018.04.06
이더리움 개요  (0) 2018.04.05

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


이더리움에 대한 설명을 어디서부터 어떻게 시작할지 참 많은 고민이 있었습니다. 우선은 백서에 대한 내용을 이해하는것이 가장 먼저인것같았습니다, 그래서 이더리움의 백서 내용을 조금더 쉽게 이해할 수 있도록 풀어서 설명하는 포스팅을 진행할 예정이며, 깊히 있게 다뤄야하는 부분은 추후 따로 개별 포스팅을 진행하도록 하겠습니다.

오늘은 첫시간이니만큼 간략한 개요 정도로 가볍게 포스팅을 시작하도록 하겠습니다, 부족한 부분이나 오류가 있는 부분은 코멘트 주시면 감사하겠습니다!


비탈릭 부테린


이더리움의 창시자인 비탈릭 부테린은 어렸을떄부터 프로그래밍에 소질이 있었고, 비트코인으로부터 큰 영향을 받은 인물중 한명입니다. 2011년 비트코인 매거진을 만들었을 정도로 비트코인에 대한 열정이 가득한 청년이었습니다. 비탈릭은 비트코인 기술을 응용하면 단순한 지급 결제뿐 아니라, 주식 발행, 부동산 계약, 보험 상품 설계, 법인 등록, 전자 투표등 다양한 분야에서 블록체인 기술이 활용될수 있다고 생각했습니다. 그럼 비탈릭은 어떤 부분에서 이런 생각을하게 되었을까요?


스크립트(Script)

비트코인 내부에는 간단한 프로그래밍인 스크립트(Script)가 있습니다. UTXO를 관리하기 위한 잠금 스크립트와, 서명이 담겨있는 해제 스크립트가 있었죠 그리고 이 스크립트들이 실행되면서 소비 조건이 맞는지 확인하고 암호해제와 거래 이전을 보장하는 역할을 수행했습니다, 하지만 비트코인의 스크립트는 간단한 연산과 판단만을 할 수 있었으며 이것을 튜링 불완전성이라고합니다. 비탈릭은 이러한 비트코인의 스크립트의 튜링 불완전성을 수정 보안하여, 튜링 완전성을 확복하고 나아가 단순한 암호화폐 교환의 역할만 수행하는 블록체인 기술을 해방시키고자 하였습니다.


비트코인 커뮤니티

비탈릭은 이러한 내용으로 비트코인을 개선하고자 하였으나, 기존의 채굴자들은 이러한 변화를 환영하지 않았죠.. 자신들에게 더 많은 수익이 창출될거라는 생각보다는 기존의 프로그램을 변경해야하며, 악의적인 사용자가 스크립트에 무한루프(반복문)를 통하여 악성 코드를 심었을 경우 네트워크는 마비될 것이라는 비관적인 시선이었습니다. 이러한 문제로 인하여 비탈릭은 새로운 코인을 만들 수 밖에 없었습니다.





이더리움


이더리움과 비트코인의 가장큰 차이점은 사용 범위에 있습니다. 비트코인은 단순한 결제, 거래 관련 시스템이입니다. 즉 화폐로서의 기능에 집중되어 있죠, 하지만 이더리움은 블록체인을 기반으로 거래나 결제뿐만 아니라, 계약서, SNS, 이메일, 전자투표 등 다양한 애플리케이션을 투명하게 운영할 수 있도록 확작성을 제공하였습니다.

이더리움의 등장으로 기존의 암호화폐는 단순한 화폐의 기능을 제공하였다면, 블록체인을 활용한 다양한 응용분야의 확장성을 제안함으로써 2세대 코인의 대표주자로 자리매김하게되었습니다.

이더리움의 가장큰 목표는 분산 어플리케이션 제작을 위한 대체 프로토콜을 만드는것이었습니다, 즉 블록체인을 활용한 모든 것을 프로그래밍할 수 있도록 도와주는 플랫폼을 만들고 싶었던것이죠. 우리는 앞으로 이더리움이 무엇인지에 대한 보다 더 자세한 내용을 살펴보기 위하여 백서를 참고하여 내용을 간략하게 이해한 후 중요한 요소들은 개별적인 포스팅을 통해 심도있게 학습을 진행하도록 하겠습니다. 백서의 내용이 궁금하신분들 위해 한글, 영문 백서의 링크를 아래와 같이 첨부하였습니다. 미리 읽어보시는것도 좋을것 같습니다.


이더리움 백서 목차

  • 역사

    • 상태변환시스템으로서의 비트코인

    • 채굴

    • 머클트리

    • 블록체인 사용한 다른 사용사례

    • 스크립팅

  • 이더리움

    • 이더리움 어카운트

    • 메시지와 트랜잭션

    • 이더리움 상태변환함수

    • 코드 실행

    • 블럭체인과 채굴

  • 어플리케이션들

    • 토큰 시스템

    • 금융 파생상품

    • 신원조회와 평판시스템

    • 탈중앙화된 파일 저장공간

    • 탈중앙화된 자율 조직

    • 추가적인 어플리케이션들

  • 기타 이슈들

    • 수정된 GHOST 도입]

    • 수수료

    • 연산과 튜링완전성

    • 통화와 발행

    • 채굴 중앙집중화

    • 확장성

  • 결론

  • 주석과 추가 자료



더하기

2014년 '월드테크놀로지어워드' 올해의 정보기술(IT) 소프트웨어 부문 수상은 모두가 페이스북의 마크 저커버그가 차기할 것이라고 예상하였지만, 이더리움의 아버지인 비탈릭 부테린이 수상하게 되었죠, 그 당시 비탈릭의 나이는 20살에 불과하였습니다. 이때 우리나라에서는 이더리움의 표기를 이시리움이라고 표기하고 있었던것 같네요.. 보다 자세한 내용이 궁금하신분은 아래의 링크를 통해 그 당시 뉴스 기사를 읽어보셔도 재미있을것 같습니다.


이로써 이더리움에 대한 아주 간략한 개요에 대한 포스팅을 마치도록 하겠으며, 다음 포스팅에서는 이더리움 백서에 나와있는 '역사'파트에 대한 내용을 찾아뵙도록 하겠습니다. (역사 파트이다보니, 비트코인에 대한 이야기로 내용이 구성되어있습니다.)


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



[참고문헌]

https://brunch.co.kr/@blockchainstory/5

https://brunch.co.kr/@ashhan/10

http://news.hankyung.com/article/2014121540821

https://namu.wiki/w/Ethereum

'이더리움 > 이더리움(백서)' 카테고리의 다른 글

이더리움 백서(6편)  (0) 2018.04.12
이더리움 백서(5편)  (0) 2018.04.11
이더리움 백서(3편)  (0) 2018.04.10
이더리움 백서(2편)  (0) 2018.04.06
이더리움 백서(1편)  (0) 2018.04.06

+ Recent posts