by @0xdabaojian

Abstract

This post proposes a design for a consensus-based preconfirmation protocol with multiple concurrent proposers. It aims to enhance censorship resistance and experiment with multiple concurrent proposer schemes out of the protocol, potentially paving the way for future in-protocol implementations.

Background

Current designs for preconfirmation protocol on L1 and L2(aka based preconfirmation) typically involve a single preconfirmer, be it the L1 proposer or a chosen delegatee. This design expands the single leader design by introducing a preconfirmer consensus set, drawing inspiration from FOCIL, Execution Consensus Separation and Multiplicity: A Gadget for Multiple Concurrent Block Proposers.

Goal

This design aims to increase censorship resistance by distributing the preconfirmation process across multiple entities for both L1 and L2 preconfirmations. It also serves as a testbed for multiple concurrent proposer schemes, which could inform future protocol-level implementations.

<aside> 💡 Notes:

1. this design is not meant to create an out-of-protocol implementation of multiple concurrent proposers for full blocks. It is meant to create a PartialBlock that is a subset of L1 fullblock. In this regard, it bears reseblance to FOCIL, where inclusion list is only a part of the full block, and Multiplicity, where the design is not prescriptive about the block being built only with the “special bundles”
2. Exactly where to place the PatialBlock. be it TOB or BOB, is up for further discussion.
3. The rest of the article assumes implementation based on an L1 preconfirmation protocol. However, it should be forward compatible with L2 Based Preconfirmation without significantly breaking the proposed architecture. </aside>

System Requirements

A Fast Finality Preconfirmer Consensus Set:

• A group of (re)staked validators opted into the preconfirmation consensus protocol
• Responsible for 1) creating individual unordered blocks and 2) participating in attestation.

Shared Mempool:

• A shared mempool where users submit preconfirmation requests.
• Accessible to all staked preconfirmers in the consensus set for block creation.

Current Slot Preconfirmer:

• A rotating role among the consensus set. By default it’s the current slot Ethereum L1 proposer, or proposer’s delegated preconfirmer
• Responsible for ordering transactions and creating the final PartialBlock.

Conditional Tipping Mechanism:

• A fee structure that rewards preconfirmers based on inclusion rates.

Proposer Commitment Sidecar

• A Commit-Boost style sidecar software that facilitates proposer commitments

Trusted Relay:

• Ensures that blocks submited to the opted-in proposers contains the preconfirmed transactions

Block Ordering Algorithm:

• Used by the current slot preconfirmer to sort transactions based on priority fees and attestors to attest the transaction ordering

Inclusion Threshold:

• Ensures only transactions included by 2/3+ of preconfirmers make it to the joint block.

Flow

1. Proposer Opt-in via Restaking: Proposers stake in a restaking protocol to signal their participation in the preconfirmation system. This commitment ensures they'll honor their preconfirmations.

   Note: Staking not only enable one proposer to become a PartialBlock proposer, but also participate in PartialBlock creation and attestation while other opt-in proposers are proposing