Istanbul Byzantine Fault Tolerance/이스탄불 비잔티움 장애 허용
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
제목에 '비잔티움 장애 허용'이라 적었는데 이는 한국 위키에 기반한 제목이며 '비잔티움 내결함성'이 더 적절한 제목 같습니다.
Prepare과정에서 2F+1은 말그대로 잘못된노드를 제외한 나머지 노드를 말하는건가요?
Faulty node * 2 + 1 이면 가능합니다. Faulty node가 최대치면 67%이여야하고 최대치가 아니라면 그 아래로도 합의가 가능한것으로 이해하고있습니다.
그럼 저위 그림에 설명은 validator들은 전부 선의의 노드겠죠? 그리고 proposer 를 매 블록 생성전에 뽑는다고 하는데 이건 어떤식으로 뽑는건가요
네 맞습니다. proposer는 라운드 로빈방식으로 자동적으로 뽑혀집니다.
그럼 F중 하나가 proposer로 뽑히면 pre-prepare과정에서 라운드체인지로 돌아가나요?
궁금한게 많은데 계속 여쭤보기 뭐해서 마지막으로 여쭤봅니다..ㅎㅎ
네 맞습니다. invalid proposal 로 라운드 체인지로 돌아갑니다. 계속 질문하셔도 괜찮습니다. 아는 범위내라면 .. ㅎㅎ
Primary가 존재하는 PBFT 계열과 비슷하지만, 리더가 없다는 점이 큰 차이를 보이는 것 같습니다.
현재 IBFT기반 블록체인 사례가 있을까요?
좋은 정보 감사드립니다. :)
PBFT도 곧 한번 정리하려는데 피드백좀 부탁드립니다. ㅎㅎ Quorum이 IBFT 기반입니다. 아직 메인넷은 없는것 같구요. 읽어주셔서 감사합니다.