Final report Project Abstract During my time in the Ethereum Protocol Fellowship, I worked on implementing EIP-7732 (Enshrined Proposer-Builder Separation) in Prysm and eventually in Nimbus. Currently validators heavily relies on third-party relays for block building, with about 90% of blocks being produced through mev-boost. While this system works, it introduces centralization risks and trust requirements that go against Ethereum's principles. Our implementation aims to solve this by moving PBS into the protocol layer itself. The core idea is simple: make the exchange between proposers and builders trustless, while ensuring proposers get paid and builders' payloads become canonical when they act honestly. You can find the original project proposal here. Status Report When we started, we were working with a traditional block-auction design. The approach seemed straightforward - builders would bid for slots, proposers would select bids, and a Payload Timeliness Committee (PTC) would ensure everything happened on schedule. However, as we dug deeper into implementation, we discovered several challenges that led to significant design changes.

Week 20 and Week 21 Updates: Progress on ePBS Implementation: All-in-one Fork Choice Analysis Key Components: type AvailabilityCommittee struct { Validators []ValidatorIndex VotingPeriod uint64 // 7 seconds into slot Threshold uint64 // Majority threshold }

Week 18 and Week 19 Updates: Progress on ePBS Implementation: In the past two weeks, we've had two significant breakout meetings (#11 and #12) focusing on ePBS (Enshrined Proposer-Builder Separation). The main highlights include rethinking fork choice rules and client implementation updates. Client Progress: Prysm First to implement the new fork choice rules Main challenges we're facing:Need to modify core functions that decide which blocks to follow. GetHead(): Decides which block is the head of the chain. Insert(): Adds new blocks to the chain

Ethereum is constantly evolving, enhancing its protocols to improve security, scalability, and fairness. An important aspect of its infrastructure is the fork-choice rule, which determines the canonical chain in the presence of competing forks. This rule essentially maintains consensus across the network. Recently, a proposal has emerged to refine Ethereum’s fork-choice rule by francesco, which would work for 3 advanced and important mechanisms: enshrined Proposer-Builder Separation (ePBS), Fork-Choice Enforced Inclusion Lists (FOCIL), and Data Availability Sampling (DAS). This unified approach aims to create a more robust and efficient network by combining the strengths of these individual features. Core Mechanisms To appreciate the implications of this proposal, it is crucial to understand each component’s role within the Ethereum network. enshrined Proposer-Builder Separation (ePBS) (EIP-7732) Proposer-Builder Separation decouples the roles of block proposers (validators) and block builders. In this paradigm, specialized builders construct blocks optimized for MEV--such as including transactions with the highest fees or modify the ordering of transactions--while proposers select and propose these blocks to the network. enshrining this separation basically implies that proposer and builder will have trustless way of doing this. The best-case scenario in this case would eliminate the centralized network of relays that currently handles the majority of block production. Fork-Choice Enforced Inclusion Lists (FOCIL) FOCIL introduces a mechanism to ensure the inclusion of some transactions, particularly to eliminate censorship. Validators commit to inclusion lists that specify transactions which must be included in upcoming blocks. The fork-choice rule enforces these commitments by favoring chains that honor the inclusion lists. This mechanism promotes fairness and protects user transactions from being disregarded due to censorship or other exclusionary practices.

Week 10 and Week 11 Updates: Progress on ePBS Implementation: PR #14363: Implements sync for signed execution payload header. Introduces ExecutionHeaderVerifier and new getters in chain info package(terence) PR #14308: Implements UpdateVotesOnPayloadAttestation. Handles PTC votes and equivocations(kira) PR #14373: Adds unit tests for execution payload envelope verifier(Jihoon) PR #14378: Adds Prysm RPC endpoint for validator to get header from beacon node(terence) PR #14380: Implements retrieval of payload attestation data. Modifies HighestReceivedBlockSlot to HighestReceivedBlockSlotRoot(terence) PR #14381: Implements Prysm RPC for submitting payload attestation messages(terence) PR #14365: Hardcodes GenesisValidatorRoot in config(Amaan) PR #14383: Adds ePBS fork configuration. Merged(Jihoon)

Week 12 and Week 13 Updates: Progress on ePBS Implementation: PR #14394: Moved handling of PTC messages from sync package to chain package(Potuz) PR #14420: Added GetPTCVote helpers for forkchoice(Potuz) PR #14422: Implemented handling of execution payload insertion in forkchoice(Potuz) PR #14395: Added RPC endpoint for proposer to submit signed execution payload envelope(Terence) PR #14409:Work in progress on local payload handling (blocked pending payload ID cache changes)(Terence) PR #14419: Added helper function to wait for PTC duty(Terence) PR #14380: Implemented retrieval of payload attestation data(Terence) PR #14440: Demonstrated end-to-end local proposer workflow(Terence)

Week 8 and Week 9 Updates: Progress on ePBS Implementation: We made significant progress in implementing Enshrined Proposer-Builder Separation (ePBS) in Prysm. Several key PRs have been under development and review: Execution payload envelope sync PR by potuz, successfully passed all tests and is now awaiting final reviews. This PR is crucial for handling the new execution payload envelope structure introduced in ePBS. Amaan's PR for process_withdrawal was merged after alot of debugging. A separate test setup for ePBS was necessary due to differences in error handling and state initialization. Terence has been working diligently on validator client changes to support ePBS. His work includes developing new APIs for proposing headers, blocks, and execution payload envelopes, which are essential for the new ePBS workflow. My Ongoing Work: I've been focusing on implementing the UpdateVotesOnPayloadAttestation function (PR #14308). This involves handling of Payload Timeliness Committee (PTC) votes and addressing potential equivocations. After discussions with potuz, I've made adjustments to ensure we only set the first vote for each validator to prevent issues with unslashed equivocations.

Week 7 Updates: On the ePBS side, made the list for set of tasks/functionalites that are to be covered under ePBS. These can found in my repo PRs here. Made a shared hackmd space between fellows working on ePBS, to avoid double working on similar issue. Reviewed a bunch of helper function PRs. Started working on the forkchoice package. Deep-dived the spec for fork-choice and gathered set of targeted functionalties. These are as followed: [ ] notify_ptc_messages [ ] is_payload_present [ ] is_parent_node_full [ ] Modify get_ancestor [ ] Modify get_checkpoint_block [ ] is_supporting_vote

Hey there, I'm kira. These are my Week 6 Updates. On the ePBS side I reached out to interested fellows had a collaborative call to work together. Also co-ordinated a call with other fellows and mentors and discussed the specifics of the projects. Finalized proposal and will be presenting on Tuesday for the project. On the custom p2p implementation, started going through consensus spec for p2p interface of phase0. Started to look into bellatrix and further upgrades for the next. For Week 7 some of the tasks would be: Make a list of specific functions and packages that are to be implemented in ePBS. Complete helper function to get the flow of the project. Submit the custom libp2p implementation project. Go through the consensus spec for p2p for all the upgrades and the changes made in those upgrades.

EIP-7732: Enshrined Proposer-Builder Separation Implementation of a working Proof-of-Concept for EIP-7732 or ePBS. Motivation Currently in the Ethereum, the Proposer-Builder Separation or PBS is handled by third-party software like mev-boost and an out-of-protocol relay network. The Proposer-Builder Separation (PBS) was introduced to segregate block proposing from block building. PBS democratizes access to MEV by enabling block proposers to sell their rights to construct a block, thereby creating a market for block builders. mev-boost, an out-of-protocol implementation of PBS built by Flashbots, has been dominantly adopted, accounting for approximately 90% of Ethereum blocks being produced. Proposers want their promised transaction bundles to be delivered and get paid safely, while builders want their bundles to avoid front-running. Relays sit between proposers and builders, acting as mutually trusted auctioneers. Due to a lack of sufficient incentives to run relays, we are witnessing another centralizing force. Over the past two weeks, only five relays has produced around ~94% of total block that were proposed. Why ePBS Referring to this doc by potuz, The primary problem in the current implementation of PBS in Ethereum are as followed:

Hey there, I'm kira. These are my Week 4 Updates. On the ePBS progress and updates, Last Friday I was active during the the ePBS breakout room call. Some useful notes from call by terence. Reached out to the mentors for had initial discussion on ePBS. Opened an ePBS related thread for the EPF in the Prysm discord. Took a look at the consensus spec PR which is linked below. Grasped basic understanding of the PTC attestation votes and working of PTC. On the custom p2p implementation maxine wrote a good initial doc for getting started. Gone through this but haven't made any further updates after this. Following was discussed on the call:

Hey there, I'm kira. These are my Week 3 Updates. Brushed some of basics on running node client. Running a full node on mainnet and got familiar with implementation of Data Structures in the Prysm Codebase. Learnt basics of bazel (a build tool) and BoltDB which is being used as database in Prysm. This week I went through some of the codebase of Prysm, and made this PR. Discovered and connect with the other fellows who have interest in working on ePBS not sure if anyone is seriously pursuing it or not. Cleared some of my basics on Time Games and ePBS design with some variations. Roadmap for Week 4 For Week 4 some of the major tasks would be:

Hey there, I'm Shyam Patel, I'll referring myself as kira (alias) from now on. These are my Week 1 Updates. The primary goal for week 1 was to read more about the project(s) that I am interested to work on and gather as much context as possible with the respective teams. Before the 1st week, ePBS was the one that piqued my interest the most, since then I explored couple more ideas like Custom golang implementation of libp2p and light client support in Prysm. On the updates, I've been following the ePBS progress and updates. Last week I attended the ePBS breakout room call. Some useful notes from call by terence. Attending the call made me realise I've alot of resources to go through yet before I can start making active contributions to the conversation. I have also been trying to go through this placeholder PR by potuz that is supposed to be tracking the progress of ePBS. These are some of the resources and reference that I'm either gone through or going through over Week 1 and Week 2. Posting here so that I can track the stuff that I've that is essential to the topic. Please note that some of them are still on to-reads.

EPF Week 0 Updates Hey there, I am Shyam Patel, These are my initial updates for week 0. The primary goal for week 0 and week 1 will be to read more about the project(s) I am interested to work on and gather as much context as possible with the respective teams. During my EPFsg research phase, I briefly studied the PBS and some ePBS solutions, and currently studying Notes and Specs by Potuz and terence. So far ePBS has piqued my interest so I'll providing some updates on that. ePBS design, and prototype in Prysm client

Hey there, I'm kira. These are my Week 2 Updates. I've narrowed down some scope for the project ideas, I'd likely be contributing to consensus client (Prysm). Additionally I'm interested in contributing to more than one ideas, if possible that is. On the updates, I've been following the ePBS progress and updates. Last week I attended the ePBS breakout room call. Some useful notes from call by terence. Following was discussed on the call: A new version of the consensus specification, rebased on top of Electra, will be opened soon. Reviewed changes to the beacon block and state structure, considering whether it makes sense to use header.block_root instead of header.block_hash.

Byzantine Generals' Problem and BFT Byzantine Fault Tolerance (BFT) is a property of distributed systems that allows them to function correctly even when some components fail or act maliciously. BFT is crucial in decentralized networks, where trust among nodes cannot be assumed. In other words, a system exhibiting BFT can tolerate Byzantine faults, which are arbitrary failures that include malicious behavior. For a system to be Byzantine fault-tolerant, it must reach consensus despite these faults. Practical Byzantine Fault Tolerance (pBFT) pBFT is an algorithm designed to improve the efficiency of achieving BFT in practical applications. It works by having nodes communicate with each other to agree on the system's state. The algorithm operates in several rounds of voting, where nodes exchange messages to confirm the validity of transactions. pBFT ensures that as long as less than one-third of the nodes are faulty, consensus can be achieved. Byzantine Generals' Problem The Byzantine Generals’ Problem was conceived in 1982 as a logical dilemma that illustrates how a group of Byzantine generals may have communication problems when trying to agree on their next move. It illustrates the difficulty of achieving consensus in a distributed system with potentially faulty nodes. It is framed as a scenario where several Byzantine generals must agree on a coordinated attack plan, but some of them may be traitors trying to prevent consensus. The dilemma assumes that each general has its own army and that each group is situated in different locations around the city they intend to attack. The generals can communicate with one another only by messenger. After observing the enemy they must decide on a common plan of action. It does not matter whether they attack or retreat, as long as all generals reach consensus, i.e., agree on a common decision in order to execute it in coordination.

Transition of Consensus Mechanism in Ethereum Before I get started I'd like to point you to the Ethereum Protocol Fellowship(EPF) Wiki, where I'll be writing an in-depth version of CL in ethereum. In Ethereum, reaching a consensus means that at least 66% or two-thirds of the network's nodes agree on the global state of the blockchain. This agreement is crucial for maintaining the network’s integrity and security. The Consensus Layer defines the mechanism for nodes to agree on the network's state. It currently employs Proof-of-Stake (PoS), a crypto-economic system. PoS encourages honest behavior by requiring validators to lock ETH. These validators are responsible for proposing new blocks, validating existing ones, and processing transactions. The protocol enforces rewards and penalties to ensure validator integrity and deter malicious activity. History on Forks and ChainId Since Ethereum is a decentralized network, any participant can attempt to add a new block to an existing chain of blocks. This creates a branching structure of blocks resembling a tree. To determine the main path from the root (the initial genesis block) to the leaf (the most recent block), a consensus mechanism is needed. If nodes disagree on which path represents the official blockchain, this disagreement results in a fork — a split where different nodes might follow different histories beyond a certain point, each considering their chosen history as the correct one. This divergence can lead to incompatible records of transactions, undermining trust in the system.

Deniable Encryption: Your Secret Keeper in this world In a world where our digital footprints can be as visible as footprints in fresh snow, privacy is gold. Enter deniable encryption, a super-spy level tool that does more than just lock up your secrets—it lets you convincingly claim they never existed! What's the Big Deal with Deniable Encryption? Think of deniable encryption as the ultimate poker face for your data. It’s not just about keeping your files safe from prying eyes; it's about having the ability to shrug and show empty pockets even when your secrets are hidden up your sleeve. So, How Does This Magic Trick Work? Here’s the lowdown on how deniable encryption plays its clever game: The Ol' Switcheroo: This technique is all about multiple truths. Imagine you're forced to unlock your secret diary. With deniable encryption, you can hand over a fake key that opens a decoy diary, while your real, juicy secrets remain locked away, accessible only by another key you keep to yourself.

Directly starting from the state transition function... $$σ_{t+1} ≡ Υ(σ_t, T).....(1)$$ where $Υ$ is the Ethereum state transition function. In Ethereum, $Υ$, together with $σ$ are considerably more powerful than any existing comparable system; $\Upsilon$ allows components to carry out arbitrary computation, while $σ$ allows components to store arbitrary state between transactions. $Υ$ is State-transition function $\sigma$ is the State (the state that is stored) $$σ_{t+1} ≡ Π(σ_t, B)$$

Proposed Modifications OpML uses a multi-phase fault-proof to ensure the accuracy of machine learning results onchain. This mechanism is similar to experimental Canon Fault Proofs from the OP stack. Both technologies use a Fault Dispute Game to allow verifiers to resolve challenges on a game tree. Within this process, we aim to expand the merklized data on the OP stack FPVM to include the state transition in the opML Multi-Phase dispute game. By doing this, we aim to potentially achieve a unified framework capable of natively processing machine learning inferences onchain. By digging a bit deeper, we intend to find out if this framework’s implementation can help with the current specs or be an alternative version to the existing specs of FPVM. 1. State Transition Function Modeling The FPVM functions as a state transition system where a function $f$ maps a pre-state $S_{pre}$ to a post-state ($S_{post}$) based on an executed instruction: $f(S_{pre}$) $\rightarrow$ $S_{post}$ For integration: Proposed Framework Modification: Introduce an additional layer that handles complex decision trees or neural network outputs, which adjusts how the state transitions are computed, especially in handling error states or exceptions.