There is a common mental model for EIP-7732 which splits the proposal into three main components: Payload-Block Separation PTC Committee Trustless Builder Payments At this stage in the discussion, many core-developers are on board with the first two components. See my earlier writing if you would like to understand why. Some core-developers are more concerned about trustless builder payments and would advocate for this to be removed from Glamsterdam. As far as I can tell, there are a few main criticisms of the on-chain trustless builder payment mechanism:
7/18/2025The Problem at Hand An under-researched topic has emerged in the discussion of EIP-7732 around builders playing reveal timing games to exercise an option. Here's an example to illustrate the basic idea: Suppose at time $t=0$ three things happen: The builder places a trade to sell $Q$ ETH on a DEX at price $P_0$ at the top of their block. The builder's block is chosen by the proposer. The builder places a trade to buy $Q$ ETH on a CEX at a price $P < P_0$ to pocket the arbitrage. Suppose at time $t = Δt$ later two things happen:
7/18/2025Before last week's Berlinterop, I would never have expected that I would be recommending EIP-7732: Enshrined Proposer-Builder Separation 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. Yet another complication arose when we considered possible futures in which proposers want to make alternative agreements with builders (for example slot auctions) that the enshrined mechanism doesn't support. 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 originally raised. So then why in the world would I recommend EIP-7732 as Glamsterdam's headliner? Because to my surprise, it turns out that EIP-7732 has a number of properties which best position Ethereum for our three strategic initiatives: Scale L1: higher gas limits & L1-zkEVM Scale L2: more blobs 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.
6/24/2025