# Glamsterdam's Hidden Gem: EIP-7732 Before last week's Berlinterop, I would never have expected that I would be recommending [EIP-7732: Enshrined Proposer-Builder Separation](https://eips.ethereum.org/EIPS/eip-7732) as the network's highest priority, worthy of taking the spot as Glamsterdam's headliner. Enshrined Proposer Builder Separation (ePBS) was originally designed primarily to enable a trust-free (no off-chain relay requirement) exchange between proposers and builders. This motivation took a major hit years ago when researchers realized that [it isn't possible to completely eliminate the incentive to use out of protocol software/relays](https://ethresear.ch/t/relays-in-a-post-epbs-world/16278). Yet another complication arose when we considered possible futures in which proposers want to make [alternative agreements](https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879) with builders (for example [slot auctions](https://efdn.notion.site/Arguments-in-Favor-and-Against-Slot-Auctions-in-ePBS-c7acde3ff21b4a22a3d41ac4cf4c75d6)) that the enshrined mechanism doesn't suport. In such a future, these proposers would *necessarily* go out-of-protocol to make these agreements, seemingly undermining the whole purpose of ePBS. The last thing we wanted to do as core devs is to spend a significant amount of engineering resources to bring this market on-chain, only to have most proposers use out-of-protocol software anyway. No solution to these concerns has been found in the years since they were origianlly raised. So then why in the world would I recommend [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732) as Glamsterdam's headliner? Because to my surprise, it turns out that [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732) has a number of properties which best position Ethereum for our [three strategic initiatives](https://blog.ethereum.org/2025/06/02/announcing-protocol): 1. Scale L1: higher gas limits & L1-zkEVM 2. Scale L2: more blobs 3. Improve UX: lower latencies, faster finality, pre-confs This becomes particularly clear if one takes a slightly longer view of Ethereum for more than one fork down the road. If we do EIP-7732 (and maybe also FOCIL) in Glamsterdam, then we can do shorter slots in H*. 7732 enables us to have shorter slots than any alternative proposal. And for a given slot time we can have more blobs, and bigger blocks than any alternative proposal. And by doing it in this order (7732 first), we can achieve this vision faster and with less technical debt than any other ordering. ## EIP-7732 Rationale To understand the benefits of 7732, we need to understand the anatomy of a slot. This is the slot as it exists today.  This picture boils the slot down to the essential physics of the problem at hand. There's a protocol defined "safe broadcasting time" which is defined as `0`. There's a cutoff for attestations `A`, and there's a point at which the attestations broadcast at `A` have been aggregated and broadcast to validators `H`. It is essential to notice that we can play with the timings of these things, but we cannot reduce the time between `A` and `H`. If we want to move `H` to the left, we must move `A` to the left by the same amount. And we cannot make the slot end before `H`. Quick note: some proposers play timing games and don't actually release their block at `0`. Instead, in an attempt to maximize MEV extraction, they broadcast their block at another time after `0` but before `A` which we might call `λ` (the optimal mev-extraction release time). This has no impact on the analysis here as you can *mostly* replace `0` with `λ` in the diagrams and draw the same conclusions. `λ` will always adjust backwards towards `0` as we increase the time required to broadcast and validate the block. When one views the current anatomy of a slot through the lense of these three initiatives, it becomes immediately apparent that there's a problem. The block and blobs need to be transmitted (which I will refer to as the broadcast time) and executed by the EL (which I will refer to as validation time for reasons I will explain later) before the attestation deadline. Today, with the attestation deadline at 4 seconds, a full 2/3 of the slot is spent neither transmitting or validating the block/blobs! If we want to increase the blob counts and gas limit as much as possible, we can't afford to waste this time. Add real-time proving requirements without any changes and you add yet another heavy task that needs to fit in this small window. ZK-EVM teams reported last week that they're roughly 6 months away from being able to prove blocks in 6 seconds. Given this, it's highly likely that if we prioritize these changes in Glamsterdam, not only will it have benefits for more transactions and blobs, but real-time proving will also become viable for limited applications in the same fork. Now let's consider how we improve this situation. ### 1. Eliminate the slack We can do something like this:  We could eliminate the space between `H` (the time when proposers have enough aggregates to calculate their head) and the next `0` where the next proposer has to propose the next block. Notice this can be done *either* by moving `A` further to the right in the slot or by shortening the right half of the slot towards `H`. The result is the same (from a throughput perspective). The point of this diagram is to notice two things: 1. We can't just move `A` all the way to the right as nodes need to broadcast attestations, aggregate them, and broadcast aggregates before the next attestation deadline. 2. Simply shortening the slot time without changing anything else does little to put us in an optimal position. We still waste a huge chuck of the slot not broadcasting or validating. ### 2. Delayed Validation / Pipelining I will call the next modification delayed *validation* rather than delayed *execution*, as it is sometimes referred to (it has also been called pipelining). There is another proposal on the EL called delayed execution which is orthogonal to these considerations and we want to avoid confusion. The idea with delayed validation is to change the meaning of an attestation so that validators are just attesting to the availability of a block (& blobs), and the rest of the slot is spent determining if the block is valid. If we do this, we are left with this situation:  This is a significant improvement over today. We now have until the attestation deadline to broadcast, and essentially from whenever the block is received until the end of the slot to finish validating the block. Note that we still don't have the full slot for broadcasting because we have to have enough time for attestation aggregation. Now we address the elephant in the room: If we're not attesting to validity, how do we deal with blocks that are found to be invalid after the deadline? There are three main strategies: #### 1. Simply re-org the block This is straight forward but it has the downside of throwing out the votes for this block which: 1. penalizes honest attesters 2. throws out the weight they also gave to the ancestors There are... hacks to get around this. None of them are pretty and in my estimation they introduce technical debt that isn't worth it. #### 2. Separate the beacon block and execution payload If we do this, we can throw out the execution payload if it's invalid and keep the consensus payload and the votes. This is what 7732 does except both the payload and must be available at the attestations deadline A. This version lacks the need for the so-called "payload timliness comittee" and so I will refer to this as 7732-noPTC. #### 3. Delay Execution on the EL This is [EIP-7886](https://eips.ethereum.org/EIPS/eip-7886). Essentially we simply keep the block in the chain even if it's invalid, but we make it a no-op. This runs into a "free"-DA problem since the transactions that take up space in the block are not actually charged for the space. There are a number of different techniques we can try to do to bound this issue. It's also not clear at this point how big of a problem this actually is. The data isn't quite "free" because proposers have to sacrifice proposal rewards which (likely) will always be worth more than the DA costs. Surveying the researchers (last week), they were divided over whether they would prefer option 2 or 3. We will discuss these options and their tradeoffs in further detail, but for now we just want note that the decision seems to fall between [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732), 7732-noPTC, and EIP-7886. We discuss 7732 next. ### EIP-7732 How does [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732) change this picture of the anatomy of a slot? 7732 introduces another committee into the slot, the so-called Payload Timliness Committee. The purpose of this is to ensure honest builder safety (that the builder's payload will become canonical if they're chosen honestly and they reveal on time). But a side-effect of the PTC is that the anatomy of the slot becomes the following:  There are several things to notice here: 1. The `BeaconBlock` now lacks an `ExecutionPayload` and blobs (containing only the hash of the `ExecutionPayload`). Thus it can be transmitted significantly faster than a full `ExecutionPayload` and blobs. Attesters are now only attesting to availabilily (and trivial validity checks) of the `BeaconBlock`. Thus the attestation deadline `A` can be pushed to the left, near the beginning of the slot. 2. The PTC can be moved very far to the right of the slot as there are only 512 PTC attestations and they don't require aggregation (they never go on chain). 3. We now have almost the whole slot for broadcasting! This is the only proposal that achieves this. **This means 7732 allows for more blobs than any other proposal.** 4. Attestation aggregation has been removed from the critical path! As the attestations due at `A` do not attest to the payload availability, we can broadcast the payload and blobs while waiting for the attestations to aggregate. This actually allows us (in a future fork) to shorten the slot significantly. You could push the PTC deadline left until it's essentially on top of `H` and shorten the slot to be slightly longer:  **Contrary to your intuition, adding another attesting committee (the PTC) allows us to have shorter slots than not doing this. Thus 7732 allows for shorter slots than any other proposal.** From these arguments, it should be clear that [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732) offers the the best utilization of time in the slot. So how does 7732 compare to other viable proposals? ### Comparison between proposals So now we are left with three viable proposals: 1. [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732) 2. EIP-7732-noPTC 3. [EIP-7886: Delayed Execution](https://eips.ethereum.org/EIPS/eip-7886) Client teams and researchers spent a full 6 hours debating these the tradeoffs of these options for Glamsterdam during the recent Berlinterop. I will attempt to summarize the results of this debate below. #### 7732 vs 7732-noPTC Without the PTC, the anatomy of a slot reverts to the "Delayed Validation / Pipelining" picture in the second section above. Attestation aggregation remains in the critical path. Also.. 7732 has not only an EIP, but a full consensus spec, and two client implementations. 7732-noPTC has none of these. What we get in return for not having the PTC is slightly less modifications to fork-choice. It's worth noting that the *vast majority* of the fork-choice modifications in 7732 are present in both proposals, and there was unanimous agreement that these modifications were acceptable. It was less clear is if the addition of the PTC was acceptable. 3 out of 5 clients believe it is. The other 2 are undecided. My take on this: while I understand the motivation to minimize fork-choice complexity at all costs, I don't think the concerns around the PTC are well founded because: 1. In all but *one* case (discussed below), the PTC has zero impact on the result of `get_head()`. 2. Even in that one case, PTC votes only affect fork-choice for 1 slot (they are the builder's proposer boost) and they do not go on chain. This means they do not affect finality and don't open up new balancing attacks. 3. As consesus around 7732 has formed, [Francesco has proposed slight modifications to eliminate the boost from the PTC](https://hackmd.io/UX7Vhsv8RTy8I49Uxez3Ng?view), greatly simplifying the fork-choice analysis at the cost of having to change the `AttestationData`. I am in favor of this. Let's take a look at the one case where the PTC actually matters TODO #### 7732 / 7732-noPTC vs EIP-7886: Delayed Execution The advantage of [EIP-7886](https://eips.ethereum.org/EIPS/eip-7886) is that it requires no modifications to fork-choice. However it comes with the following downsides: 1. There is a "free" (in reality the cost of a proposal) DA problem. It's unclear how much of a problem this is. There are various methods for trying to address this which have a number of tradeoffs. 2. The chain is significantly more stable when the `BeaconBlock` and `ExecutionPayload` are separated in a future without local block building. A chain that doesn't separate the `BeaconBlock` and `ExecutionPayload` will lose finality if there's a problem building payloads. Today this is acceptable because the chain will eventually trigger a circuit breaker and revert to local building. But local building will not always be viable. In this future, a problem with a major builder will cause chaos in the consensus layer and cause Ethereum to lose finality if the `BeaconBlock` is not separated from the `ExecutionPayload`. It's much cleaner to have these separated. Viewed from this lense, separating the EL and CL blocks can be viewed as cleaning up tech debt from the merge. 3. Less bandwidth efficient than separating the payloads as noted in [EIP-7898](https://eips.ethereum.org/EIPS/eip-7898). 5. FOCIL is more difficult to implement in EIP-7886 unless you also implement [EIP-7928](https://eips.ethereum.org/EIPS/eip-7928). It is worth noting that EIP-7928 greatly facilitates real-time proving, so this EIP will likely be adopted. 6. The anatomy of a slot is the "Delayed Validation / Pipelining" picture above. The same performance as 7732-noPTC but less optimal than 7732. This means more wasted time, and slots can't be shortened as much. 7. 7886 requires changes across both the CL and EL while the 7732 & 7732-noPTC only require CL changes, leaving the EL to focus on itself for the Glamsterdam fork. 8. If it turns out that the "free"-DA problem is acceptable, you can do EIP-7886 and EIP-7732 simultaneously. Thus the time advantage for proving stacks and proovers now get **TWO SLOTS** for proving rather than one with just one of these proposals. ## Loose Ends #### Why not FOCIL? Some say EIP-7732 makes FOCIL eaiser and so Glamsterdam should be 7732 AND FOCIL. The jury appears out on this question. I'm in favor of doing both if it's viable. If it's not viable, I'd be in favor of FOCIL + shorter slots in H*. #### Why not shorter slots first? It's my belief that we can do one of re-organizing the slot or shorter slots but not both in the same fork. If we were to do shorter slots first without re-organizing the slot, we will end up leaving a significant amount of the slot wasted because we leave aggregation in the critical path. We cannot shorten slots any further without reducing blobs or the gas limit. If we decide in the future that we want to reclaim this time, we then have to do all the same work of implementing something like 7732, and then REDO all the work of timing and performance measurements and shortening of the slot again. We waste almost and entire hardfork by doing this out of order. Intuitively it makes sense to settle on the structure of a slot first and THEN shorten the slot. #### Enshrining the "wrong" thing? As of today, we haven't yet seen proposers making alternative agreements with builders. Even if this changes, we can just let them go out of protocol or modify the protocol later. We're doing 7732 because of the optimal resource uitlization within a slot so we're less concerned about this than we would be if we were doing this primarily to eliminate off-chain agreements. Even if proposers go out-of-protocol, we still get all the resource utilization benefits of 7732. #### Why did it take so long to come to this conclusion? EIP-7732 has faced significant headwinds on the road to adoption for several years. In my estimation, this is due to several factors: 1. The main reason to do it is not the main reason it was originally designed. 2. The benefits are counter-intuitive. Who would think adding another attestation committee would allow you to have shorter slots? 3. The fork-choice changes are significant and touching fork-choice is delicate enough for most to avoid it. They can only be understood upon closer examination that most had not considered. 4. The above factors contributed to a feedback loop, causing people to write it off without a close enough examination, which meant it couldn't reach a critical mass of people who understood the EIP and its benefits.