Thanks to Max, Auston and Jason for discussion & feedback

***

Historically, points of contact between Layer1 validators and the broader scaling ecosystem around Layer2s and rollups have been fairly indirect. With the advent of based sequencing we are about to experience new dynamics in this interaction.

Following the introduction of Proposer-Builder-Separation (PBS), transaction paths from users to proposers became significantly more complex. This complexity stemmed from the emergence of various intermediaries within the MEV supply chain, which collectively created a highly performant, low-latency, out-of-protocol message passing system culminating in the L1 proposer signing off the content of a new block.

Concurrently, the rollup-centric roadmap gained traction. This involved off-chain transaction execution with on-chain proof verification, usually facilitated by highly performant, centralized sequencers ordering rollup users' transactions. This division of labour enabled cheaper transactions and increased overall economic activity, ultimately settling on the L1. However, modularity also has led to growing interoperability challenges between rollups and the L1.

The concept of based sequencing (and proposer commitments such as based preconfirmations more broadly) was introduced to address this fragmentation and enhance interoperability. It was explicitly not intended to resolve shortcomings of PBS. Instead, it aims to decentralize rollup sequencers by replacing them with the L1 validator set – the most credibly neutral sequencer available – and by leveraging the attached, high-performance PBS infrastructure.

However, replicating the 2017-Ethereum-era user experience with low fees and synchronous contract calls allowing for yet another DeFi summer is challenging. Achieving shared sequencing and synchronous composability across rollups and L1 is technically complex. One of the biggest hurdles lies in providing credible based preconfirmations to emulate the user experience offered by centralized rollup sequencers.

More recently, rollup teams have warmed up to the idea of becoming based, and more specific implementation frameworks and migration initiatives have started to demonstrate concrete paths forward.

In the following, we want to zoom in on the implications and potential designs for the last mile of communication between a validator (proposer) and a delegated sequencer, while leaving the intricacies of the relationship between delegated sequencers and rollup users mostly out of scope.

L1 proposers can provide additional value to Ethereum by helping to defragment the ecosystem, allowing for less brittle developer and user experience, stronger network effects, and increased economic activity on Ethereum. In exchange for offering new services, they may receive additional streams of yield, specifically preconfirmation tips, a premium which users are willing to pay for the UX of receiving near-instant transaction confirmations.

“…a proposer creates the specs, or the template, by which the resulting block must be created, and the builders engaged by the proposer are tasked with delivering the block according to its specifications.” - source

While proposer commitments rely heavily on the existing PBS infrastructure, there is one important difference between them and simply extending the mev-boost-style interactions between validators and relays: In order to provide proposer commitments, proposers are required to bring additional collateral, which cryptoeconomically secures proposer commitments and is supposed to disincentivise proposers from reneging on their promises.

Running numerous rollup full nodes to sequence (cross-)rollup transactions and preconfirm large amounts of user transactions requires significant computational and bandwidth resources.  Instead of taking on these tasks themselves, L1 validators can delegate sequencing and preconfirmation duties to gateways. Gateways are newly introduced sequencing entities that provide preconfirmations to L1 & L2 users on behalf of L1 proposers and can be thought of as auction houses for proposer commitments. Entities that operate relays are naturally well positioned to serve as gateways.

If proposer commitments required validators to self-host multiple rollup full nodes, or multiple sidecars and frequently choosing from app-store-like commitment-type subscriptions, we would further unlevel the playing field amongst proposers, ultimately hurting the legitimacy of based sequencing and potentially render the concept socially unviable. As of today, sophisticated staking operators already have an edge over solo stakers as they benefit from economies of scale in order to play timing games and farm on average higher staking yields due to MEV-smoothing. Since a decentralised validator set is the ultimate bulwark of Ethereum PoS, we want to shield validators from further sophistication at all cost.

Ideally, the barrier-to-entry for operating a gateway should be as low as possible. One potential approach to incentivize gateways after an initial bootstrapping phase is to allow them to collect a portion of the preconfirmation tips.

In the current design proposal, gateways (much like relays) host a two-sided-marketplace, receiving bids for blocks from the commitments-pipeline (e.g. rollup users) while being constrained by proposers (to honor the commitments).

By contrast to relays, proposers delegate to one gateway per slot. Rational proposers will delegate to the gateway delivering the highest value of additional yield from proposer commitments, increasing concerns about gateway centralisation.

However, it could be argued that a gateway monopoly for each slot may be less problematic than initially thought:

In the current PBS design, proposers can delegate to multiple relays per slot, which is why builders are not sufficiently incentivized to send their order flow (later: preconfirmation flow) beyond a minimum number of reliable relays that have a majority of proposers delegating to them. This lack of incentive for builders to spread their order flow results in insufficient competition among relays and forces relay operators to compete on business development, rather than DevOps merit.

With gateways by contrast, builders have an incentive to integrate with as many gateways as possible, given that even a small amount of proposers delegating to gateways which builders are not serving with preconfirmations may disrupt the preconf-UX of based rollup users significantly.

Even if it turned out that proposers delegated to only a small number of gateways - similarly to relays today - resulting in an oligopolistic sequencing market, we would still end up in a strictly better scenario than rollups being centrally sequenced.

Bonding gateways and making them subject to slashing conditions, moreover, serves as incentive alignment with L1 proposers, who despite high-trust assumptions in gateways have low switching costs in case gateways lose reputation.

Given the large number of solo stakers serving the network, we should aim to simplify the process of distributing proposer commitments while maintaining validators as dumb pipes. One potential approach to achieve this could include the following actions:

1. One-Time Opt-In Operation

• Validators signal their interest in becoming "preconfers" through a one-time on-chain operation.

• This involves placing a minimal amount of collateral (e.g., 1 or 2 ETH) to ensure accessibility due to low bond requirements.

2. Running a Single Validator Sidecar

• Validators run one lightweight sidecar (e.g. Commit-Boost) to offer enhanced commitment types, similar to mev-boost. For simplicity reasons, validators ideally only need to run one single sidecar in the future. Diversity among sidecar implementations remains desirable regardless.

• Configuration: Validators select delegates (gateways) mainly based on reputation using a local configuration file, operating mostly in a "set-and-forget" mode (similar to configuring relays today)

• Interaction: The interaction between validators and gateways resembles a simple get_header / submit_signed_header flow, similar to current PBS.

3. Off-Chain Gateway Switching

• The sidecar enables off-chain switching between gateways.

• Registration: Registering with a gateway occurs off-chain and includes a commitment to adhere to slashing conditions.

4. Choosing From Multiple Gateway Endpoints

• Gateways can offer various endpoints, including e.g. out-of-protocol Inclusion List endpoints, similar to non-censoring "ethical" relays post-merge.

• Partially altruistic proposers hereby may actively minimise gateway centralisation risks.

• Gateway endpoints can be curated by the community, e.g. by EthStaker.

All this is to demonstrate that if proposers fully delegate heavy duties, their node operation experience will not be significantly different from today.

The relationship between proposers and gateways involves high levels of trust by design. Therefore, proposers need to hold gateways responsible for safety faults, such as providing invalid blocks. Conversely, gateways need to hold proposers accountable for liveness faults, such as going offline and not fulfilling preconfirmation promises. Slashing the proposer collateral or the gateway's bond is one way to enforce this accountability. Proposers are incentivized to monitor key metrics to ensure the reliability and efficiency of gateways. This alignment of incentives helps maintain the security and robustness of the system through delegation. If a liveness fault occurs that is not the proposer's fault, they are expected to seek compensation from gateways through off-chain mechanisms. It is worth pointing out that cases of ambiguous fault attributability remain partially open design questions.

Note: one way to reduce trust in gateways going forward could be to explore running gateway logic inside trusted execution environments.

Delegating heavy duties away from validators aligns with potential futures of the Ethereum protocol. Recent research directions point towards unbundling staking tasks. Additionally, research into separating attestation from proposing duties (APS) introduces the role of sophisticated execution proposers, which could act as shared sequencers and proposer commitment providers. This will only be compounded by the rapidly approaching tasks around real-time ZK-proving the EVM.

Meanwhile and when the chips are down, the broader Ethereum community will have come up with different approaches to address and solve interoperability issues.

Nevertheless, it is not far-fetched to expect proposer commitments to happen out-of-protocol for the foreseeable future. It also seems worthwhile to keep in mind that any solution - be it delegation or non-delegation - can be implemented permissionlessly in the absence of Ethereum governance. This post aimed to demonstrate that, in line with Ethereum’s ethos, delegating heavy duties to specialized entities is preferable to overloading validators.

Thanks to Max, Auston and Jason for discussion & feedback

***

Historically, points of contact between Layer1 validators and the broader scaling ecosystem around Layer2s and rollups have been fairly indirect. With the advent of based sequencing we are about to experience new dynamics in this interaction.

Following the introduction of Proposer-Builder-Separation (PBS), transaction paths from users to proposers became significantly more complex. This complexity stemmed from the emergence of various intermediaries within the MEV supply chain, which collectively created a highly performant, low-latency, out-of-protocol message passing system culminating in the L1 proposer signing off the content of a new block.

Concurrently, the rollup-centric roadmap gained traction. This involved off-chain transaction execution with on-chain proof verification, usually facilitated by highly performant, centralized sequencers ordering rollup users' transactions. This division of labour enabled cheaper transactions and increased overall economic activity, ultimately settling on the L1. However, modularity also has led to growing interoperability challenges between rollups and the L1.

The concept of based sequencing (and proposer commitments such as based preconfirmations more broadly) was introduced to address this fragmentation and enhance interoperability. It was explicitly not intended to resolve shortcomings of PBS. Instead, it aims to decentralize rollup sequencers by replacing them with the L1 validator set – the most credibly neutral sequencer available – and by leveraging the attached, high-performance PBS infrastructure.

However, replicating the 2017-Ethereum-era user experience with low fees and synchronous contract calls allowing for yet another DeFi summer is challenging. Achieving shared sequencing and synchronous composability across rollups and L1 is technically complex. One of the biggest hurdles lies in providing credible based preconfirmations to emulate the user experience offered by centralized rollup sequencers.

More recently, rollup teams have warmed up to the idea of becoming based, and more specific implementation frameworks and migration initiatives have started to demonstrate concrete paths forward.

In the following, we want to zoom in on the implications and potential designs for the last mile of communication between a validator (proposer) and a delegated sequencer, while leaving the intricacies of the relationship between delegated sequencers and rollup users mostly out of scope.

L1 proposers can provide additional value to Ethereum by helping to defragment the ecosystem, allowing for less brittle developer and user experience, stronger network effects, and increased economic activity on Ethereum. In exchange for offering new services, they may receive additional streams of yield, specifically preconfirmation tips, a premium which users are willing to pay for the UX of receiving near-instant transaction confirmations.

“…a proposer creates the specs, or the template, by which the resulting block must be created, and the builders engaged by the proposer are tasked with delivering the block according to its specifications.” - source

While proposer commitments rely heavily on the existing PBS infrastructure, there is one important difference between them and simply extending the mev-boost-style interactions between validators and relays: In order to provide proposer commitments, proposers are required to bring additional collateral, which cryptoeconomically secures proposer commitments and is supposed to disincentivise proposers from reneging on their promises.

Running numerous rollup full nodes to sequence (cross-)rollup transactions and preconfirm large amounts of user transactions requires significant computational and bandwidth resources.  Instead of taking on these tasks themselves, L1 validators can delegate sequencing and preconfirmation duties to gateways. Gateways are newly introduced sequencing entities that provide preconfirmations to L1 & L2 users on behalf of L1 proposers and can be thought of as auction houses for proposer commitments. Entities that operate relays are naturally well positioned to serve as gateways.

If proposer commitments required validators to self-host multiple rollup full nodes, or multiple sidecars and frequently choosing from app-store-like commitment-type subscriptions, we would further unlevel the playing field amongst proposers, ultimately hurting the legitimacy of based sequencing and potentially render the concept socially unviable. As of today, sophisticated staking operators already have an edge over solo stakers as they benefit from economies of scale in order to play timing games and farm on average higher staking yields due to MEV-smoothing. Since a decentralised validator set is the ultimate bulwark of Ethereum PoS, we want to shield validators from further sophistication at all cost.

Ideally, the barrier-to-entry for operating a gateway should be as low as possible. One potential approach to incentivize gateways after an initial bootstrapping phase is to allow them to collect a portion of the preconfirmation tips.

In the current design proposal, gateways (much like relays) host a two-sided-marketplace, receiving bids for blocks from the commitments-pipeline (e.g. rollup users) while being constrained by proposers (to honor the commitments).

By contrast to relays, proposers delegate to one gateway per slot. Rational proposers will delegate to the gateway delivering the highest value of additional yield from proposer commitments, increasing concerns about gateway centralisation.

However, it could be argued that a gateway monopoly for each slot may be less problematic than initially thought:

In the current PBS design, proposers can delegate to multiple relays per slot, which is why builders are not sufficiently incentivized to send their order flow (later: preconfirmation flow) beyond a minimum number of reliable relays that have a majority of proposers delegating to them. This lack of incentive for builders to spread their order flow results in insufficient competition among relays and forces relay operators to compete on business development, rather than DevOps merit.

With gateways by contrast, builders have an incentive to integrate with as many gateways as possible, given that even a small amount of proposers delegating to gateways which builders are not serving with preconfirmations may disrupt the preconf-UX of based rollup users significantly.

Even if it turned out that proposers delegated to only a small number of gateways - similarly to relays today - resulting in an oligopolistic sequencing market, we would still end up in a strictly better scenario than rollups being centrally sequenced.

Bonding gateways and making them subject to slashing conditions, moreover, serves as incentive alignment with L1 proposers, who despite high-trust assumptions in gateways have low switching costs in case gateways lose reputation.

Given the large number of solo stakers serving the network, we should aim to simplify the process of distributing proposer commitments while maintaining validators as dumb pipes. One potential approach to achieve this could include the following actions:

1. One-Time Opt-In Operation

• Validators signal their interest in becoming "preconfers" through a one-time on-chain operation.

• This involves placing a minimal amount of collateral (e.g., 1 or 2 ETH) to ensure accessibility due to low bond requirements.

2. Running a Single Validator Sidecar

• Validators run one lightweight sidecar (e.g. Commit-Boost) to offer enhanced commitment types, similar to mev-boost. For simplicity reasons, validators ideally only need to run one single sidecar in the future. Diversity among sidecar implementations remains desirable regardless.

• Configuration: Validators select delegates (gateways) mainly based on reputation using a local configuration file, operating mostly in a "set-and-forget" mode (similar to configuring relays today)

• Interaction: The interaction between validators and gateways resembles a simple get_header / submit_signed_header flow, similar to current PBS.

3. Off-Chain Gateway Switching

• The sidecar enables off-chain switching between gateways.

• Registration: Registering with a gateway occurs off-chain and includes a commitment to adhere to slashing conditions.

4. Choosing From Multiple Gateway Endpoints

• Gateways can offer various endpoints, including e.g. out-of-protocol Inclusion List endpoints, similar to non-censoring "ethical" relays post-merge.

• Partially altruistic proposers hereby may actively minimise gateway centralisation risks.

• Gateway endpoints can be curated by the community, e.g. by EthStaker.

All this is to demonstrate that if proposers fully delegate heavy duties, their node operation experience will not be significantly different from today.

The relationship between proposers and gateways involves high levels of trust by design. Therefore, proposers need to hold gateways responsible for safety faults, such as providing invalid blocks. Conversely, gateways need to hold proposers accountable for liveness faults, such as going offline and not fulfilling preconfirmation promises. Slashing the proposer collateral or the gateway's bond is one way to enforce this accountability. Proposers are incentivized to monitor key metrics to ensure the reliability and efficiency of gateways. This alignment of incentives helps maintain the security and robustness of the system through delegation. If a liveness fault occurs that is not the proposer's fault, they are expected to seek compensation from gateways through off-chain mechanisms. It is worth pointing out that cases of ambiguous fault attributability remain partially open design questions.

Note: one way to reduce trust in gateways going forward could be to explore running gateway logic inside trusted execution environments.

Delegating heavy duties away from validators aligns with potential futures of the Ethereum protocol. Recent research directions point towards unbundling staking tasks. Additionally, research into separating attestation from proposing duties (APS) introduces the role of sophisticated execution proposers, which could act as shared sequencers and proposer commitment providers. This will only be compounded by the rapidly approaching tasks around real-time ZK-proving the EVM.

Meanwhile and when the chips are down, the broader Ethereum community will have come up with different approaches to address and solve interoperability issues.

Nevertheless, it is not far-fetched to expect proposer commitments to happen out-of-protocol for the foreseeable future. It also seems worthwhile to keep in mind that any solution - be it delegation or non-delegation - can be implemented permissionlessly in the absence of Ethereum governance. This post aimed to demonstrate that, in line with Ethereum’s ethos, delegating heavy duties to specialized entities is preferable to overloading validators.