Multiplicity

A Tendermint Add-On for Multiple Concurrent Proposers

Introduction

Modern blockchains operate on a leader-based system where a rotating proposer holds the power to decide which transactions are included in each block and what order to include them in. Some proposers collude with MEV-searchers to maximize the rents that they can extract from this temporary monopoly (e.g. MEV boost). The value extracted is far from pennies, and is estimated to be worth billions of dollars a year on Ethereum.
Now imagine if a chain could capture all that value and return it back to users in the process. Impermanent loss for liquidity providing wouldn’t exist! Luckily, auctions are a great mechanism for selling complex bundles of resources such as blockspace. Unluckily, on-chain auction designs have a major vulnerability. Malicious block proposers are given a monopoly on transaction inclusion​
The proposer’s monopoly on inclusion is the weak link, which allows for cheap censorship. In order to improve the censorship resistance of a chain we need to destroy this monopoly by allowing multiple concurrent block proposers (MCBP). In particular, we would like to expand the set of nodes who are able to contribute transactions in each block. Multiplicity is a practical gadget that allows non-leader nodes to include additional transactions into a block.

Multiplicity: A Practical Gadget for Multiple Concurrent Proposers

Informally, In the first stage every non-byzantine validator on the committee sends a signed special bundle of transactions, to the leader. In order to construct a valid block, the leader must include at least 2/3 (stake weighted) of these bundles. Therefore the leader cannot construct a valid block that omits a transaction which was included in >1/3 (stake weighted) of the special bundles.
More formally: a proposed block is only valid if the leader includes a sufficient quorum (defined either by stake-weight or number) of validator-signed special bundles of transactions.
The gadget adds the additional steps to proof-of-stake protocols:
  1. 1.
    Each validator constructs a special bundle of transactions from their local view of the mempool. They sign this and send it to the leader.
  2. 2.
    Based on payloads received from other validators, the leader creates, signs and broadcasts a block proposal containing at least 2/3 (stake weighted) of these special bundles. .
  3. 3.
    When determining the validity of the leader’s proposal, validators check that sufficiently many special bundles are included in the block
 3a.  If the block contains a quorum of payloads the block is sufficient and  consensus proceeds normally.
 3b.  If the block does not contain a quorum of payloads it is considered invalid and a new round of consensus starts the same way it would if a block contained a transaction with an invalid signature.

Implementation

​Multiplicity will be built in collaboration with Skip's protocol owned builder (POB) as part of a larger paradigm shift towards the notion of Sovereign MEV.
Last modified 18d ago