> For the complete documentation index, see [llms.txt](https://ethernal-2.gitbook.io/blade/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ethernal-2.gitbook.io/blade/detailed-design/consensus-mechanism/ibft-2.0-consensus-algorithm/backend.md).

# Consensus Backend

The truth is that every blockchain (in the blockchain system) starts with a genesis block identical for all participants. This is also the case in the Blade solution. Each subsequent block is added to the blockchain using a consensus algorithm, where a set of validators agrees or disagrees with the proposed block. Besides, the data used by selected validators for adding the block varies. To ensure that `IBFT` always has access to the necessary data needed for creation of a new block, the `IBFTBackend` component is leveraged.

As already described in [IBFT 2.0 Initialization](/blade/detailed-design/consensus-mechanism/ibft-2.0-consensus-algorithm/initialization.md), `IBFT` is initiated by invoking the `RunSequence()` method and is implemented as a state machine. The initial state used for start is `newRound`. In the initial state, `IBFT` checks whether the current node is the block proposer for the given round and height. If the current node is chosen to be the proposer for the round and height, then it creates a new block. The creation of a new block is done by the `IBFTBackend,` and `IBFT` calls the `BuildProposal()`method from the `IBFTBackend`, which returns the created block.

To ensure that the created block is known to other validators, the chosen proposer creates a `PrePrepare` message through which the block is sent to other validators. The creation of the `PrePrepare` message is also done in the `IBFTBackend` (by `BuildPrePrepareMessage()` method).

After the `PrePrepare` message is created, the proposer marks the new block as an accepted proposal. Other validators participating in the consensus must perform certain validations on the block as well, before marking it as an accepted proposal. The first method called in the proposed block verification is `IBFTBackend`'s `IsProposer()`. This method checks whether the sender of the block is indeed the chosen proposer for the current round and height. After that, the `IsValidProposalHash()` method is called, which verifies whether the hash in the message matches the hash of the proposed block. To validate that the proposed block is correct, i.e., that the transactions in the block are valid, the `IsValidProposal()` method is used. This method executes all transactions and decides whether the sent block is valid. In the case that the round is greater than zero, during the verification of `RoundChange` messages, the `IsValidValidator()` method is called from the `IBFTBackend` to check whether the sender of the Round Change Certificate (RCC) is valid. The last method called from the `IBFTBackend` before `IBFT` transitions to a new state is `BuildPrepareMessage()`. After sending the `Prepare` message, `IBFT` transitions to the `prepare` state.

In the `prepare` state, a validator retrieves all `Prepare` messages from its `Message` storage for the corresponding height and round. Subsequently, it performs validation of these messages. For each message, the `IsValidProposalHash()` method is called from the `IBFTBackend` to verify whether the hash in the `Prepare` message matches the `Proposal` hash. If a sufficient number of `Prepare` messages exist, satisfying the quorum requirement, a `Commit` message is sent. After sending the message, `IBFT` transitions to a new state called `commit`.

Similarly to how the `IBFT` in the `prepare` state collects all Prepare messages from the `Message` storage, it now does the same but specifically collects `Commit` messages for a given round and height. Each message must undergo validation, and only valid messages are considered when checking the quorum for `Commit` messages. For each message, the first step is to verify whether the hash in the `Commit` message matches the `Proposal` hash. This verification is done by calling the `IBFTBackend`'s `IsValidProposalHash()`method. After this verification, the next step is to check whether the signature of the `Proposal` hash in the `CommittedSeal` is indeed signed by the validator. Once the quorum for `Commit` messages is reached, `IBFT` transitions to the `final` state.

In the `final` state, `IBFT` adds a new block to its local blockchain and removes all messages from its `Message` storage that were used for previous decisions on the correctness of the block. The block is added to the blockchain by invoking the `InsertProposal()` method from the `IBFT Backend.` After successfully adding the new block to the blockchain, `IBFT` sends a signal on the `roundDone` channel, thus halting the execution of the initiated sequence.

<figure><img src="/files/q2RtdJjzu68LyHuuVQvY" alt=""><figcaption><p>IBFT and IBFTBackend Interaction Sequence Diagram</p></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://ethernal-2.gitbook.io/blade/detailed-design/consensus-mechanism/ibft-2.0-consensus-algorithm/backend.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.