[EIP-7732] enshrined Proposer Builder Separation | Devcon SEA

[Music] hi good afternoon everyone so my name is SKB I've been working onbs implementation in the nus 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 clients because I wanted to have a deeper understanding understanding of the protocol in itself so we decided I decided to choose EIP 7732 insuring proposal Builder separation um it was it was proposed to be implemented in Nimbus I mean prisum initially but there was need for client diversity and to have it implemented in multiple clients so so basically what what thep does is basically separating the etherum block into a consensus and execution into the consens and education Parts basically so and it has the 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 um Bon block proposals they request as root from a third party Builder via VIA a relay they submit a signed blinded beon block to that trusted relay um the relay now the relay is responsible for replacing that ash3 routs with a full execution payload submitted by the Builder basically the relay is responsible for like selecting the best beid from the Builder and and carrying out the transaction basically so this project was about um solving this trust issue basically because um so we are trying to like enshrine this currently PBS exist but outside of the protocol so he just basically trying to enshrine it in the protocol exactly so it it helps to guarantee two major things right a proposal payment proposal payment safety proposal payment safety and the Builder payload safety so it just goes to say if an hon next Builder submits um if an just submits a payload and like commits to a particular beon Lo it it should always get paid or he or she should always get paid and the Builder P safety just basically means um if I if he publishes a payload then that block should become canonical so um core changes and basically our approach was basically just it's a it's a research work that has been in the pipeline for a long while so what we just did was basically what I did basically was like implementing implementing it based on the spec that that had already been written right so the major changes were like in the execution layer there was no changes required so basically keeps the execution people happy then we just had to like um make sure almost almost all the Implement implementation had to be done on the consensus layer which was like the two major parts was the Bon chain and the Choice Logic the Choice logic is I don't quite complex really but um quite complex because currently that's the point that's the point we are had we had and there's a new there's a new so that's what we are implementing next pH um all right uh I'm going to expand on that a bit uh so uh basically for is uh when we started the project we had basically two uh designs one is like blog auction and Slot auction uh by the end of the project uh whatever like whatever was built was basically replaced by a new design uh thanks to Francesco um but yeah uh uh I'm going to explain like what uh what what we did during the uh cohort and like what the what was the design that we are working on uh yeah so basically this what they uh what EPS does is separate the consensus and execution validation of the block um which means that uh right uh now right now the ethereum block has only like two seconds to do like everything uh like validate da or uh produce the kcg proes uh so what this will do is like separate the consensus block from the execution block uh so for the first three seconds uh like proposers or validators can validate the consensus block and the exec tion validation can be deferred to like uh the the next 3 seconds of like next slot of the the first 3 seconds of the next slot 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 uh kcg proofs uh since like consensus block no longer carries execution uh this also results in Faster propagation like faster Network propagation and verification of that um and yeah this also ensures that consensus liveness no longer depends on the execution results or uh the block uh the finality of the execution block uh one last Point uh here is like any Builder can set the floor for for the auction through P2P Market space this like remains unchanged uh like this is what happens right now except uh this done like on a off- protocol relay network uh yeah so basically this is what uh an ppbs slot looks like uh yeah so it is divided in basically four intervals uh the first three uh the first three second is when honest validators would uh gather sign bits uh or like the sign execution pillow header uh from Builders and then submit uh submit their consensus block or uh we call it sign beacon block uh with this BS uh for the second part it remains unchanged uh as it is right now honest vedors would submit their atten attestations uh uh what is like happening right now as well uh for the third for the third interval uh the aggregators would aggregate these attestations and uh the Builder broadcast uh their uh full either the full payload or a message indicating that whether they are uh withholding the payload or uh or yeah I think basically that's it for the fourth interval uh some vators are selected to form a new payload timeliness committee uh payload Timeless committee and which which kind of attach to the presence and timeliness of the uh timeliness of the Builder's payload um okay yeah so this is like what okay uh yeah so at any given at any given uh slot the blockchains head uh uh can be like a block uh can be like a block from a pre previous slot if the current slots proposer has did not submit a block so in this case uh all the validators would attach to the parent block and then like uh the slot would go like without a block uh in the second case uh uh it would be an empty block if if the if if proposer does not submit any Block in the current slot but the Builder uh sorry uh if the if the proposer submits a block in the current slot and the Builder did not reveal any P load on time uh and in the third case uh it will be like a full block when both uh both proposer and Builder would uh reveal the block uh on time uh yeah so this this was the initial Fork Choice rule that we are like uh basing our implementation on uh this is called block slot uh uh sorry blog auction uh uh blog auction design uh which uh which contain like new payload and with Boost uh so basically this is what our mentors like tested like just two days before the Devcon I think yeah it's uh it's on 7th yeah uh so this this this assumes that uh uh the the block here uh sorry the yeah the block provocator here assumes that it is tested on local interupt and u meaning like that the proposer and Builder are the same entities uh we have haven't like yet tested uh I think on the P2P side of things yet um uh but yeah for the future work uh implement the new Fork Choice design uh if you have time I can like expand on that a bit more uh yeah and then like hope that uh more more clients join our uh emplo like more uh more clients join uh and like start the implementation for EVS I think te has already started it and uh Caleb and I am like working on Nimbus and I think PTO and Teran have been like working Rel relentlessly on the prison side of things um yeah uh and then like update the for choose consensus spec according to the new design uh do the spec test and like at last do the datet testing uh I don't know if do have time I think uh yeah this is uh this is the new like this is this is what a slot would look like in a new Fork Choice Design This was proposed by Francesco in the last uh e PS um breakout room uh this basically design uh sorry combines uh epvs fil and uh DS into a unified Fork Choice framework uh uh and like it it will support all three of this or like all in one all in one fork Choice which will work for all of them uh uh so it basically uses availability committee so the pad timely payload Timeless committee is like uh rename name to the avilability committee here and uh and like now it doesn't only just votes on the timeliness of the block but it also votes on the payload and the blow ability um yeah while also enforcing the inclusion list through the 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 uh of uh including the iels uh on uh that's uh that's what basically uh I I committee uh kind of ensures uh not to more go more on deep on the fossil side of things uh but if we include fossil it also um it also touches the execution side of things uh yeah and finally a special thanks to all the mentors P Terence and TK and uh and the excellent EF researchers who came up with a new simple design barnab and Francisco and uh Mario for uh organizing this EPF thank [Applause] you yeah thank you so much guys thank you for the kind words um so before we uh wrap it up do we have any questions comments for Caleb and Kira um there's a ton of stuff a lot of work done on both implementations I think it's incredible guys um and if you have any thoughts about it any comments any questions uh feel free to raise your hand and uh yeah okay otherwise I guess we'll wrap it up here uh yeah if there is anything I mean we will be hanging around like feel free to reach us out thank you so much guys and uh yeah with this presentation um yeah let's give it up again once again for Kiran Caleb thank you so much guys incredible work and yeah uh this uh right now we are finishing the morning block of