# EPF - Week 3

This week I entirely spent on learning about PBS. Here's what I learned:

## ePBS

### What's PBS?

Proposer-Builder Separation - a model in which validator (block-proposer) delegates his block-building rights to external actors known as builders (or block-builders). These actors specialize in MEV. They manipulate bundles of transactions (by re-ordering, frontrunning, backrunning, sandwiching, etc) in such a way that extracts maximum value out of them[^1].

[^1]: https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725

Today PBS is possible thanks to mev-boost. MEV-boost is a [sidecar plugin](https://learn.microsoft.com/en-us/azure/architecture/patterns/sidecar) to beacon-node[^2] and is responsible for producing more than 90% of blocks[^3], which shouldn't be surpising because profit from using MEV-boost regularly goes up to 300%[^4], so validators are very motivated to use it.

[^2]: https://github.com/flashbots/mev-boost
[^3]: https://www.mevwatch.info/
[^4]: https://youtu.be/EswDO0kL_O0

### What is ePBS?

ePBS - enshrined PBS, or in-protocol PBS. MEV-boost is an external solutions that is not visible to the protocol, and thus ungovernable. The goal of ePBS is to make block builders visible in the protocol level and get rid of mev-boost[^11].

[^11]: https://barnabe.substack.com/p/seeing-like-a-protocol

### Things are already working well already why are we bothering enshrining PBS in protocol?

MEV-Boost's current design requires having an entity that proposers and builders trust - a relay. Without relays direct exchange of blocks or commitments between builders and proposers opens up multiple attack vectors that would force both parties to have OTC deals[^5]

One of the goals of ePBS is to remove relays and make the network fully trustless, because getting rid of an intermediary whose sole purpose is to bridge communications between entities that don't trust each other is the exact problem that blockchains are created to solve[^6].

[^5]: https://youtu.be/PS9SlHGJlrU
[^6]: https://hackmd.io/ZNPG7xPFRnmMOf0j95Hl3w#21-The-essential-players

### Different approaches to enshrining PBS

#### Two-slot proposer/builder separation[^7]

A rather brute force approach where commit-reveal scheme of mev-boost is enshrined in protocol in a two-slot way.

Slot time is reduced to 8s.

PBS flow under this model would look like this:
1. At the start of a slot 0, builders gossip execution headers and their bids to a proposer
2. Proposer chooses the best bid and publishes a beacon block with an execution header
3. At slot 1, a builder sees the beacon block and attestations on that block to make sure that the beacon block won't get reverted, and publishes execution body (transactions) corresponding to the execution header of the beacon block
4. At slot 2, validators attest on execution body and builders submit new blocks.

Under this model we have 2 kinds of block - beacon block and builder's block that are attested and gossiped depending a slot number. Beacon block has to be changed not to include execution payload.

We can also change the model a little bit to introduce just 1 new type of block - blind beacon block. This way, a proposer at slot 0 publishes a blind beacon block (a beacon block with execution header) and builder at slot 1 publishes a normal beacon block with an execution payload added[^8]

[^7]: https://ethresear.ch/t/two-slot-proposer-builder-separation/10980
[^8]: https://hackmd.io/@ttsao/r1wrQ7UMn

#### Two-block Headlock[^9]

A modification of two-slot PBS. Under this model, we only have one slot but the slot time is increased and is divided into 4 phases:
- phase 1 - proposer chooses builder bid and publishes the blind beacon block
- phase 2 - comittee attests on the blind beacon block
- phase 3 - builder makes sure that there is no equivocation and publishes execution body
- phase 4 - committee attest on exec body

[^9]: https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710#one-design-instantiation-two-block-headlock-tbhl-7

#### PTC - Payload-timeliness committee[^10]

Similar to Two-block headlock, but builder's block is given weight which is considered by the fork-choice rule.

[^10]: https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054

#### Execution tickets [^12]

This is a slightly different approach than the three mentioned before.

This model introduces tickets that block builders can buy to have a chance to propose an execution payload to a beacon block.


We still have one slot divided into 2.
- In the first half of the slot, a validator, chosen randomly from a set of all active validators, proposes a beacon block. That block is then attested by a committee.
- In the second half of the slot, a block builder, chosen randomly from a set of execution ticket holders, proposes an execution payload. That block too is attested by a committee.

Major changes:
- There are now 2 lotteries instead of one.
- This model introduces a primary market for execution tickets and open a possibility for a secondary market where block builder can sell their tickets.
- MEV is removed from validator rewards.

There are other big ramifications of this model that I need to study further.

[^12]: https://ethresear.ch/t/execution-tickets/17944

## Goals for the next week

- Learn ePBS specs and see how it's different from other approaches.
- Learn about inclusion lists and PEPC
- Contact with mentors
- Participate in ePBS breakout room - https://github.com/ethereum/pm/issues/1083