블록체인 - 이더리움 백서

오늘 내가 배운 것

1. 이더리움 백서

2. 역사

3. 이더리움

 

1. Ethereum (이더리움) 백서

https://github.com/ethereum/wiki/wiki

Home

(한국어 : https://github.com/ethereum/wiki/wiki/%5BKorean%5D-White-Paper) 

Home

 

이더리움 공식 Github Wiki에 적혀있고, 이더리움의 공동 창립자인 비탈릭 부테린이 작성하였다.
이더리움 개발의 기반이 되는 이더리움의 비전 설계 사용사례 등이 적혀있다.

보통의 문서와 다르게 목차 앞에 서술되어 있는 내용이 있다.

 

차세대 스마트 컨트랙트와 탈중앙화된 애플리케이션 플랫폼
 : 블록체인 기술인 블록체인 네트워크(생태계)를 활용해서 애플리케이션(웹사이트)을 쉽게 만들어주는 플랫폼이 이더리움의 목적이다.

 

백서에 이더리움이 제공하려는 것은 완벽한 튜링완전 프로그래밍 언어가 심어진 블록체인이다라는 말이 있다.

튜링완전이란?
튜링 기계를 시뮬레이션할 수 있는 시스템이나 프로그래밍 언어를 말한다. 알고리즘으로 설명할 수 있는 모든 계산을 수행할 수 있는 이론적 장치이다. 시간과, 리소스가 주어지면 알고리즘으로 해결할 수 있는 모든 문제를 말한다.

조금 쉽게 말하자면 계산 가능한 문제를 해결할 수 있는 모든 기계의 공통된 능력이라고 할 수 있다.
계산이 되는 식을 계산하고, 계산이 안 되는 식을 안 한다 라는 의미이다.
ex) 1+1 (가능) / 1+오리 (불가능)

"이더리움이 제공하려는 것은 완벽한 튜링완전 프로그래밍 언어가 심어진 블록체인이다"를 다시 말하면
"이더리움이 제공하려는 것은 완벽하게 계산이 가능한 문제를 해결할 수 있는 프로그래밍 언어가 심어진 블록체인이다."라고 설명할 수 있다.

그래서 비트코인은 결제에 많이 집중되어 있지만, 이더리움은 결제에 집중되어 있지 않다.

 

 

 

 

 

2. 역사

역사를 소개하면서 비트코인의 POW를 혁신적이라 표현하였고, POW가 2가지 문제를 동시에 해결했다고 말한다.

  1. 간단하면서, 상당히 효과적인 합의 알고리즘을 제공했다.
  2. 누구나 합의 프로세스에 참여할 수 있다.

백서에서는 처음에 POW방식으로 합의 알고리즘을 진행하여 개발하였기 때문에 POW에 대한 내용을 언급했고, POS 합의알고리즘에 대해서는 있다는 정도만 언급을 하였는데, 이더리움은 POW에서 POS방식으로  방식을 바꾸었다.
이더리움이 POW에서 POS로 바꾼 이유가 있는데, 크게 2가지 이유라고 추정된다.

1. POW의 장점인 누구나 채굴을 할 수 있다는 점을 악용하여, 마이너들끼리 그룹을 만들어서 서로 보상을 나누는 문제가 생겼다. 여러 사람이 힘을 합쳐서 해시파워가 커진다면 이 블록체인 생태계는 그 그룹이 장악하게 되어 더 이상 탈중앙화라고 부를 수 없기 된다. 

2. POW방식은 많은 사람들이 동시에 작업을 하여 그중 단 한 명에게만 보상이 주어지기 때문에 막대한 전력의 소비 및 낭비로 환경문제에도 거론될 정도로 심각하다.

 

 

2-1. 상태 변환 시스템으로서의 비트코인

비트코인 백서 참고

이더리움에서 state라고 표현한 것은 비트코인의 UTXO와 비슷한 느낌으로 이해할 수 있다.
이더리움의 상태 개념을 정말 추상적으로 React의 상태로 이해할 수 있다.

React에서의 상태는 구성요소를 유지관리하는 내부 테이터를 나타낸다. React의 상태는 구성 요소가 렌더링 되고 작동하는 방식을 결정하는 데이터를 저장하고 관리하는 데 사용한다.

이와 비슷하게 이더리움에서의 상태도 블록체인 네트워크의 현재 상태를 나타낸다. 계정 잔액, 계약코드 및 기타 정보를 포함한 다양한 데이터를 담는다. 이더리움의 상태는 트랜잭션이 처리되고, 실행됨에 따라 지속적으로 변경되어 네트워크의 전체 상태를 변경한다.

이런 의미에서의 상태의 개념이 추상적으로 비슷하다고 할 수 있다.

 

 

2-2. 스크립팅

이더리움 백서에서 별도의 확장 없이도 비트코인 프로토콜은 낮은 수준의 "스마트 계약"의 개념을 가능하게 할 수 있다.라는 문구를 통해서 비탈릭 부테린은 서명에 관한 로직을 스마트 컨트랙트라는 시점으로 바라본다고 생각할 수 있다.
하지만 비트코인에 구현된 스크립트 언어의 한계점에 대해서도 언급했는데,

  1. 튜링불완전성 : 비트코인을 사용하여 생성할 수 있는 "스마트 계약"의 복잡성을 제한한다.
  2. 가치무지하다 : Bitcoin의 스크립팅 언어는 Bitcoin 자체의 전송 이외의 다른 유형의 가치를 처리할 수 없다. 더 복잡한 금융 상품 (이자)을 처리할 수 있는 기본 제공 기능이 없다.
  3. 다양한 상태를 표현할 수 없다 :비트코인의 스크립팅 언어는 트랜잭션 간에 변경 가능한 상태를 유지할 수 없다.
  4. 블록체인을 해독할 방법이 없다

라는 문제점을 말했다.
그래서 이더리움에서 스크립팅은 이러한 문제점을 극복하기 위해서 튜링완전 프로그래밍 언어인 Solidity(솔리디티)를 이용한다..

 

 

3. 이더리움

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

비트코인으로는 예금, 보험 및 금융상품을 만들 수 없다.(이자 구현 불가능)
비트코인은 결제에 대한 부분만 처리하고 있기 때문에 결제에 대한 부분만 비트코인으로 처리하고, 이자 부분을 따로 구현하여 처리해야 한다.

하지만 이더리움은 이러한 부분을 보안하여 이더리움이라는 플랫폼을 만들었고, 이 플랫폼을 이용해서 짧은 시간에 탈중앙화를 사용하여 데이터를 저장하는 사이트 등을 만들 수 있었다. 이런 탈중앙화 된 프로그램을 Dapp이라고 한다.

이더리움을 이용해서 탈중앙화와 통신할 수 있는 프로토콜을 구현하여 쉽게 탈중앙화 네트워크에 데이터를 저장할 수 있다. - 스마트 컨트랙트

 

3-1. 이더리움 Account

이더리움에서, 상태(state)는 어카운트(account)라고 하는 오브젝트(object)들로 구성되어 있다.라는 말이 핵심이다.
이더리움에서 사용하는 account는 우리가 비트코인을 구현하면서 만들었던 20byte의 hash 값이다.

이더리움의 account를 살펴보면 아래와 같다.

interface Account {
    nonce: number // 각 트랜잭션이 오직 한번만 처리되게 하는 일종의 counter (이중지불 방지)
    balance: string // 이더잔고
    storageRoot: string //스마트 컨트랙트의 데이터를 저장하는 공간
    codeHash: string //스마트컨트랙트 코드
}

 

트랜잭션이 발동되면 상태(Account)가 바뀐다.

UTXO처럼 +/-가 객체로 하나씩 쌓이고 소비되는 것이 아닌, 상태가 업데이트되는 것이다.
그래서 검증과정이 필요한데, 이때 nonce값을 이용할 수 있다.
nonce 값은 트랜잭션이 발동되면서 1씩 증가하며, nonce값을 이용해서 이중지불을 막을 수 있다.

Account는 2가지 타입이 존재한다.

-   EOA ( Externally Owned Accounts ) : 프라이빗 키에 의해 통제되는 외부 소유 어카운트
-   CA ( Contract Accounts ) : 컨트랙트 코드에 의해 통제되는 컨트랙트 어카운트 (프라이빗 키가 존재하지 않음)

EOA의 경우 nonce는 계정 주소에서 전송된 트랜잭션 수이다.
CA의 경우 nonce는 계정에서 생성한 계약의 수이다.

EOA는 storageRoot, codeHash를 사용하지 않지만 CA는 사용한다.

 

 

3-2. 이더리움 Message/Transaction

이더리움에서는 signature(서명)이 있는 Receipt(영수증)을 Transaction이라고 말한다.
Signature(서명)이 없는 Receipt(영수증)을 Message(메시지)라고 한다.

 

interface Message {
    from?: string // 기본구성 - 메세지를 보내는 사람
    to: string // 기본구성 - 메세지를 받는 사람
    value?: number // 기본구성 - 메세지와 함께 전달할 이더 양

    hash?: string //
    nonce?: number // 메세지를 보내는 사람의 계정에 대한 nonce

    gas?: number // 메세지 처리를 위해 사용할 가스의 양
    gasPrice?: number // 가스의 가격

    data?: string // 메세지 데이터(바이트코드로 인코딩)
}

//서명이 포함 되면 Transaction이 된다.

interface Transaction extends Message {
    //SignatureInput 에서 사용했던 것과 같다.
    v: number
    r: string
    s: string
}

from에 대한 사람만 nonce값이 증가되고, 받는 사람인 to의 계정은 nonce의 값이 올라가지 않는다.

 

 

3-3. 이더리움 gas

주유소에서 1L당 적힌 금액이 있다.
예를 들어 1L당 1716원이라고 가정했을 때,
3만 원을 넣는다는 가정을 하면, 17.4825L를 넣을 수 있다.

이것이 가스 측정 방식이다.
gasPrice - 1L당 가격인 1716 // 내가 지정할 수 있음
gas - 총 주유량이다. 17.4825 // 내가 지정할 수 없음 // min - 21000

총수수료는 (gas X gasPrice)이다.

가스라는 것은 재측정이 되는데, TX들이 블록에 담길 때, 총 사용가스 양이 다시 측정이 된다.

내가 총 낼 수수료를 작성하지만 다시 측정이 되고, smart contract, 튜링완전, 반복문,
스마트 컨트랙트에 for 문을 작성했다고 가정했을 때, 1~10, 1~1000까지 반복한다.
하지만 실수로 무한루프를 돌리게 되면, 이더리움은 완전튜링을 했지만, 무한루프 같은 문제를 해결하기 위해서 가스라는 것이 있다.

연산이 될 때마다 가스가 발생한다.

애초에 블록에다가도 gaslimit를 지정하지만 최종적으로 총사용량은 블록에 담긴 모든 트랜잭션으로 결정된다.
기본적으로 내 코드가 얼만큼 가스를 소비해야 하는지 알아야 하기 때문에 TDD를 사용하게 된다.
gaslimit를 넘게 되면 다음 트랜잭션은 다음 블록에 포함되게 된다.
수수료는 그냥 사라지는 것이 아닌 , 채굴자에게 기본 보상 + 수수료로 준다.

이더리움은 화폐에 대한 포커스가 아니어서 코인 발행 개수가 지정되지 않았었는데, 가스 수수료의 일부를 소각하는 메커니즘을 도입하여 새로운 ETH 발행 비율을 효과적으로 줄였다.

 

 

3-4. 이더리움 EVM

ethereum virtual machine의 약자로 이더리움의 스마트 컨트렉트를 위한 런타임 환경이다.
하드웨어가 하고 있는 일은 소프트웨어로 구현이 가능한데 (CPU, MEMORY, HardDisk) 이를 가능하게 하는 것을 VM이라고 한다.
각 노드들이 EVM을 가지고 있는데, 각 노드는 내용(코드)을 전달받게 되면 EVM으로 실행한다.

1. solidity 생성, 컴파일
-   smart contract를 실행하기 전에 contract compile 하여 EVM이 이해할 수 있도록 변환함

2. Transaction 생성/서명 (수수료 발생)
-   EVM이 이해할 수 있는 Compile 된 내용을 Transaction.data 부분에 넣고 Transaction 생성된다.

3. Gas 소비
-   Miner에 의해 EVM을 통해 Bytecode가 해석되고, 이때 Gas량이 측정된다.

4. 코드실행
-   contract 인스턴스 생성(한번 배포하면 1개의 인스턴스만 존재한다.)

5. 상태 변경
   -contract 기본상태 설정 및 변경
   `value`값

6. 트랜잭션 완성

 

 

 

---