# PEPC-Boost V0

## Contents

1. [Abstract](https://hackmd.io/XUj5jkz6R2Kuq0cEizQr4g?both#Abstract)
1. [Glossary](https://hackmd.io/XUj5jkz6R2Kuq0cEizQr4g?both#Glossary)
2. [Introduction](https://hackmd.io/XUj5jkz6R2Kuq0cEizQr4g?both#Introduction)
3. [System Architecture](https://hackmd.io/XUj5jkz6R2Kuq0cEizQr4g?both#System-Architecture)
4. [Implementation-Specific Details](https://hackmd.io/XUj5jkz6R2Kuq0cEizQr4g?both#Implementation-Specific-Details)
5. [Current State](https://hackmd.io/XUj5jkz6R2Kuq0cEizQr4g?both#Current-State)
6. [Future Work](https://hackmd.io/XUj5jkz6R2Kuq0cEizQr4g?both#Future-Work)
7. [Demo Video](https://hackmd.io/XUj5jkz6R2Kuq0cEizQr4g?both#Demo-Video)

### Abstract

Integrated searcher-builders like HFT firms have superior capabilities to extract high-value top-of-block MEV opportunities like CEX-DEX arbitrages compared to smaller builders. Current PBS auctions, done through MEV relays, only auction off the entire block, which means that builders capable of extracting high-value top-of-block opportunities can easily outbid the rest of the other builders by winning the whole block auction, increasing the centralization and reducing the builder market's competitiveness.

This article takes inspiration from [PEPC](https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879?u=barnabe), a proposed in-protocol mechanism for more general block allocation mechanisms, to propose a new relay design called PEPC-Boost. PEPC-Boost holds separate auctions for the top-of-block and rest-of-block. PEPC-Boost relay allows searchers to bid separately to include their CEX-DEX arbitrage transactions on the top-of-block, and it allows builders to submit blocks that will get included in the rest-of-block. By selling the top-of-block and rest-of-block separately, PEPC-Boost aims to reduce the competitive advantage of integrated searcher-builders, which will help increase competitiveness and reduce centralization in the builder market.

### Glossary

| Term | Description |
| -------- | -------- |
| ToB | Top of Block |
| RoB | Rest of Block |
| HFT Firms | High Frequency Trading Firms |
| ToB value | The amount Eth searchers are willing to pay to the proposer for including their txs in the ToB slot |
| RoB value | Validator payouts added by RoB builders |
| Searchers | Actors who look to extract a lot of MEV |
| Builders | Actors who build blocks and submit them to the MEV relayer, allowing them to bid for validator block space |
| PEPC | Protocol Enforced Proposer Commitments |

### Introduction

[PEPC](https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879?u=barnabe) as proposed by Barnabe Monnot is a protocol mechanism to allow proposers to enter into commitments over the blocks they build. Some examples of possible commitments are [certain types of transaction ordering, parallel block building, etc.](https://efdn.notion.site/PEPC-FAQ-0787ba2f77e14efba771ff2d903d67e4#6775d4c031d545609434e24213a4fde2)

[PEPC is useful](https://efdn.notion.site/PEPC-FAQ-0787ba2f77e14efba771ff2d903d67e4?pvs=25#b5d2966c2215482eaba942f93bdfb613) because it allows more general block allocation mechanisms in the protocol which removes specific locked outcomes which may have undesirable side-effects on the protocol.

The current builder landscape is very [centralized](https://www.rated.network/builders?timeWindow=30d&network=mainnet&page=1). Integrated builder-searchers like HFT firms are more likely to win the PBS auctions because they can maintain private order flows and have access to specialized centralized exchange feeds, giving them superior top-of-block capabilities, which enable them to extract much more profit from CEX-DEX arbitrages than non-integrated builders and win the PBS block auctions which also reduces the competitiveness of the builder market.

[PEPC-Boost](https://efdn.notion.site/PEPC-FAQ-0787ba2f77e14efba771ff2d903d67e4#2dfe02bc6dcd48878c82647676ca8d68%29) is a proposed out-of-protocol implementation of a specific PEPC-type allocation which splits a block into a top-of-block and rest-of-block lane (which is similar to the concept of lanes in [Skip protocol](https://skip-protocol-docs.netlify.app/chains/overview)). Searchers can engage in an auction to bid for [CEX-DEX arbitrage txs](https://arxiv.org/abs/2305.19150) they want to include in the top-of-block, and builders can bid to include their block in the RoB. This opens up the proposer block space by allowing different actors to construct segments of the whole block, which is a form of a [parallel block auction](https://efdn.notion.site/PEPC-FAQ-0787ba2f77e14efba771ff2d903d67e4#6775d4c031d545609434e24213a4fde2).

Integrated searcher-builders are not incentivized to use PEPC-Boost relay as they already have superior capabilities to extract ToB opportunities, which enables them to build high-value blocks that can outbid other builders on the full block auction. Searchers who are capable of building RoBs can use PEPC-Boost to trustlessly pair up with searchers capable of producing high-value ToB txs to build high-value blocks, which can compete with the best builders. These blocks can potentially outbid large integrated searcher-builders, improving the builder market's decentralization and competitiveness. It also allows weaker builders to include their transactions, increasing the protocol's censorship resistance. Since the top integrated searcher-builders are not incentivized to use PEPC-Boost, we can expect the builders with a much lower block inclusion rate to connect with PEPC-Boost so that their txs are more likely to be included. Note that this is an analysis that needs to be done more thoroughly.

### System Architecture

The PEPC-Boost relayer exposes a new endpoint that accepts a bundle consisting of ToB txs from the searcher and a payout tx to the proposer for including the bundle at the ToB. The relayer receives RoB blocks from builders through an endpoint dedicated to receiving RoB blocks. If the sum of the values of the ToB bundle proposed by a searcher and RoB block submitted by a builder is the highest value block seen for that particular slot, we assemble the ToB bundle and RoB block into a combined execution payload and store the final bid in the relay database. The value of the final bid is the sum of the ToB's value and the RoB's value. We are doing a "static evaluation" for the initial version to sum up the values and check if it's the highest. The actual value of the block might be lower because the txs in the RoB might revert due to state changes by the ToB. We are exploring solutions that can help us model RoB values more efficiently.

Below is a diagram which shows the architecture of PEPC-Boost:


Searchers send a bundle they want to include in the ToB for a given slot and on top of a particular parent hash which consists the ToB txs and a payout to the proposer via the `/relay/v1/builder/tob_txs` endpoint. The endpoint first simulates the bundle to check if the searcher has included a payout for the proposer of the given slot and if the ToB txs sent are valid non-reverting txs. This simulation happens via a `validateTobSubmission` RPC call. Once the simulation is successful, we check if the ToB tx in the bundle is a potential CEX-DEX arbitrage-related tx. In the initial versions of PEPC-Boost, we allow only one CEX-DEX arbitrage tx by the searcher, which currently is an Eth/USDC Uniswap V3 swap. By limiting the type of txs we accept on the ToB, we also reduce the chance of state conflicts with the RoB, reducing the chances of txs in the RoB reverting. In future versions, we will increase the number of ToB txs we accept in the bundle and allow a bundle with multiple CEX-DEX arbitrage-related txs. If the bundle is of the highest value seen so far, we store the bundle in the Redis cache of the PEPC-Boost relayer.

For more details on ToB Auction and ToB tx checks, please refer to:
* ToB auction: https://github.com/bharath-123/pepc-boost-docs/blob/main/TOB_AUCTION.md
* ToB tx checks: https://github.com/bharath-123/pepc-boost-docs/blob/main/TOB_TX_CHECKS.md

When a builder submits a RoB block via the `/relay/v1/builder/rob_blocks`, we check if a ToB bundle is present for the slot and parent hash of the submitted block. If there is a ToB bundle and the sum of the ToB value and RoB value is the highest seen so far, we send it to the `blockAssembler` RPC to assemble the ToB txbundles and the RoB block into a combined execution payload and store the final bid with this combined execution payload in the PEPC-Boost relay database. The RoB builder currently pays the proposer using the existing model by appending the payout to the proposer at the end of the block.

For more details, please refer to:
* ToB and RoB building: https://github.com/bharath-123/pepc-boost-docs/blob/main/TOB_ROB_BUILDING.md
* Block Assembler: https://github.com/bharath-123/pepc-boost-docs/blob/main/BLOCK_ASSEMBLY.md

Below is a sequence diagram highlighting the interactions in PEPC-Boost:


### Implementation-Specific Details

PEPC-Boost leverages the [Flashbots MEV-Boost Relay code](https://raw.githubusercontent.com/bharath-123/pepc-boost-docs/main/diagrams/PEPCBoost.png). https://github.com/bharath-123/pepc-boost-relay contains the code of the PEPC-Boost relay.

We leverage [Flashbots Builder](https://github.com/flashbots/builder) to implement the RPCs for block assembler and ToB tx validation. https://github.com/bharath-123/pepc-boost-builder contains the implementations of the block assembler and ToB tx validation RPC.

To test PEPC-Boost on local devnets, we have used [Kurtosis](https://github.com/kurtosis-tech/ethereum-package). Kurtosis allows to spin up local devnets very easily. For more details on using Kurtosis to test PEPC-Boost, please refer to https://github.com/bharath-123/pepc-boost-docs/blob/main/CUSTOM_DEVNET_SETUP.md.

We have written scripts in https://github.com/bharath-123/pepc-boost-testing/tree/devnet-testing to send searcher txs to the PEPC-Boost relay to test it.

https://github.com/bharath-123/pepc-boost-docs contains detailed documentation of each component.

### Current State

In the initial version of PEPC-Boost, We have implemented a ToB auction that accepts one Uniswap v3 Eth/USDC tx and a proposer payout tx. We have introduced a new RoB block submission API to which builders send RoB blocks. We have integrated the block assembly RPC with the RoB block submission API, which is invoked whenever a builder's RoB tx is matched with valid ToB txs for the slot to get back an assembled payload of the ToB txs and RoB txs.

We have implemented the block assembly RPCs and ToB validation RPCs in the builder.

https://github.com/bharath-123/pepc-boost-relay contains the initial version of PEPC-Boost, and https://github.com/bharath-123/pepc-boost-builder includes the implementations of the RPCs for block assembly and ToB validation.

We are testing PEPC-Boost in a local devnet we have setup using Kurtosis.

We have also now deployed PEPC-Boost to Goerli!

https://website.pepc-booost.com/ hosts the PEPC-Boost website.

If you are running a validator, please feel free to connect to PEPC-Boost at https://api.pepc-booost.com/

### Future Work

As we move ahead with PEPC-Boost, below are some of the things we are looking at:
1. To increase the number of ToB txs allowed in the ToB bundle.
2. To model proposer payouts for the RoB builder more efficiently. Conflicts between the ToB txs and the RoB txs can cause RoB txs to revert, which could reduce the expected amount received by the RoB builder. Considering this case, we want to see if we can model proposer payouts better, which requires more research.
3. Optimize for higher block values by storing RoB partial blocks in the relay. We discard RoB blocks once we merge them with the ToB txs, which will not allow the PEPC-Boost relayer to combine subsequent ToB bundles with RoB blocks sent before the searcher sends the ToB txs to the relay, which could be of high value. As we advance, we want to cache the partial RoB blocks to build them with subsequently sent high-value ToB txs to get the highest value block possible.
4. To allow searchers to cancel ToB bundles they have sent.
5. To explore block cancellation by builders. Since two different actors are building a block, we need to research how complete block cancellations would work for the searcher and builder.

Please find a complete list of items we are currently working on in PEPC-Boost here: https://github.com/bharath-123/pepc-boost-relay/issues

### Demo Video

Below is a Demo video with a brief explanation of PEPC-Boost and a working demo.

https://youtu.be/kUuDLqlsaSE

### Acknowledgments

I want to thank [Barnabe Monnot](https://twitter.com/barnabemonnot) (EF), [Mike Neuder](https://twitter.com/mikeneuder) (EF) and [Terrence](https://twitter.com/terencechain) (Prysmatic Labs) for all their valuable feedback and discussions.

I want to thank [Paritosh](https://twitter.com/parithosh_j) (EF) for guiding me to test PEPC-Boost better!

I want to thank the [Kurtosis team](https://twitter.com/KurtosisTech) for building a solid product to set up local Ethereum devnets easily. The team is very helpful and super responsive, which has helped me immensely.

I want to thank [Mario Havel](https://twitter.com/TMIYChao) (EF) and [Josh D](https://twitter.com/joshdavislight) (EF) for organizing the EPF program which has enabled me to put out this work.