Initial implementation of ePBS on Lodestar.

Motivation

PBS is an important component on the Ethereum roadmap that provides many benefits such as censorship-resistence to transactions and fairness between hobbyist and insitutional validators. Although MEV-boost has already provided the separation of proposers and builders, the out-of-protocol solution is deemed to be brittle from recent attacks that targeted MEV-boost relays. There is also a significant cost is time and labour to maintain the compatibility between CL clients and relays especially during hard forks. As such, there is a demand of ePBS advocated by the community which provides a in-protocol solution for PBS. Through implementing ePBS on Lodestar, it serves as an initiative of slowly transitioning ePBS from research stage to a concrete stage of engineering.

Project Description

There are a lot of ideas and designs floating around for ePBS. However the community has not agreed on a single design yet. PTC is one of the more mature designs among them and we shall head to the direction of experiementing with it on Lodestar as well as proposing updates to the specification of all the affected components in the Ethereum protocol until the community holds strong opinion for an alternative design.

This is a non-exhaustive list of areas we would like to focus on. If there is any change to the PTC design or any sort of unforseenable blockage, the list might change.

• Consensus Specs
• Beacon API
• Execution API
• Lodestar Implementation
• Testing

Goal

• Drive community discussion on ePBS and push core devs to agree on a single implementation
• Consider all scenarios and edge cases and finalize a specification
• Implement and test ePBS on Lodestar accoding to the specification
• Continue to improve and refine the specification

Specification

On-going discussion with latest specs is here.

Roadmap

Phase 1 - Preparation, planning and spinning up discussion

• ePBS literature review and get up-to-date on the recent research dicussion
• To draft up the project scope, goal, acceptance criteria, logistic, roadmap etc
• Start a discussion on potential changes to consensus spec and beacon api spec with all parties interested in ePBS
• Depending if there is any change on EL side, we might need to have dicussion on EL spec change

Phase 2 - Settle down on an initial specs

• To get a first complete specification (Consensus, builder, P2P, Engine API etc.) written up and all team members agree with it
• Consider and visualize various kinds of workflows eg. Builder onboarding, builder exit, payment to proposer etc.

Phase 3 - Lodestar technical design and coding

• Analyze Lodestar codebase and write up technical design documents for complete ePBS implementation
• Re-discuss and refine specs if we encounter rooms for improvement

Phase 4 - Testing

• Set up infrastructure for devnet
• Perform testing on possible scenarios

Possible Challenges

• Since ePBS is still in its active research phase, there is a lot of open questions yet to be addressed which could yield a sudden pivot in PTC design or may completely abandon it in favour of another design. As such, during the technical design stage, we should design it to easily accomodate future change it happens.
• There is a potential prequisite that ePBS might depend on SSF or increasing MAX_EFFECTIVE_BALANCE. If this is agreed by the community, a separate dicussion needs to be made with the project management.

Resources

• PTC design: https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054
• Intro on ePBS: https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710 and https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879/1
• PBS: https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance
• Aggregated reading list by others: https://collective.flashbots.net/t/bookmarks-relevant-for-proposer-builder-separation-pbs-researchers/1319
• Terrence's work: https://hackmd.io/CfxJ1ZskSGKDYSLtTrhqnQ?view