Authors: Marcin Pawlowski [email protected], Thomas Lavaur [email protected]

Revision History

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 selects valid Mantle Transactions (as defined in [1.4.0] Mantle) from its mempool and includes references to them in the proposal.
   3. 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 retrieve complete transactions from their mempool that are referred in the block.
   3. 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 [1.4.0] Mantle.
   2. They update the different variables that need to be maintained over time.
   3. They execute the [1.2.1] Service Reward Distribution Protocol to generate reward notes locally.

Constructions

Hash

We are using two hashing algorithms that have the same output length of 256 bits (32 bytes) that are [Poseidon2 (ZK Friendly Hash Function)](https://nomos-tech.notion.site/Poseidon2-ZK-Friendly-Hash-Function-1fd261aa09df81f48afcd5bbe86c4a18) and [**BLAKE2b (General-Purpose Hashing)**](https://nomos-tech.notion.site/BLAKE2b-General-Purpose-Hashing-1fd261aa09df81b3890fcc4f9606ee9e).

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.