Interpretation of Istanbul BFT consensus algorithm

Istanbul BFT consensus algorithm detailed documentation

Istanbul BFT as a class BFT algorithm has been the practice in the etheric Square. Although Istanbul there are still some potential problems, but the algorithm idea and implementation is still worth learning and reference.

the term

• Validator: Block verifier.
• Proposer: the blocks will.
• Round: several rounds of consensus. Made from a round block by block a proposal to start, ending submission to block or change the number of rounds (round number may change because of an error or block update).
• Proposal: a new block in the process proposed.
• Sequence: the height of the proposal. And a sequence corresponding to block high.
• Blocklog: inside information recorded in the backlog in the future.core.backlogs
• Round state: Roundand Sequencebind together to form view,
• Consensus proof: block signature submission. Each validatoris signed will block it after verification.
• Snapshot: Voting validator of state.

Consensus Algorithm Description

Istanbul BFT modified from PBFT algorithm consists of three phases: PRE-PREPARE, PREPAREand COMMIT. In Nnetwork nodes, the algorithm can tolerate up to Fone error nodes, wherein N=3F+1. Before the beginning of each round, validatorwill choose one of them as proposerthe default round-robin fashion (in addition to sticky way, the search stickyProposermethod to see the details). Then proposer will block a proposal put forward, and broadcast PRE-PREPAREinformation. Upon receipt of a validator PRE-PREPAREmessage will state flag is PRE-PREPAREDthen broadcast PREPAREinformation. This step is to ensure that all of the validator be verified in the same seqnence consensus and round (the code for the view) on. Upon receipt of 2F+ 1a PREPAREmessage, validator enter PREPAREDand broadcast status COMMITinformation. This step is to inform the peer node has received the proposed block, and the block will be inserted into the chain. Finally, Validator wait 2F + 1months COMMIT, then go to COMMITTEDstate block is then inserted into the chain.
Istanbul BFT algorithm block is determined, and legal bifurcation means that the chain does not necessarily block in the chain. In order to prevent a malicious node generates a different chain, the block is inserted into the chain before , each of the validator need 2F + 1a COMMITsignature into the region of the header extraDatafield. Therefore, the block can be self-validation (because of the signature) and light client is also supported. However, dynamicextraDataIt can also cause block hash calculation. Because a block can be verified different validator, so there will be a different signature, so there will be a different hash same block. Solution is to calculate the hash of the block when the COMMITsignature excluded. Therefore, we can guarantee any course conducted at the same time block hash consensus verify consistency.

Consensus state

• New Round: A proposer sends a new block proposal. validator waiting for PRE-PREPAREinformation.
• PRE-PREPARED: A validator has received PRE-PREPAREinformation and broadcast PREPAREinformation. Then wait 2F + 1two PREPAREor COMMITinformation.
• PREPARED: A validator has received 2F + 1a PREPAREmessage and broadcast COMMITinformation. Then wait for 2F + 1a COMMITmessage
• COMMITTED: A validator has received 2F + 1a COMMITmessage and at this time can be inserted into the proposed block chain.
• FINAL COMMITTED: A validator has been successfully inserted into the block chain, and wait for the next round.
• ROUND CHANGE: A validator waiting on the next round of the same 2F + 1number ROUND CHANGEinformation.

State transition

• NEW ROUND -> PRE-PREPARED:
  • Proposer collectible trading in txpool in.
  • Proposer put forward a proposal and block broadcast to validator. Then enter the PRE-PREPAREDstate.
  • Each validator into the PRE-PREPAREDstate, upon receipt of PRE-PREPAREDthe information and accompanied by the following:
    • Block proposal is effective from the proposer.
    • Effective header area.
    • sequence and state validator round and block matching proposal.
  • Validator broadcast PREPAREinformation to other validators.
• PRE-PREPARED -> PREPARED:
  • Validator receive 2F + 1valid PREPAREinformation, and enter the PREPAREDstate. Effective information needs to meet the following criteria:
    • sequence and round match.
    • Trading hash match.
    • Information from validators is known.
  • Once in the PREPAREDstate, Validator COMMIT broadcast information.
• PREPARED -> COMMITTED:
  • Validator receive 2F + 1a · valid COMMITinformation in order to enter the COMMITTEDstate. Effective information needs to meet the following criteria:
    • sequence and round match.
    • block hash match
    • Information from validators is known.
• COMMITTED -> FINAL COMMITTED:
  • Validator to 2F + 1a commitment of the signatures into the header region extraDataand attempt to insert the block into block chain.
  • When you insert a block success, Validator into the FINAL COMMITTEDstate.
• COMMITTED FINAL -> NEW ROUND:
  Validators choose a new proposer start a new round.

potential problems

• Fail-Stop failures
• This article analyzes the IBFT
• No incentives