A new data path to accelerate: Where latency will matter most when ePBS goes live on Ethereum
There's a new data delivery race that's coming with Ethereum's Glamsterdam upgrade and it's headliner EIP-7732, known as ePBS. It shifts deadlines within a slot and changes the path that block data travels, creating new areas where low latency matters most.
Today, there's a 4 second window at the beginning of each slot where block builders are sending bids through relays to the proposer. One of those bids get accepted, and then must reach the wider validator network for attestation. All this has to take place in under 4 seconds, so moving data quickly all across the world is essential. This is Optimum's bread and butter, getting blocks out to the network much faster than the standard libp2p gossip channel.
Under ePBS the slot looks completely different. Notably, relays are out of the mix and bids get sent straight from builders to the proposer. The proposer chooses a winning bid, and they'll have that bid selected immediately at the start of the slot. Once the slot begins, the proposer sends out the new beacon block to the rest of the network for attestation. The deadline for attestation under ePBS is at the 3 second mark of the slot, 1 second earlier than today.
However, the contents of that beacon block won't look the same as today either. Under ePBS the beacon block no longer contains the execution payload (the actual transactions being made), instead it contains a signed header identifying that payload. Proposer duties look relatively similar, except bid selection will occurring earlier, there's slightly less time to broadcast for attestations, and there's a lighter amount of data that needs to be sent in that phase. Fast data delivery is still important here, but the most economically important race now happens after attestation, between seconds 3-9 of the slot.
This portion of the slot is where the winning builder must broadcast the execution payload to the whole validator network. Among the network, 512 validators are selected to serve as that slot's PTC (payload timeliness committee). If the whole PTC doesn't receive and vote on the payload by the 9 second mark the slot will go unfilled. In such case the builder, who already paid out the bid to the proposer, will be left holding the bag without getting the execution order they paid for.
The Takeaway
Under ePBS, builders are in a data delivery race that takes place over Ethereum's p2p gossip network. Optimum has already built an ultra fast p2p data delivery engine (mump2p). Naturally, we're preparing to offer our services to the builder market once Glamsterdam comes online, so they can consistently realize the economic value of having their bid selected.