Pitch
This ROP consists in a feasibility study for a Multiplicity gadget adapted to the Ethereum Proof-of-Stake protocol.
Abstract
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
- Consensus researchers familiar with Ethereum Proof-of-Stake (i.e., Gasper) and current literature on data distribution.
- Protocol researchers able to specify the architecture of the mechanism and think through incentive compatibility issues.
- 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:
- Background review: Understand the current literature related to censorship and Multiplicity.
- 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?
- The ideal deliverable of 1. + 2. is a research paper or report (e.g., ethresear.ch post).
- Specification: The mechanism is specified as a Pull Request to the consensus-specs, consensus-api and execution-specs repositories.
- The ideal deliverable is a Pull Request.
- Implementation: The mechanism is implemented as a prototype in a client of your choice.
- The ideal deliverable is an open source repository containing a fork of a client with the code for the gadget.
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
- Free DA problem: Intuitively, this mechanism is liable to increase the free Data Availability problem (see “No free lunch — A new inclusion list design”), where a user is able to obtain publication of data on-chain for free, for instance by getting a transaction included in the Multiplicity consensus set, yet invalidating the transaction with a distinct same-nonce transaction eventually included in the block.
- Incentive schemes: Increased accountability and programmable protocol logic could allow for sophisticated incentive schemes, e.g., the conditional tip logic discussed in “Censorship Resistance in On-Chain Auctions”, Section 6.2 + “Introducing Multiplicity” post.