Introduction

In this document, we present the specification defining the construction of the block proposal, its validation, and execution. We define the block proposal construction that contains references to transactions (from the mempool) instead of a complete transaction to limit its length. The raw block size increases with the size of transactions it contains up to 1 MB, and the proposal compresses its size down to 33 kB, which saves the bandwidth necessary to broadcast new blocks.

Overview

For the consensus protocol to make progress, a new leader is elected through the leader lottery. The new leader is in possession of a proof of leadership (PoL) that confirms that it is indeed the leader. The main objective of the leader is to construct a new block, hence becoming a block builder, and share it with other members of the network as a block proposer. The block must be correctly constructed; otherwise, it will be rejected by the network nodes who are validating every block. Only validated blocks are executed, which means that the transactions included in the block are interpreted by all nodes, and the state of the chain is modified according to the instructions embedded in the transactions.

High-level flow

Below, we present a high-level description of the block life cycle. The main focus of this section is to build an intuition on the block construction, validation, and execution.

A leader is selected. The leader becomes a block builder.
The block builder constructs a block proposal.
1. The block builder selects the latest block (parent) as the reference point for the chain state update.
2. The block builder constructs references to the deterministically generated Mantle transactions that execute service reward distribution and collection (see Service Reward Distribution Protocol), if such transactions can be constructed. For example, there is no need to distribute rewards when all rewards have already been distributed.
3. The block builder selects valid Mantle Transactions (as defined in Mantle Specification) from its mempool and includes references to them in the proposal.
4. The block builder populates the block header of the block proposal.
The block builder sends the block proposal to the blend network.
The validators receive the block proposal.
The validators validate the block proposal.
1. They validate the block header.
2. They verify the distribution and collection of service rewards through Mantle Transactions as specified in Service Reward Distribution Protocol. This is done by independently deriving the collection and distribution transactions and confirming that they match the first two references, if constructed by the block builder.
3. They retrieve complete transactions from their mempool that are referred in the block.
4. They validate each transaction included in the block.
The validators execute the block proposal.
1. They derive the new blockchain state from the previous one by executing transactions as defined in Mantle Specification.
2. They update the different variables that need to be maintained over time.

Constructions

Hash

The hashing algorithm used in the specification is blake2b ([**BLAKE2b (General-Purpose Hashing)**](https://nomos-tech.notion.site/BLAKE2b-General-Purpose-Hashing-1fd261aa09df81b3890fcc4f9606ee9e)). The default length of the output of the hashing algorithm is 256 bits (32 bytes).

Block Proposal

The Proposal is a block proposal that, instead of containing complete Mantle Transactions of an unlimited size, contains references of fixed size to the transactions. Therefore, the size of the proposal is constant and it is 33129 bytes.

We define the following message structure: