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): 이더리움(Ethereum)의 지분증명(PoS) 방식의 합의 알고리즘

4,065 views

Published on

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

Published in: Technology
  • Be the first to comment

캐스퍼(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/

×