# What is the status of ePBS and its future iterations by Potuz | Devcon SEA

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 24:44
- Watch: https://streameth.org/watch/yt-w-VwYHq1FA4
- YouTube: https://www.youtube.com/watch?v=w-VwYHq1FA4

## Description

We will go over the implementation and research status of ePBS (EIP-7732) and the future iterations and mechanisms it enables.We will describe in detail the main benefits to the protocol that are not directly related to any PBS system. We will showcase the tradeoffs that are present on each design decision and how the separation of validation between the consensus and execution layer in fact frees research with less technical debt and more independent mechanisms for future upgrades.

Speaker(s): Potuz
Skill level: Intermediate
Track: Core Protocol
Keywords: PBS, fork, choice

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] thank you but just in my defense I opened my Twitter account only to pitch this and as soon as this is shipped I'm going to shut up on Twitter anyway so today I'm going to be talking about the status of epbs and epbs during this talk is going to mean enshrined payload block separation this is not the usual meaning and you'll notice that I'll only mention proposers and Builders towards the last couple of slides um the talk is going to be divided in three sections the first section I want to convince you for a while that um dividing the payload the execution payload from the consensus block is something that is necessary in ethereum it is highly beneficial it is a scaling factor and it enables other scaling Solutions like PR Das to actually fulfill its full potential we have this problem that we have since emerge which is our Tech depth that we adopted this minimalistic way of merging out of proof of work in which we included the execution block the one that has the transactions and everything that we need to like modify the ethereum machine inside of the consensus block that has the attestations the deposits the exits everything that we need to decide what what is our current head and we distribute them both together this makes for a large Chun of data that is distributed among the nodes when this data has logically different purposes and logically different validations what a node does when when it reaches gets a block it needs to get to consensus in two different things one thing is what is the status of the network what is the execution status of the network the validity of the block and the other thing is given two different views of the network which one even both of them possibly valid which one is the one that we consider the head of the chain these two validations are completely independent and they are done by two different clients even two different soft pieces of software the validator runs in the running in the computers the execution consensus is about validity the consensus consensus is about which one of the world the viewers of the world is the current one because of our Tech Deb the way that we validate blocks puts all of the strain of the network in the very first few seconds of the slot a block is broadcast at the beginning of a slot and it needs to be validated it needs to be downloaded entirely by by the whole network and by 4 seconds validators need to have already checked consensus executed the execution check that the blob data was available in the future check that inclusion list this were're satisfied and a test for this the rest of the slots is useless time essentially we're just counting attestations aggregating them the node doesn't do anything if anyone here runs a node you're going to see here the fans going off exactly every 12 seconds so that's what the ethereum validation is today and the question is can we make this better can we make the timings better presumably yes we have 4 seconds and we don't use those for seconds but the problem is that validators are incentivized to actually propose their blocks as late as possible so that they can extract more M out of them and these timing games make twigling with this these timings for attestations a an impossible problem to solve if we gave more time to actually sync better blocks larger blocks have more blobs in the network what would happen is that validator would just propose later and extract more m so why separating them since we do not need to validate execution to decide what is our head why not just broadcast the block which is a minimal block which is just consensus validate consensus decide what is our status of the of the chain and then use the rest of those 12 seconds to validate execution check if the blobs are available validate inclusion list do all of the stuff that is actually heavy in the High latency path and the low latency path which is validation of consensus that takes two seconds you just download the tiny block validated immediately it takes 7 70 milliseconds today to validate the consensus side and just a test so that's that's a scaling feature of separating the the payload From the Block so that was the first part of the talk I want to I hope I convince you that the separation gives us a lot of benefits for ethereum now the question is what have how can we achieve separating the block from the payload and the minimum features that we want that we need if we want to separate them would be this so what's what we desire of such a s of such a separation we would want to have these validations done completely independent we want to validate the consensus side in the fast path and the execution side in the low in the in the slow path we want to separate the propag of these two blocks the large chunks of transactions might take longer to come the blobs that are the huge chance of transaction might take longer to to to come we do not need to have a very high uh Uplink bandwidth to submit the blobs because it takes 12 seconds to be disseminated so we solve the bottlenecks that we have we have today in things like perer D or full D and we see immediately one problem and is that well since now you cannot sign the block with with the payload because because otherwise we would have a free data availability problem we need to have those two objects being signed that's it that's not so hard verifying signatures is not a problem here's a real problem the real problem is that now whatever the situ whatever the designed the mechanism designed to separate the block from the payload you will have to deal with new features uh with new situations uh today a slot either has a block or it doesn't those are the two possible stat if you have a consensus blog you have a payload and if you don't well you don't have a payload but in a situation in which you have validated the blog the consensus block you attested to it and it's your head and the payload might be invalid or might not come or the blobs were not available or it didn't satisfy an inclusion list the situation is that we have two we have one extra status which is the status in which the consensus block was valid and the payload was not and this gives a problem which is a for Choice problem you need to change for choice to account for this for this statuses you need to check that if I attested to a to a block that whose parent did not have a payload well that attestation this does not count towards a parent that did had a payload and this is completely independent of any auction mechanism this is the complication of for choice of course you need to still provide security that you're not going to be reared for free but anyway so in such a word the other complication that you have that client implementers will have is the fact that we we have it enshrined in our coding that we get the block we validate in certain order we we can validate in parallel execution and consensus and we all do because the validations are independent but then we wait until both validations are done and we attest now one would naively think that uh that's easy to separate because you just send the things that we're doing in parallel you just no just validate consensus a test and then validate execution in the rest and that's it but that's not so easy because unfortunately the merge was minimalistic but then we had capella and in Capella we added new messages that came from the consensus layer to the execution layer in Capella we have withdrawals that are deducted in the consensus layer and then later on are well and and are Credit in the execution layer if we have them separated we're going to have to do that logic theed duct first when withdrawals and then uh credit on the execution layer when we see a payload so that's a complication and Electra gives us many more headaches now in Electra we have messages in the other direction and in future Forks we expect to get more and more messages in the direction from the L triggered in the L towards the consensus layer these are for example deposit requests withdrawal requests and so forth which you will have to change your code in such a way that when the payload comes you process those okay so the point I'm trying to make is that the complication has nothing to do with neither me and the auction mechanism so now we're going to start moving to auctioning but before that let me tell you what the slot will look like in a in a way in which we separated the payLo From the Block regardless of of auctioning mechanism we will have a broadcast you're going to have to validate quickly execution which is fast and then you have the rest of the slot to just get consensus on whether or not the payload was there okay so that was the part of payload block separation now we we come to the section of proposer Builder separation so I've describe the problem the big lifting of separating the block and the payload is in two sections changing for choice to achieve consensus on what is the head of the chain and changing clients uh implementations on how they sync their block because they they need to do things in a in a essentially different way they need to access the databases in essentially different way but now the question is well how do we implement this how do we achieve an implementation that separates the block and the payload in a minimalistic way and I want to convince you well which is probably hard but I want to make a case that with minimal assumptions uh EIP 7732 is a system that achieves this in an actual minimal way so we need to decide a way of how the payload appears and I'm I'm going to talk a little bit about auctions there are many ideas going around on they all have acronyms that that are hard to remember epbs slot auctions APS ETS ATS I don't know but they all more or less are in the same way there's someone that sells a right to produce a payload in Block auctions the proposer submits a block a consensus block with a commitment to a particular payload and the Builder that's committing for that particular payload promises to pay uh a value to for the rights of producing that payload in slot auctions the proposer does not commit to a particular payload it only commits to a particular Builder and then the Builder later on produces any payload that he wishes to produce there's execution tickets or execution auctions in which the auctioneer is not a validator but is the protocol itself the protocol sells far in advance 32 slots in advance either tickets and then there's a lottery that is run uh by random n and we choose who later 30 later who proposes a payload or you can actually sell the protocol can sell can hold an auction and sell the rights to propose a slot 302 slots in advance and all of these mechanisms have their tradeoffs none of them come for free they all of them impact the me chain and they all of them uh produce different kinds of centralizations all of these mechanisms that I'm describing here you can or may not run them with burn that means that even if the proposer is choosing and getting some value out of the Builder you could in principle include a burning of that value towards the protocol the one that I didn't include is no auction but that's certainly possible we wanted to St it was about enrin payload block separation in principle I could just enforce that the proposer is the same signature as as the Builder keep everything exactly as it is today in the M chain and keep using me boost nothing would change except that we have all the Machinery to separate the block and the payload however if we've already did the heavy lifting which is changing for choice and changing block processing changing the auction is zero work for us changing the auction is nothing because the auction we already have it we have the code that requests header from the Builder we don't need to change that the only thing that we need to check is that the signature will be different it's coming from a particular validator so the heavy lifting is done in a minimal way and adding an auction to get Block auctions is Trivial so what are the things that actually change the problems that adding the auction increases is that in a world in which the proposer and the Builder may be different then you need to give certain safeties to the Builder if the proposer and the Builder is the same then you don't care about protecting the Builder if the payload came late or if the payload did if the Builder wanted to withhold the payload this is because well the proposer is the same as the Builder he should have sent everything together but in a world in with the in which the proposer and the Builder are different you need to protect the Builder you need to give assurances to the Builder that if the Builder submitted his block on time the block is canonical the payload is canonical and you need to give assurances of hard one is a new situation this was a previous slide where the three phenomenas could happen this is the full the block was full here the proposal of slot n is building on top of an empty slot here the proposer of slot n is reorg entirely the previous block but now we have a new situation in which the proposer of slot n is trying to make the Builder pay for a payload that he didn't reveal because the previous block was weak so we need to prevent that situation from happening and this is a minimal change likely for us uh EF researchers on for Choice are very good and we have minimal solutions for this that are a tiny bit more of code to the previous heavy lifting which is dealing with the whole tree so how does the PB epbs slot actually work on an auction mechanism the builder at the proposer at the beginning of the slot requests exactly as with me boo today with the exact lines of code will request directly from the builders not the relays their best bid it would choose whatever bit he wants it would include it in the blog and submit his consensus block that can be validated immediately before 3 seconds we could have been two seconds actually because we don't need time to propose blocks consensus blocks the rest of the slot well the the Builder would now have to be protected is going to count attestations for that block it's going to count for one second until he reaches enough attestations in practice it's going to be 40% of attestations once the Builder saw 40% of attestations for the block the Builder knows that that block cannot be reor therefore the Builder Reveals His payload this is a 4 seconds so you have since then until the very next slot to validate the payload you can just increase the gas limit a lot if we could manage to solve the disk uh the state growth problem uh you can increase the blob number a lot because now we have have 12 seconds to distribute the blocks you don't have two two seconds to distribute the blocks later on there's a light vote there's a light vote by a committee of 512 members and that vote is to Signal the rest of the chain that the payload was on time that the next proposer should not reort the payload there are other designs that do not include uh that do not include a light vote there there were previous designs that included a full vote an aggregated vote an attestation of the whole committee for the payload or not uh but this design is robust enough and it requires only 512 signatures so let me tell you about implementation status of uh I'm not sure if I can ah yes it's an empty video but uh let me tell you about implementation status of this so we wanted to have a proof of uh yeah a proof of concept model for EBS and we have it there's uh we we are finalizing epbs locally constructing blocks so we're not contacting a builder but we are finalizing a Network that has the payload and the block separated um two clients two consensus clients have have already the implementation is underway um te I believe is close to being an interupt uh Nimbus has two EPF uh working on this uh loads are on Li house I think they initiated at least they have the typing but they haven't Advanced much more but the point is that it takes it took us a couple of months of sitting down and coding not more uh it's not production code but it's certainly ready the the EIP is ready to go uh as I described there's no changes I'm only mentioning consensus layer changes there's no changes on the execution layer that's why the execution layer guys are happy because we're going to give them a lot of time to validate the block without anything on without them writing a single line of quote however the interaction with fossil is not trivial if we want to include inclusion list which is something that we really need in in ethereum we're going to have to involve the execution layer and the interaction of fossil with the IP with epbs is not entirely trivial it's not uh something that I'll describe today here all right thank you very much guys all right we'll go through some questions from most upvoted are there any other protocols or message propagation mechanism being explored other than Li P to be not that I know simple answer after implementing epbs on prism how would you rate the complexity of changing the entire consensus execution validation sync Etc while still maintaining backwards compatibility that's that's a great question uh it was much harder than I thought uh Fortress was the problem and uh but uh we have now a because we iterated several times until we realize what is the right way of doing it so now backwards looking there was a very simple way of doing it so my original implementation was hard but now we have a very simple change as I said in two months we did it now I believe knowing what is the right design we could have done it in two weeks what if there's a reorg larger than depth uh of one nothing changes uh absolutely nothing changes for Choice uh my original design used boosts to rely on the if the block was poor and the pay the the Builder did not want to uh reveal the the payload my original for Choice design uh relied on the network reorg the whole thing uh luckily Francesco came up with a simplest solution that doesn't touch for choice at all it's the usual lmg ghost mechanism without any boosts so for choice is not change is not different in the way that we count weights the only difference is in the way that there are nodes that may or may not have a payload what do you think about implementing consensus execution separation without epbs uh I so the I think that I the the way I phrase this talk is that uh there's a big chunk of changes that are completely independent of any kind of mechanism for auctioning and those changes are going to have to be included in any known road map for ethereum ethereum in all of the known road maps for ethereum we have the separation between payload and block and that's the heavy lifting that has been done now you need to put on top of this an auction just to as an implementation detail and the way the reason why we chose uh block auctions is because I do not know how to implement any of the other ones and if anyone gives me an actual spec to implement execution tickets or future slots without single slot finality I'll be happy to code it but these are the only two that we actually have a spec and we know that it's robust and safe what about the impact on the the late block of proposer boost uh what about the could you repeat that one what about the impact on the late block of proposer boost we I'm not sure if I understand the question but uh so perhaps oh okay so the the question is perhaps that if a block comes late proposer boots can reorg yes and this is something that we do today today in order to not incentivize seeing late blocks we actually have seen blocks coming in the early days at 12 seconds trying to reorg the next block in order to not incentivize this we actually actively reorg a block that comes late and that's not going to change here uh the only thing that is going to change is that the Builder uh has a safety mechanism that if the block came late with a commitment to its payload then the Builder may not reveal it because he knows that it's not going to be forced to pay because it has to be reor does this proposed change require an e spec change or an EIP and or does it only require client client implementation it is a it is a consensus breaking protocol it's a it's it's not backwards compatible it's requires any IP the IP is 7732 we have two more minutes so if anybody has a Live question that they want to ask oh that's uh that that that's a great question can you repeat the question so the question is whether or not we have we if we've implemented syn no I have not uh purposely because I really wanted to have the the proof of concept before Devcon it nothing really changes though because for sync what you you don't you can pck it you can pick it back what we already have today so for sync you're going to send the full block together anymore yes are you afraid that given the changes and introduction of new features of the offchain PBS uh pipeline we are soon going to reach a point of no return where epbs is pretty hard to even be realized uh I'm not sure I'm not sure I understand the question I'm sorry for example when PBS started we had the relayer just do one thing but then we did stuff like optimistic relays recently there have been proposals of stuff like gateways which again relays do so we keep adding complexity into the offchain PBS stuff that would need to be matched or very or or improved within epbs do you is this a problem that you see or foresee or is this a viable risk for you I I don't I don't see this I I can tell you something that I see as a risk uh I don't see this particular thing a risk because complexity on the relay all that it will CH change what epbs the way we proposing is what it does is it allows the Builder to be a relay directly and permissionless so what what you're describing to me sounds like builders in the protocol which they are already are because relays are Builders uh they will have to have this complexity if they want to compete be competitive in the market but from the protocol perspective we don't care what I do see as a risk though is other things that are being piggy back on PBS say for example uh pre-confirmation uh and all of these extra markets that are being done I would require I would ask for the teams that are working on pre- comps to make it compatible forward looking compatible with mechanisms of separation and if the person who has um answered the multiple current concurrent proposer question wants to ask him afterwards we're out of time for questions um but he'll be around in the room um thank give a hand to pus [Applause]