PEPC-Boost

This document contains a project proposal to implement a POC of PEPC-Boost.

Motivation

Proposer-builder separation is a model which has been implemented out of protocol in Ethereum using a trusted MEV Relay. The essence of the model is that the proposer of the block can defer block building activities to an external builder. We can re-phrase this as a commitment to say that "the builder has a commitment to the proposer to produce a block whose value is more than the block which they can produce locally".
Currently, there are designs which aim to enshrine proposal builder seperation in protocol to eliminate the trusted relay and use the ethereum chain for trust. PEPC and PEPC-Boost is one such proposed design which is in its very early phases.
Continuing from the above "commitment", We look at PEPC. PEPC or Protocol-Enforced-Proposer-Commitment, is essentially a generalization of the proposer builder seperation where we allow the proposer to enter into any such commitment with the builder. Some example commitments could be:

Full Block Auction which is the current PBS
Partial Block Auction where the proposer suggests some transactions to be included in the block.
Parallel Block Auctions where multiple builders suggest transactions to one block.

PEPC-Boost is a proposed out-of-protocol implementation of PEPC. The goal is to implement it in the current MeV Boost architecture.

Project Description

We want to implement a POC of PEPC-Boost which is a proposed out-of-protocol implementation of PEPC. Since PEPC and PEPC-Boost are very new research areas, this project could also involve a bit of research work alongside engineering work.

Specification

A basic specification for PEPC-Boost has been described by Barnabe Monnot in PEPC FAQ.
The key idea is that we split a block into 2 parts, the TOB(Top of the block) and ROB(Rest of the block). We modify the relay spec to let the builders to bid seperately on the TOB and ROB.

The plan will be to iteratively build out the features of PEPC-Boost. We want to build the following features in a step by step manner(inspired by Barnabe's article):

For the first version, we just allow only 1 tx in the TOB bid and rest of the other txs in the ROB bid. To prevent state interference, we can make sure that the TOB bids only happen for a specific tx (eg: ETH/USDC swaps on Uniswap v3) and the rest of the txs are in the ROB bid. ROB builders can build knowing that they shouldn't not include txs from arbitrageurs who would do a DEX trade at a block.
If we are able to successfully achieve this, the next step would be to extend the TOB bid to include more txs. We can generalize it for more txs but the correct way would be to make sure that more liquidty pool swaps are included. We need to ensure that we have reserved tx slots for each LP to minimize state interference.

The next steps following this are more research oriented and much more deeper:

The next step would be to how we can utilize this separation of blockspace in TOB and ROB to implement inclusion lists. At this stage, we will have to think how we can implement inclusion lists as a proposer commitment. We will need to define the structure of a proposer commitment.
Post that, we can think about parallel block auctions amongst N builders by furthur splitting the TOB and ROB block furthur into N parts using the proposer commitment model which can specify the number of builders to use.

The Tech stack we will be using for PEPC-Boost implementation is:

Flashbots MeV Relay as the relay we will be modifying to implement PEPC-Boost relay
Using Prysm as the consensus layer
Using Geth as the execution layer
Flashbots Builder as the base for the builder implementation
I will setup my own devnet in my personal AWS account where I will deploy PEPC-Boost

Roadmap

Week 1-3:
Spend time on learning more about PEPC, PBS and ethereum in general while designing iteration 1 and 2 of PEPC-Boost. I aim to have a design and specification ready by the end of this phase. I also aim to have feedback from mentors on the design and specification
During this phase, I will also work on spinning up my own devnet which I will require for my testing.

Week 4-11:
Implement the specification for iteration 1 and 2 of PEPC boost and deploy them to devnet. Try getting some feedback on it. On the side, if there is enough bandwidth, try to start working on implementing iteration 3 and 4 as well.

Week 12:
Document the project thoroughly. If iteration 1 and 2 go well, then try deploying it Goerli testnet.

Possible Challenges

Some challenges are listed below:

PEPC-Boost and PEPC are very new ideas that are currently in the research phase. PEPC-Boost has been proposed less than 2-3 weeks ago. There is bound to be a lot of unknowns which will have to be answered on the way. This project will be touching both research and engineering. There might be difficulties during implementation because it touches a lot of parts like the CL, EL, Engine API, Builder API and relays. This may result in the project taking a longer time then estimated. Although, For iteration 1 and 2, we will mostly be touching only the relayer and builder spec. For iteration 3 and 4, we will have to get to the consensus and execution layer spec.
It will also be a challenge to design for PEPC-Boost with optimistic relaying since we might require a third actor like an assembler to assemble transactions from various builders which might increase latencies of the relayer.
Working on iterations 3 and 4 will be particularly challenging. Parallel block building with multiple builders can make state interference high and will be challenging to solve it. Coming with a general proposer commitment model will also be challenging.

Goals of the project

The end goal is to explore designs for the implementation of PEPC-Boost iteratively and implement them in devnet.

The required deliverables will be:

A MIRO design board highlighting the overall architecture of PEPC-Boost, along with the design for each iteration as specified in the Specification section.
A specification document highlighting changes to Builder API, Engine API, Consensus Layer specs and Execution Layer specs for each iteration. Althought, For iteration 1 and 2, we will mostly be touching only the relayer and builder spec. For iteration 3 and 4, we will have to get to the consensus and execution layer spec.
Deployment of PEPC-Boost to a local devnet with the implementation of the first 2 iterations.
Documentation on PEPC-Boost
Articles on learnings, thoughts and ideas related to PEPC and PEPC-Boost.

Deliverables which would be nice to have:

Deploy iterations 1 and 2 to Goerli testnet.
Being able to implement designs for iteration 3, 4 and deploy to devnet.

Another goal is to read and document learnings in hackmd articles, design boards and so forth.

Collaborators

Fellows
Bharath V

Mentors
Barnabe Monnot
Terrence Tsao
Mike Neuder

Resources

PEPC FAQs
PEPC Original Proposal

Michael Neuder

2023/08/09 20:52:39

Proposer-builder

proposer-builder (Edited)

2023/08/09 20:52:51

separation

separation (Edited)

2023/08/09 20:53:53

id suggest using MEV or mev instead of MeV. to avoid confusion with Mega electronVolts (Edited)

2023/08/09 20:55:11

out-of-protocol

out-of-protocol (Edited)

2023/08/09 20:55:20

a proposed (Edited)

2023/08/09 20:57:38

implement inclusion lists

this is likely out of scope for this timeline. could be worth researching though (Edited)

2023/08/09 20:57:55

Post that, we can think about parallel block auctions amongst N builders by furthur splitting the TOB and ROB block furthur into N parts using the proposer commitment model which can specify the number of builders to use.

also probably out of scope, just FYI (Edited)

2023/08/09 20:58:43

AWS

i would suggest using goerli! better than a local testnet and very easy to get connected to (Edited)

2023/08/09 20:59:24

i don't think this is a pessimistic deadline! this is a super ambitious project (Edited)

2023/08/09 21:00:17

This project will be touching both research and engineering. There might be difficulties during implementation because it touches a lot of parts like the CL, EL, Engine API, Builder API and relays. This may result in the project taking a longer time then estimated. Although, For iteration 1 and 2, we will mostly be touching only the relayer and builder spec. For iteration 3 and 4, we will have to get to the consensus and execution layer spec. 2.

i think you will be able to shape it into a more resesarchy project or a more softwarey project tbh. (Edited)

2023/08/09 21:02:51

A specification document highlighting changes to Builder API, Engine API, Consensus Layer specs and Execution Layer specs for each iteration. Althought, For iteration 1 and 2, we will mostly be touching only the relayer and builder spec. For iteration 3 and 4, we will have to get to the consensus and execution layer spec. 3.

this is a lot FYI. also would need to change the relay spec (which dictates how the relay and builder communicate), because the relay would need to inform the builder of the proposer commitments before the builder can construct a conformant block (Edited)

Bharath Vedartham

2023/08/10 05:24:22

yup, totally (Edited)

2023/08/10 05:29:05

but I feel with goerli, we might have a relatively lower frequency of block proposals. which might make it harder to test no? (Edited)

2023/08/10 05:29:19

yeah just kept it to define a roadmap (Edited)

2023/08/10 11:02:33

But i feel like for iteration 1 and 2, we would only need relayer spec and builder api changes. Plus we mostly have to introduce a third actor called an assembler. So need to figure out those apis and trust assumptions. (Edited)

2023/08/10 11:03:17

We can discuss this offline! (Edited)

2023/08/10 11:03:38

cool! (Edited)

2023/08/10 11:04:14

yes yes, but I just wanted to keep it there. The intent is to ideally pursue this post EPF too if everything works out. So just placing it there. But I ll re-work the doc to make these more explicit. (Edited)

2023/08/10 11:04:23

got it! (Edited)

2023/08/10 11:04:51

done! (Edited)

2023/08/10 11:04:54

2023/08/10 11:04:56

2023/08/10 11:05:03

2023/08/10 11:08:59

consensus layer and execution layer specs along with engine api would probably come if we work on iteration 3 and 4 (Edited)

2023/08/10 11:57:14

have removed my pessimism... :P (Edited)

2023/08/10 11:57:31

2023/08/10 11:57:43

want to do a bit of both if possible. But lets how it evolves! (Edited)

Mario Havel

2023/08/11 10:06:52

The only benefit of goerli would having more active third parties running relays. Otherwise Ephemery would be a better options (Edited)

2023/08/11 10:07:35

yep, could be rephrased as feasibility research (Edited)

Barnabé Monnot

2023/08/11 12:37:34

We modify the re

We likely don't need to do that. The idea is that the change is invisible to proposers today. They can connect to the PEPC-Boost relay as if they were connecting to any other relays available. So the Builder API remains the same, the proposer will only ever be asked to make one signature on the block (Edited)

2023/08/11 12:39:25

ROB builders can build knowing that they shouldn't not include txs from arbitrageurs who would do a DEX trade at a block.

If searchers are smart, they wouldn't send another ETH/USD swap to arb in the ROB block, because they would expect the arb to be gone by then. So the ROB builder doesn't need to be careful about what they include, if a searcher mistakenly tries to get the top spot of the ROB block to get the arb, it's their loss, since the TOB part is separated (Edited)

2023/08/11 12:41:25

+1 (Edited)

2023/08/11 12:42:43

Goerli deploy sounds like a very meaningful deliverable! (Edited)

2023/08/11 12:44:42

The research side will look like protocol design, e.g., what is the best architecture between the different components, but I see mostly as relevant the TOB builders (which are simple cex/dex arb searchers), the ROB builders, and the relay. As noted above, the relationship between proposers and relay should be the same as before (I could be wrong on that, but maybe a good working assumption) (Edited)

2023/08/11 12:45:57

Not sure what the assembler is, I guess in my mental model the relay is the assembler, but from an implementation perspective it may be easier to have two distinct logical entities? That's a good question to explore! (Edited)

2023/08/11 13:27:10

makes sense. I actually meant the relay spec! Got it messed up! (Edited)

2023/08/11 13:28:46

Will explore ephemery! Goerli I need to evaluate on my own. It should be post testing on devnets and ephemery. Its not a good testing ground initially. Let me think through (Edited)

2023/08/11 13:45:46

got it point noted (Edited)

2023/08/11 13:47:45

since here we are having a model where seperate builders can propose a TOB and ROB block independently. I believe we should have a third actor who can combine the TOB and ROB and generate the final state root, receipt root etc (Edited)

PEPC-Boost

Motivation

Project Description

Specification

Roadmap

Possible Challenges

Goals of the project

Collaborators

Read more

Validator Relay Integration

Relay payouts with Parallel Block Auctions

Thoughts on PEPC-Boost as a Product

Final Dev Update