by @feng @0xdabaojian

tldr

• Proposer delegation is crucial for Based Rollups due to the increased hardware requirements, L2 state synchronization, and expertise needed for transaction sequencing.
• The ideal preconfirmer selection mechanism should be ex-ante, compatible with PBS, and clearly delineate responsibilities between the delegator and delegatee.
• Centralization risk and multi-block MEV should be carefully considered when designing the selection mechanism.
• The Selection Game framework models the selection process as a multi-agent game with three stages: pre-selection, selection, and post-selection.
• The article analyzes several selection mechanisms, including first-price English auction, one-holder-one-ticket lottery, one-holder-multiple-ticket lottery, and execution ticket.
• By tweaking the probability function $f_P$ and the design of participant states $S$, the framework provides tools to achieve various design goals, such as encouraging decentralization or preventing consecutive winners.
• Implementing these mechanisms in practice presents challenges related to randomness sources, programmability, and gas costs. ZK coprocessors, like Axiom, offer a promising solution for implementing exotic allocation functions while ensuring integrity and reducing on-chain costs.

Background

Following from the last post on Proposer Commitment, in this article, we shift our focus to the delegation mechanism often seen in proposer commitment schemes, particularly in the context of preconfirmation.

Proposer Delegation

Proposer delegation today commonly serves two purposes

1. Delegation for Operational Complexity
   • By design, proposers are meant to be “lazy”. The ideal validator setup is to sync an execution client and consensus client then never touch it again. This is to encourage the decentralization of validator set. Proposer commitments, unless baked into the protocol via proposals like PEPC, generally requires sophistication in addition to the vanilla validator setup. As such, proposer commitment may require delegating the task to third parties to alleviate the complexity of handling commitments directly.
2. Delegation for Trust
   • Proposers, having control over the content of the block, could exploit the "last look" advantage by re-arranging the transaction sequence. The current overarching approach is to delegate the commitment process to a trusted party. This party pledges not to violate the intended protocol behavior, often through social consensus.

A prime example of delegation in action is the current PBS architecture on the Ethereum L1. Under MEV-Boost, the validator-proposer delegates two critical tasks to relays:

1. Block simulation & propagation: Relays are responsible for simulating the block for validity and propagating the block to the network to reduce the burden on the proposer.
2. Fee confirmation: Relays ensure the receipt of payment from the block builder. To achieve this, the relay must examine the block submission, thus being trusted by the block builder to not alter the block content.

Preconfirmation Delegation

For the design of Based Preconfirmation for Based Rollups, delegation is also crucial, as sequencing transactions for L2s minimally requires: