이더리움 연구회 정기 발표회, 세션2 - 이더리움 합의 알고리즘과 마이닝

1. 이더리움 합의 알고리즘 및 마이닝
엔진 분석
ethereum 연구회
박혜영 / 변동삼 / 채효철
goblinok@gmail.com
dongsamb@gmail.com
chaeso@gmail.com

2. 목차
1.PoW
2.Ethash 알고리즘
3.PoS
ethereum 연구회

3. 문제점1. 비잔티움 장군 문제
• 5명의 장군이 성을 공격하려면 성안의 병력보다 많은 병력이 공격해야 함
• 장군들은 연락병을 보내 소통 가능하나, 그 중에 배신자가 있어 서로 신뢰 불가함
1982년 레슬리 램포트등의 논문에서 처음 언급
ethereum 연구회

4. 문제점2. 이중 지불 문제
• 분산 디지털 화폐 시스템에서 토큰이 한번 이상 소비되는 문제
• 탈 중앙형 환경에서는 트랜잭션에 대한 Finalize를 결정하기 어려움
Authority
1 to B
1 to C
possible!
< 중앙 집중형 > < 탈 중앙형 >
Finalize!
Finalize?
A
B
C
1 ether
A
1 ether B
C
x
ethereum 연구회

5. 합의 알고리즘 계층이 왜 필요한가?
• P2P 네트웍에서는 처리된 블록이나 트랜잭션에 문제가 없는지를 확인해 주는 주체가 없기
때문에 참여자들은 서로 검토하고 동의하고, 유효성을 판단하는 절차가 필요
• 유효한 블록체인이 두개 존재할때 어떤것을 선택할지 규칙이 있어야 함
합의 방식 알고리즘 장점 단점 처리속도
PoW
(Proof of Work)
Ethash 검증됨 많은 에너지 사용 낮음
PoS
(Proof of Stake)
Casper 보다 효율적 검증 안됨 높음
합의 알고리즘을 통해 서로 신뢰할수 있는 규칙을 따르게 됨 (비잔티움장군 문제 해소)
ethereum 연구회

6. PoW 동작 원리 (1/2)
TxMsg : signed_txs
Sender Peer
Public Key
ECDSA
(256 bit)
Private Key
ECDSA
(256 bit)
Sender의 Account Address
(160 bit)
Pairing
Keccak256
NewAccount()
SignTx()
Raw_Tx
Nonce, GasPrice
GasLimit, ……
SendTransactio()
Signed_Tx
Nonce, GasPrice
GasLimit, ……
TxPool
Transaction 1
Transaction 2
Transaction 3
Account 생성부터 Transaction 전파까지
Transaction Validation Check
Signature
ethereum 연구회

7. Transaction 생성부터 BlockChain 전파까지
TxPool
Temporary Block
Miner 1 Node 1
Transaction 1
Transaction 2
Transaction 3 StateDB
123 124 125 126
PoW
PoW 동작 원리 (2/2)
ChainDB
Sealed
Block
126
Block Validation Check
Ethash
+ Uncle Block
ethereum 연구회

8. 블록 유효성 검증
① Difficulty가 제일 높은 블록을 선택
② 작업 증명(PoW)을 제대로 되었는지 확인 (Nonce로 검증)
③ 머클 패트리샤 트리 확인 (Merckle Status Transition proof)
④ 가스 사용량 비교 (gasUsed <= gasLimit 검사)
⑤ 블록 넘버, 트랜젝션 루트, Uncle 루트 검증 등
125 126
Confirmation!
124
Validation Check
새로운 블록체인이 연결하기 전 합의를 준수했는지 검증(Validation)후 Confirmation하는 과정
Regular Fork Case
125
126’
126124 127
Uncle block
검증(Validation)과정을 통해 확인된 블록을 Confirmation하고,
정규 블록이 아니거나, 잘못된 블록은 6 confirmation 까지 기다렸다가 최종 Reject한다.
125
126
126
124
동시에
① 동시에 블록에 등록될 때
② Winner Block이 못 되었을 때
ethereum 연구회

9. 6 Confirmations이 지나면 나누어진 블록에서 Canonical Block을 확정할 수 있다.
[참고] 6 Confirmation
A
B
C
1 ether waits for 6 confirmations
waits for 6 confirmations
Abandoned block
à Finalized!
à Rejected!
동시에
6 Confirmation을 기다리면 최종 Finalized하여 거래를 확정한다. (이중지불 문제 해소)
다음 블록이 이전 블록을 Confirm함
< 이중 지불 문제>
ethereum 연구회

10. PoW 알고리즘
작업증명을 통한 Block chain 구성
Block Header N
Time stamp
Prev Hash
Nonce
Merkle Root
Prev Hash
Nonce
Merkle Root
2^256
/
Transaction 1
Transaction 2
Transaction 3
Merkle Tree
Block Header N
Time stamp
Prev Hash
Nonce
Merkle Root
작거나 같으면
신규 Block 생성
크면
Nonce 재조정
Hash
Hash
Hash
Difficulty
00000xxxxxxx..
ethereum 연구회

11. [참고] Difficulty
* Difficulty 계산 공식 (비잔티움)
diff = (parent_diff +(parent_diff / 2048 *max((2 if len(parent.uncles) else 1) -
((timestamp - parent.timestamp) // 9), -99))) + 2^(periodCount - 2)
2^(periodCount - 2)의 의미?
: 난이도 폭탄, periodCount 는 인위적으로 마이닝 시간을 늘리기 위한 Fake 블록 수
비잔티움 하드포크
비잔티움 에서는 난이도 폭탄 값이 초기화
§ 블록 생성 주기가 짧아짐
§ 마이너 보상이 5에서 3이더로 조정
ethereum 연구회

12. 12초의 비밀
Q1. 뷰탈릭은 왜 10분을 12초로 줄였나?
블록 사이즈가 클수록 블록 인터벌이 적을수록
Stale Block(엉클블록) 이 많이 생긴다.
Block Size
Stale Rate
Transfer Time
ethereum 연구회

13. 엉클블록
블록생성은 성공했으나 난의도가 낮아 정상체인에는 등록되지 못한 블럭
Miner 1 Node 1
TxPool
Transaction 1
Transaction 2
Transaction 3
Winner Block
124 125 126
Broadcasting
Transaction 4
Miner 2
TxPool
Transaction 1
Transaction 2
Transaction 3
Transaction 4
126
126’
PoWPoW
.
Uncle Block126’
1초
2초
ethereum 연구회

14. 엉클 블록의 문제를 고스트(Ghost, Greedy Heaviest Observed Subtree) 알고리즘을 사용하여 해결한다.
엉클블록 문제 해결
123 124 125 127122121 126
• 엉클블록 허용 범위 : 6블럭 이내까지 허용, 한 블록에 max 2개만 허용)
- 블록생성 보상 (Mining fee): 5 이더 à 3이더
- 트랜잭션 보상 (Transaction fee): 블록 안에 포함되는 모든 트랜잭션 가스의 합
- 엉클블록은 블록생성 보상의 7/8(0.875) : 4.375 이더, 조카블록은 1/8(0.125)
• 마이너가 받는 보상?
122’ Uncle Block
1 2 7
122’’
122’’’
Nephew Block
63 4 5
ethereum 연구회

15. Ethash
이더리움의 Proof of Work 알고리즘
Bitcoin 의 마이닝 알고리즘과 무엇이 다르고 왜 만들었나?
ASIC(주문형 반도체) 로 인한 Hashrate 독점, 중앙화 문제 해결에 초점
ethereum 연구회

16. GPU
vs
ASIC
https://compubench.com
https://en.bitcoin.it/wiki/Mining_hardware_comparison

17. Bitcoin Mining Flow
Bitcoin 의 경우 단순히 SHA256
연산만을 필요로 하므로
일반 CPU, GPU 보다
수천배 이상 빠른 ASIC 제작이
ethereum 연구회

18. Ethash Mining Flow
Bitcoin 의 경우 단순히 SHA256 연산만을
필요로 하므로 일반 CPU, GPU 보다
수천배 이상 빠른 ASIC 제작이 가능
단순히 SHA256 연산만을 필요했던
Bitcoin 의 Mining 알고리즘과 달리
Ethash 에서는 DAG 를 통해
미리 알 수, 할 수 없는
순차적 메모리 연산을 요구하여,
ASIC 제작을 어렵게 함
ethereum 연구회

19. Ethash
• Memory Hard Computation
• Memory Easy Validation
• ASIC ( 주문형 반도체 ) 제작을 힘들게
• 위 같은 목적 달성을 위해 매 3만 블록마다 수 GB 의 DAG(Directed acyclic graph)를
새로 생성하여 해싱에 사용( 점점 사이즈 증가 )
• KECCAK(SHA-3) 사용
• Dagger 와 Hashimoto 알고리즘의 장점을 결합한 Dagger-Hashimoto 의 수정버전
ethereum 연구회

20. Ethash: DAG data, cache size
• 블록의 헤더들을 스캔하여 Seed 값 추출 가능
• 해당 Seed 를 통해 16MB 의 pseudo random cache 를 계산 가능
• 해당 Cache를 통해 1GB 이상의 Full Dataset 을 생성 가능
• 30,000 Block 단위 별로 Full Dataset 이 완전히 바뀌고, 선형으로 커지도록 설계 됨
• 해당 Full Dataset 의 랜덤한 부분을 마이닝 해싱 작업에 포함 시키도록 함
• 따라서 메모리 읽기 연산, Dataset 저장 공간 등의 제약을 주어
ASIC 제작이 불가능하도록 함
ethereum 연구회

21. Ethash: DAG Cache Generation
선형 증가하는 소수를 사이즈로 사용
2048 epoch 만큼의 lookup table 이 미리 계산되어 하드코딩 되어 있다.
2017.11 기준 약 450만 블록으로서, 약 150 epoch 이며 DAG 의 사이즈는
2.2GB 정도
https://github.com/ethereum/wiki/wiki/Ethash

22. Ethash: DAG Cache Generation
Sergio Demian Lerner 의 RandMemoHash Strict Memory Hard Hashing Functions (2014) 알고리즘을 사용하여
연산 시 메모리가 특정 임계치 보다 낮으면 연산 속도가 기하급수적으로 길어지도록 설계,
이를 통해 특정 시간동안 특정양의 메모리가 해당 연산을 위해서만 사용 되었음을 증명 할 수 있게된다.
https://github.com/ethereum/wiki/wiki/Ethash
# 3
# 64
# keccak512
ethereum 연구회

23. # 30000

24. Ethash: DAG Full Dataset calculation
https://github.com/ethereum/wiki/wiki/Ethash
# 16 == 64 // 4
# mix[0] = mix[0] xor i
# 256
# keccak512
# xor 의 대체제로 fnv hash 사용 (분
fnv(a, b): (a *
ethereum 연구회

25. https://github.com/ethereum/wiki/wiki/Ethash
# 64
# 64
# 32 == 128 // 4
# 2 == 128 / 64
# to little-endian
# [0, 4, 8, … ]
# for Fetch DAG Page
# Fetch DAG Page from dataset_lookup ta

26. Ethash: Hashimoto, Mining
https://github.com/ethereum/wiki/wiki/Ethash
# zero padding
Hashimoto_light 는 light client 가 1기가 이상의 DAG 를 가지고 연산하기 무거우니
16MB 이상의 cache 만으로 실시간으로 DAG를 연산, 생성하여 사용하도록 한 것

27. Ethash 정리
• 민주적, 비독점적인 탈중앙 마이닝을 위해 ASIC 제작을 어렵도록 설계
• ASIC 의 경우 오로지 마이닝 용도이므로 (전기료 == 채굴수입) 이 되어 에너지가 낭비됨
• Ethash 계속 확장, 변경되는 DAG 파일을 통한 메모리 연산을 요구함
• 따라서 별도 장비구입 없이 이미 모두가 소유하고있는 일반적인 PC 로 채굴하기 적합
• 하지만 합의 과정을 위해 불필요한 연산을 통한 에너지 소비는 여전하므로
장기적으로 PoS 가 불가피
ethereum 연구회

28. PoW 문제점
리소스 문제
GPU로 아무 의미(?) 없는 해시값을 찾아내야 하고, 그 작업을 위해 불필요한 리소스들
이 대거 투입되어 무의미한 에너지 소비가 증가하는 문제
엉클블록 문제
빨라지는 주기를 PoW의 Difficulty로 유지하는데는 한계가 있다. (12초 목표)
컴퓨팅 파워가 큰 마이너의 영향력이 커져 악의적으로 이용될 수 있는 우려
ethereum 연구회

29. Proof Of Stake (PoS; 지분증명)
- Validator (=virtual miner) 가 가진 지분(Stake)에 비례한 확률로 블록을 생성할 권한을
얻게 되고, 블록을 생성한 후 원하는 체인에 블록을 붙이고 보상을 얻는 방식
- 장점
- 에너지 비용 절감 (PoW와 같이 어려운 문제를 풀지 않아도 됨)
- 전기비가 들지 않기 때문에 많은 코인을 새로 발행할 필요가 없어짐
- 보안성 강화
- 중앙화 위험 감소
- PoW 에서는 대형 마이닝 풀 몇개가 공모하면 51% 공격도 가능
- PoS 에서도 대형 거래소 몇개가 공모하면 공격 가능하지만 폭락으로 인해 가능성 적음
- 과거 블록을 바꾸기 매우 힘들게 만듦 (finality 성질)
- 공격 하다 실패하면 모든 자산 → 0
ethereum 연구회

30. 기본 아이디어
1. 이더리움의 기본 화폐인 이더(Ether)를 Capser 스마트컨트랙트에 예치(Deposit)하면 Val
idator 가 된다 (한동안 이더가 묶임)
2. Validator 가 되면 새로운 블록을 정규 체인에 추가할지 여부를 투표 가능
(항상 가능한 것은 아니고 지분의 비율 대로 랜덤하게 권한이 부여됨)
3. Validator 가 규칙을 따르지 않으면 불이익을 얻는다
a. 잘못된 블록에 투표 하면 불이익
b. 투표를 안해도 불이익
ethereum 연구회

31. 초기 PoS 알고리즘의 문제 : Nothing-at-stake
2011년에 나온 PeerCoin 에서 처음 도입. 그런데 보상해주는 개념만 있어서 2개의 체인이 나
눠졌을 때 둘다 맞는 체인으로 투표 하면 더 큰 보상이 주어짐
ethereum 연구회

32. Nothing-at-stake 문제 해결 아이디어 (Slasher 전략)
ethereum 연구회

33. PoS 의 단계적 적용
내년 까지 점차 비율을 늘려 가며 PoW → PoS 적용
○ Checkpoint 라 불리는 매 100번째 block 마다 Finalize
■ 한번 Finalize 되면 되돌릴 수 없도록 하여 51% 공격, 이중지불 등을 방지
● 되돌리려면 여러 Validator 가 많은 돈을 소각해야 함
■ Finalize 를 위해 2/3 이상의 투표를 받아야 함
Block 1 Block 2
Block 1
00
…..
Block 1
01
…..
Finalize
(PoS)
PoWPoW PoW
ethereum 연구회

34. Capser 의 스마트 컨트랙
Viper 라는 실험적인 언어로 작성됨
- Solidity 대체 언어
- 파이썬과 유사
- 스마트컨트랙: simple_casper.v.py
ethereum 연구회

35. Casper Paper : overview
Casper 프로토콜 처음 공부하는 분이 읽기 좋은 논문
“Casper The Friendly Finality Gadget”

36. Q&A

37. Appendix

38. DAG : Directed Acyclic Graph
ethereum 연구회

39. ethereum 연구회

40. https://gist.github.com/dongsam/53dfce6262e62957891c7315117d89c2

41. DAG Cache Generation
Sergio Demian Lerner 의 RandMemoHash
Strict Memory Hard Hashing Functions (2014)
알고리즘을 사용하여
연산 시 메모리가 특정 임계치 보다 낮으면
연산 속도가 기하급수적으로 길어지도록 설계,
이를 통해 특정 시간동안 특정양의 메모리가
해당 연산을 위해서만 사용 되었음을
증명 할 수 있게된다.
ethereum 연구회

42. SHA-3 ( KECCAK )
ethereum 연구회

43. FNV hash

44. ethereum 연구회