Tendermint 창업자 Buchman Ethan의 논문 분석 #1

<< 이 포스트에서는 블록체인 및 텐더민트의 개요와 텐더민트의 합의 알고리즘을 설명한다.  TBA – To Be Analysed>>

 

블록체인의 보편적인 합의방식, 작업증명 PoW – 거래의 순서 (블록체인의 블록 체인 순서)는 부분 해쉬 충돌 (partial hash collision)에 기반한 경제적으로 보상차원의 장려되는 암호학 임의 복권 (random lottery) 방식을 통함. 거래 데이터에서 부분 해쉬 충돌을 찾은 노드가 블록에 거래들을 순서대로 기록하고 가장 어려운 난이도 (the greatest cumulative difficulty)를 가진 충돌 collision이 단 하나의 정확한 순서로 가정/합의한다. [여기서 부분 충돌이라 함은 난이도가 0x000000abcd 라면 이 이하 범위에 속하는 값을 찾는 것]

비트코인의 기술적 설계에 따른 한계점 – 거래를 확정짓는대 최대 1시간까지 걸림. 비트코인 기반으로 앱 작성 어려움, 보안을 보장하는 방식으로 확장하기 어려움[TBA-여기서 말하는 확장/보안은 무엇인가 파악], 비트코인 커뮤니티 내부의 미성숙된 정치적 논란 [이는 최근 하드포크를 이끈 이더리움 재단과 비교하는 의미인듯 함]

텐더민트 Tendermint : 합의 프로토콜, Go기반 고성능 구현, 합의 상에 임의의 앱을 작성할 수 있도록 하는 유연한 구조, 배포 deploy 또는 관리 등의 툴셋 제공. 보안 + 성능 + 간결의 조합

Replicated State Machine : 결정적 상태 기기들이 여러 프로세스들로 복제되어서 몇몇 프로세스가 장애를 일으켜도 단일 상태 기기로 동작하게 되는 것. 복제 상태 기기를 보면 분산 합의 Distributed Consensus를 이해할 수 있다.

 

거래 transaction라는 입력값으로 상태 변환 및 결과 반환됨. 거래의 경우 DB의 atomic operation이기에 중간 상태란 것이 없다. [상태 전이 함수 = 앱 로직 Application Logic, 즉 발생한 거래에 따라서 앱 상태가 변하게 되는 것을 말함] 합의 프로토콜을 통해 거래들의 순서를 정함. 결정적 상태전이 함수를 쓰는 것은 모든 프로세스들이 주어진 거래 로그(transaction log)들로 동일한 상태를 계산한다.

장애-허용 복제 상태 기기 (fault-tolerant replicated state machine)의 목적은 장애가 존재함에도 유용한 서비스를 제공하면서 동기화되게 머무르는 컴퓨터 네트워크를 조직화하는 것임. “동기화를 유지하는 것”(=Safety)은 거래 로그를 성공적으로 복제하는 것. “유용한 서비스를 제공하는 것”(=Liveness)은 새로운 거래를 위해 상태 기기가 유효함을 유지하는 것에 달려있음. 여기서 safety는 나쁜 일이 일어나지 않는 것 / liveness는 결국 좋은 일이 일어날 것임을 내포한다. Safety는 두개 이상의 거래 로그가 경쟁할 때 violated되며, Liveness는 응답없는 네트워크일 때 violated되었다 한다. 모든 거래를 다 받아 들이면 liveness를 만족하고, 아무 것도 받아들이지 않으면 safety를 만족한다.

동기화되는 환경하에서는 (즉, 네트워크 메시지의 최대 지연 또는 프로세서 클럭의 최대 속도에 대한 가정이 존재할 때 <- 복제 상태 기기를 유지할 설정들을 미리 파악 가능하다면) 순서대로 새로운 거래들을 제안하고, majority  다수결 투표를 하고, 동기화 가정의 “경계 bound”시간 안에 제안하지 않으면 제안할 기회를 잃어버리는 등의 처리는 쉽게 이뤄진다.

비동기화되는 환경에서는 (즉, 네트워크 지연이나 프로세서 속도의 가정이 보장되지 않을 때) trade-off는 관리하기 매우 힘들다.. “FLP impossibility result”는 하나의 프로세스라도 망가졌을 때 결정적 비동기화 프로세스들은 (deterministic asynchronous processes) 분산합의가 불가능하다는 결론에 이른다??!!는 이론임! [TBA-프로세스들이 실패할 수 있기에, 합의를 방해하는 적절한 시간에 프로세스들이 실패하는 프로토콜의 유효한 실행이 있게 된다?! – 그래서 합의를 보장할 수 없는 것이다.]

[합의에 대하여 반드시 읽어볼 글 : https://1ambda.github.io/93/cloud-computing/cloud-computing-7/ ]

보통 프로토콜 상에서 동기화는 특정 거래들을 관리하기 위해 시간제한 timeout을 사용한다.  메시지가 임의로 지연될 수 있는 비동기 환경에서 safety를 위해 동기화 기법인 시간 제한에 의존한다면 거래 로그가 분기fork 될수 있다..liveness를 보장하기 위해 시간제한 동기화에 의존한다면 합의가 멈추게 되며 서비스는 응답 불가상태가 된다. 특히 fork의 경우 더 심각한데 충돌나는 로그를 복원하는 것은 불가능한 일일 가능성이 있다.

FLP impossibility result 극복 방안
– 더 강력한 동기화 가정을 사용 : 최종적으로 망가진 프로세스들은 crashing 의심받고 정확한 프로세스들은 그렇지 않음.  이 경우, leaders를 활용함.  리더가 조직하는 특별한 역할을 하고 일정 타임아웃 후에 faulty 오류있음으로 의심받으면 skip된다.. 단, 실제로는 leader-election 방식은 제대로 동작하기 어렵다. [TBA-왜?]
– 비결정론적 방법 활용 : 임의화된 요소들 (합의를 이루는 확률이 1에 가능 경향이 있는 요소.) 적용. 단, 임의화 radonmization에 의존하면 매우 느리다.. 물론 발전한 암호학 기술들이 최근 속도측면에서 많은 향상을 보이긴 한다.

RBC – reliable broadcast : 메시지가 한번에 올바른 모든 프로세스로 종국에 전달되게 하는 기본동작 (primitive)
– 유효성 validity : 올바른 프로세스가 m을 브로드캐스팅할 때 종국에는 m을 전달한다.
– 동의 agreement : 올바른 프로세스가 m을 전달할 때, 올바른 모든 프로세스가 종국에는 m을 전달한다.
– 무결성 integrity : 전송자가이를 브로드캐스팅 했을때만 m이 딱 한번 전달된다.

ABC – Atomic BroadCast
전체 순서 total order – 옳은 프로세스 p와 q가 m과 m’을 전달한다면, q가 m’전에 m을 전달하는 필요 충분조건 하에서 p는 m’ 전에 m을 전달한다. [즉, 각 호스트에서 전달된 순서와 동일하게 전달된다.] 참고 사이트 https://en.wikipedia.org/wiki/Atomic_broadcast

합의 원칙 consensus primitives
– 종료 termination : 모든 옳은 프로세스들은 종국에 결정한다.
– 무결성 integrity : 모든 옳은 프로세스들은 최대 한번 결정한다.
– 동의 agreement : 한 프로세스가 v1로 결정하고 다른 프로세스가 v2로 결정했다면 v1과 v2는 동일하다.
– 유효성 validity – 옳은 프로세스가 v를 결정하면, 적어도 하나의 프로세스가 v를 제안했다.

ABC는 합의라는 관점으로 좁혀볼 수 있는데 이를 위해 해당 합의 프로토콜을 구현한 많은 인스턴스들을 순차적으로 구동하고, 바잔틴 문제 (Byzantine Faults)문제를 해결하기 위해서 약간의 가정이 필요하다.

합의 알고리즘인 Paxos (ABC를 만족시키기 위해 90년대 후반에 사용) – 실제 실용적인 장애 허용 합의 알고리즘 (fault-tolerance consensus algorithm) [산업계에서는 아마존, 구글등이 사용할 정도로 주요한 합의 알고리즘이나 이해하기 어렵다는 단점이 있다.

Raft – 상태 기기 복제 알고리즘 : Paxos 대비 이해력 증가 목표 understandability
오픈소스 커뮤니티에서 활용.. 거래 로그 transaction log를 먼저 집중, 특정 포인트에 “리더쉽 선정”을 한 후 리더가 다운되지 않는 한 지속적으로 거래를 commit할 수 있게 함.

Crash fault vs Byzantine Fault
: Crash는 그냥 프로세스가 멈춰서 다른 프로세스에게 잘못된 정보를 전달하지 못하지만 Byzantine의 경우는 잘못된 정보를 전달할 것이다. Crash의 경우 허용하는 숫자가 f라면 프로세스는 적어도 2f+1개 있어야 시스템이 정상동작한다. 즉, majority 여기서는 절반 이상을 가지면 된다. 그러나 이 기준은 Byzantine에서는 safety violation 이 발생한다. (remind: safety는 동기화를 유지하는 것. 분기가 일어나면 안된다.)

PBFT – Practical Byzantine Fault Tolerance (1999년 카스트로와 리스코브가 제안함) 산업 시스템에서 사용가능한 비잔틴 장애허용의 실현가능성에 대한 새로운 전례를 만들어냄 – 초당 수만 거래를 처리할 수 있음! (1/3 이상이 비잔틴이라 하면 safety를 보장하지 않는다.)

장애 허용 fault tolerance는 결국 프로세스들이 어떻게 동작할지 알지 못하는 신뢰의 부족에서 발생한다. 신뢰 – 이론적으로는 세상의 한 모델의 “엔트로피 entropy”를 줄이는 방법. 누군가를 믿는다는 것은 세상에 대한 불확실성을 낙관적으로 줄이고, 조직의 고차원적인 형태에 좀더 집중화할 수 있게 되는 것임. [엔트로피가 높다는 것은 한 상태에서 다른 상태로 변화할 가능성이 높다는 이야기임]

암호학적 접근법이 근본적으로 신뢰의 문제와 연관되며, 엔트로피에서 엄청난 감소를 허용하는 메카니즘이라 할 수 있다.. 암호학 함수를 성공적으로 증명하는 것은 가능한 출력값들의 분포를 출력값의 하나로 모을 수 있다.. [TBA – 암호학을 사용하면 엔트로피를 감소시킬 수 있다는 이야기인데 논리적으로 다시 정리할 필요!]

법, 규칙 등과 같은 조직적인 신뢰의 더 위대한 형태를 가지는 문명화의 경우 높은 생산성 및 더 활발한 경제를 갖는다. 신뢰할 수록 조직화하기가 쉽다. 다만 기관들의 복잡도가 최근들어 엄청나게 증가하면서 “신뢰도 trustworthiness”를 평가하기가 쉽지 않다. “암호화”가 새로운 기관들에 대해 신뢰를 위한 기반을 형성할 수 있는데 이는 믿지 못하는 행위들에 대한 위험을 감소시킴으로써 글로벌 영역으로 사람들을 조직화 할 수 있는 능력을 엄청나게 향상시킬 수 있다. BFT 알고리즘에서도 암호화 접근법의 중요도가 높아지는데 인증뿐만 아니라 비결정적 seeding에 대해서도 그러하다.

경제적인 메커니즘 또한 엔트로피를 감소시키는 방법으로 활용된다. 경제적 에이전트가 특정 행위를 실행함으로써 보상을 받는다면 (incentivized). 비트코인의 경우에도 상태의 안전한 복제를 이루기 위해 공적인 합의 네트워크의 엔트로피를 충분히 감소시키기 위해 암호화 접근법과 함께 경제적 인센티브를 제공한다.

블록체인은 비잔틴 장애 허용 원자 브로드캐스팅 (Byzantine Fault Tolerant Atomic Broadcast)관련 문제를 해결하기 위해 무결성 integrity 기반의 접근법이다. [무결성이라 함은 위변조 방지 보장]
비트코인 블록체인의 경우 경제적/암호학적 임의화 randomization의 조합을 이용해서 Safety 가 violated되지 않는다는 것은 아주 높은 확률로 보장한다. (약한 동기화 weak synchrony를 가정하는데 블록들이 부분 해쉬 충돌 Lottery를 통해 찾아지는 것보다 훨씬 빨리 퍼질 것이라는 가정함 [TBA-이게 왜 weak인가? 약한 동기화란 일종의 경계 범위를 두고 그 안에는 동기화가 이뤄진다는 가정을 함] , 참고 http://akdntmwhr.tistory.com/entry/3-Models-of-Communication)

ABC를 해결하는 데 있어서 채용한 두 개의 최적화로부터 블록체인이란 이름을 얻게됨..
– 많은 거래에서 높은 커밋 지연 (commit latency)를 ‘분할 상환’하기 위해 블록안에 거래들을 그룹화짓는다. [여기서 분할 상환이라 함은 시스템을 위해 개별 거래들의 처리가 지연시키나 전체적인 시스템 성능으로는 향상. 지연 상황을 분할해서 개별 거래들이 부담한다는 의미]
– 블록들을 암호학 기반의 해쉬를 통해 비가역적 체인 immutable chain에 연결한다. 해쉬 체인이기에 예전 기록들을 검증하는 것이 쉽다.. [TBA – 허용치 tolerance 향상의 의미 파악]

블록체인을 “해쉬가 연결된 거래 뭉치들”이라고 일반적으로 여겨진다.
텐더민트가 80년대부터 잘알려진 BFT 알고리즘을 한단계 향상시키는 첫 제안임. 그리고 IBM이 PBFT를 업그레이드 해서 블록체인에 적용하고, JP 모건이 Raft의 BFT 버전을 업그레이드 함.

구체적인 알고리즘은 레퍼런스 참고
텐더민트의 BFT 알고리즘의 원래 버전 : groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf
IBM의 PBFT 알고리즘 관련 : https://www.zurich.ibm.com/~cca/papers/sieve.pdf
IBM의 Open BlockChain : https://github.com/openblockchain/obc-peer
JP 모건의 Raft의 BFT 버전 : https://github.com/buckie/juno

분산시스템은 각자 동시에 병핵적 수행하므로 디자인, 구현 그리고 디버깅등이 매우 어렵다. 이에 반해 컴퓨터 과학의 기본이 일반적으로 ‘순차적’ 기반이라 쉬움.

Process Calculi는 병행 계산 (concurrent computation)를 위한 기반을 제공하고자 하는 모델의 일종이다. [TBA – 이런 언어 디자인 설계 핵심 파악 필요!!]
: CSP – Communicating Sequential Process = Go언어와 같은 현대 프로그래밍 언어의 이론적인 배경을 형성하는 가장 인기있는 calculus, 이는 병행 원칙 concurrency primitive이 언어 디자인에 포함되어있다. [즉 golang은 병렬을 ‘기본 동작’이라는 관점하에 설계된 언어]

CCS : Calculus of Communicating System <- Functional Programming Language

pi-calculus로 텐더민트의 알고리즘을 정의함 [TBA – pi-calculus 를 재파악 필요]

안전하고 secure, 자치적이며 autonomous, 분산 distributed, 장애 허용 fault-tolerant 기반의 실행함. BBPB (Big Bad Public Blockchains) – 공개 블록체인. 해당 프로토콜은 내장된 자체 가상 통화의 경제적 인센티브에 기반한다. Consortia Blockchain – 컨소시엄/비공개 블록체인. 해쉬 트리, 디지털 서명, P2P 네트워킹 및 강화된 책임 accountability를 사용하여 기본 합의 알고리즘과 BFT 알고리즘의 향상 [TBA – 공개 블록체인과는 달리 비공개 블록체인은 BFT 합의를 통한다?!. 또한 공개 블록체인처럼 가상화폐 보상 등의 인센티브는 필요없다?!]

텐터민트는 컨소시엄 블록체인으로 최적화됨. 내부 조직적 로직 (inter-organizational logic). 개인 회사부터 글로벌 화폐까지 누구든 활용 가능할 정도로 유연함. 현재 etcd,consul,zookeeper 같은 주요, non-BFT, 합의 솔루션과 비교해도 고성능임. 앱 개발자들에게 회복력, 안전 보장, 유연함을 제공함!

텐터민트 – 블록체인 패러다임에서 안전한 상태 기기 복제 알고리즘. 만약 Safety가 훼손되었을 때 누가 악의적으로 행동했는지 검증하는 것이 “항상 가능”할 정도의 설명할 수 있는 BFT-ABC 의 형태를 제공함. (Atomic BroadCast)

검증자 validator (public key로 신원 확인함) 개념
– 복제된 상태의 전체 카피본을 유지하는 책임을 지님.
– 새로운 블록 (거래들의 뭉치)을 제안 proposal.
– 전달된 블록에 대해 투표처리 vote.
블록 block
– 증가하는 index ( 블록 높이 height 라고도 불림) – 각 높이마다 유효한 하나의 블록만이 존재
– 라운드를 돌면서 각 height 마다 검증자는 차례대로 새로운 블록을 제시함. (즉 각 라운드 마다 최대 하나의 유효한 제안자 proposer 존재.)
– 네트워크의 비동기 때문에 특정 height에서 블록을 commit하는 것은 여러 라운드를 거칠 수 도 있음
– 1/3 이상의 검증자가 오프라인이거나 분할 partitioned 되었다면 네트워크가 정지 [합의 진행 불가]
– 검증자는 제안된 블록이 commit 하기까지 두단계의 투표 voting을 거침 [pre-vote / pre-commit]
– 간단한 잠금 메카니즘 Locking Mechanism : safety (동기화)를 절충함에 있어서 1/3 이하의 검증자가 악의적인 공동체를 방지하는 것. [1/3 이상이 비잔틴이라면 시스템의 safety는 무너진다.]

각 블록은 헤더 header라 알려진 메타데이터를 포함한다. 헤더에는 이전 블록 높이의 블록 해쉬를 포함하기에 해쉬 체인 chain이 되는 것이다. 또한 블록 높이, 블록이 제안된 로컬 시간, 블록안에 포함된 거래들의 머클 루트 해쉬 merkle root hash등이 헤더에 포함된다.

 

텐더민트의 합의 알고리즘 중요 개념 – Proposal / Vote / Locking
– 제안 : 각 라운드 마다 새로운 블록 제안.. 다른 검증자들에게 gossip으로 전달. 충분한 시간동안 제안이 도착하지 않으면 그 라운드의 제안자 proposer는 스킵 [TBA-제안자 결정 순서은 deterministic?! – 이미 제네시스 블록에 기술되어 있음]
– 투표 : 최적의 비잔틴 장애 허용 (byzantine fault tolerance)를 확보하기 위해 두 단계의 투표를 진행한다.. Pre-vote -> Pre-commit 각 단계마다 2/3 이상 검증자의 디지털 서명이 있어야 한다.
– 잠금 : 1/3 이하의 검증자가 악의적이다는 가정하에 두 검증자가 동일한 높이 때 서로 다른 블록을 commit하지 않도록 보장한다. 같은 높이의 이전 pre-votes와 pre-commit 에 따라서 검증자가 pre-vote / pre-commit 하는지가 결정되는 Locking Mechanism 이다.. Liveness를 절충하지 않도록 주의깊게 디자인 되어야함. [즉, 특정 블록높이에서 한 검증자는 하나 이상의 블록에 대해 투표하지 않아야 한다.]

최소 4개의 검증자가 유지되어야 함. (하나의 Byzantine Fault를 허용하기 위해)
각 검증자 validator는 디지털 서명을 생성하기 위해 비대칭 암호학적 Key-Pair 를 보유한다. 검증자들은 검증자들의 순서 리스트 ordered list를 가지고 공통 초기 상태부터 시작한다. 각 검증자들은 공개키로 신원확인이 가능하고 모든 제안이나 투표는 비밀키로 디지털 서명해서 내보낸다. (그래서 제안과 투표들은 어떤 관찰자 (Observer)를 통해서 검증이 가능하도록 한다.) 1/3 까지의 검증자들이 악의적이라면 시스템의 safety나 liveness를 전복시킬수 있다.

[특정 블록높이에서 여러 라운드로 합의를 이룬다.] 라운드 round의 출력(outcome)은 commit이거나 아님 다음 라운드로 이동을 결정, 이 두가지이다. 다수의 라운드를 사용하는 것은 네트워크의 비동기 또는 검증자의 실패등의 사건이 있음에도 합의에 이를 수 있다는 다수의 기회가 검증자들에게 주어진다.

리더 선정 같은 형태를 요구하는 알고리즘과는 달리 각 라운드마다 새로운 리더(Proposer)를 가진다. 제안을 accept하기위해 투표하는 것 처럼 다음 라운드로 skip하는 투표를 한다. (둘 다 uniformity 동일한 형식을 취하는데.. 이는 명확한 리더 선정 프로그램이 없이도 프로토콜이 동작하기 위해서임.) [투표는 prevote, precommit 그리고 skip하고자 한다면 nil 전달, nil의 경우 시간 내에 정보가 도달 안했을 경우 발생시킴]

각 라운드의 시작은 검증자들이 Proposer를 생략함을 결정하기 위해 지역 시간 local time을 사용하므로 동기화에 대해서는 의존성이 거의 없게 동작한다. (weak dependence). 지역 시간 기반으로 안에 제안이 도착하지 않으면 새로운 라운드로 이동. (의 경우 자체적으로 증가할 수도 있다.) [TBA – 동기화 없이 노드의 지역시간에 기반하므로 발생하는 문제는 없는가 파악.] 제안 후에는 전적으로 비동기 방식으로 라운드가 진행된다. 검증자는 다른 검증자들의 적어도 2/3로부터 의견을 들은 후에 처리한다. (합의의 각 단계 prevote-precommit-commit) 동기화된 시각이나 경계가 있는 네트워크 지연 등에 의존하지는 않으나 1/3 이상의 검증자가 응답이 없는 상태에 빠지면 시스템은 멈추게 된다.

잠금 규칙 : 검증자들이 그들의 투표에 대해 타당함을 보여줄 수 있게 해줌. 실시간으로 해당 타당성을 전달하지는 않아도 관련 데이터를 유지하고 있고. safety가 절충될 때 증거로써 불려지게 한다. [특정 블록높이의 합의가 완료될 때까지 하나 이상의 의견을 표현하지 않음을 보장하는 규칙] PBFT 보다 실패를 마주했을 때 더 강력한 보장을 제공할 수 있게 함.. (PBFT의 경우 2/3 이상의 검증자가 Byzantine일 경우는 어떠한 보장도 할 수 없다.) [TBA – PBFT보다 강력한 이유 분석 필요]

검증자들은 블록체인, App 상태, 피어 네트워크 그리고 합의를 관리하기 위해 다양한 메시지를 사용하여 소통한다. 핵심 합의 알고리즘은 검증자 간의 두가지 메시지를 활용한다.
– ProposalMsg : 특정 블록 높이 및 라운드에 블록을 제안하고 이는 제안자가 디지털 서명한다.
– VoteMsg : 제안에 대한 디지털 서명된 투표

Mempool (일종의 지역 캐쉬)에 저장된 받은 거래들 중 뭉치를 블록으로 만들어서 ProposalMsg 메시지로 디지털 서명해서 브로드캐스팅한다. 만약 제안자가 Byzantine이라면, 다른 검증자들에게 다른 제안을 브로드캐스팅할 것이다. 간단하고도 결정적 라운드 로빈을 통해 순서지어지며 모든 검증자들은 누가 “제안자”인지 알고 있다. 제안 proposal이 현재보다 더 낮은 라운드 관련이거나 옳지 않은 검증자에게 받았다면 거절된다.

제안자들의 순환은 비잔틴 장애 허용에 필수적이다. (Raft에서는 선택된 리더가 비잔틴이고 다른 노드들로 네트워크 연결이 연결되어있다면 모든 safety와 liveness 보장을 파괴하면서 시스템을 완벽히 위태롭게 한다. 텐더민트의 경우, 투표와 잠금 메카니즘을 통해 Safety를 보장하고, 제안자를 순환함으로써 Liveness를 유지할 수 있다. (그래서 누군가 거래를 처리하지 않으면 다른 이들이 알아챈다.) 검증자들은 비잔틴 검증자들을 제거하거나 대체하기 위해 관리 모듈 (governance module)을 통해 투표한다. [TBA – 관리 모듈 동작방식 파악 ex. 실시간으로 검증자 리스트를 갱신하는 것인지]

검증자가 완전한 제안를 받으면 pre-vote를 디지털 서명하고 이를 네트워크 통해 브로드캐스팅한다. ProposalTimeout안에 제안을 받지 못하면 nil을 pre-vote한다. 비잔틴 검증자들과 비동기 환경에서 각 검증자들이 하나의 투표권을 가지는 상황에서 각 투표단계에서 safety를 보장하기 충분치 않다.. 검증자들이 악의적으로 행동할 수 있고, 메시지 전달 타임에 대해 보장이 없기 때문에, 악의적인 검증자들은 다른 검증자들을 조직하여 특정 값을 commit할 수 있고, 해당 commit을 보지 못한 다른 검증자들은 새로운 라운드로 가고 다른 값을 commit한다?! [TBA – 즉 라운드마다 투표권을 한번 가지고 있으면.. safety를 보장하기 힘들다.. – 두 단계 pre-vote / pre-commit 을 가지는 이유인듯 한데 파악!]

투표의 단일 단계에서 검증자들은 제안에 대해 아는 것을 서로 이야기 함. 비잔틴 장애를 허용하기 위해서는 다른 검증자들이 해당 제안에 대해서 안다고 주장한 바에 대해 어떤 것을 인지하고 있는지 서로에게 말해야 한다. 즉, 두번째 pre-commit 단계에서는 충분한 검증자가 첫번째 pre-vote단계의 결과를 목격함을 보장한다.

블록에 대한 pre-vote는 해당 블록을 commit할 수 있게 네트워크를 준비시키는 역할임. nil에 대한 pre-vote는 네트워크에게 다음 라운드로 이동시키도록 준비시킨다. 2/3 이상의 검증자가 해당 제안에 대해서 pre-vote를 하고, 단일 블록에 대해 2/3이상의 pre-vote 를 “polka“라고 함.. nil을 2/3이상의 검증자가 받았다면 이를 “nil-polka“라고 함. [nil-polka의 의미는 지금 네트워크가 특정 블록을 합의할 준비가 되지 않았다.] 검증자가 polka를 받으면, 이는 네트워크가 해당 블록을 commit하기 위해 준비되었다는 신호이며, 해당 검증자가 해당 블록에 대해 pre-commit 투표를 디지털 서명하고 브로드캐스팅할지 여부에 대한 판단으로 작용한다. 네트워크의 비동기 때문에 polka를 받지 못했을 때 해당 검증자는 nil에 대해 pre-commit을 디지털 서명 및 발행한다. polka로부터 판단없이 pre-commit에 디지털 서명하는 것은 악의적인 행위로 판단한다.

pre-commit은 실제로 블록을 commit하기 위한 투표이다. nil에 대한 pre-commit은 다음 라운드로 넘어가자는 것이고, 검증자는 단일 블록에 대해 2/3 이상의 pre-commit을 수신하였을 경우, 해당 블록을 commit하고 최종 상태를 계산하며. 다음 블록 높이의 라운드 zero으 이동한다.. 검증자가 2/3 이상의 nil에 대한 pre-commit을 받으면 다음 라운드로 이동.

동일한 블록높이에서 다른 라운드에서 두가지 다른 블록을 commit 했다는 상황을 피해야 safety 보장이 된다. 텐더민트에서는 “Locking 메카니즘“으로 해결하고자 함.. polka가 그 핵심?! (2/3이상의 pre-vote) polka로 pre-commit이 정당화 되고, 검증자는 마지막으로 pre-commit한 블록에 잠긴다. Lock! [다시 한번 강조 – polka가 precommit을 정당화 한다.]

Locking Mechanism 잠금 규칙 2가지 : Prevote-the-Lock / Unlock-on-Polka

– Prevote-the-Lock : 검증자는 잠겨져 있는 블록에 대해 무조건 pre-vote해야하며 제안자라면 제안해야한다. 이는 검증자들이 첫번째 라운드에서는 한 블록에 대해 pre-commit하고 다음 라운드에서 다른 블록의 polka에 기여하는 것을 방지하고자.. 이는 safety 문제와도 직결된다.

– Unlock-on-Polka : 검증자는 락걸린 라운드보다 더 높은 라운드에서 polka를 받았을 경우에만 락을 해제한다.. 이는 검증자들이 네트워크의 나머지가 commit 하기 원하지 않는 어떤 것을 pre-commit했기에 락을 해제하도록 된다. 이는 Liveness를 보호하게 된다.[즉, 시스템이 멈추는 것을 방지함] 검증자가 락걸린 후의 라운드에서 polka가 있을 경우만 언락된다. [즉 동기화의 조건이 되었기에] 이것이 safety를 보장한다?! 간단하게 설명해서, 검증자들은 매 블록높이마다 라운드-1에 nil에 락되어있다고 가정하면 된다. Unlock-on-Polka는 polka를 보기 전까지 새로운 블록 높이에서 pre-commit을 하지 못한다는의미!! Prevote-the-Lock 만으로는 충분치 않다. Liveness를 침해당할 수 있다.