-
Notifications
You must be signed in to change notification settings - Fork 22
6. Core
IBFT is not a typical state machine.
It can better be described as a series of events that occur if certain conditions are met. These events are in the form of messages being received, and the conditions are based upon the number of certain messages received, as well as the internal state of the IBFT machine.
The start of every consensus sequence begins with a simple check for the node - “am I the proposer for this view?”.
If the node determines (with the Backend
) that they are the proposer for the current view, they need to build and propose the block. Upon proposing (multicasting) the proposal in the form of a PREPREPARE message, the node moves to wait for PREPARE messages from other nodes.
If the node determines that it’s in fact not a proposer for the current view, they need to wait for the proposal to arrive from the calculated proposer.
Upon receiving the proposal, several things are checked to make sure the proposal is valid:
- The proposal view matches the current consensus view
- The proposer is the calculated proposer
- The block is valid (validated by the
Backend
)
If all of these conditions are met, then the node multicasts a PREPARE message, and moves over to the Prepare state.
If the node is accepting a proposal for a round that is > 0
, then the proposal validation is somewhat different.
In this case, additional things need to be verified, such as the Round Change Certificate
.
If the node does not receive a valid PREPREPARE message in time (until the round timeout expires), the node breaks out of the consensus loop and moves to the next round, broadcasting the next round as the desired round in RC.
The purpose of the prepare state, for a node, is to get some kind of feedback information from other nodes that they also think the block is valid.
Upon receiving a PREPARE message, the only kind of validation needed is to determine if the hash of the proposal contained in the message, and the local hash of the proposal (for the node) match. If they match, the message is considered valid.
In this state, the node needs to receive Quorum valid PREPARE messages in order to proceed further, to Commit state.
Before moving along to the Commit state, the node saves this proposal as the last prepared proposal, and creates a Prepared Certificate
.
After that, it multicasts a COMMIT message.
If the node does not receive Quorum valid PREPARE messages in time (until the round timeout expires), the node breaks out of the consensus loop and moves to the next round, broadcasting the next round as the desired round in RC.
The final state for which messages need to be received - Commit state.
In Commit state, the node waits to receive a Quorum of valid COMMIT messages from other peers. Upon receiving the COMMIT message, several things are checked to make sure the message is valid:
- The hash of the proposal in the commit message matches the local hash of the proposal
- The committed seal is valid
If all of these conditions are met, then the node has essentially finished the phase of the consensus where communication with other nodes in required for the current view, and moves over to the Fin state.
If the node does not receive Quorum valid COMMIT messages in time (until the round timeout expires), the node breaks out of the consensus loop and moves to the next round, broadcasting the next round as the desired round in RC.
Fin marks the end of the IBFT consensus protocol - it is the moment where the node actually inserts the proposal into the local chain.
Every round in IBFT has a ticking timeout.
This means that whenever a node starts a new IBFT consensus round, a timer that runs in the background is started as well. As soon as this timer expires, the node needs to stop going through its consensus states and move to the Round Change state to rendezvous with other nodes before starting a new round.
The timeout for the timer is calculated based on the current round number, as well as the base timeout (by default 10s
).
At any point in time, a node can receive a PREPREPARE message from its peers, that is higher in round that the node's current round.
This flow is completely valid, and if the node verifies the proposal is valid (on the basis of its Round Change Certificate
), it accepts the proposal
and moves to the round specified in the proposal message.
At any point in time, a node can receive set of Round Change
messages that form a Round Change Certificate
from its peers, that is higher in round that the node's current round.
When the node verifies that the RCC
is valid, and that it contains at least Quorum
Round Change
messages,
it moves to the highest round number specified in the RCC
.