캐스퍼(Casper): 이더리움(Ethereum)의 지분증명(PoS) 방식의 합의 알고리즘

캐스퍼(Casper)
이더리움의 지분증명(PoS: Proof of Stake) 방식의 합의 알고리즘
문영훈
version 0.1
final edit: 2017. 11. 29
based on Casper the Friendly Finality Gadget (Vitalik Buterin, Virgil Griffith / Oct 29, 2017)

목차
캐스퍼: 이더리움의 지분증명(PoS: Proof of Stake) 방식의 합의 알고리즘

• 비잔틴 장애 허용(BFT: Byzantine Fault Tolerant) 방식의 합의 알고리즘에 기반
한 합의 알고리즘
• 규칙을 어기는 검증자를 식별하고 이들의 예치금을 몰수(slashing)하는 방식으
로 책임을 물을 수 있으며 이를 통해 “nothing-at-stake” 문제를 해결
• 검증자의 집합이 동적으로 변경 (dynamic validator set)
• “경제적 완결성 (economic finality)”을 보장
• Casper the Friendly Finality Gadget(FFG)는 블록 제안 메커니즘(proposal
mechanism) 위에 overlay로서 구현되며 캐스퍼의 첫 번째 버전은 작업증명
(PoW) 방식의 제안 메커니즘 위에 지분증명(PoS)을 구현하는 hybrid PoW/PoS
방식으로 구현
캐스퍼란?

• 체크포인트(checkpoint): 높이가 100의 배수 (100*k)인 블록 (e.g. 제네시스 블록
, 블록 #100, #200, …)
• 예치금(deposit): 검증자가 검증에 참여하기 위해 캐스퍼 스마트 컨트랙트에 예
치해야 하는 금액. 지분증명의 보안은 예치금의 총량에 비례하기 때문에 “2/3 이
상의 검증자”란 “예치금의 합이 총 예치금의 2/3 이상이 되는 검증자”를 말함
• 투표(vote): 검증자가 자신이 올바르다고 생각하는 블록에 투표하는 메세지이며
검증자에 대한 정보, 두 개의 체크포인트(source와 target)와 각각의 높이값, 자
신의 전자서명 데이터로 구성
• supermajority link: 체크포인트 A, B에 대해 2/3 이상의 검증자가 A를 source로
하고 B를 target으로 하는 투표 메세지를 네트워크 상에 공개한 경우 (A, B) 사이
에 supermajority link가 있다고 하며 A → B 로 표현. 이 때 A와 B가 인접할 필
요 없음
• 충돌(conflict): 두 개의 체크포인트가 서로 다른 branch에 위치하는 경우 두 체
크포인트가 충돌(conflict)한다고 함
• justified: 체크포인트 c 는 (1) c 가 제네시스 블록이거나 (2) justified 된 c’에서 c
로의 supermajority link (i.e. c’ → c)가 존재하는 경우 justified되었다고 함
• finalized: 체크포인트 c 가 justified 되어 있으며 c 에서 c 의 direct child 인 c’ 으
로의 supermajority link (i.e. c’ → c)가 존재하는 경우 c가 finalized되었다고 함
용어정의 (1/2)

블록 #0
블록 #1
블록 #100
블록 #200
블록 #99
.
.
.
.
.
.
블록 #201
.
.
.
블록 #101
• 체크포인트(checkpoint): 높이가 100의 배수 (100*k)인 블록 (e.g. 제네시스 블
록, 블록 #100, #200, …)
요 없음
용어정의 (1/2)

• 체크포인트(checkpoint): 높이가 100의 배수 (100*k)인 블록 (e.g. 제네시스 블
록, 블록 #100, #200, …)
요 없음
source:
https://github.com/ethereum/research/blob/master/papers/cas
per-basics/casper_basics.pdf
용어정의 (1/2)

, 블록 #100, #200, …)
• 투표(vote): 검증자가 자신이 올바르다고 생각하는 블록에 투표하는 메세지이
며 검증자에 대한 정보, 두 개의 체크포인트(source와 target)와 각각의 높이값,
자신의 전자서명 데이터로 구성
요 없음
(v, s, t, h(s), h(t))
source
target
validator
용어정의 (1/2)

, 블록 #100, #200, …)
• 투표(vote): 검증자가 자신이 올바르다고 생각하는 블록에 투표하는 메세지이
며 검증자에 대한 정보, 두 개의 체크포인트(source와 target)와 각각의 높이값,
자신의 전자서명 데이터로 구성
요 없음
source:
(v, b1, b2, 1, 3)
용어정의 (1/2)

Prepare, Commit → Vote
source: https://ethresear.ch/t/casper-ffg-with-one-message-type-and-simpler-fork-choice-rule/103
이전 버전의 캐스퍼는 검증자들이 prepare와
commit 두 종류의 메세지를 보낼 수 있었던 반면 9
월 말 이후 업데이트된 버전의 캐스퍼에서는 검증
자들이 vote 라는 한 가지 종류의 메세지만을 보낼
수 있도록 설계. 캐스퍼 프로토콜이 계속해서 빠르
게 변화함을 알 수 있음

, 블록 #100, #200, …)
• supermajority link: 체크포인트 A, B에 대해 2/3 이상의 검증자가 A를 source
로 하고 B를 target으로 하는 투표 메세지를 네트워크 상에 공개한 경우 (A, B)
사이에 supermajority link가 있다고 하며 A → B 로 표현. 이 때 A와 B가 인접
할 필요 없음
블록 #0
블록 #1
블록 #100
블록 #200
블록 #99
.
.
.
.
.
.
블록 #201
.
.
.
블록 #101
supermajority link
블록#0 → 블록 #200
용어정의 (1/2)
검증자의 2/3 이상의
투표 메세지 필요!
두 개의 체크포인트가
인접할 필요 없음

, 블록 #100, #200, …)
요 없음
source:
충돌(conflict)
용어정의 (1/2)

, 블록 #100, #200, …)
요 없음
source:
용어정의 (1/2)

, 블록 #100, #200, …)
요 없음
source:
FINALIZED!
용어정의 (1/2)

검증자 v는 아래의 조건을 만족시키는 다음과 같은 서로 다른 투표 메세지를 공개할 수 없다
< v, s1, t1, h(s1), h(t1) > < v, s2, t2, h(s2), h(t2) >
I. h(t1) = h(t2) i.e. 검증자는 같은 target 높이를 갖는 두 개의 서로 다른 투표 메세지를 공개할 수
없다
II. h(s1) < h(s2) < h(t2) < h(t1) i.e. 검증자는 자신이 투표한 범위 내 다른 투표 메세지를 공개할 수
없다
캐스퍼 프로토콜

검증자 v는 아래의 조건을 만족시키는 다음과 같은 서로 다른
투표 메세지를 공개할 수 없다
< v, s1, t1, h(s1), h(t1) > < v, s2, t2, h(s2), h(t2) >
I. h(t1) = h(t2) i.e. 검증자는 같은 target 높이를 갖는 두 개의 서
로 다른 투표 메세지를 공개할 수 없다
II. h(s1) < h(s2) < h(t2) < h(t1) i.e. 검증자는 자신이 투표한 범위
내 다른 투표 메세지를 공개할 수 없다
캐스퍼 프로토콜

• Accountable Safety: “1/3 이상의 검증자(validator)의 예치금이 몰수당하지 않는 한
두 개의 상충(conflicting)되는 체크포인트(checkpoint)가 완결(finalize)될 수 없다.”
• Plausible Liveness: “과거 이벤트(e.g. 예치금 몰수, 블록의 지연, 검열공격 등)와 관
계없이 2/3 이상의 검증자가 프로토콜을 따른다면 그 어떤 검증자의 예치금 몰수
없이 항상 새로운 체크포인트를 완결할 수 있다.”
캐스퍼의 두 가지 기본속성

• 두 개의 충돌하는 체크포인트 am 과 bn 이 모두 finalize 되었다고
가정
• 만약 h(am) = h(bn) 라면 1/3 이상의 검증자가 캐스퍼 프로토콜 I
을 어긴 것으로 이들의 예치금이 몰수
• am 과 bn 높이가 다른 경우 h(am) < h(bn) 가정
• bn 이 finalize 되었으므로 supermajority link로 이루어진 체크포인
트의 체인 r → b1 → b2 → · · · → bn 이 존재
• 캐스퍼 프로토콜 I 에 의해 어떠한 h(bi) 도 h(am) 혹은 h(am+1) 과
같을 수 없음.
• 이 때 h(bj) > h(am+1) 을 만족하는 최소값을 j 라 하면
• h(bj-1) < h(am)
• 하지만 이는 캐스퍼 프로토콜 II 에 위배
정리 1. (Accountable Safety) 두 개의 충돌하는 체크포인트 am과 bn
은 동시에 finalize 될 수 없다검증자 집합이 동적으로 변하지 않는 기본적인 경우

• a 를 가장 큰 높이를 가지는 justified 된 체크포인트, b 를 검증자
가 투표한 최대 높이의 target 체크포인트라 하자
• 이 때 h(a’) = h(b) + 1 을 만족시키는 a 의 자손 체크포인트 a’ 에
대해 캐스퍼 프로토콜을 위반하지 않으며 supermajority link a →
a’ 생성 가능 (i.e. a’ 이 justified)
• a’ 이 justified 된 이후 a’ 으로부터 a’ 의 direct child 에 대한
supermajority link 를 생성함으로써 a’ 을 finalize 시킬 수 있음
정리 2. (Plausible Liveness) finalized된 체인의 children이 존재하는
경우, supermajority link를 추가하여 새로운 체크포인트를 finalize 할
수 있다
a
b

수 있다
a
b
a’

수 있다
a
b
a’
a’’

• 기존 작업증명(PoW) 방식의 포크 선택 규칙은 “가장 긴 체인 위에 블록을 추
가”시키는 것. 하지만 캐스퍼의 경우 그와 같은 포크 선택 규칙을 도입하는
경우 체인 자체가 더 이상 justify 되거나 finalize 될 수 없는 경우가 발생할 수
있음
• 따라서 캐스퍼의 포크 선택 규칙은 “가장 긴 justified 된 체크포인트의 체인을
포함하고 있는 체인 위에 블록을 추가”
캐스퍼 포크 선택 규칙 (fork choice rule)

있음
FINALIZED
채굴자들이 가장 긴 체인을 채
굴하므로 a 의 finalization에
참여한 검증자들의 자발적인
예치금 몰수 없이 새로운 블록
에 finalize 불가
a
b

JUSTIFIED
b 대신 a 위에 채굴a
b
있음

• 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의
safety와 liveness를 증명. 하지만 이더리움과 같은 비허가성 블록체인에서는 검증자가
자발적으로 검증에 참여하거나 탈퇴할 수 있어 검증자 집합이 동적으로 변화하는 상황
을 가정해야 함
• 한 가지 방법은 하나의 블록이 finalize 된 후에 새로운 블록을 생성하는 방식 (e.g. 블록
#1 생성 → 블록 #1 finalize → 블록 #2 생성 → 블록 #2 finalize → · · · )
• 하지만 이 방식은 블록의 생성과 finalization이 동시에 일어나는 캐스퍼의 “interwoven
consensus” 방식에 적용하기 힘듬
• 캐스퍼의 interwoven consensus 방식에 적용하기 위해 블록의 finalization에 대한 증
거가 다음 블록 이전에 블록체인에 포함된다면 검증자 집합을 변경하고 포함되지 않는
다면 검증자 집합을 변경하지 않는 방식을 생각해 볼 수 있음
• 하지만 이 경우에도 블록이 finalize되었는지 합의할 수 있는 방법이 없기 때문에 오른
쪽과 같이 하나의 부모 블록에서 서로 다른 검증자 집합을 갖는 두 개의 블록이 예치금
몰수 없이 finalized 될 수 있음
• 캐스퍼는 이전 검증자 집합의 2/3 이상과 신규 검증자 집합의 2/3 이상의 투표 메세지
를 받는 경우에만 supermajority link로 인정
동적 검증자 집합 (Dynamic Validator Set)
source: https://medium.com/@VitalikButerin/safety-under-
dynamic-validator-sets-ef0c3bbdf9f6

를 받는 경우에만 supermajority link로 인정 source: https://medium.com/@VitalikButerin/safety-under-

#1 생성 → 블록 #1 finalize → 블록 #2 생성 → 블록 #2 finalize → · · · ).

• dynasty: 블록 b 의 dynasty는 b 의 부모 블록으로부터 루트(root)까지의
finalized된 체크포인트의 개수를 나타냄
• 검증자가 되고 싶은 참가자 v의 예치 메시지(deposit message)가 d의 dynasty
값을 갖는 블록에 추가되면 해당 참가자는 d+2의 dynasty값을 갖는 첫 번째
블록부터 검증자로서 참여하며 d+2 를 start dynasty 혹은 DS(v)라 함
• 마찬가지로 검증을 그만 두고 싶은 검증자 v의 탈퇴 메시지(withdraw
message)가 d의 dynasty값을 갖는 블록에 추가되면 해당 검증자는 d+2의
dynasty값을 갖는 첫 번째 블록부터 검증자로서 참여하지 않으며 d+2 를 end
dynasty 혹은 DE(v)라 함
• forward validator set: Vf (d) ≡ {ν : DS(ν) ≤ d < DE(ν)}
• rear validator set: Vr (d) ≡ {ν : DS(ν) < d ≤ DE(ν)}
• supermajority link: d의 dynasty 값을 갖는 rear validator set 및 forward
validator set의 2/3 이상이 s → t 로의 투표 메시지를 공개한 경우 (s, t)는
supermajority link를 갖음
• finalized: 체크포인트 c 가 justified 되었고 c 의 direct child 인 c’ 으로의
supermajority link (i.e. c → c’)가 존재하며 c 를 justify하는 모든 supermajority
link 가 c’ 의 자녀(child) 이전에 블록체인에 추가된 경우 c 가 finalized 되었다
고 함
용어정의 (2/2)

고 함
용어정의 (2/2)
블록 #0
블록 #1
블록 #100
블록 #200
블록 #99
.
.
.
.
.
.
블록 #201
.
.
.
블록 #101
supermajority link
블록#0 → 블록 #100
supermajority link
블록#100 → 블록
#200
dynasty = 1
dynasty = 2
dynasty = 3
블록 #300
supermajority link
블록#200 → 블록
#300

고 함
용어정의 (2/2)
블록 #0
블록 #1
블록 #100
블록 #200
블록 #99
.
.
.
.
.
.
블록 #201
.
.
.
블록 #101
dynasty = 1
dynasty = 2
dynasty = 3
블록 #300
참가자 v의 예치 메시지
v 검증자로서 참여 시작
DS(v) = 3

고 함
용어정의 (2/2)
블록 #0
블록 #1
블록 #100
블록 #200
블록 #99
.
.
.
.
.
.
블록 #201
.
.
.
블록 #101
dynasty = 1
dynasty = 2
dynasty = 3
블록 #300
참가자 v의 탈퇴 메시지
v 검증자로서 탈퇴
DE(v) = 3

고 함
용어정의 (2/2)
블록 #0
블록 #1
블록 #100
블록 #200
블록 #99
.
.
.
.
.
.
블록 #201
.
.
.
블록 #101
dynasty = 1
dynasty = 2
dynasty = 3
블록 #300
참가자 v1의 예치 메시지
참가자 v2의 탈퇴 메시지
V = dynasty 1의 검증자 집합
Vf (3) = V + {v1}
Vr (3) = V — {v2}

고 함
용어정의 (2/2)
체크포인트 #45
새로운 검증자 집합: B
A에 의해 서명
체크포인트 #46
새로운 검증자 집합: C
A + B 에 의해 서명
체크포인트 #47
새로운 검증자 집합: D
B + C 에 의해 서명
supermajority link
supermajority link
A: forward validator set
B: rear validator set

고 함
용어정의 (2/2)
source:
justified
c
c’
c’’
supermajority
link
supermajority links justifying c
included before c’’

• “nothing-at-stake” problem
• long range revision
• catastrophic crash
다양한 공격의 방어

source: https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/

source: https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
Slasher: 예치금을 예치하고 잘못된 행동시 예치금을 몰수

source:
검증자의 예치금에 대한 출금지연(withdraw delay)을
통해 클라이언트가 주기적으로 justified chain 에 대한
정보를 획득하면 장거리 공격을 막을 수 있음

검증자의 1/3 이상이 동시에 검증에 참여하지 못하는 경우 (i.e. 네트워크 분할,
악의적 행동 등) 체크포인트가 finalized 되지 못함
검증자가 검증에 참여하지 않는 경우 “inactivity leak”을 통해 검증자의 예치금
을 조금씩 줄여나가는 방법. 감소된 이더(ether)를 검증자에게 일정시간 이후
돌려주어야 하는지 여부 및 구체적인 공식(formula)는 경제적 인센티브 설계의
영역.

source:
inactivity leak 으로 인해 충돌하는 두 개의 체크포인트
가 동시에 finalize 될 가능성이 있음. 이러한 다양한 공
격을 방지하는 방법은 아직까지 열린문제로 남아있음

• 제안 메커니즘(proposal mechanism)이 타협(compromise)되면 캐스퍼 프로
토콜이 새로운 블록을 finalize 할 수 없음. 현재 작업증명 기반의 제안 메커니
즘에서 지분증명(PoS) 기반의 제안 메커니즘으로 전환하는 것이 목표
• 보상과 벌금을 통해 검증자 집합이 동적으로 변화하는 경우에도
accountable safety와 plausible liveness 를 충족한다는 것을 증명
• 지분증명 방식의 합의 알고리즘에서 발생할 수 있는 공격상황을 가정한 후
포크 선택 규칙에 대한 formal specification
• 캐스퍼 내 경제적 인센티브에 대한 분석
Future Work

Resources
• Casper the Friendly Finality Gadget (Vitalik Buterin, Virgil Griffith / final update: Oct 29, 2017):
https://github.com/ethereum/research/blob/master/papers/casper-basics/casper_basics.pdf
• Casper PoS & Smart Contract Consensus Overview (Karl Floersch / Jun 30, 2017):
https://www.youtube.com/watch?v=MyDocEQfBGA&t=1090s
• Minimal Slashing Conditions (Vitalik Buterin / Mar 2, 2017): https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c
• Safety Under Dynamic Validator Sets (Vitalik Buterin / Mar 5, 2017): https://medium.com/@VitalikButerin/safety-under-dynamic-validator-
sets-ef0c3bbdf9f6
• Ethereum Casper 101 (Jon Choi / Oct 22, 2017): https://medium.com/@jonchoi/ethereum-casper-101-7a851a4f1eb0
• Ethereum Research: https://ethresear.ch/
• Proof of Stake FAQ: https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
• Incentives in Casper the Friendly Finality Gadget (Vitalik Buterin / Sep 4, 2017):
https://github.com/ethereum/research/blob/master/papers/casper-economics/casper_economics_basic.pdf
• Proof of Stake Design Philosophy (Vitalik Buterin / Dec 31, 2016): https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-
506585978d51
• Proof of Stake: How I Learned to Love Weak Subjectivity (Vitalik Buterin / Nov 25, 2014): https://blog.ethereum.org/2014/11/25/proof-stake-
learned-love-weak-subjectivity/

캐스퍼(Casper): 이더리움(Ethereum)의 지분증명(PoS) 방식의 합의 알고리즘

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

캐스퍼(Casper): 이더리움(Ethereum)의 지분증명(PoS) 방식의 합의 알고리즘