Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Istanbul BFT

5 154 vues

Publié le

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

Publié dans : Ingénierie
  • Comparing VigRX Plus to ED Prescription Drugs  http://t.cn/Ai88iYkP
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • I went from getting $3 surveys to $500 surveys every day!! learn more... ■■■ http://ishbv.com/surveys6/pdf
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Just got my check for $500, Sometimes people don't believe me when I tell them about how much you can make taking paid surveys online... So I took a video of myself actually getting paid $500 for paid surveys to finally set the record straight. I'm not going to leave this video up for long, so check it out now before I take it down! ■■■ https://tinyurl.com/make2793amonth
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

Istanbul BFT

  1. 1. Istanbul BFT Yu-Te Lin
  2. 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. 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. 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. 5. Istanbul BFT
  6. 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. 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. 8. Protocol • Three-phase protocol: • Pre-prepare: Proposer proposes a block. • Prepare: Validators agree on block. • Commit: Validators agree on commit.
  9. 9. Protocol – Propose Proposer proposes a block
  10. 10. Protocol – Pre-prepare Pre-prepare message
  11. 11. Protocol – Prepare Prepare message
  12. 12. Protocol – Prepare Prepared when i receives 2f prepares that match pre-prepares.
  13. 13. Protocol – Commit Commit message
  14. 14. Protocol – Committed Committed If prepare(i) and received 2f+1 commits
  15. 15. State Machine
  16. 16. State Machine – New Round
  17. 17. State Machine – Pre-prepare
  18. 18. State Machine – Pre-prepared
  19. 19. State Machine – Pre-prepared
  20. 20. State Machine – Prepared
  21. 21. State Machine – Commit
  22. 22. State Machine – Committed
  23. 23. State Machine – Insert Block
  24. 24. State Machine – Final Committed
  25. 25. State Machine – New Round
  26. 26. State Machine – Round Change
  27. 27. State Machine – Round Change
  28. 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. 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. 30. Ottoman Testnet • 4 pre-set validators • Command: geth --ottoman
  31. 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. 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. 33. Preliminary Result – Consensus • Consensus time: 10ms ~ 100ms. • Process 0 tx ~ 1000+ tx.
  34. 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. 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. 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. 37. Project Status • EIP: https://github.com/ethereum/EIPs/issues/650 • Pull Request: https://github.com/ethereum/go-ethereum/pull/14674
  38. 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.

×