Owner: @Marcin Pawlowski @Thomas Lavaur

Reviewers: 🟢@Daniel Sanchez Quiros 🟢@David Rusu 🟢@Álvaro Castro-Castilla

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 consensus 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 lifecycle. The main focus of this section is to build an intuition on the block construction, validation, and execution.

1. A leader is selected. The leader becomes a block builder.
2. 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 the 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.
3. The block proposer sends the block proposal to the Blend network.
4. The validators receive the block proposal.
5. The validators validate the block proposal.
   1. They validate the block header.
   2. They verify distribution of service rewards through Mantle Transactions as specified in Service Reward Distribution Protocol. This is done by independently deriving the distribution transaction and confirming that it matches the first reference, if there is rewards to be distributed.
   3. They retrieve complete transactions from their mempool that are referred in the block.
   4. They validate each transaction included in the block.
6. 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

We are using two hashing algorithms that have the same output length of 256 bits (32 bytes) that are Poseidon2 and Blake2b.

Block Proposal

A block proposal, 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: