Ethereum Pectra Upgrade & Consensus Layer Insights

[00:00:00][Music] hi everyone uh this is sebastia I'm principal engineer at K working mostly on etherum and I'm like very pleased to have teren here uh with a core developer on ethereum uh working on the prism consensus client which is one of the main consensus client on ethereum and uh we also have l who is a senior project manager at K also focusing on if and today we are going to to talk a bit about the next etherum upgrade which is called pectra um and we'll also have like some cool insight about how what it looks like to develop on the consensus side from Terence um so yeah welcome Terren and I'm very very happy to have you here uh could you introduce a bit yourself maybe a bit more than what I did yeah sure thank you for having me it's a pleasure to be here U big uh big fan of K and what you guys are doing really cool but um yeah so I'm Terence I've been um working in this space ethereum since 2018 so I um I work on Prison it's a consensus client it's written in go um so nowadays my focus is more on um scaling so um I'm adittion scaling for example um epbs I'm sure we can talk more on that and then I also spend a lot of time on fossil inclusion this design so yeah just happy to be here and happy to chat about um anything nice so you've been a long time working on the Bon train I guess you were there from the very beginning how how did you start like working on it like what what brought you to to etherum yeah so um it's actually a Funny Story So like um back in 2018 I wanted to do something with eum but there wasn't so much to do because of like the limitation of the blockchain was I guess theit at that time so I came across this post by vitalic on Charing and then so I was oh this is really cool and they are offering a grand so I could work on that but then it turns out um we for get so we implemented sharding through some sort of smart contract logic and then there was like a parallel effort going on they're doing the same thing but for proof of stake so back then proof of stake was like you use a small contract and then you take 1500 e and then you do some sort of like checkpoints which you know today they are what we call FFG checkpoint but they're using the smart contract to do that basically and um so I guess at the end of the day like there was essentially this two parallel track one sharding one proofer STI and then back then people wanted to prioritize proof stake which I think was the right decision and then at the same time Justin came up with this idea idea of using BLS signature aggregation which enable us to actually Implement a new protocol and that's what we know a bacon chain so then we're like okay well what should we end up doing right and then we thought okay well bacon chain is a great idea so we started moving from working on sharding to implem a bacing chain and then we started this pris chist layer client and that's and basically that's kind of the story like how I started it and then the basically the rest is history three nice that's a very cool way to start working on if I think uh like probably like had a huge impact on the on the chain and a lot of decisions that were made afterwards um so yeah congrats um so yeah let's let's start talking a bit about pectra um so like this discussion is going to be mostly on the conen side so we yeah but like a Spector bra has like two side like there is a execution side and also like why the consensus side um so on the consensus side I guess the main eips are uh the max effective balance which means that validators would be able to have more than 30 to if of effective balance uh and the goal of this and we'll discuss a bit more about it is like to reduce the number of validators on the network um and there are also some implications on slashing behind this um there's also an like uh e72 which is about being able to exit validators from withraw credentials from the execution layer which which was not possible before so it has like it had some cust ship issues especially like on the staking landscape uh and there also uh IPS about blob in support increase uh and also like some simplication on the uh deposit process uh which means that the delay between the moment you stake you send your deposit transaction and the moment The Valor is active on the Bon chain is going to be smaller so that's I guess quite a lot of changes on the on the consensus side um as you have seen like all of the prior big updates of eum like and of on the cons side like how does this upgrade looks like from from your perspective yeah I think it's interesting because it kind of from The Outsiders point of view you guys are looking at it it has a little bit everything but it doesn't really have like that one thing right CU if you look at every hard for so far we starting from the merge then we went to Capella which abl withraw then dap uh which en blow up but if you look at this hard for you're like what are we doing here it seems like it has a bit of element with everything and I kind of think that's a feature but also like a bug because of we don't have this common theme that we put everything together it's slightly more Messy as we learned which we can definitely do better right right so I think like for definely I think the theme of this power for is just that it doesn't have a thing it has a little bit of too many things because of that there is this diverse interest right people want to like I work on this EIP I wanted to get in you work on this EIP you want this G right and then on top of that there were EIP complications for example if you look at EIP it may seem just a one line change for example we uh update attestation structure by moving the committee index to a different location such that we can do less hashing but it is like one to two lines change in the spec but it turns out it's really hard to do in a client code and that didn't show up until later when people start coding it right so this is something that we also learn as well and then the third thing I wanted to point out is that I think we do realize that at the end of the day day testing is a bottl net which I want to shout out eanda UPS like Perry barnab and those people are doing such a wonderful job but it is limited at the end of the day right when you have so many eips in a hard Fork we need some sort of uh fast testing or testing for a long time and then the more eips you have and the more service you have to test and there's all and there's no way around it and that also prolong the time as well so I'm actually really happy that Petra is coming along it's I mean we have a we have a date we have we know when minut will be but not going back I might do a few things slightly differently but again this is a good Learning lesson for everyone this is like I think the first time this has happened and we're and basically we are learning from it I I think this is like very interesting what you pointed out like the the tting parts the different eips that you realize are a bit more complex when you you know you go from the draft to the implementation maybe like as you're really like into this processes maybe you can clarify expand a bit more on this if we double click on this like can you describe like for example for pectra like what what was like kind of the initial discussion phases for this outwork uh how like eips were decided to be included inside the the upgrade and kind of right what PRM did into that you know did you push certain eips did you push the testing for these eips like how how does it work in terms of coordination there yeah definitely that's a great question so I think like I can maybe chat about like a general process of EIP then we can look at how Petra did it which it's not that much difference right because if you look at in general from the history like I mean there hasn't been that many eips that got most of the eips that got in are pretty like non-controversial but these days we're seeing a little bit more controversial IP that where like client a wants it but client B is against it right but typically how it works is that you have an idea you write down your idea and then you talk to your friends and then your friends also like this idea and then you start writing this eips right so EIP is this like I mean I'm pretty sure the audience here know what the EIP is but you have the EIP and then you find your co-authors and then for the EIP and then nowadays I think you have to do a little bit more you have to like um think about the test cases and stuff like that and then you try to get community feedback and then people thumbs up thumbs down if you have enough like I would say like political influence at this point then you can go to ACD and like propos it basically and then like people like it more blah blah blah blah then you get clients to implement it you have to convince like five clients or even 11 clients if it's both CL and E right and then you kind of have to go through this weird face is what we call like Vibe check like does he have good vibe and then this is very very subjective in a way that like I I don't know how to describe it but it's like yeah it's it kind of becomes a popular contest in a way and then if there is like I would say more Clans like it or even more popular Clans like it you probably have e you probably have an easier time pushing it if Vitality likes it then you're definitely good to to go CU he has a lot more weight than what he says right but then again right so people implement it you you kind of survive this Vibe check phase and then and then you and then you do some death Nets you do some test Nets and everything goes well you go to minute right that's kind of like a process and it's it's very like rough this what we call rough governance and then I guess it's also by Design doing this way because like it doesn't have any like coin volting for example which is really hard to bribe people which is I think I I mean I think it's a nice process now going back to how Petra work how Petra work in the beginning was that uh which we did this part really really well that all the client deaths all sorry all the client teams they review all the eips that's out in the open and then they basically um come up with this that says that we want to implement this so prism had this Lighthouse has has a this R has a this and given that the this we kind of just pick some like greedy simple algorithm we take the UN or the interception of those and we propose those for Petra and and basically that was it right and then I think there were two issues there the first issue is that when clients look at the this of VIPs they probably don't know what the community wants I mean they I I mean I mean they do it's not like they don't know but they may miss a certain points right and then another problem is that when we choosing the this was a time a but at time B the priority may change for example like scaling wasn't like that big of a issue um last year during like say summer is maybe it was but it wasn't like this urg but noway like blob scaling is very very urgent that's what we know want to work on right so we add a bunch of eips that's more I would say staking friendly to like Lio Rocky poo and stuff like that which doesn't really address the most priority today unfortunately I think that's another problem yeah so I think those two are the main problems and again like there was this it magician threat out there by team that all clans had their input on Petro like retrospective and yeah that encourage people to read that and as as the present them like what would you say is your your focus here like do you take an active part in this Vibe check part where like like what you said like most of your time is like kind of vibe taking eips try to do box and Tres to to test them and see if they make sense or do you kind of go along with with the community as well what's your appr yeah so prison uh I think luckily has um has some weight then because of I think at the end of the day like Cent diversity matters a lot but prism and Lighthouse I think teu are the three most used clients so I think like probably perhaps outside of EF research the more client share he has ideally he may has more influence in this process I think for us it's like for Petra we are uh less opinionated on what it got in we're more just like just we didn't really like we were not in any of the eips as far as I remember as an author so we're just like implementer we implement eips we give feedback to the spec we find Buck we help with testing and stuff I think for fusaka we may be slightly more opinionated because like we have epbs and stuff like that that we very like to push to get in but for Petra we more like playing like a a ass type of R yeah so this is quite interesting on the EPS side um so as you are like champ championing this EIP and trying to to push it um so yeah there is a big part of like as you mentioned that is quite political where you have to convince other teams um could you like tell us like a bit what it entails to like are you like writing uh implementations of epvs before proposing it to the rators to like show them how hard it is like how how do you help yeah I think I I think nowadays it's a bit harder than before because nowadays requires you to do a lot of work that is um I can tell you what we did for epbs and it's most important so shout out to him is that we had a EIP we had a consensus spec on top of that we have a annotated consensus spec basically they basically break down consensus spec into a long form each has ra rationale then some of those actually have some like for Choice proof and stuff like that basically and then we had a lot of um short writeoffs on why we why epbs is made sense why delayed execution helps with U for example blob scaling gas limit scaling even complimentary fossil even complimentary with prec confirmation and stuff like that so we have been doing a lot of like I would say posts like write ups around that outside of like technical work basically and then yeah and then at the end of the day like not everyone agrees with epbs because of the auction mechanism how the auction is basically happened to people today some people do like going through the relayer because the relayer can do this some sort of second price option because they can like refund the they they they can refund basically and then relay also takes the cut and stuff like that some people like the relayer because they think it's like much faster you can relayer can propagate all the blocks much faster than the propos can they can use this centralizing point as like a favor and stuff like that and then epbs um does have solution to those but it's less known to people so we need to do unfortunately a bit more education on that front so for epbs besides um those we also have a comprehensive spec test as well uh that making sure that exting SP test pass and we're working on comprehensive SP test alongside that and then we do have a single client um death net has been off and running but then we also added Tacko to the m so now prate Tacko could finalize together but we also need to convince Lighthouse Nas and lar to come with us to join the journey as well so that's kind of like the hard part to like convince the client teams to spend resource on working on this and yeah and I guess the next steps here was like will likely be around Builders as well right because it also changes the way Builders are going to push their blocks right right so Builders becomes the relayer in this sense so Builder to absorb relayer basically but then again I think we're very open in how that auction part works all we want is this separation between ex Fusion payload and the block I think I think everyone agrees in thean community that pipelining is good we need to do pipelining but then the question is that how do we do that pipelining there are different like Solutions out there epbs is one of them for example right I think there's definitely some people they against epbs because the first point is complication they think slightly complicated which I don't think that's true if you look at us by today actually pretty simplify the second thing is that they don't like how the alra mechanism is start epbs today which uh in the back to date the that option is the minimum part the option is that you always you don't even have to care about the option you can um we can do separate option if there's a feedback on what Al mean is better but all we really want is essentially that pipelining you can separate block with a payload and we think that is the future that ethereum should be heading towards makes sense uh thanks for the detailed explanation um so on another topic which we briefly touched before um so like the prism client team has been around since the beginning so it had like to implement uh well all of those eips among the along the years um so there is like at the moment like the eips are U let's say crafted like as you said like the priorities can change and sometimes some eips can be a bit like old on they get to to Manet to the point where maybe they are not needed anymore so there is kind of like this Sensation that you're are carrying a big bag of like eips when you developing consen with client uh to first like is it like really the case and if so like uh how do you see like the the balance between like let's say implementing new features but also like have to take into account like the times that you are thund all of those like counter cases that were like previously introduced like uh yeah basically how how do you feel the technical debt if I could call it like this and that maybe it's not like the the right term here yeah I think like luckily I don't work on instiution L I think extion Len feels more than us so we only have been around for four years versus them has been around for longer I think e app is a good example that like some teams are against e app because now you have to maintain these two separate versions of it which kind of sucks right but I guess for consensus with a client yes I mean it is true that there are lery code that we have to maintain but you I I was mention that like there are eips that we're working on or tools that allows you to delete te uh technical dep I think one example is that EIP 6110 that essentially the deposit now comes from this engine API versus having client to essentially querry the deposit contracts log event because that takes about eight hours versus you just get it through the engine API takes about 30 minutes and then because of that we can delete the O code where we uh just uh keep looking at log events for deposit contractors that code is not very nice anyway right I think that's one example that yeah we can do and I definitely think we should have more eips like that I think we shouldn't be afraid of deleting history I think that's probably a controversial thing to say but I think like at some point history should just have this like all of One honest minority behavior that as long as you trust that one person has a history you can get it from it then it's good I don't think every client like or every node or every running node should keep the history because that's just not going to scale right like I think e 4444 is another B example I think it's coming at sometime this year that like the e will just start with a snapshot hopefully I think it's post merge so pre-merge they will not get the data anymore and I think that's very nice and then I think in the future that I'm pretty sure maybe we'll talk about it later is that when we reach beam chain that's another paradig shift right I mean beam Cham is a popular very popular topic I don't know when we'll get there but it sounds like people are very interesting it but once we get to beam chain that like it's kind of like be chain 2.0 right so you can kind of uh redo B client in a way that makes more sense for ZK star so this will also allow you to deete the old code yes so maybe talking about beam as you started introducing it um how do you see like um this like basically how do you see in general like the the future of what prism can do regarding like the future eips like in the next five years you there is so much to to do it seems like each art Fork is more and more has more and more adaps uh and then there is this big beam project which is kind of a complete refactoring of the consensus layer how do you approach that as as prism like both this kind of scaling with a lot of ips and and the refactoring coming with beam um do that realistic or um yeah how do you approach that as a consensus cling team yeah I think it's hard I mean I can't speak on entire presenting I can speak on what I think and then again Lighthouse nimas teu they all face the same dilemma right the dilemma here is that we have our daily job our daily job is to make prism as great as possible we have a set of eips we have hard for to L TS and then in parallel there is this effort is basically beam chain basically and then beam chain uh will essentially re Vamp the state transition function you will probably need a new ssz layer and the networking layer because of everything has to be ZK friendly so maybe uh you have a new hashing function for example that's another parallel effort right so essentially we I mean client teams they need more resources if they want to keep up with benchin unless they want to do them on their side what I'm hopeful for is I'm not sure if this will happen but I'm really hopeful for is that uh client today like prism Lighthouse Le buus can do what they're doing what they're good at but at some point transition to beam chain just some sort of like swapping out basic like a swap out so you can think of beam chain is just a station station function so prism can essentially code that code essentially the pr essentially and then and then and then we can just black bars the state transition function I think this doing this will require some architecture changes How We Do code I think every Clan code is different some Clan code may be harder to do this some Clan Cod may be easier so I think it's never too late to start planning these type of things that thinking like what to do point B chain comes just I mean we still want to maintain prison client I don't want prison client to go away but the question is that how do we make prism client um workable under this spin CH Paradigm I guess like yeah I guess too ear to know we haven't seen any much technical details outside of beam chain besid Justin's announcement so once we see this back once we see what that beam chain is I think I think we I think we will know more so yeah just quick question on this so right now the state transition function is basically like there is no clear separation I guess in like existing cont clients between like your that's a networking code from like the the actual St transition function like so I guess that's the main challenge if you want to to rely on exting St sorry on EX existing St transition function that could be done by other things or exactly and then another thing I want to mention is I think if you look at J list I think there are 12p teams right now and like everyone is working on two languages like Ross and C++ and C right and no one's working on like go for example because I think the truth is like gold is not great at calling other languages I think that's going to be a problem down the line is that how do we make go more efficient at calling C code or coin rust code because end of the day those station function will be written in Rust some something that can compile to was some risk five for for basically for ZK proving and stuff like that so that's something that we have to figure out I I think it's a very interesting problem yeah so just on on this topic of uh yeah of languages uh so like if we like don't talk about beam like just on like the purely like what was done so far on prism um do you see like in retrospective like from everything that was done like Artic AR sorry architectural mistakes that were made in prism or like maybe places where you feel like go was not the right choice or maybe like where it was actually the right choice like how yeah what's your your take on five like six years I guess of prism development yeah I think go has a few Advantage the first is go is good at like client server architecture stuff for example like doer communities they all written in go and go is also easy to read so meaning that you're easy to onboard developers I think that's another good thing and then go is also good at like concurrency stuff you can do that and then it doesn't and then yeah and then you can like spin up your own go routine and then and then it's memory management is also easy to deal with I think those are the advantage it's not as like powerful as rust for example C++ um in terms of like mistake I think there were a few right the first one is that before there wasn't this Beacon API when we started so we ended up implementing our own like prison version of bacon API using grpc it turns out like we probably didn't need to do that now we have literally the two API to maintain which we want to deprecate um drpc AP I soon but again it's very hard to do that because you have like production system that I don't know how many people are actually using in this so we we have to decate it more like carefully for example and then another one is that yeah we definitely rely on grpc way too much versus we should just use native GH sh for everything that would have been cleaner and yeah I think that was probably the main um thing I will have we go back and fixed yeah I think this is one of the topic that menu worked on at some point he was minus grade yes um okay um so yeah very like it's very interesting to have your Insight on this like thanks a lot um so I back to pectra like sorry I feel like we are in a labyrinth and we are trying to get out and like we navigate from one topic to the other uh so back on pectra like on the max eff balance EIP uh so one the goal is to reduce the the validator set and so like what it means basically like because you have less validators you have less Network congestion you have like less processing and and so like it's like you have basically like more rooms for Fe potential features on the consensus side um so do do you think like in this like frame like this like which I think was how mik noer initially frame it do you think like this will help uh here moving forward like as in like uh actually like uh yeah uh leave enough room like for new features or do you think that like because we are talking about you know like acceleration like Accel like accelerate everywhere and so on do you think it's a bit too late and maybe like there are other ways like through BL blobs or like yeah sorry I'm going in a directions but the question is simple like um how much processing do we get from PCT basically so I think like um I think your first point mention was this EIP 7251 right that you essentially allow you to reduce a Bator size on Manet I think that is I think that's a very underrated EIP a lot of people kind to just see the EIP as it is but this EIP enable us to do many more things for example like syral SLO finality like even orbit ssf uh there's also like 3sf there are bunch of proposals out there right but today I think the consensus the back bone it's not very ideal because you have this like lmd ghost for choice you have your ffu finality and then everyone relies on this like finalized checkpoint but it happens every 30 minutes so and then yeah and people don't really question is that why is it 13 minutes can we short turn that to two slots what is the Compromise when we do that right so we need some sort of like I would say faster finality but without sacrificing too much like security Maybe we have some more like synchrony assumption I think that's okay to make but um I I think in order to do that we must consolidate reduce the amount of messages we have on the mainnet so today it's ridiculous you have essentially $1.1 millionar uh sorry 1.1 million Keys per 32 slots you divide it by 32 that's a lot of message just passing around the network right and then if we can consolidate those messages like you can opens a lot of like doors for all sort of design and I I think that is actually very underrated EIP and then I think like yeah I'm definitely looking forward to see what this EIP will enable in the future thanks um yeah like I think it's going to be very interesting to follow the Dynamics one Spectra goes life like to see who consolidates and how the variator set evolves um yeah it's also a weird problem to have because I think like most other blockchains don't have like one million validators like it's a very unique uh engineering thing we are working on right uh on each own um so yeah you mentioned also this a bit before about like the way the eips were selected uh and the fact that P was basically a version of etherum without one big feature that was like like this is what we want uh and I I think like you mentioned there was like a retrospective like uh like some weeks ago on like what basically went right and wrong on on picture U so like what's your take like what what was right and wrong from your perspective and what should be addressed for the next upgrade yeah I think what we're right is defitely testing we learned a lot on just how to do testing better like what is fast testing the fact that we're still finding consensus bug like last week which is very very like uh late in the stage to be finding those type of BU shows a lot about like testing but not in a bad way but in a good way that like testing can continue all the time you don't have to wait until all the clients Cod Ready to do testing today if today uh Lighthouse is ready and nus is ready don't wait for prism just go launch your death there start doing testing start fing and F the bus right I think previously we have this notion of like we want to wait for everyone and then let's just and then go together but that eventually delays it I think so that's probably one learning one feedback that we have the second feedback it wasn't our feedback but I see a lot of it is that kind of do some sort of like pipelining I'm I'm kind of playing the war here like pipelining for um for hard Forge for example kind of like how we do it for p do where we finalize the scope for n and then for un Plus one but we Ship N but the N plus one scope is essentially finalized already so you cannot really change it then you start paying for n plus two so you kind of have this some sort of like pipelining so it allows smaller for but happen more frequent so maybe instead of doing like one for per year which is like very slow maybe you can do two to four uh hard fors per year and then there are some people that mention anym like having some sort of committee that's like St ing like help with the guidance what you Happ to include kind of like how kuet does it which I I didn't read so much on that but some people do mention that but yeah I I think all the feedback is great I think like going back to the first question like what was my impression I think my impression is that we learned a lot from Petra and then yeah I I I think those experience is very great and it will definitely te us learning to faka yeah definitely interesting and kind of looking forward as well to to sit live in mate and see all these new Dynamics I think we'll also learn a lot like not only from the white Forks but from what people will do with it so uh yeah very interesting um and then so maybe like uh you know we talked a bit about the beam chain but if we look like for example in the next few years let's let's say we do a new podcast in two years what would you expect to happen until then what are you po until until then uh especially like for the the prism road laap yeah I think maybe I can talk about ethereum in the beginning first so on the ethereum I think we'll definitely see a lot more blobs one way or another because like for ethereum to be competitive you has to compete on this blob space thing and then that's the first thing the second thing is execution like how much essentially like gu limit you can put in a block right so if you look at etheria for the um last few years like they have been very slow since in terms of this like scaling thing besides like blob scaling which was a very very nice approach that the gas limit hasn't increased for some time until Petra or sorry not Petra this is not how for dependent but until a few weeks ago we increased with 36 and that's about a 20% bomb I think we'll see more aggressive Push by the community on just scaling and then there blob scaling and then execution scaling and then I I don't really have a number in mind but I think we will probably see like like near 4X or even 10x I think we'll do this without sacrificing security at decentralization which is I think a hard problem but I think we can get there I think the second thing we'll see is is I'm very excited is a better pricing model so today I think the whole pricing of the up coting is flawed in a way it's just a single gas unit but it's used across storage compute and then State growth and stuff like that I think we'll see a better pricing model in the next few years that allows us to scale better because there is a better um yeah I I because there is a better pricing model I think another thing will see is probably uh maybe it's unrelated but a better interrupt in general between layer ones and layer twos I think today the interrupt is not very nice on bridging and stuff like that but there are a lot of proposals out there by different there two teams companies they're doing more like intent based interr for example this will a lot better user experience I guess one last thing since I'm talking about us experience that I think that EIP 7702 will also makes a huge difference which we will start seeing this year just like instead of sending like three transactions to approve blah blah blah you just send one transactions and I'm very excited to see what people build there yeah right very cool yeah uh so yeah we've been like I think it's almost the end of this podcast so we have like two more like open TRS like so like the first one is is like it's about like like where where can like our listeners um get information about prism or like what's your recommended uh let's say Channel or like uh resource yeah definitely just GI Hub discore Twitter but I mean don't just join the prison Discord it's kind of boring that you should join the etherum R&D Discord that's more fun you see all the client teams there so yeah I would say uh yeah prism is great but like there's so much you can do in prism focus on ethereum as a whole so like the ethereum R&D Discord ethereum Twitter account I think they have been tweeting more now so that's pretty awesome and then just follow all the all core death process it's all in the PM issues and all the breakout rooms are in the open yeah nice uh yeah like it's quite intense to follow if we search Discord are sometimes uh yeah intimidating say uh and do you have a like particular book or reading to recommend to our audience or yeah just influen you um so I'm kind of convinced to myself that I will be out of the job if I don't learn ZK in a few years so I've been reading more cryptography related book I think there's a one is called Moon math for tography is really good and then there are um the latest white paper by Justin Drake and etherum research on hash based um uh Hash Hash based signature aggregation type of thing I think that's also very interesting so mostly cryptography but for cryptography you just start at the beginning level there are actually well really good books out there that's very easy simple math to understand and that's where yeah that's what I'm focused on these days so getting ready for beam getting ready for ZK Paradigm yeah well thanks a lot for uh for your well for this podcast Terren uh so yeah thanks r as well for your time and I guess uh thanks a lot for well our listeners who went through the end of this podcast and uh let's see you on on the ethereum research and development Discord thank you guys see you see you