Multiplicity: A Gadget for Multiple Concurrent Block Proposers (aka Ending the Proposer Monopoly)

Research
1

Co-authored with Max Resnick

Expands on an initial forum post on Ethereum Research for the context of Flashbots

MEV and the Proposer’s Monopoly on Inclusion

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).

This collusion can warp the equilibria of on-chain mechanisms by allowing some users to pay to censor other users’ transactions. Auctions – a key tool in on-chain mechanism design – are particularly susceptible to manipulation through censorship See Censorship Resistance in On-Chain Auctions for more details.

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. 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. 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. 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.

Conditional Tipping Logic to Incentivize Inclusion

Conditional tipping rules where the transaction tip is only split among the proposers who include a transaction can be used to improve censorship resistance even further. Conditional tipping logic increases the cost of censorship by making colluding equilibria less stable.

For example, say there are three validators, a transaction with a tip of $5 and a bribing agent who values censoring the transaction at $10. If there is a single leader, it is in the leader’s best interest to take the bribe for > $5 in exchange for censoring the transaction. When more leaders are added, the bribing agent must bribe each of the leaders, eventually it becomes too expensive to bribe everyone and the transaction gets through. See Censorship Resistance in On-Chain Auctions for more details.

SUAVE and L2 Sequencing

A blockchain’s state machine can impose arbitrary ordering rules for transaction execution. This is because the ordering of transaction inclusion does not necessarily need to be the order of transaction execution.

There are many competing opinions and mechanisms for ordering how transactions should be executed. Some mechanisms focus on whole block auctions such as MEV-Boost while others propose first-come-first serve mechanisms such as the receive-order fairness literature. By focusing only on guaranteeing inclusion we can build many different ordering mechanisms into the state machine. Whole block auctions are particularly interesting given SUAVE’s goal of being an on-chain orderflow auction and block builder for Ethereum.

The mechanism for multiple concurrent block proposers can also be used for decentralized rollup sequencing when implemented at the base layer. Since rollups inherit the censorship resistance of their base layer, current “fork choice sequencing rules” that rely solely on block inclusion are not economically compatible with the block leader’s incentives. This is because the block leader can always make strictly more money by censoring all of the blocks for a given rollup other than their own with the minimum bid or cost - for reasons described in Censorship Resistance in On-Chain Auctions the application has no power to capture any surplus for itself or it’s users.

Through base layer censorship resistance provided by Multiplicity, L2s can run decentralized sequencing rules without needing to worry about leader censorship. This also navigates around the lack of decentralized sequencing infrastructure which is currently an issue for Ethereum L2s.

If the rollup prefers using a secondary sequencing mechanism, Multiplicity using proof-of-stake leader selection serves as a way to not only decentralize leader selection (as in currently proposed designs) but to also decentralize individual block production. This ensures that the surplus of value created in a block can be returned to the application and its users instead of the leader by running censorship resistant blockspace auctions.

Notes

Duality Labs is building multiplicity for an on-chain MEV auction that redistributes value back to liquidity providers to reduce LVR. The v1 is largely inspired by ABCI++ and being built with custom add-ons to Tendermint and ABCI 1.0 (PrepareProposal and ProcessProposal), but is generalizable to most leader-based PoS consensus algorithms through the previously described steps. We plan on open sourcing a repo in Q2 2023. In the meantime feel free to reach out for partnerships and collaboration on twitter: @PossibltyResult.

Big shoutout to Zaki Manian for leading us down the right path for a practical implementation of multiple concurrent block proposers.

2 Likes
2

Nice post! It kind of reminds me of 1) Themis, but you ignore the ordering it imposes and 2) the decentralised order flow distributer proposal.

Conditional tipping rules where the transaction tip is only split among the proposers who include a transaction can be used to improve censorship resistance even further. Conditional tipping logic increases the cost of censorship by making colluding equilibria less stable.

It would be interesting to see how this is actually implemented and what the leader’s incentives are to pay the tips.

I also wonder how you would combat the dynamic arising from non-leader validators waiting to the last possible moment to increase their bundle (therefore tip) size, especially in a stake-weighted setup.

3

Thanks for sharing. I’m new here and look forward to reading your paper. This reminds me of how it sounds like the Flashbots relay sits in a monopoly position. Is the idea that by requiring MEV transactions to be included by many proposers, it makes it ineffective to pay all proposers to get everyone to include it with the leader? So if the transaction fee is t, you basically have to pay t+nb where n is the number of bribes b you would have to pay. I guess I’m kind of confused if you a searcher is willing to pay a bribe and it shows up as a high transaction fee, are those fees some how shared with the block proposers and not just the leader? Sorry if my question doesn’t quite make sense!

4

What do you mean re: “what the leader’s incentives are to pay the tips?”

The leader has some control over which transaction payloads are included and which aren’t, but they don’t choose whether to pay the tips or not, this would be defined in the state machine (“application / binary level”)

Re: the dynamic of waiting, I think this might be more of a feature than a bug. It incentivizes validators to optimize their payloads to wait as long as possible in order to include more bids (in the individual tx case) or run more effective combinatorial auctions (in the full block case). Of course if they wait too long they won’t be included, but ideally they’re doing whatever is highest EV.

5

Yeah the idea is that if a single leader can decide what’s included or not, the cost to bribe the leader (via off-chain auctions) is cheap relative to if tx inclusion is decided by more than one leader - since you need to bribe all of them.

A little confused about the last question but this may help w/ your understanding: in this model the tip that a validator receives is conditional on how many other validators include it. The searcher / user never needs to pay a higher tip than they expect, but the validator’s rewards are dependent on how many others include it.

6

I see what you are saying I think- only one validator gets the tip, but it depends on how many other validators also included the tx?

I was thinking you had to bribe all the validators to include it, so the bribe gets watered down the more validators include it.

7

The tip get’s split up among the validators that include a tx. The more validators that include the less each individually receives. The reason this becomes more expensive to bribe is because if a briber only bribes n-1 of the proposers of the n total proposers, then the one not bribed will receive the entire tip, so that’s how much they’ll expect to be paid in order to censor the tx.