# On Multi-proposer Gadgets and Protocols


by [Thomas Thiery](https://x.com/soispoke) – Tuesday; August 27th, 2024.

_Thanks to [Julian Ma](https://x.com/_julianma), [Barnabé Monnot](https://x.com/barnabemonnot), [Anders Elowsson](https://x.com/weboftrees) and [Max Resnick](https://x.com/MaxResnick1) for the very helpful comments and feedback._

## **Introduction**

A lot of attention has recently been focused on block co-creation by multiple proposers on Ethereum. The multiple proposers idea is broad enough to create compelling narratives and emphasize the need to strengthen the protocol’s censorship resistance (CR) properties. However, the discussion often fails to capture the nuances between different proposals and the various ways to achieve that goal. In this note, I hope to disambiguate ***gadgets*** like [FOCIL](https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870) from new ***protocols*** like [BRAID](https://x.com/danrobinson/status/1820506643739615624) by highlighting their drastically different approaches to CR and MEV.

*Disclaimers:*

- *When FOCIL is mentioned in this post I refer to it as an IL aggregation mechanism per say, but also as FOCIL with properties (e.g., conditional enforcement, anywhere-in-block) that put minimal constraints on the block producer. The latter part goes beyond the mechanism itself, and is more of a personal opinion about what the philosophy behind FOCIL’s design could be.*
- *I obviously know a lot more about FOCIL than BRAID so expect to see thoughts and opinions from this perpective.*
- *Highlighting differences between FOCIL and BRAID does not mean they’re incompatible, or going in an opposite direction.*

## **Scope**

### FOCIL

On the one hand, Fork-Choice Enforced Inclusion Lists (FOCIL) can be thought of as a ***gadget*** or add-on to the existing Ethereum protocol. In each slot, a committee of validators is elected to create local lists of transactions based on their view of the public mempool. The block producer (BP) must include the aggregate of transactions from these local lists in its block for it to be considered valid. This new validity condition is enforced by attesters, who observe the local lists, the aggregate inclusion list (IL), and the payload that was ultimately constructed. Based on their observations, they determine whether the block is valid and vote accordingly.

Importantly, FOCIL’s scope is quite narrow. The only thing it is designed for is allowing multiple validators to force-include a set of transactions into blocks, thereby improving CR properties by preventing a few builders from arbitrarily deciding what does or does not go into an Ethereum block. *It does not care about ordering rules or MEV, fairness or redistribution.* On the contrary, I think the [philosophy](https://ethresear.ch/t/uncrowdable-inclusion-lists-the-tension-between-chain-neutrality-preconfirmations-and-proposer-commitments/19372) behind FOCIL’s current design is to let sophisticated builders handle all this, and order transactions as they please as long as they include transactions given by the FOCIL committee. This is because again, FOCIL's scope is not to solve MEV (whatever 'solving MEV' in a decentralized setting means) and there are plenty of other ideas and acronyms ([EAs](https://mirror.xyz/barnabe.eth/QJ6W0mmyOwjec-2zuH6lZb0iEI2aYFB9gE-LHWIMzjQ), [ETs](https://ethresear.ch/t/execution-tickets/17944), [MEV-burn](https://ethresear.ch/t/mev-burn-a-simple-design/15590/4)) to address some of the negative externalities MEV imposes on the protocol. To expand on this a bit more, I think trying to have a small committee impose ordering constraints on MEV-extracting parties will only result in MEV being pushed elsewhere (maybe in less transparent ways?), and/or [crowd](https://ethresear.ch/t/uncrowdable-inclusion-lists-the-tension-between-chain-neutrality-preconfirmations-and-proposer-commitments/19372) the inclusion list by playing [bribing and extortion games](https://ethresear.ch/t/fun-and-games-with-inclusion-lists/16557) with committee members. Following this line of thought, FOCIL purposefully allows the BP to get the “last look” and the “last say” on transactions ordering. BPs are even allowed not to include transactions from the inclusion list if their block is full (i.e., conditional IL property) in the current version of FOCIL. One of the reasons is that if some blockspace were dedicated to IL transactions, it would be very easy for a sophisticated builder to bribe IL committee members and ensure that their valuable transactions are included anyway. However, if the block is not full, transactions in the IL aggregate ***must*** be included in the payload, and the BP has limited agency over this (with delta giving the bound). If the BP excludes transactions, the block just won’t be valid, and won’t get any consensus or execution layer rewards. Note that things could get even worse for BPs who choose not to propose a block if missed slot penalties are introduced.

It is worth mentioning a potential limitation of focusing on gadgets that deal with CR (FOCIL), timing games (APS), and MEV redistribution (MEV-burn) in isolation. There is a risk of gadgets competing over resources or time allocation within a given slot, and we also don't want to overload attesters with too many additional tasks. This underscores the importance of integrating these potential upgrades to ensure they are compatible with each other. For example, we are currently spending some time evaluating how ePBS and FOCIL fit together.

### BRAID

To me, BRAID sits at the other end of the spectrum with a much broader scope by trying to both improve CR ***and*** "solve MEV". Multiple proposers in BRAID run parallel chains, each responsible for building an entire sub-block. The union of transactions in these sub-blocks then makes up the complete block for a given slot. After consensus is reached on the union, an ordering rule (e.g., by priority fees) strictly determines the sequence in which transactions should be executed. By having multiple proposers determine the content of the complete block, coming to consensus on what transactions will be included and then enforcing an ordering rule at the time of execution, BRAID is designed to both (1) improve CR properties (i.e., preventing a transaction from being included in a block would require bribing multiple proposers) and “solve” MEV. And it does so by trying to create an entirely new ***protocol***, with a new consensus mechanism, new rules and timings for executing transactions, probably different requirements from validators, and the list goes on. Two things that keep being mentioned:

- There is no need for a special block producer with BRAID, the protocol is leaderless.
- *This is definitely a significant difference from FOCIL, where there is still a leader, but the leader lacks the ability to exclude transactions.*
- Issues coming from one proposer having more power than others, such as getting the last look and seeing all other sub-blocks before proposing their own, are somewhat mitigated because (1) dApps will capture most of the MEV, and (2) the proposer with the last look could only be able to capture residual MEV opportunities that were not captured by all the other proposers via inclusion.
- *This part is difficult for me to fully grasp, as knowing the content of all other sub-blocks and the ordering rule (e.g., by priority fees) would allow the last proposers to insert their transactions wherever they want (e.g., arbitrages). We can speculate on what this might mean:*
1. *MEV will go to zero, or rather dApps will capture most of the MEV in the future. While this statement seems to benefit other solutions as well, a protocol like BRAID might push dApps to improve their designs and become MEV-aware to stay relevant. Specifically, if a strict ordering rule is implemented at the protocol level, dApps that send users' transactions non-atomically, rather than in bundles or batches, could face frequent reverts, making them less competitive. However, whether it’s possible to create MEV-aware dApps that are both permissionless and decentralized remains an open question (as [Phil Daian](https://x.com/phildaian) pointed out during [this debate](https://youtu.be/SBOGdofF4u8?si=Za_AamvPlnB325Qf&t=702), taking Cowswap as an example). Furthermore, cross-app MEV extraction opportunities would likely continue to exist.*
2. *Adverse selection between multiple proposers through reversions: A proposer with the last look could in theory revert other proposers' transactions and replace them with their own. Note that the cost of reverting a transaction (e.g., revert a swap by letting it hit its slippage limit) should not exceed profits extracted from a given MEV opportunity. It also remains to be seen whether the residual MEV that the last-look proposer gains from their information rent is large or small. To prevent the last-look proposer from having an unfair advantage, the authors of BRAID consider adding a timelock round using either threshold or time-based encryption. Each option comes with its own set of trade-offs and requirements (e.g., the number of rounds, bandwidth and computational demands, and latency considerations) that might make implementation challenging. Additionally, these options don't resolve the adverse selection issue (e.g., you still gain more information from Binance if you submit your sub-block later). There's also the question of whether encrypting sub-blocks could shift MEV strategies toward statistical arbitrage.*

## Implementation

Neither FOCIL nor BRAID have EIPs or detailed specs yet. However, I think the two proposals are at very different stages of research:

- FOCIL builds on [two](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Version-with-multiple-crList-proposers) [years](https://notes.ethereum.org/Dh7NaB59TnuUW5545msDJQ#) of work on inclusion lists, can reuse much of the code from [EIP-7547](https://eips.ethereum.org/EIPS/eip-7547), and leverages the way committees are already implemented for other purposes (e.g., sync committees). As mentioned earlier, it is considered an add-on to improve CR and recover chain neutrality by using a committee of validators, without making any fundamental changes to how the Ethereum protocol currently works. It was specifically designed to address shortcomings identified in previous inclusion list designs, such as IL equivocation or incompatibilities with Account Abstraction, and we are actively exploring ways for it to be compatible with other EIPs like [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732). There is also a working group focusing on specs and proof-of-concepts, reach out if you’re interested in contributing!
- BRAID is inspired from research on the [economics of censorship resistance](https://arxiv.org/abs/2301.13321), and was recently introduced in [a talk from Max Resnick](https://x.com/danrobinson/status/1820506643739615624) given at a Paradigm research workshop. A recent post looked into [BRAID’s liquidity requirements](https://ethresear.ch/t/censorship-insurance-markets-for-braid/20288), and I’m sure there is a lot of research going on but BRAID is both 1) relatively new and unspecified 2) much broader in scope. In the talk, it was mentioned a new consensus mechanism is needed to make it all work without a huge increase in communication complexity between proposers, but we also don’t exactly know what ordering rule would be chosen yet, what fee markets or block building would look like, how to deal with equivocation, etc… Most of these unknown unknowns were explicitly mentioned by Max Resnick during [this talk](https://x.com/danrobinson/status/1820506643739615624). For now, without details on these core components, it’s difficult to get a good idea of the tradeoffs, the potential attacks, or how the MEV landscape would shift in a protocol like BRAID. But I'm really looking forward to see progress as more research comes out!

## Conclusion

Overall, I’m personally quite happy the narrative recently shifted towards caring more about censorship resistance as a fundamental blockchain property. [Having multiple proposers contribute transactions that must be included in the block does seem to be a good idea](https://x.com/VitalikButerin/status/1820993698106368166), but to me the current version of FOCIL looks like an “implementable” proposal, that can be further improved to cover more ground (e.g., include blobs) or boost adoption (e.g., [IL committee rewards](https://ethresear.ch/t/the-more-the-less-censored-introducing-committee-enforced-inclusion-sets-comis-on-ethereum/18835)). BRAID takes the approach of providing a holistic vision of what a multiple proposers protocol with CR and without MEV would look like, and is trying to get there from the ground up. I'm really looking forward to seeing both approaches explored in parallel in the short/mid-term, with (1) gadgets like FOCIL being iterated on as an improvement to the existing protocol and (2) innovative protocols like BRAID being explored so they both can potentially converge towards the ideal multiple proposers design in the future.