Skip to main content

Consensus quality initiatives

This section describes the mechanisms we use to maximize the consensus quality on Massa blockchain.

Endorsement​

Massa uses the Proof-of-Stake selection mechanism with Nakamoto consensus. In that context, when there are multiple cliques in close competition, we want all nodes to converge towards a single clique as fast as possible to minimize finality time and maximize the quality of the consensus. To achieve this, we draw inspiration from Tezos and introduce the concept of Endorsement.

Each block header in Massa contains EE ordered endorsement slots. An endorsement includes the slot it belongs to, the hash of the endorsed block, the endorsement slot index, the creator's public key, and a signature. At each slot, a Proof-of-Stake selection mechanism chooses the block creator and E other stakers who can create endorsements for that slot. Endorsements can be seen as votes endorsing the parent block in the corresponding thread.

The attacker's likelihood of consecutive PoS draws decreases exponentially. With endorsements, E+1E+1 draws occur at each slot, increasing safety and convergence speed. The consensus algorithm selects the clique with the highest fitness as the blockclique, where the fitness is determined by the number of PoS draws involved in creating the block. This mechanism enhances safety and convergence speed by allowing block producers to select the best clique based on the endorsements' "votes."

Endorsement structure​

Note that the WrappedEndorsement structure includes the underlying Endorsement as well as the signature, and the public key of the endorsement producer.

Within a block, endorsements are fully included inside the header.

A header is invalidated if:

  • it contains strictly more than E endorsements
  • at least one of the endorsements fails deserialization or signature verification
  • at least one of the endorsements endorses a block different than the parent of the including block within its own thread
  • any of the endorsements should not have been produced at that (endorsement.slot, endorsement.index) according to the selector
  • there is strictly more than one endorsement with a given endorsement.index
pub struct Endorsement {
  /// slot in which the endorsement can be included
  pub slot: Slot,
  /// endorsement index inside the including block
  pub index: u32,
  /// Hash of endorsed block.
  /// This is the parent in thread `self.slot.thread` of the block in which the endorsement is included
  pub endorsed_block: BlockId,
}

Endorsement lifecycle​

To create endorsements for a specific slot SS, the Endorsement Factory wakes up at a certain timestamp and checks the endorsement producer draws for that slot. The factory asks Consensus for the latest blockclique block with a lower period than S.period to choose the block to endorse. The created endorsements are sent to the Endorsement Pool for future inclusion in blocks and propagated through the Protocol to other nodes.

In the Protocol, endorsements can be received from other modules or nodes. Received endorsements are propagated and added to the Endorsement Pool if they are not already known. The Endorsement Pool stores a limited number of endorsements that can potentially be included in future blocks. Consensus notifies the Endorsement Pool of newly finalized blocks, allowing it to remove endorsements that can only be included in already-finalized slots.

When the Block Factory produces a block and needs to include endorsements in its header, it requests the Endorsement Pool for the endorsements that endorse the block's parent in its thread and can be included in the block's slot.

Incentives and penalties​

To incentivize the creation and endorsement of blocks, as well as the inclusion of endorsements in blocks, a revenue split is implemented. The total revenue generated by a block, denoted as RR, is divided into 1+E1+E equal parts, where EE is the number of endorsements.

Each part, denoted as rr, is distributed as follows:

  • The block creator receives rr to motivate block creation, even without endorsements.
  • For each successfully included endorsement:
    • The block creator receives r/3r/3 to incentivize endorsement inclusion.
    • The endorsement creator receives r/3r/3 to motivate endorsement creation.
    • The creator of the endorsed block receives r/3r/3 to encourage timely block emission for endorsement.

This revenue split increases the frequency at which stakers receive coins, reducing the need for staking pools.