This ROP consists in a feasibility study for a Multiplicity gadget adapted to the Ethereum Proof-of-Stake protocol.


Multiplicity was introduced in 2023 by Duality Labs, as a way to reduce the input of single block proposers into the make-up of their blocks. Before the block is produced, a committee signs off on a set of items, over which consensus is obtained. Items from the set must be included in the subsequent block for the block to be valid.

Multiplicity is related to inclusion lists, where some party makes a list of transactions which must be included in the next block as long as there is enough room. However, one can see inclusion lists as “single-leader” mechanisms, where a single party is responsible for their construction. This may lead to bribing or extortion attacks, as described in “Fun and games with inclusion lists”.

By assigning the responsibility of constructing an inclusion set to a committee instead of a single leader, we no longer rely on the honesty or rationality of a single party. Obtaining consensus over the set of items to include could also increase accountability and allow for incentive schemes.

Relevant skills

  1. Consensus researchers familiar with Ethereum Proof-of-Stake (i.e., Gasper) and current literature on data distribution.
  2. Protocol researchers able to specify the architecture of the mechanism and think through incentive compatibility issues.
  3. Software engineers looking to improve their knowledge of client code (e.g., EPF fellows).

Expected deliverables

We wish to obtain more arguments on the desirability and feasibility of this mechanism in the context of Ethereum Proof-of-Stake. The deliverables are expected to provide more details on the following points:

  1. Background review: Understand the current literature related to censorship and Multiplicity.
  2. Feasibility: Is this mechanism appropriate for Ethereum? Does it quantifiably improve censorship-resistance or other relevant metric? Can the mechanism be deployed in the current context of Ethereum’s Proof-of-Stake consensus mechanism, and how?
  3. Specification: The mechanism is specified as a Pull Request to the consensus-specs repository.
  4. Implementation: The mechanism is implemented as a prototype in a client of your choice.

We believe the deliverables should be performed in order, and are willing to engage with teams or individuals who perform only a subset of these (e.g., team A does 1. + 2., individual B works on 3. + 4.)

Additional notes