# [EIP-7732] enshrined Proposer Builder Separation

- Speakers: [kira](https://streameth.org/speakers/kira), [Caleb](https://streameth.org/speakers/caleb)
- Channel: [Devcon 7 SEA](https://streameth.org/devcon_7_sea)
- Date: 2024-11-13
- Duration: 12:32
- Watch: https://streameth.org/watch/6734486c9dbb7a90e1866fa0

## Description

ePBS implementation in Prysm and Nimbus, fundamentally aimed at solving about solving trust issues. We're gonna discuss the block-auction, slot-auction and the approach proposed by Francesco during the cohort. Some technical challenges and problems that we came across like separating EL and CL block, PTC committee etc.

## About the speakers

### kira

Ethereum Protocol Fellow


## Transcript

Hi, good afternoon everyone. So my name is Caleb. I've been working on the PBS implementation in the Nimbus consensus clients. So coming into EPF, the motivation for me initially was choosing a project that touched on almost every major part of the consensus client because I wanted to have a deeper understanding of the protocol in itself. So I decided to choose EIP-7732 and try and propose a builder separation. It was proposed to be implemented in Nimbus. I've been praising it initially, but there was a need for client diversity and to have it implemented in Nimbus, I mean, Prism initially, but there was need for client diversity and to have it implemented in multiple clients. So basically what the AIP does is basically separating the Ethereum block into a consensus and execution, into the consensus and execution parts basically. So it adds a mechanism for the proposer to be able to choose a builder on chain or on protocol, which is currently done off protocol. So it fundamentally changes the way a block is validated by decoupling the execution validation from the consensus validation. So currently, beacon block proposers, they request the hash tree route from a third-party builder via a relay. They submit a signed blinded Beacon Block to that trusted relay. The relay is responsible for replacing that hash tree route with the full execution payload submitted by the builder, basically. The relay is responsible for selecting the best bid from the builder and carrying out the transaction, basically. So this project was about solving this trust issue, basically, because we are trying to enshrine this. Currently, PBS exists, but outside of the protocol. So it's just basically trying to enshrine it in the protocol, exactly. So, it helps to grant it two major things, right? A proposal payment safety. Proposal payment safety. And a builder payload safety. So, it just goes to say, if an honest builder submits a payload and commits to a particular beacon block, it should always get paid, or he or she should always get paid. And the Builder Payload Safety Dot basically means if it publishes a payload, then that block should become canonical. So, core changes. Basically, our approach was basically just it's a research work that has been in the pipeline for a long while. So, what we did was basically implementing it based on the spec that had already been written. So, the major changes were like, in the execution layer implementing it based on the spec that had already been written, right? So the major changes were like, in the execution layer, there was no changes required. So basically it keeps the execution people happy. Then we just had to make sure almost all the implementation had to be done on the consensus layer, which was like, the two major parts was the beacon chain and the fork choice logic. The fork choice logic is quite complex really, but quite complex because currently that's the point we are at and there's a new design, so that's what we are implementing next with the guy. All right. I'm going to expand on that a bit. So basically, for choice, when we started the project, we had basically two designs. One is like block auction and slot auction but the end of the project whatever like what I was built was basically replaced by a new design thanks to Francesco yeah I'm gonna explain like what what what we did during the cohort and like what what was the design that we are working on. Yeah, so basically this, what EPPS does is separate the consensus and execution validation of the block, which means that right now, the Ethereum block has only like two seconds to do everything, like validate DA or produce the KCG pros. So what this will do is separate the consensus block from the execution block. So for the first three seconds, proposers or validators can validate the consensus block and the execution validation can be deferred to the next three seconds of the next lot of the first three seconds of the next lot. So basically you will get like 12 to 15 seconds to validate DA instead of one or two. And then also there will be like more time to produce KCG proofs. Since like consensus block no longer carries execution, there's also results in faster propagation, like faster network propagation and verification of that. And yeah, this also ensures that CSS liveness no longer depends on the execution results or the finality of the execution block. One last point here is like any builder can set the floor for the auction through P2P market space. This remains unchanged. This is what happens right now, except this is done on an off-protocol relay network. So basically this is what an EPBS slot looks like. So it is divided in basically four intervals. The first three second is when honest validators would gather signed bits or like the signed execution payload header from builders and then submit their consensus block or we call it signed beacon block with these bits. For the second part, it remains unchanged as it is right now. Honest validators will submit their attestations, which is happening right now as well. For the third interval, the aggregators would aggregate these attestations and the builder broadcast either the full payload or a message indicating whether they are withholding the payload or, yeah, I think basically that's it. For the fourth interval, some variators are selected to form a new payload timeliness committee, payload timeliness committee, which kind of attests to the presence and timeliness of the, timeliness of the builder's payload. Okay. Yeah, so this is like what, okay. Yeah, so at any given slot, the blockchains had, can be like a block, can be like a block from a previous slot if the current slot's proposer did not submit a block. So in this case, all the validators would attach to the parent block, and then the slot would go without a block. In the second case, it would be an empty block if proposer does not submit any block in the current slot, but the builder, sorry, if the proposer submits a block in the current slot and the builder did not reveal any payload on time. And in the third case, it would be like a full block when both proposer and builder would reveal the block on time. Yeah, so this was the initial fork choice rule that we are basing our implementation on. This is called block auction design, which contained new payload and withdrawal boost. So basically this is what our mentors tested just two days before the DevCon. I think, yeah, it's on 7th. Yeah. So this assumes that the block here, sorry, yeah, the block propagated here assumes that it is tested on local interop, and meaning that the proposer and builder are the same entities. We haven't tested, I think, on the P2P side of things yet. But yeah, for the future work, implement the new Fortress design. If you have time, I can expand on that a bit more. But yeah, and then hope that more clients join our, more clients join and start the implementation for ePPS. I think Taeku has already started it, and Caleb and I am working on Nimbus, and I think Portus and Terence have been working relentlessly on the present side of things. Yeah, and then update the fork choose consensus spec according to the new design. Do the spec test and at last do the down net testing. I don't know if you have time. Yeah, this is a new, this is what a slot would look like in a new fork choice design. This was proposed by Francesco in the last EPBS breakout room. This basically combines EPBS, Fossil, and DAS into a unified fork choice framework. And it will support all three of this, all in one fork choice, which will work for all of them. So it basically uses availability committee. So the payload timeliness committee is like renamed to the availability committee here. And like now it doesn't only just votes on the timeliness of the blog, but also votes on the payload and the blog availability. Yeah, while also enforcing the inclusion list through deadlines. So if you see i think uh it's at the 10th second uh if uh if so there's like a deadline for freezing freezing of including the ielts uh on uh that's uh that's what basically uh i uh il committee kind of ensures uh not to more more go more on deep on the fossil side of things, but if we include fossil, it also touches the execution side of things. Finally, a special thanks to all the mentors, Porter, Terence, and Tercek, and the excellent EF researchers who came up with the new simple design, Barnaby and Francesco, and Mario and Josh for organizing this EPF. Thank you. Thank you very much guys. Thank you for the kind words. So before we wrap it up, do we have any questions, comments for Caleb and Kira? There is a ton of stuff, a lot of work done on both implementations. I think it's incredible, guys. And if you have any thoughts about it, any comments, any questions, feel free to raise your hand. And yeah, okay. Otherwise, I guess we'll wrap it up here. Yeah. If there is anything, I mean, we will be hanging around. Feel free to reach us out. Thank you so much, guys. And yeah, with this presentation, yeah, let's give it up once again for Kira and Caleb. Thank you so much, guys. Incredible work, and yeah, this right now we are finishing the morning block of