# The case for EIP-7732 in Fusaka

A one sentence, no-nonsense, FAQ for why we should include EIP-7732 in Fusaka

- **What does ePBS mean?**: you should think of the acronym as *enshrined payload block separation* and you will start to think differently about it.

## Pipelining Benefits
- **Is the complexity worth it?** Yes it is, all of the complexity lies in the separation of consensus an execution blocks, with all the benefits explained in this FAQ. The auction mechanism is the trivial part and can be swapped at any time. Take a look at [my devcon talk](https://youtu.be/w-VwYHq1FA4) explaining this in detail.
- **What timing benefits do we get?** Instead of 2 seconds to validate the execution and the data availability of the block, we get 9 to 12 seconds for it.
- **What bandwidth benefits do we get?** Instead of having to broadcast the consensus block, the execution block and all blobs in less than 2 seconds to all the network, validators only need to broadcast the consensus block in a short time. This means that peak bandwidth requirements are much smaller while maintaining the average needed bandwidth but properly distributing during the entire slot.
- **I am a homestaker why do I care?** It means better attestations, less missed proposals.
- **I am a builder why do I care?** If you are a vertically integrated builder you don't care, nothing changes. If you are instead auctioning in a relay, you get better latency and thus more time to build the block until the last millisecond.
- **I am a user why do I care?** Less reorgs means a more stable chain, less 1-slot uncertainty about your transaction being canonical or not.
- **I am a Discord support moderator, why do I care?** (h/t @terencechain) If a block is invalid, there should be more visibility on who is building the block. Currently, in discord, client developers point to the relay, relays blame the builders or MEV-Boost software, and this long debugging process causes many missed blocks (see the Bloxroute incident). Client software could blacklist bad builders after one missed block.
- **Won't my transaction take longer to be included?** Yes, with block auctions (the default in EIP-7732) The average inclusion time for a paying transaction is 12 seconds instead of the current 6 seconds. With slot auctions this UX degradation wouldn't happen (see below however for preconfirmations).

## Design decisions
- **What about tech debt?** The tech debt is the fact that we had a minimalistic merge and we now are stuck with the payload within the block. Every single future of Ethereum roadmap has these separated. EIP-7732 solves this tech debt.
- **But why do we need to have an auction?** It's not strictly needed, but after separating the block from the payload that's a minimal change and it removes a trust assumption on an external player (the relay). The auction mechanism itself can be easily swapped out at any future fork without much work. SSF for example enables a wide variety of auctions in a safe manner.
- **Will validators be able to self build?** abstolutely, moreover, homestakers that want to self build get a huge improvement since they can broadcast their execution block immediately with their consensus block, and thus having 12 seconds for that payload to be validated an an entire 9 seconds to propagate until the committee voting for its timeliness. ePBS removes entirely the bottleneck of uplink bandwidth from homestakers.
- **Does the builder need to be staked?** EIP-7732 requires the builder to be a validator and payments are handled in the beacon chain. The reason for this is simplicity. We would in principle have a system by which the builder submits payments on the EL, but this has considerable tradeoffs:
- It requires EL interaction when processing the consensus block which is something we wanted to avoid by enshrining the separation.
- It cuts the time needed to process the payload.
- It makes a purely consensus chain into a cross-layer change.
- It does not prevent the builder from having to have the money up-front stored and ready to make the payment (we can't process transactions that pay the bid with the money extracted from MEV in the same block).
- **How much will be builder need to be staked?** In the current design they will need to be staked at the very minimum 32ETH. They can only bid blocks for as much ETH as they are currently staked. So to bid for a 400ETH block, they will have to be staked as much.
- **How about smaller builders that don't have 32ETH to stake?** If there is such a builder today, presumably initially they could use staked relays (all relays today are builders anyway). However there are possible designs with DVT and/or staking pools solutions like Lido's CSM that would allow or very low staked builders to participate in the future. More research would be needed in this area.
- **Vitalik mentions APS and not ePBS in the future of Ethereum, why do we need ePBS now if we are going with something else?**. These aren't incompatible, the main benefit comes from the separation of the block and the payload which can be achieved today, after all the research and community outreach has been done on the final auctioning mechanism, that can be swapped out from ePBS. What ePBS does now is lay the ground of the separation of the block from the payload which will anyway be needed for execution tickets, execution auctions, or whatever system researchers can come up with.
- **Others talk about multiple concurrent proposers instead, are these incompatible?** No in principle MCP are not incompatible with ePBS. There is no publicly available specification for MCP, but there is no known (to me) fundamental incompatibility. MCP and ePBS address different problems, if anything MCP has more of an incompatibility with FOCIL than with ePBS. ePBS is about separating the payload from the block, not about censor resistance nor MEV extraction. This separation can be composed with anti-censor gadgets or other MEV capturing mechanisms.

## Off protocol designs
- **Will preconfirmations make ePBS impossible?** No, in fact preconfirmation design becomes simpler with ePBS, since you can slash both the proposer **and** the builder in-protocol and in a trustless manner for not honoring the preconf. Users/Apps know in advance the proposers and therefore by forcing them to use whitelisted in-protocol builders, get some assurances that their preconf is good.
- **Does it help with censorship resistance?** It does since it allows validators to monitor directly which builder is censoring. This is currently impossible by them being behind a relay. This allows for automatic detection and blacklisting of specific builders by any validator at any time. This increases the cost of censorship. Having said so, inclusion lists designs like EIP-7805 provide much stronger guarantees. EIP-7732 is fully compatible with inclusion lists, actually providing better implementation details for them.
- **Are there timing games involved?** Yes, the current timing games that make sophisticated proposers propose late will not disappear, however, the timing is more strict since consensus validation takes less time, this allows us to shorten the attestation period. In addition, late blocks will be forced to be reorged, this is not the case in the current forkchoice that has this as an optional feature.

## Bypassability
- **Will validators be able to use Mev-Boost?** no they won't, at least not on vanilla software unless consensus clients decide to keep maintaining it. Prysm will not.
- **What if every single validator decide not to use it?** What if Vitalik turns on his master node and rugs us all? let's keep it realistic please.
- **Ok seriously, how about bypassability using relays, are there benefits to still use Mev-Boost?** Ok this is a better phrased question, so let's address the many questions that people have with regards to this.
- **Builders get some services from relays, like bid cancellations, will they get this on ePBS?** Bid cancellation only exists because builders push bids in the relay auction. On ePBS they are useless since proposers pull bids at the last time. See [this document](https://hackmd.io/@potuz/HyhN0Nt9A) for a thorough explanation.
- **How about latency races?** ePBS achieves optimal latency for the builder without a relay: builders and proposers are directly connected.
- **But still proposer builder co-location leads to latency races?** This does not change at all, proposer relay co-location happens today and nothing changes in this regard. Removing the relay from the picture just removes an extra hop in the communication
- **What if builders refuse to send payment in-protocol?**. Today over 9% of blocks are not produced by Mev-Boost but over 98% of validators are registered with relays. Given a large MEV opportunity, builders can reach proposers during that slot. On ePBS, builders not willing to participate will not even get a chance to reach those validators that do not run forked software and do not want to run off-protocol. Since profits for builders are concentrated in those highly valued blocks, risking not being able to propose at all during those slots is negative EV for them.
- **How about small builders that do not want to stake** Those builders can still use a relay. Relays post-ePBS are simply builders. They can run secondary off-protocol auctions without affecting the trust assumptions nor the security of the system.
- **But if proposers can make more money off-protocol wouldn't they bypass it?** Yes they would, but as replied above, there is zero incentives and no indications that being off-protocol will be more profitable. In fact, the latency benefits and the impossibility to reach some percentage of proposers make a compelling case that being in-protocol is beneficial for proposers while being off-protocol has an opportunity cost for builders. Incidentally, a very large group of people have been trying to find actual benefits to going off-protocol, some were found in fact: Julian Ma pointed to a clear benefit to being off-protocol if we had JIT slot auctions. To my knowledge there is no known argument against block auctions, while at the same time there is a big lists of benefits of being in-protocol as mentioned throughout this note.
- **How about commit-Boost then?** Same as above (see *preconfirmations*) ePBS makes preconfirmation design much simpler by enforcing directly on the builder rather than a large validator set. ePBS obsoletes commit-boost by allowing the proposers to directly contact the preconfirmation gateway and the preconf protocol to trustlessly slash proposers and builders in-protocol.
## The case for Fusaka
- **Didn't we commit to only Peer-DAS in Fusaka?** no we didn't.
- **Will this delay Peer-DAS?** This is a tough question, I would venture that it won't but then again every single feature delays others. Having said so:
- **How does ePBS interact with Peer-DAS?**: Here's one of the biggest impacts of ePBS, current Peer-DAS devnets are broken, blob count can't be increased cause nodes don't have time to produce the proofs. Bandwidth continues being a bottleneck. ePBS gives several seconds more for proof-generations, it gives several seconds more to check the local mempool against blobs avoiding to broadcast them on the CL p2p stack. **ePBS allows Peer-DAS to fulfill its potential**.
- **What is the current status of implementation?** Prysm has a proof of concept implementation showing that we can handle the slot times and finalize a devnet. Teku has advanced implementations and hopefully soon to interop. Nimbus has two EPF working on this, Lighthouse and Lodestar have some very early advancements.
- **Isn't forkchoice a big dangerous change?** Forkchoice has a big change in that we need to deal with full or empty blocks. As with any change in forkchoice, there is a danger of network splits. However, with the latest iterations to forkchoice, all changes are now limited to dealing with empty or full blocks, this means that the formal properties of forkchoice remain the same, concentrating the risks purely to implementation bugs rather than protocol ones.
- **Are there known problems?** I already mentioned the 6 seconds delay on transaction inclusion from the user sending it. There are other known problems. On block auctions, the builder may purposedly include an invalid payload, the hash of the block is committed on-chain anyway on the CL block and it is attested to. This is like having the data availability of a very large blob that lasts for just 1 slot instead of multiple days. The cost of this is the bid for the entire block. A variant of this is the builder simply deciding not to broadcast the block because it contains some transactions that have turned out against them on centralized exchanges or other chains with faster throughput. On slot auctions the known problem is that it becomes actually beneficial for proposers to be off-protocol.
- **Are we worried about the speed of off-protocol developments?** I am, the need to separate the payload from the block is urgent. Specially given the bandwidth constrains we have today. Even though the current developments around preconfirmations and intent-based markets seem to actually benefit from ePBS instead of being harmed, the risk is that some other secondary market, in the rapidly evolving scenario with restaking, preconfs, based rollups, etc. capture enough staking participation that it makes the separation impossible.