본 시리즈는 github의 DeFi Developer Roadmap Repo의 로드맵을 참고함

A Next-Generation Smart Contract and Decentralized Application Platform

2009년 Satoshi가 발표한 Bitcoin은 banking 시스템, 내재적인 가치, 그리고 중앙화된 통제자가 없다는 점에서 통화의 혁신을 가져왔다고 종종 이야기 된다.

but) 화폐적 기능보다 우리가 주목해야할 점은 Bitcoin의 기반을 받쳐주고 있는 blockchain 기술과 blockchain 위에서 실현되는 distributed consensus이다.

블록체인 기술을 이용한 alternative한 application들에는 다음과 같은 것들이 있다.

• custom currencies (사용자 정의화폐)와 금융 상품들을 블록체인 위에 represent하는 "colored coins"
• 물리적 대상의 소유권을 표현하는 "smart property"
• 도메인 이름과 같이 non-fungible한 assets을 기록하는 "name coin"
• arbitrary rules (임의적 계약규칙)을 구현한 코드에 의해 digital asset을 관리하는 "smart contract"
• blockchain을 기반으로한 decentralized 자율조직 "DAOs"

이더리움이 제공하려는 것

• Turing-complete한 프로그래밍 언어가 심어진 blockchain
• 코딩된 규칙에 따라 arbitrary state를 다르게 변환시키는 transition funcion이 포함된 "contract"를 유저들이 작성함으로서 위의 시스템을 구현가능케 하는 것
• 아직 상상하지 못한 다른 App들도 매우 쉽게 만들 수 있게 하는 것.

Introduction to Bitcoin and Existing Concepts

History

Decentralized digital currency는 Bitcoin의 등장 이전에도 있었다.

• 80s - 90s 익명의 e-cash 프로토콜
  • Chaumian blinding으로 알려진 로우레벨 암호 알고리즘에 기반
  • 중앙화된 주체에 의해 운영되었으므로 실패
• 98년 "Wei Dai"의 B-money
  • decentralized consensus와 퍼즐 문제풀이 방식으로 화폐를 발행하는 아이디어 제안
  • decentralized consensus를 실제로 어떻게 구현할지 solution은 제안하지 못함
• 05년 Hall Finney의 reusable proof of work
  • b-money와 Adam Back의 해시 퍼즐을 통해 암호화폐의 개념을 만들었음
  • but) 백엔드에 trusting computing에 의존하면서 decentralized는 실패
• 09년 Satoshi Nakamoto의 Bitcoin
  • 공개키 암호화 방식을 통해 ownership을 증명해내고 (전자서명) proof of work이라는 합의 알고리즘과 결합해서 decentralized한 currency를 가능케 함

POW은 동시에 두 가지 문제를 해결함

1. 간단하면서도 효과적인 consensus algorithm을 제공함
   • network상의 모든 node들이 Bitcoin의 장부 state에 일어난 표준 업데이트의 집합 (a set of canonical updates)에 공동으로 동의할 수 있게 해줌
2. 누구나 consensus process에 참여할 수 있도록 허용
   • 누가 consensus에 영향을 줄 수 있는지에 대한 정치적 문제를 해결해줌 + Sybile 공격도 방어할 수 있다
   • 기존의 형식적인 장벽 대신, 경제논리에 입각한 장벽, 즉 각 node의 consensus 결정권의 크기는 해당 node가 가진 computing power에 기반한다는 것이다. (즉, 네트워크에 더 열심히 기여한 사람에게 결정권을 주겠다 이말임.)

Bitcoin As A State Transition System

Technical한 관점에서 보았을 때, Bitcoin과 같은 암호화폐의 ledger는 상태를 변화시키는 시스템 (state transition system)으로 볼 수 있음.

State Transition System의 구성

• 모든 Bitcoin의 ownership 현황으로 이루어진 하나의 "State" (전체 장부)
• 이 State와 Transaction을 받아서 새로운 State' 을 return하는 state transition function (상태변환 함수)

은행 시스템에 비유하자면, 송금 요청 (state transition function)이 오면, 송금인의 계좌 잔고 (State에서 색인)를 확인하고 송금액 보다 클 경우 State를 변경시키는 함수를 실행하고 (송금인의 계좌에서는 -, 입금인의 계좌는 +) 잔고액이 송금액 이하라면 Error를 return한다.

APPLY(S, TX): return S' or ERROR 
// S = State, TX = transaction

뱅킹 시스템의 예를 들면,

APPLY({Alice: $50, Bob: $50}, "send $20 from Alice to Bob") 
 -> { Alice: $30, Bob: $70} 이라는 새로운 State를 return

Error가 발생하는 예도 확인하자

APPLY({Alice: $50, Bob: $50}, "send $70 from Alice to Bob")
 -> Error를 return. TX의 금액이 current balance을 하회하므로

Bitcoin에서 "State"란

• collection of all coins (UTXO의 모음), that have been mined and not yet spent

UTXO에 표시되는 것

• denomination - 각 UTXO가 얼마인지
• UTXO의 owner (20-byte의 address로 알려줌 - address는 알다시피 public key를 암호화한 것)

Transaction

• 하나 이상의 input 및 output을 포함함
• 각 input에는...
  • UTXO의 전송인 쪽의 address에 선택된 UTXO에 대한 reference
  • private key로 암호화된 digital signature (owner의 address와 연관)
• 각 output에는...
  • 새로운 State에 추가될 UTXO 정보가 나옴

State Transition Fucntion APPLY(S, TX) -> S'은 다음과 같이 정의할 수 있다.

1. Transaction의 각 input에 대해
   • 만약 UTXO의 reference가 State에 없다면, Error
   • 만약 signature이 UTXO의 owner와 match하지 않으면, Error
2. 만약 모든 input UTXO의 denomination(액면가)의 합 < 모든 output UTXO의 demomination의 합 -> Error
3. 모든 입력에 사용된 UTXO (state의)가 삭제되고, output UTXO가 추가된S'를 return

보다 현실적인 example

Alice가 Bob에게 11.7BTC를 보내고 싶다고 해보자.

• 먼저 Alice의 address로부터 표시된 금액의 합이 11.7BTC인 UTXO의 집합을 찾는다

• 딱 합이 11.7BTC인 UTXO의 구성을 찾을 수 있으면 좋겠지만, 대게 딱 떨어지는 경우가 없으므로 상회하는 집합을 찾은 후 거스름돈을 넣는 형식으로 진행한다고 이해하면 된다.

• Alice의 address에서 각각 6, 4, 2 BTC가 표시된 3개의 UTXO를 reference할 수 있다고 하자.

• Input

  • 6BTC의 UTXO, 4BTC의 UTXO, 2BTC의 UTXO

• Output

  • 11.7 BTC가 표시된 UTXO -> owner는 Bob의 address
  • 0.3 BTC (12 - 11.7)의 잔돈이 표시된 UTXO -> owner는 Alice의 address

Mining

상기 기술한 내용은 centralized 시스템에서는 굉장히 간단한일. centralized server의 하드에 state의 변화 과정만 저장하면 되니까.

그러나 Bitcoin 같은 decentralized 통화 시스템을 구축하려면, 참여하는 모든 node가 수긍할만한 consensus system을 state transition system과 잘 결합해야 한다.

Bitcoin의 distributed consensus system

• network에 Block이라고 불리는 transaction의 패키지를 생성하는 노드 (채굴자)가 필요
• 해당 network는 약 10분마다 1개의 Block을 생성토록 유도함
• 각 Block의 구성요소
  • Timestamp
  • nonce
  • reference to the previous block (Previous hash)
  • previous block 이후 발생한 모든 transaction의 목록 (이번 블록의 transaction들)

이러한 Block에 대한 validation의 과정은 다음과 같다

1. 해당 block에 의해 reference되는 previous이 존재하는지, valid한 건지 확인

2. timestamp가 이전 block보다 큰지, 2시간 이내인지 확인

3. Block의 Proof of work이 valid한지 확인 (target hash를 도출하는 올바른 nonce값을 넣었는지)

4. S[0]을 이전 block의 마지막 state가 되도록 설정

5. TX를 n 개의 transaction으로 이루어진 해당 블록의 (채굴자가 검증한) transaction이라 하자

   • 0...n-1의 모든 n에 대한 S[i + 1] = APPLY(S[i], TX[i])의 모든 set 중 하나라도 error를 return 한다면 False를 return 하고 종료
   • 그러니까 block에 담긴 transaction들이 위에서 말한 state transition function에 대해 error를 return하지 않는, valid한 transaction들이라는 것을 검증하려는 것

6. S[n]을 해당 블록의 마지막 state로 등록하며, True를 return한다

기본적으로 Block에 포함된 각 transaction은 valid한 상태변환을 일으켜야 한다.

State에 대한 정보가 Block에 담겨있지 않다는 것에 주목해보자.

• State는 기록되지 않지만, 해당 state가 과연 valid한 것인지 알려주는 abstract한 hash 값이 저장되어있다.
• 해당 hash값은 genesis 블록의 transaction부터 lastest 블록의 transaction까지 모두 순차적으로 hashing 함에 따라 나온다.
• hash function의 특징을 알면 알겠지만, 중간에 하나라도 틀리면 전혀 다른 값이 나온다.

Proof Of Work - validity condition

• 256-bit 숫자로 표현되는 각 블록의 이중 SHA256 hash값이 매번 바뀌는 target hah보다 작아야 한다.
• SHA256은 예측 불가능한 pseudorandom function으로 설계 되었기 때문에 valid한 block을 생성하기 위한 유일한 방법은 block header의 nonce값을 1부터 증가시키는 trial & error 뿐
• 해당 Ether 백서 작성 중 target hash의 max값은 2^187이었고, 이를 구하기 위해서는 평균적으로 2^64번의 시도를 해야한다
• 매 2016개의 블록마다 (약 2주) difficulty가 조정되며, 이는 블록 생성텀인 10 분을 맞추기 위함
• 이 "mining"에 대한 보상으로 minting된 BTC를 (현 시점 6.25BTC) 받고, output금액보다 input금액이 크다면 그 차액만큼을 transaction fee 명목으로 가져감.

악의적인 공격

• 잘 가고 있던 blockchain에서 특정 transaction을 manipulate하고 싶어 특정 지점에서 block을 fork한다면, 그 후로 완성된 block들까지 전부 고쳐야함 (다음 블록이 생성되는 10분 내에)
• 이 것이 51% 공격인데, 거의 일어나지 않음.(실현불가능성 + 경제적인이유)

Merkle Trees

Merkle Tree

• binary tree structure
• child node 둘 혹은 하나의 hash 값으로 parent node를 구성함
• 그렇게 leaf node부터 쭉 타고올라가서 root node까지 hash화
• 그렇게 되면 해당 merkle tree의 어느 node가 변경되어도, root node의 값은 뒤틀리게 됨
• 따라서 root node값만 저장해도 모든 node가 valid하다는 것을 알 수 있다.

Bitcoin의 Merkle Tree

• block의 "hash"라는 말은 사실 blockheader의 hash만을 의미함
• blockheader 안에는...
  • timestamp, nonce, previous block hash, merkle root (tree 전체가 아닌 merkle tree의 root node만)
  • 약 200-byte 정도의 data
• merkle tree protocol은 bitcoin network을 장시간 sustainable하게 만들어준다.
• Bitcoin network에서 각 블록의 모든 정보를 저장하고 처리하는 "Full node"는 14년 4월 기준 15GB의 disk 공간을 필요로 하며, 매달 1GB씩 증가하는 중
• 이제 폰으로는 채굴이 불가능하고, 데탑으로만 가능하다
• 그리고 계속 이렇게 늘어난다면, 가정용으로 소소하게 채굴하는 것은 불가능해질 것. (지금도 불가능한 것 같은데...)
• Simplified Payment Verification; SPV 프로토콜은 light node라고 불리는 다른 종류의 node가 존재
• Light node는 block header를 다운로드하고, 그 block header에서 proof of work을 진행, 그리고 관련 transaction들에 대한 branch들만 다운로드한다.
• 가벼우면서도, 강한 안전성을 보장해준다.

Alternative Blockchain Applications

Bitcoin 이전에도 blockchain의 개념은 존재했고, 몇몇이 이를 실현하고자 했지만 실패했다. 2009년 Bitcoin의 decentralized consensus가 개발되면서, 관련 응용 application들이 등장하기 시작한다.

Consensus protocol을 build하는데는 2가지 접근법이 있다

1. 독립적인 network를 build하는 것
   • Namecoin의 경우에는 성공적이었지만, 일반적으로 쉽지 않다.
   • 각 개별 implementation이 독립적인 블록체인을 구동시켜야 하며, 필요한 state transition과 networking code를 건설하고 점검해야함
   • 대다수 application 자기 자신의 blockchain을 보장하기에는 너무 작을 것
2. Bitcoin 위에 protocol을 build하는 것
   • SPV의 특징을 상속받지 못한다는 단점이 있다.
   • SPV는 Bitcoin 위에서는 작동하지만, Blockchain에 기반한 meta-protocol에서는 불가능하다.
   • 따라서 fully secure SPV meta-protocol을 실행하려면 특정 transaction의 유효성을 검증하기 위해 blockchain의 시작까지 scan해보아야 함
   • 현재 모든 Bitcoin-based meta-protocol은 trusted server에 의존하고 있으며, 이는 Bitcoin이 등장하게된 정신과는 거리가 있다.

Scripting

별도의 extension 없이도 Bitcoin protocol은 낮은 수준의 "smart contract"을 구현할 수 있다. Bitcoin의 UTXO는 public key만으로 sort할 수 있을 뿐아니라, 단순한 stack-based programming language로 표현되는 Script로도 획득할 수 있다. 사실, basic한 public key ownership 메커니즘 역시 script를 통해 실행된다

Script를 이용하여 다음과 같은 일들도 가능하다

• 3개의 private key 중 2개로부터 signature를 받아야지만 승인이 될 수록 (Multisig) script를 만들 수 있다.
  • 이러한 script는 회사 계정, 에스크로 서비스 등에 이용될 수 있다.
• 어떠한 문제에 대한 보상금을 지불할 수도 있다. (지식인 같이)
  • "만약 해당 denomination의 Dogecoin을 나에게 전송했다는 SPV proof를 제공한다면, 이 Bitcoin UTXO는 당신의 것이다." 라는 내용을 Script로 만들 수 있음

즉, Bitcoin의 Script 만으로도 "A조건을 이행하면 그 결과로 B를 이행"이라는 Smart Contract를 간단한 수준으로 구현할 수 있다는 뜻이다.

그러나 Bitcoin에 구현된 Script언어는 몇가지 한계가 존재한다.

• Lack of Turing-completeness
  • Bitcoin Script는 while이나 for와 같은 loop 기능이 없다. (infinite loop을 회피하기 위해서)
  • loop없이도 프로그램을 build할 수는 있지만, 때때로 매우 공간비효율적인 코드가 불가피할 때도 있다.
• Value-blindness
  • 인출 금액에 대한 세밀한 컨트롤이 불가능하다.
  • 알다시피, UTXO는 all-or-nothing으로 송금의 단위를 조각내서 보낼 수 없다. 한번에 다 보내고 거스름돈을 받는 식으로 할 뿐.
• Lack of state
  • UTXO가 표현할 수 있는 state는 spent-unspent 둘 뿐이다.
  • 위 두가지 state이 외의 다른 어떤 state를 가지는 복잡한 contract를 만들 수 없다.
  • 이 때문에 multi-stage options contract을 만들기 어려우며, 단순하고 1회성의 contract에만 이용할 수 있을 뿐, decentralized organization과 같은 복잡한 "stateful" contract은 build할 수 없다.
• Blockchain-blindness
  • UTXO는 nonce, timestamp, previous block hash와 같은 blockchain data를 조회하지 못한다.
  • 이로 인해 randomness를 구현하기 힘들어지면서, 도박이나 다른 여러 분야의 Application을 만드는 발목을 잡는다.

따라서, 우리는 3가지 approaches 암호화폐 위에 발전된 application을 구축하는데에는 3가지 접근법이 있다

• 새 blockchain을 구축하는 것
  • 제약없이 자유롭게 프로그래밍하는 것이 가능하지만, 초기 투자가 수반되야함 (개발기간, 초기 set-up 과정, 보안 등..)
• Bitcoin의 script 언어를 이용하는 것
  • simple한 contract는 구축 가능하지만 이용범위가 제한적이다
• Bitcoin위에 meta-protocol을 구축하는 것
  • scalability의 결함을 감수해야한다.

이더리움은 이에 대해, 개발이 용이하고 더 강력한 light client properties를 가지며 동시에 경제적인 개발환경과 블록체인을 공유하는 Application을 만들 수 있는, alternative framework을 제시하고자 한다.

References

• Ethereum Whitepaper
• [Korean] Ethereum Whitepaper