Se ha denunciado esta presentación.

Istanbul BFT

16

Compartir

Cargando en…3
×
1 de 39
1 de 39

Istanbul BFT

16

Compartir

Descargar para leer sin conexión

Descripción

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

Transcripción

  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.

Descripción

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

Transcripción

  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.

Más Contenido Relacionado

Libros relacionados

Gratis con una prueba de 30 días de Scribd

Ver todo

Audiolibros relacionados

Gratis con una prueba de 30 días de Scribd

Ver todo

×