2. Messages

The messages package represents the implementation for the message queue, as well as message types being passed around in the system.

All messages exchanged by the go-ibft package need to have the following structure:

// View defines the current status
message View {
  // height represents the number of the proposal
  uint64 height = 1;

  // round represents the round number in the specific height
  uint64 round = 2;
}

// Message defines the base message structure
message Message {
  // view is the current view for the message
  View view = 1;

  // from defines who is the message sender
  bytes from = 2;

  // the signature of the sender, if any
  bytes signature = 3;

  // type defines the message type
  MessageType type = 4;

  // payload is the specific message payload
  oneof payload {
    PrePrepareMessage preprepareData = 5;
    PrepareMessage prepareData = 6;
    CommitMessage commitData = 7;
    RoundChangeMessage roundChangeData = 8;
  }
}

By the IBFT 2.0 specification, there are 4 unique message types:

Preprepare Messages

Preprepare messages are messages sent out by the proposers for the current view. They contain information regarding the proposal for the current round.

Proposers are chosen on a per-round basis, and follow a pattern defined by the Backend. Possible implementations for this proposer selection mechanism can be for example Round Robin selection, or Sticky Proposer selection.

When the proposer sends out a Preprepare message, they wait for other messages just like the rest of the nodes in the cluster. The only difference between proposers and other nodes in the cluster is that proposers have one additional step before committing to the same execution flow as validators - to propose a block.

Prepare Messages

Prepare messages are messages sent out by the validators for the currently active proposal. They contain the hash (keccak256) of the active proposal.

The hashing implementation is left for the Backend to decide and implement.

Commit Messages

Commit messages are messages sent out by the validators for the currently active proposal. They contain the hash (keccak256) of the active proposal, as well as the signature of the mentioned hash, called a committed seal.

Round Change Messages

Round Change messages are messages sent out by the validators with the purpose of agreeing on what the next round should be.

Round Change messages are never exchanged if there is a valid flow in the IBFT consensus protocol, but rather if there is a problem that needs to be resolved (invalid proposal, invalid block insertion…).

Round Change messages, and the Round Change state in general, serve as sort of rendezvous for nodes in the consensus network to agree on how to move forward (what the next round should be, and in turn who should propose the block next).