Ethereum Asia Tour-Taiwan 2017 taipei-0330-nccu v3
•
1 like•500 views
1) The document describes a project to add Byzantine Fault Tolerant (BFT) consensus to the Geth Ethereum client based on an earlier HydraChain approach. 2) The implementation modifies Geth minimally and adds a new BFTProtocolManager. Initial alpha testing is complete and a beta release is being prepared. 3) The consensus protocol was changed from HydraChain to a PBFT-like approach due to safety and liveness concerns with the original algorithm in the presence of Byzantine nodes. Preliminary performance testing shows throughput of 20-30 transactions per second and latency of 2-4 seconds to commit blocks.
Recommended
More Related Content
Similar to Ethereum Asia Tour-Taiwan 2017 taipei-0330-nccu v3
Similar to Ethereum Asia Tour-Taiwan 2017 taipei-0330-nccu v3 (20)
Recently uploaded
Recently uploaded (20)
Ethereum Asia Tour-Taiwan 2017 taipei-0330-nccu v3
- 1. An Implementation of BFT Consensus for Ethereum --Adding BFT Consensus to Geth Kung Chen, Tung-Wei Kuo Yi-Chun Hsu, Ming-Chuan Lin National Cheng-Chi University, Taipei, TAIWAN March 30, 2017 以太坊亞洲巡迴交流會：台灣 Ethereum Asia Tour: Taiwan 政大資科系區塊鏈團隊
- 3. Outline • Project Background • Project Status • Our BFT Consensus Protocol • Preliminary Performance Test Results
- 4. Project Background • Launched in July 2016, the initial goal is to develop a variant of geth with Byzantine Fault Tolerant (BFT) consensus based on the approach of HydraChain (based on pyethapp). • A step towards developing a framework of pluggable consensus protocols for Geth. • Ended up with a PBFT-like consensus algorithm, as the safety and liveness properties of HydraChain consensus algorithm may not hold in the presence of Byzantine faulty nodes.
- 5. Project Status • Implementation: Keep the changes to geth as small as possible. • Add a BFTProtocolManager to geth. Use cmd-line-arguments to turn on the BFT consensus protocol. • Geth –bft –num-validators 4 –node-num 1 • Disable gas limit check when BFT mode is turned on • Alpha testing now, beta release under preparation. • AMIS is now testing an earlier version of January.
- 6. From HydraChain to Our Consensus Protocol
- 7. Commit block 𝐵𝐵 if a quorum for 𝐵𝐵 is intercepted Quorum for block 𝐵𝐵: +⅔ of all nodes vote for block 𝐵𝐵 Proposer broadcasts a proposal HydraChain at a High Level Propose Intercept Quorum Commit Every node broadcasts its vote Vote
- 8. Propose 1 3 4 5 Propose 𝐵𝐵𝑏𝑏𝑏𝑏 𝑏𝑏𝑏𝑏𝑏𝑏 Propose 𝐵𝐵𝑟𝑟𝑟𝑟𝑟𝑟 Proposer Byzantine fault node 2 Byzantine fault node 6 7
- 9. Vote 1 3 4 5 Vote 𝐵𝐵𝑏𝑏𝑏𝑏 𝑏𝑏𝑏𝑏𝑏𝑏 Vote 𝐵𝐵𝑟𝑟𝑟𝑟𝑟𝑟 Proposer Byzantine fault node 2 Byzantine fault node 6 7
- 10. Vote 1 2 4 5 6 7 Proposer Byzantine fault node Byzantine fault node 3 received before timeout received after timeout
- 11. Vote 1 2 Proposer Byzantine fault node Byzantine fault node 3 received before timeout received after timeout 54 6 7
- 12. Intercept Quorum 1 2 4 5 6 7 Proposer Byzantine fault node Byzantine fault node 5 > 7 × �2 3 Node 3 intercepts a quorum and commits 𝐵𝐵𝑏𝑏𝑏𝑏 𝑏𝑏𝑏𝑏𝑏𝑏 3
- 13. The Result • Only node 3 commits block 𝐵𝐵𝑏𝑏𝑏𝑏 𝑏𝑏𝑏𝑏𝑏𝑏 • Other nodes cannot commit a block • Moreover, other nodes receive more votes for 𝐵𝐵𝑟𝑟𝑟𝑟𝑟𝑟 than 𝐵𝐵𝑏𝑏𝑏𝑏 𝑏𝑏𝑏𝑏𝑏𝑏 • In the future, other nodes might commit block 𝐵𝐵𝑟𝑟𝑟𝑟𝑟𝑟, instead of block 𝐵𝐵𝑏𝑏𝑏𝑏 𝑏𝑏𝑏𝑏𝑏𝑏 • Safety is threatened
- 14. Our Consensus Protocol at a High Level Propose Intercept Quorum Commit Vote Precommit If I commit a block, then +⅓ non-faulty nodes will back me up (even if the next proposer conflicts with me)
- 15. Our Consensus Protocol at a High Level Propose Intercept Quorum Commit Vote Precommit Commit block 𝐵𝐵 if +⅔ nodes intercepts quorum for 𝐵𝐵
- 16. Our Consensus Protocol at a High Level Precommit Other 4 steps are also updated Propose* Intercept Quorum* Commit* Vote*
- 17. Consensus flow New height Propose Vote Nil Vote Block Precommit Nil New Round Wait for Precommit +⅔ Wait for votes from +⅔ If +⅔ nodes intercepts quorum for 𝐵𝐵 If a quorum for 𝐵𝐵 is intercepted Precommit Block Commit
- 18. Future Directions 1. Detecting certain types of Byzantine faults 2. Fine-tuning the parameters in consensus algorithms
- 20. Test Environment • Amazon EC2 instance of type t2.medium. • 2 vCPU and 4 GB of RAM • 20,000 payment transactions are preloaded to txpool. • Commit 20 blocks in total.
- 21. Throughput *Revised on April 12, 2017
- 22. Latency of Committing *Revised on April 12, 2017