In Ethereum's evolution towards scalability via rollups and layer 2 solutions, block creation duties are increasingly outsourced from proposers (validators) to external block "builders." Most designs for formalizing this proposer-builder separation (PBS) focus on enshrining a specific mechanism, such as a full block auction, to facilitate proposer-builder exchanges. However, restricting the protocol to enabling only one type of exchange may not serve proposers optimally across the diverse spectrum of potential duties they could offload.

Protocol-enforced proposer commitments (PEPC) proposed by Barnabé Monnot in 2022 offers a more flexible approach by providing generalized infrastructure for proposers to make credible commitments to any outsourced block building task. We will explore the potential benefits, open questions, roadblocks, and additional context around PEPC as an alternative path to unfetter proposers and allow permissionless innovation in outsourcing mechanisms.

Let us first consider the rationale behind PEPC's more open-ended design.

In the vision for Ethereum's "endgame" with widespread data sharding and rollup adoption, proposers will likely need to outsource an expanding array of duties essential for block validity. These may encompass outsourcing tasks like:

• Full block construction to builders

• Transaction ordering to mitigate MEV concerns

• Specific valid transaction inclusion through inclusion lists

• Validity proofs for rollup blocks or ZK execution environments

• Retrieval of data availability fragments

• Any number of other critical functions in future protocol upgrades

Enshrining specific exchange mechanisms for each proposer duty is daunting. The "optimal" market structure is challenging to pin down, let alone encode immutably in the protocol. Meanwhile, proposers require flexible infrastructure to make credible commitments to the outsourcing of their duties.

PEPC provides this flexibility by allowing proposers to register arbitrary commitments, expressed via EVM execution, that external parties can rely upon. The key principles are:

• Proposers can signal commitments to use any external service essential for block validity.

• The protocol enforces satisfaction of commitments before considering blocks valid.

• Anyone can provide services to proposers as long as they satisfy registered commitments.

• There is no single imposed mechanism all proposers must adopt.

In other words, PEPC focuses on providing infrastructure for commitment credibility, rather than mandating a strategy for outsourcing. Proposers choose how to leverage this infrastructure based on their needs and preferences.

As background, there already exist some out-of-protocol mechanisms like Eigenlayer that allow validators to make commitments via external contracts. However, the Ethereum protocol is unaware of these commitments.

For instance, validators may "restake" their ETH deposits to Eigenlayer as collateral for providing services. Failure to deliver results in balances being slashed on Eigenlayer but not in the core protocol. This leads to discrepancies between actual validator incentives and the protocol's perception.

One simple augmentation, which we'll call "in-protocol Eigenlayer" (IP-Eigenlayer), is allowing messages to reduce validator balances in the core protocol based on their performance of out-of-band duties. This synchronizes their real balance with the protocol's view.

However, IP-Eigenlayer provides only limited guarantees. Malicious proposers can still deviate from commitments if the reward exceeds the slashed amount. We need the protocol to enforce commitments, not just record outcomes.

To move from recording outcomes to enforcing commitments, the protocol must differentiate between:

1. Proposer made a commitment and external party delivered → Process payout

2. Proposer made a commitment and external party did not deliver → Process payout

3. Proposer made no commitment → No payout expected

4. Proposer made a commitment but deviated → Invalid state transition

Outcomes #1 and #2 are valid, #3 represents no commitment made, but #4 is an invalid state transition that should not be possible.

One approach is optimistic enforcement: let attesters slash proposers if they make invalid blocks violating commitments. But this retains misaligned incentives.

A stronger guarantee is pessimistic enforcement where invalid transitions simply cannot occur because blocks violating commitments are inherently invalid.

We can achieve this by allowing proposers to specify custom validity conditions via EVM execution. Commitments become prerequisites for block validity. Attesters merely check that blocks satisfy registered commitments. No invalid transitions can be finalized.

Enforcing commitments requires appropriate handling of data availability for builder contributions. We must prevent griefing between proposers and builders.

There are two broad categories of outsourcing contracts:

Paying Contracts: Proposer pays an external party for delivery of a service. For example, proposer requests a zk proof of block validity from a builder.

Procurement Contracts: External party pays the proposer to take some action. For instance, a builder pays for rights to construct a block.

Paying contracts have natural data availability guarantees. Builders only get paid by satisfying registered commitments.

However, procurement contracts allow griefing. Attackers could repeatedly bid without delivering, preventing honest builders from winning. Unfortunately, there are challenges with fully eliminating this vector:

• Bidding deposits slash malicious actors but disadvantage less capitalized builders.

• Complex zero knowledge proofs place a burden on honest builders.

• Encrypted bids must be decrypted by a committee upon reveal.

There are no perfect solutions currently. But PEPC infrastructure enables continued innovation to tackle these concerns.

Many PBS designs aim to promote "proposer dumbness" by having passive proposers accept the highest bid for their full block space. But this over-constrains proposers.

With PEPC infrastructure, a proposer need not rely on any specific outsourcing mechanism. Sophisticated proposers can leverage commitments creatively. Less sophisticated ones aren't forced into a single model but can adopt preset commitments. The key is flexibility.

To make this more concrete, here are some examples of commitments proposers could make:

• Full block auction to a single builder

• Partial block auctions to multiple builders

• Transaction inclusion lists

• Future block production rights

• Validity proofs for blocks or execution environments

• Any number of customizable outsourcing mechanisms

Proposers choose which commitments suit their needs rather than having the protocol dictate a specific model.

As described earlier, PEPC builds upon the Eigenlayer approach of enabling validators to make external commitments. However, it aims to create stronger guarantees by making the protocol enforce satisfaction of commitments instead of just recording outcomes.

Specifically, Eigenlayer supports three primary use cases according to founder Sreeram Kannan:

1. Economic use cases - Users care about amount staked as collateral

2. Decentralization use cases - Users care about independent participant diversity

3. Block production use cases - Validators make commitments about block contents

PEPC is most relevant for the third use case of block production commitments. By incorporating commitments into block validity conditions, PEPC moves this from an optimistic model (validators can violate but get slashed) to a pessimistic model (violating commitments inherently invalidates blocks).

However, for economic and decentralization use cases, it remains unclear whether PEPC can improve upon Eigenlayer's approach. This is an open area for further exploration.

Overall, PEPC generalizes some of the block production commitments enabled by Eigenlayer, and offers validators stronger credibility for certain outsourced duties essential for block creation. But it may not enhance other Eigenlayer use cases related to collateralization or distributed participation.

SUAVE allows validators to make credible commitments about their blocks by developing blocks based on declared user preferences. However, the SUAVE process operates on faster timescales, enabling "fast games" compared to the slower pace of Ethereum block production.

PEPC complements SUAVE by offering validators a way to make credible commitments even earlier in the process before SUAVE's block construction begins. PEPC commitments occur at the consensus layer, whereas SUAVE focuses on the execution layer.

Using PEPC, validators could commit to satisfying certain constraints or outsourcing specific duties while still leveraging SUAVE for flexible block building based on user preferences. For instance, validators might use PEPC for commitments about transaction ordering, and integrate SUAVE for maximizing user Extractable Value subject to those constraints.

Essentially, PEPC and SUAVE provide tools for validators to make credible commitments at different stages of the block production process. Used together, they offer a powerful framework for validators to align incentives and signal intentions to user communities.

Major open questions surround PEPC's feasibility and desirability:

• Implementation complexity: PEPC may require similar research as PBS for consensus safety. Can optimistic aggregation handle multiple parallel builder commitments? What metering applies for proposer conditions?

• Flexibility vs predictability: There is tension between supporting open-ended commitments and having predictable, well-understood exchange mechanisms. Would preset commitments be used most often?

• Proposer security: Reliable access to outsourced services is critical for proposers. Can procurement grieving be mitigated? Is pessimistic enforcement viable?

• Philosophical alignment: Does PEPC align with the protocol's role? Or does it overextend by enabling unconstrained commitments?

In Ethereum's evolution towards scalability via rollups and layer 2 solutions, block creation duties are increasingly outsourced from proposers (validators) to external block "builders." Most designs for formalizing this proposer-builder separation (PBS) focus on enshrining a specific mechanism, such as a full block auction, to facilitate proposer-builder exchanges. However, restricting the protocol to enabling only one type of exchange may not serve proposers optimally across the diverse spectrum of potential duties they could offload.

Protocol-enforced proposer commitments (PEPC) proposed by Barnabé Monnot in 2022 offers a more flexible approach by providing generalized infrastructure for proposers to make credible commitments to any outsourced block building task. We will explore the potential benefits, open questions, roadblocks, and additional context around PEPC as an alternative path to unfetter proposers and allow permissionless innovation in outsourcing mechanisms.

Let us first consider the rationale behind PEPC's more open-ended design.

In the vision for Ethereum's "endgame" with widespread data sharding and rollup adoption, proposers will likely need to outsource an expanding array of duties essential for block validity. These may encompass outsourcing tasks like:

• Full block construction to builders

• Transaction ordering to mitigate MEV concerns

• Specific valid transaction inclusion through inclusion lists

• Validity proofs for rollup blocks or ZK execution environments

• Retrieval of data availability fragments

• Any number of other critical functions in future protocol upgrades

Enshrining specific exchange mechanisms for each proposer duty is daunting. The "optimal" market structure is challenging to pin down, let alone encode immutably in the protocol. Meanwhile, proposers require flexible infrastructure to make credible commitments to the outsourcing of their duties.

PEPC provides this flexibility by allowing proposers to register arbitrary commitments, expressed via EVM execution, that external parties can rely upon. The key principles are:

• Proposers can signal commitments to use any external service essential for block validity.

• The protocol enforces satisfaction of commitments before considering blocks valid.

• Anyone can provide services to proposers as long as they satisfy registered commitments.

• There is no single imposed mechanism all proposers must adopt.

In other words, PEPC focuses on providing infrastructure for commitment credibility, rather than mandating a strategy for outsourcing. Proposers choose how to leverage this infrastructure based on their needs and preferences.

As background, there already exist some out-of-protocol mechanisms like Eigenlayer that allow validators to make commitments via external contracts. However, the Ethereum protocol is unaware of these commitments.

For instance, validators may "restake" their ETH deposits to Eigenlayer as collateral for providing services. Failure to deliver results in balances being slashed on Eigenlayer but not in the core protocol. This leads to discrepancies between actual validator incentives and the protocol's perception.

One simple augmentation, which we'll call "in-protocol Eigenlayer" (IP-Eigenlayer), is allowing messages to reduce validator balances in the core protocol based on their performance of out-of-band duties. This synchronizes their real balance with the protocol's view.

However, IP-Eigenlayer provides only limited guarantees. Malicious proposers can still deviate from commitments if the reward exceeds the slashed amount. We need the protocol to enforce commitments, not just record outcomes.

To move from recording outcomes to enforcing commitments, the protocol must differentiate between:

1. Proposer made a commitment and external party delivered → Process payout

2. Proposer made a commitment and external party did not deliver → Process payout

3. Proposer made no commitment → No payout expected

4. Proposer made a commitment but deviated → Invalid state transition

Outcomes #1 and #2 are valid, #3 represents no commitment made, but #4 is an invalid state transition that should not be possible.

One approach is optimistic enforcement: let attesters slash proposers if they make invalid blocks violating commitments. But this retains misaligned incentives.

A stronger guarantee is pessimistic enforcement where invalid transitions simply cannot occur because blocks violating commitments are inherently invalid.

We can achieve this by allowing proposers to specify custom validity conditions via EVM execution. Commitments become prerequisites for block validity. Attesters merely check that blocks satisfy registered commitments. No invalid transitions can be finalized.

Enforcing commitments requires appropriate handling of data availability for builder contributions. We must prevent griefing between proposers and builders.

There are two broad categories of outsourcing contracts:

Paying Contracts: Proposer pays an external party for delivery of a service. For example, proposer requests a zk proof of block validity from a builder.

Procurement Contracts: External party pays the proposer to take some action. For instance, a builder pays for rights to construct a block.

Paying contracts have natural data availability guarantees. Builders only get paid by satisfying registered commitments.

However, procurement contracts allow griefing. Attackers could repeatedly bid without delivering, preventing honest builders from winning. Unfortunately, there are challenges with fully eliminating this vector:

• Bidding deposits slash malicious actors but disadvantage less capitalized builders.

• Complex zero knowledge proofs place a burden on honest builders.

• Encrypted bids must be decrypted by a committee upon reveal.

There are no perfect solutions currently. But PEPC infrastructure enables continued innovation to tackle these concerns.

Many PBS designs aim to promote "proposer dumbness" by having passive proposers accept the highest bid for their full block space. But this over-constrains proposers.

With PEPC infrastructure, a proposer need not rely on any specific outsourcing mechanism. Sophisticated proposers can leverage commitments creatively. Less sophisticated ones aren't forced into a single model but can adopt preset commitments. The key is flexibility.

To make this more concrete, here are some examples of commitments proposers could make:

• Full block auction to a single builder

• Partial block auctions to multiple builders

• Transaction inclusion lists

• Future block production rights

• Validity proofs for blocks or execution environments

• Any number of customizable outsourcing mechanisms

Proposers choose which commitments suit their needs rather than having the protocol dictate a specific model.

As described earlier, PEPC builds upon the Eigenlayer approach of enabling validators to make external commitments. However, it aims to create stronger guarantees by making the protocol enforce satisfaction of commitments instead of just recording outcomes.

Specifically, Eigenlayer supports three primary use cases according to founder Sreeram Kannan:

1. Economic use cases - Users care about amount staked as collateral

2. Decentralization use cases - Users care about independent participant diversity

3. Block production use cases - Validators make commitments about block contents

PEPC is most relevant for the third use case of block production commitments. By incorporating commitments into block validity conditions, PEPC moves this from an optimistic model (validators can violate but get slashed) to a pessimistic model (violating commitments inherently invalidates blocks).

However, for economic and decentralization use cases, it remains unclear whether PEPC can improve upon Eigenlayer's approach. This is an open area for further exploration.

Overall, PEPC generalizes some of the block production commitments enabled by Eigenlayer, and offers validators stronger credibility for certain outsourced duties essential for block creation. But it may not enhance other Eigenlayer use cases related to collateralization or distributed participation.

SUAVE allows validators to make credible commitments about their blocks by developing blocks based on declared user preferences. However, the SUAVE process operates on faster timescales, enabling "fast games" compared to the slower pace of Ethereum block production.

PEPC complements SUAVE by offering validators a way to make credible commitments even earlier in the process before SUAVE's block construction begins. PEPC commitments occur at the consensus layer, whereas SUAVE focuses on the execution layer.

Using PEPC, validators could commit to satisfying certain constraints or outsourcing specific duties while still leveraging SUAVE for flexible block building based on user preferences. For instance, validators might use PEPC for commitments about transaction ordering, and integrate SUAVE for maximizing user Extractable Value subject to those constraints.

Essentially, PEPC and SUAVE provide tools for validators to make credible commitments at different stages of the block production process. Used together, they offer a powerful framework for validators to align incentives and signal intentions to user communities.

Major open questions surround PEPC's feasibility and desirability:

• Implementation complexity: PEPC may require similar research as PBS for consensus safety. Can optimistic aggregation handle multiple parallel builder commitments? What metering applies for proposer conditions?

• Flexibility vs predictability: There is tension between supporting open-ended commitments and having predictable, well-understood exchange mechanisms. Would preset commitments be used most often?

• Proposer security: Reliable access to outsourced services is critical for proposers. Can procurement grieving be mitigated? Is pessimistic enforcement viable?

• Philosophical alignment: Does PEPC align with the protocol's role? Or does it overextend by enabling unconstrained commitments?