Some quick thoughts about how multiple concurrent proposers (MCP), FOCIL and preconfirmations (or more generally, proposer commitments) interact. ### Multiple Concurrent Proposers Multiple concurrent proposers (MCP from now on) is a proposal to break up the proposer monopoly by introducing (wait for it) more than 1 proposer to propose a partial block per slot.[^1][^2] These partial blocks are then *merged* to form the full block for that slot. It also proposes a conditional tipping mechanism to create competition between the proposers for including a certain transaction. In short, the aim is to increase the short-term censorship-resistance of the protocol. There are 2 things to consider in the merging implementation: - **Which transactions get included**: the paper proposes a *union* of the lists of proposed transactions, to maximize throughput and censorship-resistance. This means that if even just one of the proposers outputs a valid transaction, it will be included in the final block. *Edit: after some [thoughtful](https://x.com/barnabemonnot/status/1818672217477054952) [responses](https://x.com/_julianma/status/1818740327726911936) I realized it's actually more nuanced than that in cases of congestion (when the gas limit is reached). Depending on the ordering / merging rule, the transaction might have a chance of not being included.* - **How these transactions are ordered**: since each of the proposers might output a completely different ordering, there needs to be a deterministic ordering rule when merging these blocks. This is not handled in the paper, some ideas like priority fee ordering are outlined elsewhere.[^3] We will get back to the merging implementation later. ### FOCIL Fork-choice enforced inclusion lists are an implementation of inclusion lists that are enforced by a committee.[^4] FOCIL introduces a new committee that broadcasts out their local, subjective view of the mempool some time before the next proposal. The proposer then collects these local views and *merges* them into an aggregate, which it then proposes in its block. The block validity (fork-choice) is then dependent on whether this aggregate is good enough, meaning that the attesters will only vote for the block if it matches their aggregated view of the gossiped lists of transactions of each committee member. The way transactions are merged or aggregated is also a *union*. This means that it looks very similar to MCP -- each IL committee member can be thought of as one of the proposers. The difference is that the *actual* proposer still has a monopoly over other transactions and their ordering, which this proposal doesn't try to address. It just addresses the censorship-resistance problem. ### Preconfirmations & other proposer commitments Both proposals restrict the power of a single proposer over transaction inclusion, but MCP additionally restricts the power over ordering. **This means that MCP is fundamentally incompatible with execution preconfirmations, or any other proposer commitments that require a monopoly over ordering**. This is not the same with FOCIL, where there is still a leader with monopoly over the non-IL part of the block. What about commitments about inclusion (inclusion preconfirmations)? Both proposals are still compatible with inclusion preconfirmations. *In fact, they might even improve the UX of inclusion preconfirmations due to introducing more actors that can influence the contents of the final block and thus credibly provide inclusion guarantees*. The presence of multiple preconf providers resembles a leaderless system and could foster competition on preconf pricing.[^5] This is especially true with MCP: since the final proposed block is *guaranteed*[^6] to contain all valid transactions from all proposers in the slot, you just need a preconfirmation from 1 of them to be safe (the proposer can of course still miss his proposal, so to increase the probability of inclusion one could request a preconf from more of them). This means that in a multi-proposer system, inclusion commitments would require *less* proposer opt-in (1/N) than a leader-based system. Can we do the same with FOCIL? I.e. can we just request an inclusion commitment from any IL committee member? The function that attesters use to determine the validity of the proposed IL is the following: $\text{Eval}(IL_{\text{agg}}^{\text{attester}}, IL_{\text{agg}}^{\text{proposer}}, \Delta) = \begin{cases} \text{True} & \text{if } \frac{|IL_{\text{agg}}^{\text{attester}} \cap IL_{\text{agg}}^{\text{proposer}}|}{|IL_{\text{agg}}^{\text{attester}}|} \geq \Delta \\ \text{False} & \text{otherwise} \end{cases}$ Where $\Delta$ is some parameter determining how much overlap there should be between the local aggregate of the attesters and the observed aggregate in the block. It determines the "wiggle room" of the proposer in terms of what he includes in the aggregate, and thus is not as fault-proof as MCP. Note that this wiggle room is required because of various factors such as the potential unreliability and inherint delays of the underlying gossip network. Also note that most likely, the IL implementation will be *conditional* on there being space in the block.[^7] This means that just getting an inclusion preconf from an IL committee member might not provide enough guarantees, and one might still have to go directly to the leader. ### Conclusion View-merge protocols like MCP and FOCIL can potentially improve the UX of inclusion commitments by having multiple actors define the contents of a block. Whether this holds up in practice depends on the implementation: in FOCIL for example, getting a commitment from anyone *but* the proposer can only provide a probabilistic guarantee. However, getting commitments from multiple committee members might get that probability close enough to 100%. In MCP, unless there's a liveness fault, getting an inclusion commitment from a single proposer for the slot provides the same guarantees as getting an inclusion commitment from a monopolistic leader. [^1]: https://www.mechanism.org/spec/01 [^2]: https://ethresear.ch/t/concurrent-block-proposers-in-ethereum/18777 [^3]: https://ethresear.ch/t/execution-consensus-separation/19964#execution-layer-3 [^4]: https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal [^5]: https://ethresear.ch/t/leaderless-and-leader-based-preconfirmations [^6]: As mentioned in the edit above, this is not always going to be the case: a) when the gas limit is reached and that transaction is dropped by some ordering rule, and b) when there is a missed partial block from a proposer due to downtime or network issues. It's actually similar to FOCIL in that regard, except that the "wiggle room" is less clearly defined. [^7]: https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870#textil-conditionality-17