Go-ethereum practical byzantine fault tolerance (PBFT) implementation based on pluggable consensus engine.

1. Istanbul BFT
Yu-Te Lin

2. The Problems
• 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.

3. The Solution
• Practical Byzantine Fault Tolerance (PBFT)
• Miguel Castro and Barbara Liskov 1999.*
• Targeting at a Byzantine-fault-tolerant NFS service in an asynchronous system like internet.
• A state machine replication algorithm.
• Go-ethereum integration:
• NCCU BFT: Academic PBFT-like geth implementation pioneer.
• Ethermint: Ethereum on top of Tendermint.
*http://pmg.csail.mit.edu/papers/osdi99.pdf

4. 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)

5. Istanbul BFT

6. Algorithm Overview
• The proposer multicasts the block proposal to the validators.
• Validators agree on the block and broadcast their decision to others.
• Each validator waits for 2F+1 commits from different validators with the same
result before inserting the block into blockchain.
*Reference: https://www.slideshare.net/mansu/practical-byzantine-fault-tolerance

7. From Blockchain’s Perspective
• A consensus protocol.
• Maintains the order of transactions.
• A network of N validators can withstand F of Byzantine nodes.
• N = 3F + 1
• Data consistency and integrity guaranteed.

8. Protocol
• Three-phase protocol:
• Pre-prepare: Proposer proposes a block.
• Prepare: Validators agree on block.
• Commit: Validators agree on commit.

9. Protocol – Propose
Proposer proposes
a block

10. Protocol – Pre-prepare
Pre-prepare
message

11. Protocol – Prepare
Prepare
message

12. Protocol – Prepare
Prepared when i receives 2f
prepares that match pre-prepares.

13. Protocol – Commit
Commit
message

14. Protocol – Committed
Committed
If prepare(i) and received 2f+1 commits

15. State Machine

16. State Machine – New Round

17. State Machine – Pre-prepare

18. State Machine – Pre-prepared

19. State Machine – Pre-prepared

20. State Machine – Prepared

21. State Machine – Commit

22. State Machine – Committed

23. State Machine – Insert Block

24. State Machine – Final Committed

25. State Machine – New Round

26. State Machine – Round Change

27. State Machine – Round Change

28. Consensus Proof
• Upon entering committed state (received 2f+1 of commit messages), each
validator stores those 2f + 1 of committed seals in block header before inserting
the block into blockchain.
• Consensus proof: Committed seals that prove the associated block has gone
through the consensus process.

29. Manageable Validator Set
• Proposer can cast one vote to propose a change to the validators list.
• Validator proposals reaching majority consensus come into effect immediately.
• Vote authorization:
istanbul.propose("0xdc421209441a754f79c4a4ecd2b49c935aad0312", true)
• Vote deauthorization:
istanbul.propose("0xdc421209441a754f79c4a4ecd2b49c935aad0312", false)

30. Ottoman Testnet
• 4 pre-set validators
• Command:
geth --ottoman

31. Experimental Faulty Node
• Branch: https://github.com/getamis/go-ethereum/pull/99/
• Command:
geth -istanbul.faultymode <MODE>
• Modes:
• 0: Disable faulty behaviors.
• 1: Randomly run any faulty behaviors.
• 2: NotBroadcast: Don’t broadcast any message.
• 3: SendWrongMsg: Send out message with wrong message code.
• 4: ModifySig: Forge message signatures.
• 5: AlwaysPropose: Disguise as proposer and send pre-prepare messages.
• 6: AlwaysRoundChange: Broadcast round change every time.

32. Preliminary Result
• Expectation: Get a sense on transaction per second (TPS).
• Environment: Azure VM. Standard D2 V2 instance.
• CPU: 2 cores
• Memory: 7 Gib
• Validators: 4

33. Preliminary Result – Consensus
• Consensus time: 10ms ~ 100ms.
• Process 0 tx ~ 1000+ tx.

34. Preliminary Result – TPS
• Max block size: 2000 tx
• Max txpool size: 10240 tx
• Test scenario :
• 25 accounts/validator (100 in total)
• Total test time: 10 mins
• Send 100 tx/round per account
• Round timeout: 15~35sec

35. Istanbul: Preliminary Result – TPS
• TPS per 10 sec: (Fig. Left)
• Peak: 1207
• Average: 831
• Bottom: 408
• TPS per 1min: (Fig. Right)
• Peak: 389

36. Preliminary Result – Conclusion
• Generally can reach 1000+ TPS.
• Need to eliminate Geth factors:
• Tx generation overhead.
• Geth seems to have issues on processing large blocks.
• Processing time is not linearly related to block size.
• Txpool management issues. Txpool size or txpool locking?
• Slow state processor (EVM)?
• Optimization and bug fixing:
• Event mux limitation.
• …and more.
• Comprehensive benchmarking and stress testing is still in progress.

37. Project Status
• EIP: https://github.com/ethereum/EIPs/issues/650
• Pull Request: https://github.com/ethereum/go-ethereum/pull/14674

38. Future Work
• Gossip network
• Testnet: 22 nodes (7 faulty and 15 normal)
• Weighted round robin
• Fast block generation mode.
• Benchmarking and stress testing.
• Faulty proposer detection.
• Formal proofs on safety and liveness.
• Locking mechanism.