Download as PDF, PPTX
![JEONBUK
NATIONAL UNIVERSITY
Consensus Protocols of Hyperledger Besu 15Jeongwhan Choi
[1] 클라이언트가 상태 변환을 요청하는 request 메시지를 Primary Node에 전송
[2] Primary가 request 요청을 받으면 먼저 pre-prepare라는 절차를 시행
[3] 네트워크 내 임의의 Backup 노드 i가 pre-prepare 메시지를 받고 검증
검증 결과가 참: prepare 메시지를 생성해 네트워크의 나머지 모든 노드에게 전송
검증 결과가 거짓: pre-prepare 메시지를 수용하지 않음
PBFT - 합의 단계
1.Introduction 2.PBFT 3.IBFT 4.Clique](https://image.slidesharecdn.com/20200213-ibftclique-200421063319/75/Consensus-Protocols-of-Hyperledger-Besu-IBFT2-0-Clique-15-2048.jpg)
![JEONBUK
NATIONAL UNIVERSITY
Consensus Protocols of Hyperledger Besu 16Jeongwhan Choi
[4] 각각의 노드는 pre-prepare 메시지와 prepare 메시지를 수집
pre-prepare 메시지: 2f+1개 이상
prepare 메시지: 2f개 이상
[5] "prepared certificate" 조건을 만족한 노드: 모든 노드에게 commit 메시지 전송
[6] 각각의 노드는 commit 메시지를 수집
commit 메시지: 2f+1개 à 해당 노드는 "commit certificate"상태
PBFT - 합의 단계
"prepared certificate"
해당 노드: "prepared the request" 상태
1.Introduction 2.PBFT 3.IBFT 4.Clique](https://image.slidesharecdn.com/20200213-ibftclique-200421063319/75/Consensus-Protocols-of-Hyperledger-Besu-IBFT2-0-Clique-16-2048.jpg)
More Related Content
Similar to Consensus Protocols of Hyperledger Besu: IBFT2.0 & Clique
![[ETHCon Korea 2019] Park joohyung 박주형](https://cdn.slidesharecdn.com/ss_thumbnails/parkjoohyung-190602051906-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Yonsei AI Workshop 2022] Graph Neural Controlled Differential Equations for ...](https://cdn.slidesharecdn.com/ss_thumbnails/dhcx9l1rc2acdkwbnqyx-aaai22-workshop-221019003243-979010ab-thumbnail.jpg?width=640&height=640&fit=bounds)
![[KAIA2021] Graph-based Collaborative Filtering and Neural ODEs](https://cdn.slidesharecdn.com/ss_thumbnails/a7js83agtzaovjxyprgq-kaia2021tutorial-lt-ocf-221019003243-c00be3eb-thumbnail.jpg?width=640&height=640&fit=bounds)
Consensus Protocols of Hyperledger Besu: IBFT2.0 & Clique
- 1. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu Consensus Protocols of Hyperledger Besu 2020. 02. 13. Jeongwhan Choi 1Jeongwhan Choi IBFT2.0 & Clique
- 2. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 2 Hyperledger Besu Architecture • Hyperledger Besu: • 다양한 consensus algorithm을 구현 Jeongwhan Choi The high-level architecture of Hyperledger Besu is: https://besu.hyperledger.org/en/stable/Concepts/ArchitectureOverview/ consortium network 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 3. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 3 Contents • PBFT • IBFT • Clique Jeongwhan Choi 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 4. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 4 Problem - PoW • Non-finality: • Confirmations are required. • Fork is possible. • Low throughput: • Long block time Low transaction per second (TPS) • Ethash (Ghost) can only support 3~15 seconds per block. • Lack of governance: • Too open: every node can be miner. • Extra effort are required for blockchain management. • High power consumption. • Miners are competing on block generation. Jeongwhan Choi 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 5. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 5 Consortium Chain + PBFT • Pros: • Instant finality: No confirmation required. • High throughput: No extra waiting time is necessary (v.s. ethash). • Low power consumption. • Node scalability. (should be the same as ethash) • Governance: Manageable validator set. • Academic proof. • Cons: • Validator scalability: 20 ~ 30 nodes. (generally not an issue in consortium chain) Jeongwhan Choi 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 6. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu PBFT (Practical Byzantine Fault Tolerance) 6Jeongwhan Choi 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 7. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 7 PBFT • Byzantine General Problem를 해결하는 방안 • 비동기 네트워크 내에서는 Safety와 Liveness를 모두 완벽히 만족하는 합의 알고리즘을 설계하는 것이 불가능 • Blockchain: 비동기 네트워크 • à 비동기 네트워크에서 완벽한 합의 알고리즘은 존재하지 않음 Jeongwhan Choi “네트워크 내에 배신자가 있더라도 합의 내용에 문제가 없으려면 어떻게 해야 하는가 “ 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 8. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 8 PBFT • PBFT(Practical Byzantine Fault Tolerance) • Safety를 확보하고 Liveness를 일부 희생 • 비동기 네트워크에서도 합의를 이룰 수 있는 알고리즘 • 비동기 네트워크에서 Byzantine node가 f 개 있을 때, • 총 노드 개수가 3f+1개 이상 à 해당 네트워크에서 이루어지는 합의는 신뢰할 수 있다는 것을 수학적으로 증명한 알고리즘 • e.g. 4개의 노드에서는 1개는 Byzantine node라도 상관없다는 의미 • 네트워크의 모든 노드는 거래와 같은 합의 대상의 상태를 변화할 것인지 여러 단계를 거쳐 결정 Jeongwhan Choi 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 9. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 9 PBFT – 합의 단계 Jeongwhan Choi 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 10. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 10 PBFT - 합의 단계 Jeongwhan Choi • Client는 상태변경을 위한 Request 요청을 Primary 노드에 전송 • 참고로 이 대표노드(Primary) 또한 Byzantine이 될 수 있음 • Byzantine일 때, 새로운 대표노드를 선출하게 됨 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 11. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 11 PBFT - 합의 단계 Jeongwhan Choi • Primary 노드는 다른 모든 노드들에게 Pre-Prepare 메세지를 전파 • 이 상태에서는 최신상태를 일단 가지지만, 옳은 것인지는 판단 할 수 없음 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 12. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 12 PBFT - 합의 단계 Jeongwhan Choi • 자신이 받은 최신 상태정보를 기반으로 Prepare 메세지를 모든 노드들에게 전파 • 여기서 다른 노드들의 Prepare 메세지 2f개 이상 받으면, Prepared 상태 • 자기 자신 제외하고 3개중에 2개의 메시지만 받으면 됨 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 13. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 13Jeongwhan Choi • Prepare 메세지 2f를 받으면, Commit 메세지를 전파 • 다른 노드들로 부터 Commit 메세지를 받아서 자기포함 2f+1개를 받으면 커밋함 PBFT - 합의 단계 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 14. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 14Jeongwhan Choi • Commit 검증에 성공한 노드들은 Client에게 Reply을 보냄 • f+1개 이상의 똑같은 응답을 받으면 Client 는 보낸 메세지가 성공적으로 분산노드들의 상태를 변경을 했다는 것을 인지 PBFT - 합의 단계 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 15. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 15Jeongwhan Choi [1] 클라이언트가 상태 변환을 요청하는 request 메시지를 Primary Node에 전송 [2] Primary가 request 요청을 받으면 먼저 pre-prepare라는 절차를 시행 [3] 네트워크 내 임의의 Backup 노드 i가 pre-prepare 메시지를 받고 검증 검증 결과가 참: prepare 메시지를 생성해 네트워크의 나머지 모든 노드에게 전송 검증 결과가 거짓: pre-prepare 메시지를 수용하지 않음 PBFT - 합의 단계 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 16. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 16Jeongwhan Choi [4] 각각의 노드는 pre-prepare 메시지와 prepare 메시지를 수집 pre-prepare 메시지: 2f+1개 이상 prepare 메시지: 2f개 이상 [5] "prepared certificate" 조건을 만족한 노드: 모든 노드에게 commit 메시지 전송 [6] 각각의 노드는 commit 메시지를 수집 commit 메시지: 2f+1개 à 해당 노드는 "commit certificate"상태 PBFT - 합의 단계 "prepared certificate" 해당 노드: "prepared the request" 상태 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 17. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 17Jeongwhan Choi PBFT - 합의 단계 “prepared certificate” 해당 노드: ”committed certificate” “commit certificate” Client가 요청한 request를 수용해 상태변화 함수 수행 합의 도출 Safety 충족 Liveness 일부 희생request 기각합의 요건 불충족 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 18. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu IBFT (Istanbul BFT) Jeongwhan Choi 18 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 19. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 19 IBFT • Istanbul Byzantine Fault Tolerance • BFT 계열 합의 • PBFT의 형식을 따라가며 블록을 모아서 전송한다는 개념이 추가 • Immediate Finality 보장 • Transaction이 추가된 block에 포함되면 항상 blockchain의 일부임을 보장 • Fork 또는 Chain 재구성이 없음 Jeongwhan Choi 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 20. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 20 IBFT Jeongwhan Choi • 주요 차이점 • 요청을 보내고 결과를 기다리는 특정 ”client”가 없음 (모든 validator를 client로 간주) • 각 round에서 지속적으로 proposer가 선정 • 합의 노드들은 서로의 존재에 대해 알고 있음 (Public key 공유) • 각 합의 결과에 대해 file system에 대한 read/write op이 아니라 검증 가능한 새로운 block을 생성 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 21. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 21 IBFT • 3단계로 합의 과정 • Pre-Prepare: Proposer proposes a block • Prepare: Validators agree on block • Commit: Validators agree on commit • 시스템은 총 노드수가 3F+1이상이면 돌아갈 수 있음 • N = 3F +1 ( N= node, F = faulty node) • Validator: 합의를 이끌어내는 노드 • Validator들은 블록을 생성하기전(매 round 전)에 proposer를 선정 Jeongwhan Choi 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 22. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 22 IBFT – 합의 과정 Jeongwhan Choi 1. 매 순간 마다 Proposer가 결정되면, Proposer가 트랜잭션들을 담아서 block을 생성 2. block 을 다른 노드들(validator)에게 전파 3. block 을 받은 노드들은, 해당 block 을 받았음을 확인 • 확인 메세지를 나머지 노드들에게 전파 4. 전파받은 block 을 검증 • 검증하면서 서로 메세지를 주고 받는데요, 이때 2/3이상이 합의한다면, 이 블록은 제대로된 블록으로 인정받아, 체인에 연결 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 23. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 23Jeongwhan Choi Propose 단계 proposer 는 새로운 블록을 선택하고 제안 Proposer proposes a block IBFT – 합의 과정 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 24. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 24Jeongwhan Choi Pre-prepare 단계 제안된 block을 pre-prepare 메세지와 함께 공표 Pre-prepare message IBFT – 합의 과정 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 25. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 25Jeongwhan Choi Prepare 단계 Validator들은 proposer로부터 pre-prepare 메세지를 받으면 pre-prepare 상태로 돌입하며 prepare 메세지를 보낸다. 이 과정은 모든 Validator 들이 같은 Round, 같은 순서에 있는지 확인하기 위함 Prepare message IBFT – 합의 과정 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 26. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 26Jeongwhan Choi Prepare 단계 2F+1 의 prepare 메세지를 받으면 검증자들은 prepare 상태로 돌입 Prepared when i receives 2f prepares that match pre-prepares. IBFT – 합의 과정 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 27. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 27Jeongwhan Choi Commit 단계 prepare 상태로 돌입하고 commit 메세지를 보냄 Commit message IBFT – 합의 과정 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 28. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 28Jeongwhan Choi Committed 단계 이 과정은 제안된 block이 수락되었다는것을 peer들에게 알리는 역할 수락된 block을 체인에 연결 2F+1 의 commit 메세지를 받으면 commit 상태로 돌입 블록은 체인에 연결 Committed If prepare(i) and received 2f+1 commits IBFT – 합의 과정 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 29. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 29 State Machine Jeongwhan Choi 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 30. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 30 State Machine – Round Change Jeongwhan Choi 합의가 실패한 경우 Round change로 돌아가 다시 round 시작 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 31. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 31 State Machine – Round Change Jeongwhan Choi 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 32. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 32 IBFT 1.0 to 2.0 Jeongwhan Choi • Blockchain의 동일한 height에서 commit된 다른 block을 가질 수 있음 • e.g. IBFT 1.0에서 5 validators가 있으면 다음 block 을 Blockchain에 추가하기 위해 3 개의 node만 동의하면 됨 IBFT 1.0에서 proposer가 Byzantine 인 경우: à 두 집합의 validator와 합의하는 특정 상황이 있음 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 33. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 33 IBFT 1.0 to 2.0 Jeongwhan Choi • super-majority modification: 합의에 도달하는 데 필요한 node 수를 변경 • e.g. 5 validators를 사용하면 IBFT 2.0에서는 block을 blockchain에 추가하기 위해 block 에 대해 합의에 도달하려면 4 validator가 필요 • round change modification: IBFT 1.0의 liveness 문제를 해결 • IBFT 1.0: round change은 항상 새로운 block propose를 초래 • IBFT 2.0: validator가 round에서 commit하는 경우 연속 round에서 propose된 block이 commit 된 block과 일치하도록 함 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 34. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu Clique Jeongwhan Choi 34 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 35. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 35 Clique • Clique는 Geth에서 구현된 PoA(Proof of Authority) • Rinkeby testnet에서 사용 • Fault Tolerance: Validator의 최대 절반 • Transaction 및 block은 승인된 계정(signer)에 의해 검증 • signer는 차례대로 다음 블록을 생성 • 기존 signers 는 signer를 추가하거나 제거하기 위해 제안하고 투표 • Immediate Finality 제공하지 않음 (Fork 가능) Jeongwhan Choi 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 36. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 36 Clique Jeongwhan Choi • 둘 다 현재 리더가 새 block을 제안한 첫 번째 Round를 가짐 (Block Proposal) • Clique는 그렇지 않지만 Aura는 추가 라운드 (Block Acceptance)가 필요 • Clique는 각 단계에서 leader는 block과 모든 authorities들을 직접 chain에 commit 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 37. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 37 Clique Jeongwhan Choi • 둘 다 현재 리더가 새 block을 제안한 첫 번째 Round를 가짐 (Block Proposal) • Clique는 그렇지 않지만 IBFT는 추가적인 단계 필요 (Pre-Prepare…) • Clique는 각 단계에서 leader는 block과 모든 authorities들을 직접 chain에 commit IBFT 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 38. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 38 Clique Jeongwhan Choi • 알고리즘은 미리 정해진 commit된 block 시퀀스에 의해 식별되는 epoch로 진행 • 새로운 epoch가 시작되면 특별한 transition block이 전파 • authority set를 지정하고 동기화해야하는 새로운 authority에 의해 현재 블록 체인의 스냅 샷으로 사용될 수 있음 • Block을 propose 할 수 있는 authorities: 최대 N-(N / 2 + 1) • N-(N/2+1)=3 authorities들이 각 step마다 block 제안 허용 • 그 중 하나는 leader 역할 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 39. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 39 Clique Jeongwhan Choi • 각 단계에서 더 많은 authorities가 블록을 제안할 수 있으므로 Fork 발생할 수 있음 • Fork 발생 시 GHOST 프로토콜 사용 • Block Scoring 기반 • Leaders’ block이 더 높은 score를 가지므로 Fork 해결 A fork occurring in Clique. a4는 a3이 두 번째 block 으로 제안한 블록을 가지고있는 반면, a5는 a2가 제안한 블록을 가지고 있음 결국, a4는 a3가 제안한 블록을 a2가 제안한 블록으로 (a2의 score가 더 높아서) 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 40. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 40 IBFT2.0 vs. Clique Jeongwhan Choi IBFT 2.0 (Istanbul BFT) Clique 구분 IBFT 2.0 Clique Immediate finality O X(Fork 가능) min No. validators 4 validators Single Speed Slow (Node 수 증가 시 느려 짐) Fast (Node 수 증가 Fork 확률 증가) A group of nodes Validators Signers 1.Introduction 2.PBFT 3.IBFT 4.Clique
- 41. JEONBUK NATIONAL UNIVERSITY Consensus Protocolsof Hyperledger Besu 41Jeongwhan Choi Thank you