Istanbul Byzantine Fault Tolerance(=IBFT)에서는 3단계로 합의과정이 이루어져있다.
- Pre-Prepare
- Prepare
- Commit
시스템은 잘못된 노드(나쁜 노드)가 F라고 가정했을때 총 노드수가 3F+1이상이면 돌아갈 수 있다.
- N = 3F +1 ( N= node, F = faulty node)
합의를 이끌어내는 이들을 검증자 (Validators)라고 하며 검증자들은 블록을 생성하기전(매 라운드 전)에 proposer를 뽑는다. 그럼 이제부터 합의과정이 시작되는데,
첫째, proposer 는 새로운 블록을 선택하고 제안하며 이것을 pre-prepare 메세지와 함께 공표한다.
둘째, 검증자들은 proposer로부터 pre-prepare 메세지를 받으면 pre-prepare 상태로 돌입하며 prepare 메세지를 보낸다. 이과정은 모든 검증자들이 같은 라운드, 같은 순서에 있는지 확인하기 위함이다.
셋째, 2F+1 의 prepare 메세지를 받으면 검증자들은 prepare 상태로 돌입하며 commit 메세지를 보낸다.
이 과정은 제안된 블록이 수락되었다는것은 피어들에게 알리는 역할을 하며 수락된 블록을 체인에 연결시킨다. 2F+1 의 commit 메세지를 받으면 commit 상태로 돌입하며 그 블록은 체인에 연결된다.
전제 알고리즘은 그림과 같고 합의가 실패한경우 Round change로 돌아가 다시 라운드를 시작한다.
합의과정은 3단계로 이루어져있으며 IBFT에서 블록은 Finality를 의미한다. 즉, 포크가 불가능하며 유효한 블록은 무조건 메인체인에 존재한다. 잘못된 (나쁜) 노드에 의해 잘못된 체인이 생성되는것을 방지하기위해 블록을 체인에 연결하기전 검증자들은 commit 서명(2F+1)을 헤더안의 extra data에 첨부한다. 그러므로, 블록들은 스스로 검증가능하며 라이트 클라이언트로 지원가능하다.
하지만 Dynamic extra data는 블록 해쉬계산에 문제를 일으킬 수 있다. 같은 블록이여도 검증자마다 다른 commit 서명을 가질 수 있으므로 블록해쉬도 다르게 가질 수 있기때문이다. 이를 해결하기 위해서 IBFT에선 commit 서명을 제외한채 블록해쉬를 계산한다. 그러면 블록헤더에 Consensus proof 도 넣을 수 있을뿐만 아니라 블록/블록해쉬의 일관성도 유지할 수 있다.
참조 : https://github.com/ethereum/EIPs/issues/650
https://www.slideshare.net/YuTeLin1/istanbul-bft