By @Stanley He

Ethereum currently has one proposer per slot, hence the “proposer monopoly” when it comes to transaction inclusion and ordering, which is intuitively bad for censorship resistance (CR) - one single entity can censor any transaction he wants in a block. The problem worsens under PBS, where the majority of Ethereum blocks are built by only 3 builders, 2 of which are trading firms.

Proposed solutions for CR like inclusion list and fork choice enforced inclusion list (FOCIL) aim at introducing constraints to block proposers. But the most debated proposal recently is Braid by Max from SMG, which breaks the proposer monopoly completely by having multiple proposers propose for one block simultaneously without a leader aggregating the results.

It’s tempting to reach a seemingly easy conclusion that with multiple concurrent proposers (MCP), preconfirmation will be broken, because there will no longer be a single proposer who can provide deterministic guarantee for transaction inclusion/execution.

Nonetheless, we will show in this article that MCP looks exactly like preconfirmation. And the remaining differences will even push MCP to almost fully resemble preconfirmation with the evolving MEV dynamics.

Collective block building - the core for both MCP and Preconf

MCP is simple. The following is a direct copy paste from Max’s slide:

  1. Run k separate parallel chains using the same validator set.
  2. All chains are synchronized.
  3. The block in slot i is the union of all transactions in slot i of all k chains.
  4. After consensus on the union, execution/state transition occurs using agreed upon deterministic rules.

It’s not hard to see that the essence of MCP is collective block building that is immune from manipulation of any leader. That’s where CR arises. Interestingly, this is exactly how Luban does preconfirmation with Taiyi.

In short, Taiyi allows for anyone to purchase future blockspace with economic guarantee from proposers. Unlike the more conventional approach to preconf, where a preconf buyer needs to provide transaction content when buying the preconf, Taiyi offers what we call assignability to preconfs: a buyer can buy blank blockspace in advance, and only submit transaction call data later when the block for preconf arrives. Assignability is the key feature that makes it possible for applications to buy preconf for their users, because it is impossible for dapps to predict what transactions they will receive from users. For more detailed discussion on this, see our previous article.

Preconf with Taiyi is another way of collective block building. Preconf buyers in Taiyi share a very similar role with proposers in MCP: They can include transactions in a block, without worrying about being censored. Of course, MCP does provide stronger CR with leaderless-ness (more on this later), while in Taiyi, a proposer can still censor by not selling preconf to certain addresses. Nonetheless, preconf still weakens the proposer’s monopoly on transaction inclusion.

image.png

The remaining differences

Besides multiple proposers, two other features define MCP: