I'm jotting down some scattered thoughts as I work on proposer changes for EPBS. I want to ensure that any changes I make are sound and forward-compatible with the final product. For epbs, proposer may build its block under these three options Self build Get a bid from p2p Get a bid from RPC For now I am working on 1 then 2 then 3. But whatever I do for 1 should be future compatible with 2 and 3.

Introduction This post explores fork choice attacks through the perspective of EPBS, focusing on the new fork choice boost parameters and the rationale behind their design. We'll begin by examining why these parameters are crucial, followed by a review of the existing designs. For background reading, I recommend reading Payload Boosts in ePBS by Potuz. Additionally, for a deeper understanding of how the LMD GHOST fork choice operates today, consider Ben Edgington’s section on fork choice in his book, Upgrading Ethereum. Let’s dive in! References Payload boosts in ePBS - Feb/2024 By Potuz Sandwitch attacks on ePBS - May/2024 By Potuz Fork choice attacks today We analyze these scenarios from both the attacker's and the victim's perspectives, focusing on two consecutive proposal slots, each with distinct proposers. Two primary types of attacks can emerge:

Validator assignment PTC assignment This section explains how a validator determines whether it performs PTC duty in the current or next epoch. Similar to determining if it is responsible for submitting beacon attestations during a slot across an epoch, PTC attestation is a subset type where the PTC committee is selected by choosing a few validators from the end of each beacon attestation committee. def get_ptc(state: BeaconState, slot: Slot) -> Vector[ValidatorIndex, PTC_SIZE]: """ Get the ptc committee for the given ``slot`` """ epoch = compute_epoch_at_slot(slot) committees_per_slot = bit_floor(min(get_committee_count_per_slot(state, epoch), PTC_SIZE))

Highlights: A new version of the consensus specification, rebased on top of Electra, will be opened soon. We reviewed changes to the beacon block and state structure, considering whether it makes sense to use header.block_root instead of header.block_hash. We discussed using the SSZ option for the payload withheld message. We believe the slot auction is feasible and preferable in the current EPBS design and worth exploring. Finally, we discussed pre conf and EPBS, including potential contentions and the long-term winning design of pre conf on top of EPBS, as well as how EPBS can improve pre conf. Summary: We began the call by reviewing the latest progress on the consensus specification. Efforts are focused on rebasing to the latest Electra release, including moving consolidation out of the block body to the execution payload. Additional time is required to audit changes to attesting indices, ensuring they do not return PTC indices. Currently, no inclusion list is needed as validators can self-build. The specification will be opened soon with the following priorities:Open the consensus spec first, which includes beacon chain, validator, builder, P2P, and fork choice components. Follow with the EIP and engine API. Minimal changes are expected to the engine API specification.

Today is Monday, June 17, 2024, and I will address some top questions I've heard about ePBS over the last few days. I will be doing this reguarily. Does ePBS increase liveness and censorship risk with builders? ePBS does not increase liveness or censorship risk compared to mev-boost. Instead, it reduces these risks by removing the relayer as a trusted intermediary. Block Release: In mev-boost, the relayer is responsible for releasing the final block. With ePBS, this responsibility shifts directly to the builder. Uncensored Blocks: Currently, to obtain an uncensored block, both the relayer and builder must be uncensored. In ePBS, only the builder needs to be uncensored, one less censoring trusted party to worry upon. Circuit Breaker: In the current system, the client’s circuit breaker defaults to a local block if there are provable faults, such as missing enough blocks in an epoch. ePBS allows for a more advanced circuit breaker, enabling clients to monitor builder behavior and filter individual builders if they fail to reveal a payload. Liveness: ePBS maintains consensus liveness even if a builder fails to reveal a block, it’s different than today and making it more robust than mev-boost.

Writing down some proofs to prove that is_supporting_vote with message's vote is reflected correctly on the block node. to prove this, we take two consecutive blocks blk{slot: 100, block_root: 0xa} blk{slot: 101, block_root: 0xb, parent_root: 0xa} then we look at the following attestations and apply them to the blocks msg{slot: 100, block_root: 0xa}

This writeup summarizes the timeline differences between ePBS and MEV-Boost using inequalities. We analyze three models: 1) MEV-Boost, 2) ePBS, and 3) MEV-Boost with relayers on ePBS. We show that MEV-Boost with relayers on ePBS is slower than ePBS alone, which could lead to reorgs. Definitions $Validation_Time^{CL}$: The time taken by a node to verify the consensus portion of a block. $Validation_Time^{EL}$: The time taken by a node to verify the execution portion of a block. $Release_Time^{mevboost}$: The time when a block is released from a node or relayer, assuming the MEV-boost setting. $Release_Time^{epbs,cl}$: The time when a consensus block is released from a node or relayer, assuming the ePBS setting. $Release_Time^{epbs,el}$: The time when an execution block is released from a node or relayer, assuming the ePBS setting. $Propagation_Time^{mevboost}$: The time taken for a block to propagate across the network, assuming the mev-boost setting. $Propagation_Time^{epbs,cl}$: The time taken for a consensus block to propagate across the network, assuming ePBS setting.

Action items: The consensus layer client should check if it can process a consensus block in under 1 second. This includes the entire end-to-end process, similar to a pre-merge setting. The consensus layer client should provide a beacon API to retrieve the fork choice weight of a specific block. The fork choice specification should include a backoff scheme to recover from prolonged network liveness degradation. The fork choice specification would benefit from more reviewers to examine competitive edge cases. The validator specification should move the sync committee duty from 4 seconds to 3 seconds into the slot. The consensus specification requires more analysis on whether PTC slashing is fully necessary and if the attack vector of spamming multiple PTC statuses is a concern. The consensus specification may need to move the builder reveal cutoff and PTC attestation cutoff to an earlier time to mitigate the builder reveal timing game. Summary:

This post focuses less on the technical aspects of block building and more on the high-level reasons why depending so much on closed-source and out-of-protocol block production software in L1 consensus is negative for the protocol. While some points may seem trivial, they are worth discussing in written form with key points. First, let's define what an out-of-protocol software is and then extend the terminology further. Core-protocol software: Software that one MUST run to follow or extend the chain. Extending the chain requires staking or some sort of economic bond to account for malicious behavior. We call this software core-protocol because you must run it to follow the chain correctly and extend the chain honestly. Actions from running the software and protocol are auditable on-chain. For example, "Did Alice's validator correctly vote on slot 100?" This is further provable with EIP-4788, which can be verified on the EVM. Out-of-protocol open-source software: Software that one may run to extend the chain. An example of this is mev-boost. Some portions of relayer components are also open-sourced. Given the out-of-protocol nature, it's not auditable and enforceable. For example, "Alice chose a bid to include, but the relayer did not reveal the block on time, so Alice did not get paid." Who is at fault here? Out-of-protocol closed-source software: Software that is proprietary and cannot be run by everyone. Most builders and searchers use proprietary software. Some relayers have proprietary software components, like delaying bids or taking a fee/rebating bids to builders. For example, "The relayer offered Alice the best bid of 0.03 ETH, but is that really the best bid from the builder? How can this be trusted?" Key Point #1: The protocol is healthier the less it has to interact with closed software.

Screenshot 2024-04-30 at 9.30.36 AM This post starts by analyzing the advantages of consensus and execution block timing games both before and after the ePBS setting, focusing on the preparation time available to the next slot's proposer/builder for the subsequent slot. We then dissect the dynamics of timing when the builder block reveals, focusing on altruistic, honest, and greedy rational builder rationale. The second half of the post highlights the greedy rational builder's advantage in controlling the timing of the execution block reveal. Finally, we will list out a series of open questions for further exploration. Terminologies, Acronyms & Abbreviations ePBS (enshrined proposer-builder separation): A protocol enhancement where relayer functionality in mev-boost setting becomes part of the protocol, enabling trustless exchanges between validators and builders. New validator duties: payload timeliness committees is introduced. Unless specified otherwise, references below refer to block auction ePBS. CL (Consensus Layer): Where consensus activities like votes, slashing, and deposits happen.. EL (Execution Layer): Where execution activities like user transactions and EVM happen. Pre-ePBS beacon block: A consensus block that contains consensus data and a full execution block. Post-ePBS beacon block: A consensus block that contains consensus data and an execution header, the header commits to the execution block which is later revealed. The transactions are hidden.

TLDR: Relayers today represent both functionalities and entities. Under ePBS, the entities will disappear, but the functionalities may persist. Builders can and likely will absorb these relayer functionalities, which is positive for the MEV supply chain and the beacon chain for the reasons outlined below. Background It's December 31, 2025, and you have decided to stake 32 ETH to become a validator on the Ethereum Beacon Chain. You prepare to start your consensus layer beacon client, validator client, and execution layer client. While starting your validator client, you check the documentation and notice a CLI flag to input a list of builders from whom you wish to outsource execution blocks. You pause, thinking, 'Wait, this seems like how mev-boost used to work. Instead of connecting to relayers, I’m connecting to builders. Wasn't the entire point of ePBS to eliminate the need for these direct RPC connections? How did we end up here? We will address a common critique of block auction ePBS: the concern that relayers can not be bypassed, thus offering little difference from the current MEV-Boost PBS design. The persistence of the relayer functionality is likely in all PBS designs. Why wouldn't the relayer functionalities disappear? In short, relayers provide functionalities attractive to both proposers and builders: Fast connection over RPC reduces latency, allowing more time for MEV opportunities. This may be less relevant for slot auction-based ePBS or execution ticket-based ePBS, but our focus today is on block auction ePBS. Customization over bid preferences, such as bid cancellation and pre-confirmation, is more flexible via a single HTTP request-response exchange than through a p2p gossip network.

DALL·E 2024-04-07 15.26.59 - Design an image featuring the exact text 'ePBS vs ET' in a clear, bold font against a deep space background. The background should showcase the beauty This writeup compares ePBS and ET in their current specification forms. It outlines their similarities and differences, including a table below for reference. First and foremost, it presents some disclaimers, related work, and relevant acronyms Disclaimers Enshrined proposer builder (ePBS) referenced below primarily refers to block auction ePBS. There are various forms of PBS that people will discuss, such as slot auction PBS and others. The comparison below focuses mainly on block auction ePBS versus ET. Execution tickets (ET) referenced below are from the post in related work. It's important to remember this was the first post on execution ticket design. The design is volatile, and nothing is final, including ePBS. It is highly subject to change in the coming months. The views expressed in this post are my personal views and do not reflect those of my team or company. Related work

Agenda: https://github.com/ethereum/pm/issues/1000 Goal: Review the latest issue with IL regarding EIP3074 Problem statement: IL in n specifies address 0xa. Payload in n from a different address changes 0xa's balance. Payload in n+1 lacks a tx from 0xa, yet needs to confirm the summary condition is met for both validity and availability conditions. General problem can be broken down into two parts:

Currently, Blob transactions (type-3) are not supported in the Inclusion list EIP (EIP-7547). This document explores ideas and proposed changes to enable blob tx support. It is organized into the following sections for easier comprehension. Consensus data structure changes class InclusionListSummaryEntry(Container): address: ExecutionAddress nonce: uint64 tx_type: uint64 # New for Blob Tx class InclusionList(Container): signedSummary: SignedInclusionListSummary transactions: List[Transaction, MAX_TRANSACTIONS_PER_INCLUSION_LIST]

Monday, March 18, 2024 Objective The purpose of this break out room was to reach a consensus on the PoC spec details, enabling client teams to start implementation and decide on the IL for Pectra hard fork in the coming weeks. Key Decisions for PoC Specifications: Conditional vs. Unconditional IL for next slot proposer IL tx placement in the next block IL gas limit considerations Bundle vs. Unbundle over p2p

Definitions Proposer: Actor that signs the block. Same as validator. Builder: Actor that constructs the block. Local block: Block is constructed using local mempool. Not using mev-boost. Builder block: Block is constructed using mev-boost. Bid: The amount builder is willing to pay proposer if the block remains canonical on chain. Simple eth transfer. Defining censorship Before we start, let's define censorship in its simplest terms, when a user sends a transaction with more than sufficient base fee and tip, the transaction never gets included on the chain. There are weak and strong censorship. This article excludes the reasoning behind censoring and assumes it's just a binary decision by the proposer or builder. In the rest of this article, we will refer censorship as weak censorship and see if we can improve upon that and avoid the last defense, where the last defense for censorship through the social layer. Defending through the social layer is extremely messy, client teams need to update their code and make releases under time constraints. This is why optimistic rollup has a 7-day withdrawal delay under happy case. Can we do better against weak censorship today?

Block processing data Before Denenb Screenshot 2024-01-17 at 7.20.43 AM After Deneb Screenshot 2024-01-17 at 7.21.18 AM Notes Surprisingly, there has not been much change in chain service latency; the increase is minor. As expected, post-block and state transition have remained the same.

Background Recently, there's been a lot of buzz about the validator timing game. In this post, I want to delve into a different twist of this topic, exploring the interplay between consensus client and execution client with Engine API. I'll walk you through various scenarios, showing how this game unfolds and why sometimes your validator might miss out on an attestation head vote, or in more extreme cases, even a block. It's important to note that what I'm describing here is specifically tied to the Prysm Consensus Layer Client. This might not hold true for other clients, but hey, that's the beauty of client diversity! CL <-> EL Interactions First off, let's dive into how the CL (consensus layer) and EL (execution layer) work together after the merge. Your CL client has a few key tasks for the EL client, plus an extra request if it's proposing a block in the next slot. Here's what it boils down to: CL client asks the EL client, "Can you validate if the execution part of this block (execution payload) is valid?" Then CL client asks the EL client, "Can you make this block the new head? (ie ForkchoiceUpdate = FCU)"If CL client has a validator proposing the next slot, it adds, "and can you also begin preparing me an execution payload that's built on top of this new head? (ie FCU + attribute)" CL Validations

This post examines the potential timing dynamics at play between validators and builders, particularly in the context of post EIP-4844 with blob transaction enabled. We analyze various scenarios, discussing preventable measures for each. Vanilla Validators Without MEV-Boost: Approximately 8% of blocks are produced without MEV-Boost, suggesting a similar proportion of validators do not use MEV-Boost. These validators are straightforward to reason, and they adhere to the default behavior of standard client implementation, including transaction from public mempool based on predetermined code. If a transaction meets the base fee requirements and sometimes a priority fee as per EIP-1599, it gets included in the block. These validators do not engage in censorship or MEV extraction based on the nature of transactions. Representing the essence of blockchain in its purest form, they are integral to its fundamental principles. In the post EIP-4844 world, validators maintain a consistent approach, including blob transactions from the blob mempool as long as they are accompanied by adequate fees. This consistency simplifies economic modeling and analysis for entities like Layer 2 solutions or others aiming to publish blobs on the Ethereum network. Validators Using MEV-Boost The remainder of validators utilize MEV-Boost, indicating that block construction is outsourced to external builders, leading to increased centralization. In this scenario, validators play a limited role, focusing solely on constructing the consensus aspect of the block while deferring the execution component to the builders. This process involves validators signing the block and broadcasting it before a deadline (4s into the slot) to avoid reorg.

Pre-req: https://github.com/ethereum/consensus-specs#3531 PR: https://github.com/prysmaticlabs/prysm/compare/update-sync Key Design Decisions and Open Questions First-Class Citizenship of ROBlob Transitioned from using the protobuf format ethpb.BlobSidecar to ROBlob. Benefits: Efficiently handles hash tree root headers. Enables caching of verification results. Open Question: Are there any downsides or limitations to making ROBlob a first-class citizen? Direct Alignment Check Using ROBlob and ROBlock