# ePBS FAQ #0

*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.

**Does ePBS increase protocol complexity?**

- **Increased Complexity**: ePBS modifies the fork choice rules by changing block voting to `(block, slot, reveal_status)` voting and introduces two additional variables: *reveal boost* and *withhold boost*. These changes add linear complexity to the protocol, requiring careful consideration. ePBS aims to fit within the 12-second slot by reducing the beacon committee deadline from 4 seconds to 3 seconds and adding a payload committee at 9 seconds. Although these changes are promising on paper, their full impact will become clear during implementation. For more details, see the [design constraints](https://ethresear.ch/t/epbs-design-constraints/18728), [payload boosts](https://ethresear.ch/t/payload-boosts-in-epbs/18769), and [analysis](https://hackmd.io/@potuz/SJdXM43x0).
- **Reduced Complexity**: ePBS simplifies the protocol by separating consensus and execution into different stages. Currently, all processing must occur within the first 4 seconds, leaving effectively only 1 second before the beacon attestation deadline. ePBS delays execution validation to the subsequent slot, providing more time to validate execution, as detailed [here](https://ethresear.ch/t/advantage-of-pipelining-consensus-and-execution-delayed-execution/19668). This separation results in lighter and faster consensus and execution blocks, potentially reducing reorgs. With more processing room in both stages and a more robust fork choice, new features can be added more easily. For example, implementing inclusion lists on top of ePBS is easier than standalone today because the new fork choice accounts for (block, slot) votes.

**Can ePBS be bypassed by using MEV-Boost and relayers on top of ePBS?**

While ePBS can be bypassed using MEV-Boost and relayers, practical limitations make it challenging. To use MEV-Boost on ePBS, a relayer or trusted party is required to verify the exchanges. Adding a middleman introduces latency and costs due to additional hops—the builder submits the block to the middleman, who then verifies it. This added step increases the time needed to release the block compared to pure ePBS, where the builder directly releases the block. As a result, these delays can make blocks less profitable and more reorgs than with pure ePBS. More details on the timing impact can be found [here](https://ethresear.ch/t/block-proposing-validating-timelines-for-1-mev-boost-2-epbs-and-3-epbs-with-mev-boost/19782).

**Does ePBS freeze market design and allocation rules in a suboptimal state?**

ePBS does not freeze market design and allocation rules in a suboptimal state. Instead, it expands the design space, allowing for iteration on new market designs and allocation rules. It’s a positive step foward. Like other auction types, such as slot and ticket auctions, ePBS adds pipelining of consensus and execution with an additional round of consensus to ensure execution timeliness or validity. This approach is similar across different auction types, including block auctions, slot auctions, ticket auctions, and APS. Advanced auction types may introduce further constraints, such as in-protocol ticket market, execution proposer slashing, or more complex fork choice rules, but ePBS is designed to be forward-compatible with these future iterations. Concerns about potential limitations are welcomed for feedback and can be addressed to ensure ePBS remains adaptable to evolving allocation rules.

**Does ePBS change the auction mechanism unpredictably, raising concerns about potential second-order effects?**

ePBS does alter the auction mechanism, and the exact impacts are still uncertain. In the current mev-boost system, all bids are public. With ePBS, p2p bids remain public, but RPC bids can be either private or public depending on the design. If private bids are desired, builders could require proposers to sign their requests with a nonce using the builder’s public key. If public bids are desired, builders could allow anyone to query the latest bids. However, builders may not always follow the rules, leading to information asymmetry. Currently, with relayers, all builders submit their bids through the relayer, which controls the handling of these bids, which makes it easier to host different type of auctions under relayer (e.g. second price auction). It's also very important to note that the builders have to trust the relayers to host the auction honestly and trust relayers with their bids. The second-order effects of ePBS auction market will depend on how it manages builder bids and whether it enforces complete privacy or public access or whether there's a trustless way for publishing bids. This is an area that requires further consideration as we move forward.

**Is enshrining OOP-PBS premature given its rapid evolution?**

OOP-PBS is evolving rapidly, but it’s worth considering whether block auction ePBS is already an improvement over the current mev-boost system. If ePBS is better and compatible with common OOP-PBS designs, why delay upgrading to block auction ePBS first? The urgency depends on how flawed we believe the current mev-boost design is. If we see it as a [severe](https://www.nasdaq.com/articles/ethereums-censorship-problem-is-getting-worse) [bug](https://blockworks.co/news/mev-the-relays-problem) rather than a minor one, addressing it promptly with block auction ePBS makes sense. The primary motivation for some of us pushing block auction ePBS now is to fix what many consider a bug in the current mev-boost market, as part of our responsibility to maintain the network’s health. Finally the benefit of incremental updates is great, as this approach mitigates the risks associated with a large-scale upgrade.

**Does ePBS misalign economic incentives with builders' current revenue models?**

ePBS does not significantly alter builders' current revenue models. In fact, ePBS is likely to increase revenue for both builders and proposers. Currently, a portion of the builder's bid to the validator is used to pay the relayer, which is a reasonable cost given the services relayers provide. By eliminating this intermediary and enabling direct exchanges between builders and proposers via RPC or P2P, the end to end costs are reduced. Although builders need to open their RPC ports and handle proposer requests, these costs are minimal. In this model, validators receive the full payment directly from the builder.

**Does ePBS increase security risks by integrating builders into the core protocol?**

Builders cannot attack the protocol as one might think. Builder’s acution primarily affects the timeliness of the execution payload, which influencing only the head vote of the subsequent slot and not the finality gadget itself. Builders, for example, cannot execute balance attacks on the protocol. Interestingly, the current proposed values for proposer and builder boosts in ePBS represent an improvement over the current classical state for sandwich attacks. In the classical case, sandwich attacks require a malicious validator controlling up to 20% of the network. In ePBS, due to the reveal boost, sandwich attacks can tolerate a malicious validator controlling up to 50% of the network. However, resistance to multiple slot post-anti-reorgs decreases in ePBS, dropping from 60% to 40% for 1 slot and from 53% to 37% for 2 slots. Ex-ante protection also decreases from 40% to 20%, even though that the payload under the ex-ante attack is safe builder withholding property. For further mathematical details, refer [here](https://ethresear.ch/t/sandwitch-attacks-on-epbs/19538).

**Is ePBS not forward-compatible with pre-confirmation, potentially limiting current off-chain developments?**

From what I can see, out-of-protocol pre-confirmation is independent of ePBS. Pre-confirmation can be achieved under ePBS by using an intermediary, like a relayer, similar to the current approach. However, relying on a trusted party introduces latency for verification and is not ideal. If most validators opt in as pre-confirmers, then ePBS might not offer significant advantages over MEV-Boost, since it would revert to using an intermediary party.

In-protocol pre-confirmation brings more challenges in terms of compatibility with ePBS. Key questions include: What is the inclusion list? Can we slash the builder within the protocol? These are open questions, and it remains an active area of research. It’s worth noting that in-protocol pre-confirmation not only interacts with ePBS but also with the inclusion list, so all these aspects need to be aligned eventually.

**Does removing a trusted middleman matter if nearly all Ethereum blocks are built by the handful of players?**

Centralized block construction exists today and may continue in ePBS. While ePBS doesn't directly solve the problem of centralized block construction, it improves the situation by opening builder markets directly to proposers. Builders no longer need to go through relayers to reach the proposer. They compete directly among themselves without worrying about choosing the best relayers to work with, creating a healthier market.

Another internal benefit is unconditional payment. The protocol guarantees unconditional proposer payment rather than relying on a social contract. If the proposer reveals a valid consensus block on time, they will be paid the exact bid amount at a specified time, usually within the same slot or a new finalized epoch. While unconditional payment can also be guaranteed through an out-of-band social contract, it is more cumbersome.

Moreover, ePBS addresses issues by removing the need for trust, making the protocol cheaper, faster, and safer. Currently, the protocol’s reliance on hard trust increases latency and consensus faults. Although decentralized block building is orthogonal to ePBS, it may benefit from the reduced trust requirements and improved efficiency.