Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
캐스퍼(Casper)
이더리움의 지분증명(PoS: Proof of Stake) 방식의 합의 알고리즘
문영훈
version 0.1
final edit: 2017. 11. 29
based on Casper the Frien...
목차
캐스퍼: 이더리움의 지분증명(PoS: Proof of Stake) 방식의 합의 알고리즘
• 비잔틴 장애 허용(BFT: Byzantine Fault Tolerant) 방식의 합의 알고리즘에 기반
한 합의 알고리즘
• 규칙을 어기는 검증자를 식별하고 이들의 예치금을 몰수(slashing)하는 방식으
로 책임을...
• 비잔틴 장애 허용(BFT: Byzantine Fault Tolerant) 방식의 합의 알고리즘에 기반
한 합의 알고리즘
• 규칙을 어기는 검증자를 식별하고 이들의 예치금을 몰수(slashing)하는 방식으
로 책임을...
• 비잔틴 장애 허용(BFT: Byzantine Fault Tolerant) 방식의 합의 알고리즘에 기반
한 합의 알고리즘
• 규칙을 어기는 검증자를 식별하고 이들의 예치금을 몰수(slashing)하는 방식으
로 책임을...
• 비잔틴 장애 허용(BFT: Byzantine Fault Tolerant) 방식의 합의 알고리즘에 기반
한 합의 알고리즘
• 규칙을 어기는 검증자를 식별하고 이들의 예치금을 몰수(slashing)하는 방식으
로 책임을...
• 비잔틴 장애 허용(BFT: Byzantine Fault Tolerant) 방식의 합의 알고리즘에 기반
한 합의 알고리즘
• 규칙을 어기는 검증자를 식별하고 이들의 예치금을 몰수(slashing)하는 방식으
로 책임을...
• 비잔틴 장애 허용(BFT: Byzantine Fault Tolerant) 방식의 합의 알고리즘에 기반
한 합의 알고리즘
• 규칙을 어기는 검증자를 식별하고 이들의 예치금을 몰수(slashing)하는 방식으
로 책임을...
• 체크포인트(checkpoint): 높이가 100의 배수 (100*k)인 블록 (e.g. 제네시스 블록
, 블록 #100, #200, …)
• 예치금(deposit): 검증자가 검증에 참여하기 위해 캐스퍼 스마트 컨트...
블록 #0
블록 #1
블록 #100
블록 #200
블록 #99
.
.
.
.
.
.
블록 #201
.
.
.
블록 #101
• 체크포인트(checkpoint): 높이가 100의 배수 (100*k)인 블록 (e.g. 제네...
• 체크포인트(checkpoint): 높이가 100의 배수 (100*k)인 블록 (e.g. 제네시스 블
록, 블록 #100, #200, …)
• 예치금(deposit): 검증자가 검증에 참여하기 위해 캐스퍼 스마트 컨트...
• 체크포인트(checkpoint): 높이가 100의 배수 (100*k)인 블록 (e.g. 제네시스 블록
, 블록 #100, #200, …)
• 예치금(deposit): 검증자가 검증에 참여하기 위해 캐스퍼 스마트 컨트...
• 체크포인트(checkpoint): 높이가 100의 배수 (100*k)인 블록 (e.g. 제네시스 블록
, 블록 #100, #200, …)
• 예치금(deposit): 검증자가 검증에 참여하기 위해 캐스퍼 스마트 컨트...
• 체크포인트(checkpoint): 높이가 100의 배수 (100*k)인 블록 (e.g. 제네시스 블록
, 블록 #100, #200, …)
• 예치금(deposit): 검증자가 검증에 참여하기 위해 캐스퍼 스마트 컨트...
Prepare, Commit → Vote
source: https://ethresear.ch/t/casper-ffg-with-one-message-type-and-simpler-fork-choice-rule/103
이전...
• 체크포인트(checkpoint): 높이가 100의 배수 (100*k)인 블록 (e.g. 제네시스 블록
, 블록 #100, #200, …)
• 예치금(deposit): 검증자가 검증에 참여하기 위해 캐스퍼 스마트 컨트...
• 체크포인트(checkpoint): 높이가 100의 배수 (100*k)인 블록 (e.g. 제네시스 블록
, 블록 #100, #200, …)
• 예치금(deposit): 검증자가 검증에 참여하기 위해 캐스퍼 스마트 컨트...
• 체크포인트(checkpoint): 높이가 100의 배수 (100*k)인 블록 (e.g. 제네시스 블록
, 블록 #100, #200, …)
• 예치금(deposit): 검증자가 검증에 참여하기 위해 캐스퍼 스마트 컨트...
• 체크포인트(checkpoint): 높이가 100의 배수 (100*k)인 블록 (e.g. 제네시스 블록
, 블록 #100, #200, …)
• 예치금(deposit): 검증자가 검증에 참여하기 위해 캐스퍼 스마트 컨트...
검증자 v는 아래의 조건을 만족시키는 다음과 같은 서로 다른 투표 메세지를 공개할 수 없다
< v, s1, t1, h(s1), h(t1) > < v, s2, t2, h(s2), h(t2) >
I. h(t1) = h(t2...
검증자 v는 아래의 조건을 만족시키는 다음과 같은 서로 다른
투표 메세지를 공개할 수 없다
< v, s1, t1, h(s1), h(t1) > < v, s2, t2, h(s2), h(t2) >
I. h(t1) = h(t2...
검증자 v는 아래의 조건을 만족시키는 다음과 같은 서로 다른
투표 메세지를 공개할 수 없다
< v, s1, t1, h(s1), h(t1) > < v, s2, t2, h(s2), h(t2) >
I. h(t1) = h(t2...
• Accountable Safety: “1/3 이상의 검증자(validator)의 예치금이 몰수당하지 않는 한
두 개의 상충(conflicting)되는 체크포인트(checkpoint)가 완결(finalize)될 수 없...
• Accountable Safety: “1/3 이상의 검증자(validator)의 예치금이 몰수당하지 않는 한
두 개의 상충(conflicting)되는 체크포인트(checkpoint)가 완결(finalize)될 수 없...
• 두 개의 충돌하는 체크포인트 am 과 bn 이 모두 finalize 되었다고
가정
• 만약 h(am) = h(bn) 라면 1/3 이상의 검증자가 캐스퍼 프로토콜 I
을 어긴 것으로 이들의 예치금이 몰수
• am 과 ...
• 두 개의 충돌하는 체크포인트 am 과 bn 이 모두 finalize 되었다고
가정
• 만약 h(am) = h(bn) 라면 1/3 이상의 검증자가 캐스퍼 프로토콜 I
을 어긴 것으로 이들의 예치금이 몰수
• am 과 ...
• 두 개의 충돌하는 체크포인트 am 과 bn 이 모두 finalize 되었다고
가정
• 만약 h(am) = h(bn) 라면 1/3 이상의 검증자가 캐스퍼 프로토콜 I
을 어긴 것으로 이들의 예치금이 몰수
• am 과 ...
• 두 개의 충돌하는 체크포인트 am 과 bn 이 모두 finalize 되었다고
가정
• 만약 h(am) = h(bn) 라면 1/3 이상의 검증자가 캐스퍼 프로토콜 I
을 어긴 것으로 이들의 예치금이 몰수
• am 과 ...
• 두 개의 충돌하는 체크포인트 am 과 bn 이 모두 finalize 되었다고
가정
• 만약 h(am) = h(bn) 라면 1/3 이상의 검증자가 캐스퍼 프로토콜 I
을 어긴 것으로 이들의 예치금이 몰수
• am 과 ...
• 두 개의 충돌하는 체크포인트 am 과 bn 이 모두 finalize 되었다고
가정
• 만약 h(am) = h(bn) 라면 1/3 이상의 검증자가 캐스퍼 프로토콜 I
을 어긴 것으로 이들의 예치금이 몰수
• am 과 ...
• 두 개의 충돌하는 체크포인트 am 과 bn 이 모두 finalize 되었다고
가정
• 만약 h(am) = h(bn) 라면 1/3 이상의 검증자가 캐스퍼 프로토콜 I
을 어긴 것으로 이들의 예치금이 몰수
• am 과 ...
• 두 개의 충돌하는 체크포인트 am 과 bn 이 모두 finalize 되었다고
가정
• 만약 h(am) = h(bn) 라면 1/3 이상의 검증자가 캐스퍼 프로토콜 I
을 어긴 것으로 이들의 예치금이 몰수
• am 과 ...
• Accountable Safety: “1/3 이상의 검증자(validator)의 예치금이 몰수당하지 않는 한
두 개의 상충(conflicting)되는 체크포인트(checkpoint)가 완결(finalize)될 수 없...
• a 를 가장 큰 높이를 가지는 justified 된 체크포인트, b 를 검증자
가 투표한 최대 높이의 target 체크포인트라 하자
• 이 때 h(a’) = h(b) + 1 을 만족시키는 a 의 자손 체크포인트 a’...
• a 를 가장 큰 높이를 가지는 justified 된 체크포인트, b 를 검증자
가 투표한 최대 높이의 target 체크포인트라 하자
• 이 때 h(a’) = h(b) + 1 을 만족시키는 a 의 자손 체크포인트 a’...
• a 를 가장 큰 높이를 가지는 justified 된 체크포인트, b 를 검증자
가 투표한 최대 높이의 target 체크포인트라 하자
• 이 때 h(a’) = h(b) + 1 을 만족시키는 a 의 자손 체크포인트 a’...
• 기존 작업증명(PoW) 방식의 포크 선택 규칙은 “가장 긴 체인 위에 블록을 추
가”시키는 것. 하지만 캐스퍼의 경우 그와 같은 포크 선택 규칙을 도입하는
경우 체인 자체가 더 이상 justify 되거나 finali...
• 기존 작업증명(PoW) 방식의 포크 선택 규칙은 “가장 긴 체인 위에 블록을 추
가”시키는 것. 하지만 캐스퍼의 경우 그와 같은 포크 선택 규칙을 도입하는
경우 체인 자체가 더 이상 justify 되거나 finali...
JUSTIFIED
b 대신 a 위에 채굴a
b
• 기존 작업증명(PoW) 방식의 포크 선택 규칙은 “가장 긴 체인 위에 블록을 추
가”시키는 것. 하지만 캐스퍼의 경우 그와 같은 포크 선택 규칙을 도입하는
경우 체인 자...
• 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의
safety와 liveness를 증명. 하지만 이더리움과 같은 비허가성 블록체인에서는 검증자가
자발적으로 검증에 참여하거나 탈퇴할 수 있어...
• 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의
safety와 liveness를 증명. 하지만 이더리움과 같은 비허가성 블록체인에서는 검증자가
자발적으로 검증에 참여하거나 탈퇴할 수 있어...
• 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의
safety와 liveness를 증명. 하지만 이더리움과 같은 비허가성 블록체인에서는 검증자가
자발적으로 검증에 참여하거나 탈퇴할 수 있어...
• 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의
safety와 liveness를 증명. 하지만 이더리움과 같은 비허가성 블록체인에서는 검증자가
자발적으로 검증에 참여하거나 탈퇴할 수 있어...
• 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의
safety와 liveness를 증명. 하지만 이더리움과 같은 비허가성 블록체인에서는 검증자가
자발적으로 검증에 참여하거나 탈퇴할 수 있어...
• 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의
safety와 liveness를 증명. 하지만 이더리움과 같은 비허가성 블록체인에서는 검증자가
자발적으로 검증에 참여하거나 탈퇴할 수 있어...
• 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의
safety와 liveness를 증명. 하지만 이더리움과 같은 비허가성 블록체인에서는 검증자가
자발적으로 검증에 참여하거나 탈퇴할 수 있어...
• 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의
safety와 liveness를 증명. 하지만 이더리움과 같은 비허가성 블록체인에서는 검증자가
자발적으로 검증에 참여하거나 탈퇴할 수 있어...
• dynasty: 블록 b 의 dynasty는 b 의 부모 블록으로부터 루트(root)까지의
finalized된 체크포인트의 개수를 나타냄
• 검증자가 되고 싶은 참가자 v의 예치 메시지(deposit message)...
• dynasty: 블록 b 의 dynasty는 b 의 부모 블록으로부터 루트(root)까지의
finalized된 체크포인트의 개수를 나타냄
• 검증자가 되고 싶은 참가자 v의 예치 메시지(deposit message)...
• dynasty: 블록 b 의 dynasty는 b 의 부모 블록으로부터 루트(root)까지의
finalized된 체크포인트의 개수를 나타냄
• 검증자가 되고 싶은 참가자 v의 예치 메시지(deposit message)...
• dynasty: 블록 b 의 dynasty는 b 의 부모 블록으로부터 루트(root)까지의
finalized된 체크포인트의 개수를 나타냄
• 검증자가 되고 싶은 참가자 v의 예치 메시지(deposit message)...
• dynasty: 블록 b 의 dynasty는 b 의 부모 블록으로부터 루트(root)까지의
finalized된 체크포인트의 개수를 나타냄
• 검증자가 되고 싶은 참가자 v의 예치 메시지(deposit message)...
• dynasty: 블록 b 의 dynasty는 b 의 부모 블록으로부터 루트(root)까지의
finalized된 체크포인트의 개수를 나타냄
• 검증자가 되고 싶은 참가자 v의 예치 메시지(deposit message)...
• dynasty: 블록 b 의 dynasty는 b 의 부모 블록으로부터 루트(root)까지의
finalized된 체크포인트의 개수를 나타냄
• 검증자가 되고 싶은 참가자 v의 예치 메시지(deposit message)...
• “nothing-at-stake” problem
• long range revision
• catastrophic crash
다양한 공격의 방어
• “nothing-at-stake” problem
• long range revision
• catastrophic crash
다양한 공격의 방어
source: https://blog.ethereum.org/2014/...
• “nothing-at-stake” problem
• long range revision
• catastrophic crash
다양한 공격의 방어
source: https://blog.ethereum.org/2014/...
• “nothing-at-stake” problem
• long range revision
• catastrophic crash
다양한 공격의 방어
source:
https://github.com/ethereum/res...
• “nothing-at-stake” problem
• long range revision
• catastrophic crash
다양한 공격의 방어
검증자의 1/3 이상이 동시에 검증에 참여하지 못하는 경우 (i.e. ...
• “nothing-at-stake” problem
• long range revision
• catastrophic crash
다양한 공격의 방어
검증자의 1/3 이상이 동시에 검증에 참여하지 못하는 경우 (i.e. ...
• “nothing-at-stake” problem
• long range revision
• catastrophic crash
다양한 공격의 방어
source:
https://github.com/ethereum/res...
• 제안 메커니즘(proposal mechanism)이 타협(compromise)되면 캐스퍼 프로
토콜이 새로운 블록을 finalize 할 수 없음. 현재 작업증명 기반의 제안 메커니
즘에서 지분증명(PoS) 기반의 제...
• 제안 메커니즘(proposal mechanism)이 타협(compromise)되면 캐스퍼 프로
토콜이 새로운 블록을 finalize 할 수 없음. 현재 작업증명 기반의 제안 메커니
즘에서 지분증명(PoS) 기반의 제...
• 제안 메커니즘(proposal mechanism)이 타협(compromise)되면 캐스퍼 프로
토콜이 새로운 블록을 finalize 할 수 없음. 현재 작업증명 기반의 제안 메커니
즘에서 지분증명(PoS) 기반의 제...
• 제안 메커니즘(proposal mechanism)이 타협(compromise)되면 캐스퍼 프로
토콜이 새로운 블록을 finalize 할 수 없음. 현재 작업증명 기반의 제안 메커니
즘에서 지분증명(PoS) 기반의 제...
• 제안 메커니즘(proposal mechanism)이 타협(compromise)되면 캐스퍼 프로
토콜이 새로운 블록을 finalize 할 수 없음. 현재 작업증명 기반의 제안 메커니
즘에서 지분증명(PoS) 기반의 제...
Resources
• Casper the Friendly Finality Gadget (Vitalik Buterin, Virgil Griffith / final update: Oct 29, 2017):
https://g...
Upcoming SlideShare
Loading in …5
×

캐스퍼(Casper): 이더리움(Ethereum)의 지분증명(PoS) 방식의 합의 알고리즘

5,601 views

Published on

이더리움의 합의알고리즘인 캐스퍼에 대한 자료입니다. 최근 발표된 비탈릭 뷰테린의 논문에 근거하여 캐스퍼를 설명하였습니다.

Published in: Technology

캐스퍼(Casper): 이더리움(Ethereum)의 지분증명(PoS) 방식의 합의 알고리즘

  1. 1. 캐스퍼(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)
  2. 2. 목차 캐스퍼: 이더리움의 지분증명(PoS: Proof of Stake) 방식의 합의 알고리즘
  3. 3. • 비잔틴 장애 허용(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 방식으로 구현 캐스퍼란?
  4. 4. • 비잔틴 장애 허용(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 방식으로 구현 캐스퍼란?
  5. 5. • 비잔틴 장애 허용(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 방식으로 구현 캐스퍼란?
  6. 6. • 비잔틴 장애 허용(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 방식으로 구현 캐스퍼란?
  7. 7. • 비잔틴 장애 허용(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 방식으로 구현 캐스퍼란?
  8. 8. • 비잔틴 장애 허용(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 방식으로 구현 캐스퍼란?
  9. 9. • 체크포인트(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)
  10. 10. 블록 #0 블록 #1 블록 #100 블록 #200 블록 #99 . . . . . . 블록 #201 . . . 블록 #101 • 체크포인트(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)
  11. 11. • 체크포인트(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되었다고 함 source: https://github.com/ethereum/research/blob/master/papers/cas per-basics/casper_basics.pdf 용어정의 (1/2)
  12. 12. • 체크포인트(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)
  13. 13. • 체크포인트(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되었다고 함 (v, s, t, h(s), h(t)) source target validator 용어정의 (1/2)
  14. 14. • 체크포인트(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되었다고 함 source: https://github.com/ethereum/research/blob/master/papers/cas per-basics/casper_basics.pdf (v, b1, b2, 1, 3) 용어정의 (1/2)
  15. 15. Prepare, Commit → Vote source: https://ethresear.ch/t/casper-ffg-with-one-message-type-and-simpler-fork-choice-rule/103 이전 버전의 캐스퍼는 검증자들이 prepare와 commit 두 종류의 메세지를 보낼 수 있었던 반면 9 월 말 이후 업데이트된 버전의 캐스퍼에서는 검증 자들이 vote 라는 한 가지 종류의 메세지만을 보낼 수 있도록 설계. 캐스퍼 프로토콜이 계속해서 빠르 게 변화함을 알 수 있음
  16. 16. • 체크포인트(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되었다고 함 블록 #0 블록 #1 블록 #100 블록 #200 블록 #99 . . . . . . 블록 #201 . . . 블록 #101 supermajority link 블록#0 → 블록 #200 용어정의 (1/2) 검증자의 2/3 이상의 투표 메세지 필요! 두 개의 체크포인트가 인접할 필요 없음
  17. 17. • 체크포인트(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되었다고 함 source: https://github.com/ethereum/research/blob/master/papers/cas per-basics/casper_basics.pdf 충돌(conflict) 용어정의 (1/2)
  18. 18. • 체크포인트(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되었다고 함 source: https://github.com/ethereum/research/blob/master/papers/cas per-basics/casper_basics.pdf 용어정의 (1/2)
  19. 19. • 체크포인트(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되었다고 함 source: https://github.com/ethereum/research/blob/master/papers/cas per-basics/casper_basics.pdf FINALIZED! 용어정의 (1/2)
  20. 20. 검증자 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. 검증자는 자신이 투표한 범위 내 다른 투표 메세지를 공개할 수 없다 캐스퍼 프로토콜
  21. 21. 검증자 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. 검증자는 자신이 투표한 범위 내 다른 투표 메세지를 공개할 수 없다 캐스퍼 프로토콜
  22. 22. 검증자 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. 검증자는 자신이 투표한 범위 내 다른 투표 메세지를 공개할 수 없다 캐스퍼 프로토콜
  23. 23. • Accountable Safety: “1/3 이상의 검증자(validator)의 예치금이 몰수당하지 않는 한 두 개의 상충(conflicting)되는 체크포인트(checkpoint)가 완결(finalize)될 수 없다.” • Plausible Liveness: “과거 이벤트(e.g. 예치금 몰수, 블록의 지연, 검열공격 등)와 관 계없이 2/3 이상의 검증자가 프로토콜을 따른다면 그 어떤 검증자의 예치금 몰수 없이 항상 새로운 체크포인트를 완결할 수 있다.” 캐스퍼의 두 가지 기본속성
  24. 24. • Accountable Safety: “1/3 이상의 검증자(validator)의 예치금이 몰수당하지 않는 한 두 개의 상충(conflicting)되는 체크포인트(checkpoint)가 완결(finalize)될 수 없다.” • Plausible Liveness: “과거 이벤트(e.g. 예치금 몰수, 블록의 지연, 검열공격 등)와 관 계없이 2/3 이상의 검증자가 프로토콜을 따른다면 그 어떤 검증자의 예치금 몰수 없이 항상 새로운 체크포인트를 완결할 수 있다.” 캐스퍼의 두 가지 기본속성
  25. 25. • 두 개의 충돌하는 체크포인트 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 될 수 없다검증자 집합이 동적으로 변하지 않는 기본적인 경우
  26. 26. • 두 개의 충돌하는 체크포인트 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 될 수 없다검증자 집합이 동적으로 변하지 않는 기본적인 경우
  27. 27. • 두 개의 충돌하는 체크포인트 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 될 수 없다검증자 집합이 동적으로 변하지 않는 기본적인 경우
  28. 28. • 두 개의 충돌하는 체크포인트 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 될 수 없다검증자 집합이 동적으로 변하지 않는 기본적인 경우
  29. 29. • 두 개의 충돌하는 체크포인트 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 될 수 없다검증자 집합이 동적으로 변하지 않는 기본적인 경우
  30. 30. • 두 개의 충돌하는 체크포인트 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 될 수 없다검증자 집합이 동적으로 변하지 않는 기본적인 경우
  31. 31. • 두 개의 충돌하는 체크포인트 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 될 수 없다검증자 집합이 동적으로 변하지 않는 기본적인 경우
  32. 32. • 두 개의 충돌하는 체크포인트 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 될 수 없다검증자 집합이 동적으로 변하지 않는 기본적인 경우
  33. 33. • Accountable Safety: “1/3 이상의 검증자(validator)의 예치금이 몰수당하지 않는 한 두 개의 상충(conflicting)되는 체크포인트(checkpoint)가 완결(finalize)될 수 없다.” • Plausible Liveness: “과거 이벤트(e.g. 예치금 몰수, 블록의 지연, 검열공격 등)와 관 계없이 2/3 이상의 검증자가 프로토콜을 따른다면 그 어떤 검증자의 예치금 몰수 없이 항상 새로운 체크포인트를 완결할 수 있다.” 캐스퍼의 두 가지 기본속성
  34. 34. • 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
  35. 35. • 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’
  36. 36. • 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’ a’’
  37. 37. • 기존 작업증명(PoW) 방식의 포크 선택 규칙은 “가장 긴 체인 위에 블록을 추 가”시키는 것. 하지만 캐스퍼의 경우 그와 같은 포크 선택 규칙을 도입하는 경우 체인 자체가 더 이상 justify 되거나 finalize 될 수 없는 경우가 발생할 수 있음 • 따라서 캐스퍼의 포크 선택 규칙은 “가장 긴 justified 된 체크포인트의 체인을 포함하고 있는 체인 위에 블록을 추가” 캐스퍼 포크 선택 규칙 (fork choice rule)
  38. 38. • 기존 작업증명(PoW) 방식의 포크 선택 규칙은 “가장 긴 체인 위에 블록을 추 가”시키는 것. 하지만 캐스퍼의 경우 그와 같은 포크 선택 규칙을 도입하는 경우 체인 자체가 더 이상 justify 되거나 finalize 될 수 없는 경우가 발생할 수 있음 • 따라서 캐스퍼의 포크 선택 규칙은 “가장 긴 justified 된 체크포인트의 체인을 포함하고 있는 체인 위에 블록을 추가” 캐스퍼 포크 선택 규칙 (fork choice rule) FINALIZED 채굴자들이 가장 긴 체인을 채 굴하므로 a 의 finalization에 참여한 검증자들의 자발적인 예치금 몰수 없이 새로운 블록 에 finalize 불가 a b
  39. 39. JUSTIFIED b 대신 a 위에 채굴a b • 기존 작업증명(PoW) 방식의 포크 선택 규칙은 “가장 긴 체인 위에 블록을 추 가”시키는 것. 하지만 캐스퍼의 경우 그와 같은 포크 선택 규칙을 도입하는 경우 체인 자체가 더 이상 justify 되거나 finalize 될 수 없는 경우가 발생할 수 있음 • 따라서 캐스퍼의 포크 선택 규칙은 “가장 긴 justified 된 체크포인트의 체인을 포함하고 있는 체인 위에 블록을 추가” 캐스퍼 포크 선택 규칙 (fork choice rule)
  40. 40. • 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의 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
  41. 41. • 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의 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로 인정 source: https://medium.com/@VitalikButerin/safety-under- dynamic-validator-sets-ef0c3bbdf9f6 동적 검증자 집합 (Dynamic Validator Set)
  42. 42. • 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의 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로 인정 source: https://medium.com/@VitalikButerin/safety-under- dynamic-validator-sets-ef0c3bbdf9f6 동적 검증자 집합 (Dynamic Validator Set)
  43. 43. • 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의 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로 인정 source: https://medium.com/@VitalikButerin/safety-under- dynamic-validator-sets-ef0c3bbdf9f6 동적 검증자 집합 (Dynamic Validator Set)
  44. 44. • 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의 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로 인정 source: https://medium.com/@VitalikButerin/safety-under- dynamic-validator-sets-ef0c3bbdf9f6 동적 검증자 집합 (Dynamic Validator Set)
  45. 45. • 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의 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로 인정 source: https://medium.com/@VitalikButerin/safety-under- dynamic-validator-sets-ef0c3bbdf9f6 동적 검증자 집합 (Dynamic Validator Set)
  46. 46. • 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의 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로 인정 source: https://medium.com/@VitalikButerin/safety-under- dynamic-validator-sets-ef0c3bbdf9f6 동적 검증자 집합 (Dynamic Validator Set)
  47. 47. • 이전의 경우에는 검증자가 일정하게 유지되는 경우를 가정하여 캐스퍼 프로토콜의 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
  48. 48. • 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)
  49. 49. • 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) 블록 #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
  50. 50. • 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) 블록 #0 블록 #1 블록 #100 블록 #200 블록 #99 . . . . . . 블록 #201 . . . 블록 #101 dynasty = 1 dynasty = 2 dynasty = 3 블록 #300 참가자 v의 예치 메시지 v 검증자로서 참여 시작 DS(v) = 3
  51. 51. • 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) 블록 #0 블록 #1 블록 #100 블록 #200 블록 #99 . . . . . . 블록 #201 . . . 블록 #101 dynasty = 1 dynasty = 2 dynasty = 3 블록 #300 참가자 v의 탈퇴 메시지 v 검증자로서 탈퇴 DE(v) = 3
  52. 52. • 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) 블록 #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}
  53. 53. • 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) 체크포인트 #45 새로운 검증자 집합: B A에 의해 서명 체크포인트 #46 새로운 검증자 집합: C A + B 에 의해 서명 체크포인트 #47 새로운 검증자 집합: D B + C 에 의해 서명 supermajority link supermajority link A: forward validator set B: rear validator set
  54. 54. • 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) source: https://github.com/ethereum/research/blob/master/papers/cas per-basics/casper_basics.pdf justified c c’ c’’ supermajority link supermajority links justifying c included before c’’
  55. 55. • “nothing-at-stake” problem • long range revision • catastrophic crash 다양한 공격의 방어
  56. 56. • “nothing-at-stake” problem • long range revision • catastrophic crash 다양한 공격의 방어 source: https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
  57. 57. • “nothing-at-stake” problem • long range revision • catastrophic crash 다양한 공격의 방어 source: https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/ Slasher: 예치금을 예치하고 잘못된 행동시 예치금을 몰수
  58. 58. • “nothing-at-stake” problem • long range revision • catastrophic crash 다양한 공격의 방어 source: https://github.com/ethereum/research/blob/master/papers/cas per-basics/casper_basics.pdf 검증자의 예치금에 대한 출금지연(withdraw delay)을 통해 클라이언트가 주기적으로 justified chain 에 대한 정보를 획득하면 장거리 공격을 막을 수 있음
  59. 59. • “nothing-at-stake” problem • long range revision • catastrophic crash 다양한 공격의 방어 검증자의 1/3 이상이 동시에 검증에 참여하지 못하는 경우 (i.e. 네트워크 분할, 악의적 행동 등) 체크포인트가 finalized 되지 못함 검증자가 검증에 참여하지 않는 경우 “inactivity leak”을 통해 검증자의 예치금 을 조금씩 줄여나가는 방법. 감소된 이더(ether)를 검증자에게 일정시간 이후 돌려주어야 하는지 여부 및 구체적인 공식(formula)는 경제적 인센티브 설계의 영역.
  60. 60. • “nothing-at-stake” problem • long range revision • catastrophic crash 다양한 공격의 방어 검증자의 1/3 이상이 동시에 검증에 참여하지 못하는 경우 (i.e. 네트워크 분할, 악의적 행동 등) 체크포인트가 finalized 되지 못함 검증자가 검증에 참여하지 않는 경우 “inactivity leak”을 통해 검증자의 예치금 을 조금씩 줄여나가는 방법. 감소된 이더(ether)를 검증자에게 일정시간 이후 돌려주어야 하는지 여부 및 구체적인 공식(formula)는 경제적 인센티브 설계의 영역.
  61. 61. • “nothing-at-stake” problem • long range revision • catastrophic crash 다양한 공격의 방어 source: https://github.com/ethereum/research/blob/master/papers/cas per-basics/casper_basics.pdf inactivity leak 으로 인해 충돌하는 두 개의 체크포인트 가 동시에 finalize 될 가능성이 있음. 이러한 다양한 공 격을 방지하는 방법은 아직까지 열린문제로 남아있음
  62. 62. • 제안 메커니즘(proposal mechanism)이 타협(compromise)되면 캐스퍼 프로 토콜이 새로운 블록을 finalize 할 수 없음. 현재 작업증명 기반의 제안 메커니 즘에서 지분증명(PoS) 기반의 제안 메커니즘으로 전환하는 것이 목표 • 보상과 벌금을 통해 검증자 집합이 동적으로 변화하는 경우에도 accountable safety와 plausible liveness 를 충족한다는 것을 증명 • 지분증명 방식의 합의 알고리즘에서 발생할 수 있는 공격상황을 가정한 후 포크 선택 규칙에 대한 formal specification • 캐스퍼 내 경제적 인센티브에 대한 분석 Future Work
  63. 63. • 제안 메커니즘(proposal mechanism)이 타협(compromise)되면 캐스퍼 프로 토콜이 새로운 블록을 finalize 할 수 없음. 현재 작업증명 기반의 제안 메커니 즘에서 지분증명(PoS) 기반의 제안 메커니즘으로 전환하는 것이 목표 • 보상과 벌금을 통해 검증자 집합이 동적으로 변화하는 경우에도 accountable safety와 plausible liveness 를 충족한다는 것을 증명 • 지분증명 방식의 합의 알고리즘에서 발생할 수 있는 공격상황을 가정한 후 포크 선택 규칙에 대한 formal specification • 캐스퍼 내 경제적 인센티브에 대한 분석 Future Work
  64. 64. • 제안 메커니즘(proposal mechanism)이 타협(compromise)되면 캐스퍼 프로 토콜이 새로운 블록을 finalize 할 수 없음. 현재 작업증명 기반의 제안 메커니 즘에서 지분증명(PoS) 기반의 제안 메커니즘으로 전환하는 것이 목표 • 보상과 벌금을 통해 검증자 집합이 동적으로 변화하는 경우에도 accountable safety와 plausible liveness 를 충족한다는 것을 증명 • 지분증명 방식의 합의 알고리즘에서 발생할 수 있는 공격상황을 가정한 후 포크 선택 규칙에 대한 formal specification • 캐스퍼 내 경제적 인센티브에 대한 분석 Future Work
  65. 65. • 제안 메커니즘(proposal mechanism)이 타협(compromise)되면 캐스퍼 프로 토콜이 새로운 블록을 finalize 할 수 없음. 현재 작업증명 기반의 제안 메커니 즘에서 지분증명(PoS) 기반의 제안 메커니즘으로 전환하는 것이 목표 • 보상과 벌금을 통해 검증자 집합이 동적으로 변화하는 경우에도 accountable safety와 plausible liveness 를 충족한다는 것을 증명 • 지분증명 방식의 합의 알고리즘에서 발생할 수 있는 공격상황을 가정한 후 포크 선택 규칙에 대한 formal specification • 캐스퍼 내 경제적 인센티브에 대한 분석 Future Work
  66. 66. • 제안 메커니즘(proposal mechanism)이 타협(compromise)되면 캐스퍼 프로 토콜이 새로운 블록을 finalize 할 수 없음. 현재 작업증명 기반의 제안 메커니 즘에서 지분증명(PoS) 기반의 제안 메커니즘으로 전환하는 것이 목표 • 보상과 벌금을 통해 검증자 집합이 동적으로 변화하는 경우에도 accountable safety와 plausible liveness 를 충족한다는 것을 증명 • 지분증명 방식의 합의 알고리즘에서 발생할 수 있는 공격상황을 가정한 후 포크 선택 규칙에 대한 formal specification • 캐스퍼 내 경제적 인센티브에 대한 분석 Future Work
  67. 67. 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/

×