All Core Devs - Execution #143

Transcript

[Music] [Music] so [Music]

[Music] so [Music]

[Applause] [Music] [Music] so

Tim Beiko: so hello everyone welcome to awkwardev's number 143 first one on a thursday um a couple things today um on the merge side we wanted to discuss uh setting the merge net split blocks uh for sepolia um and then on the cl call last week we discussed uh el clients activating uh the authenticated ports before the merge and wanted to continue this this conversation some more um then on the gordy side um we've kind of agreed on the the bellatrix epoch height and nttd but we i can check

in on that there was also the gordy shadow fork happening uh literally minutes ago um and then some updates on mvv boost um beyond that uh yeah we also had uh some updates on eip four four four four uh which uh we've been kind of punting from call to call recently uh there's been some work done on that and um yeah that's that's pretty much it um i guess to kick it off um on the the sepoli so on the last call we discussed the idea of studying the sepolia uh and roxton merged split blocks we decided not to do it for robson because

robson is considered deprecated already um and uh for sepolia we had i believe floated the idea of combining this with the gordy merge releases um and i know marius uh i think you were the one who who wanted to discuss that last call but you couldn't make it so um yeah maybe you want to just share your thoughts about this and how you think we should should go forward

Marius van der Wijden: um i don't really i don't remember that i wanted to discuss this but i i also don't have any

particular um opinion and either way but i think if we're going to have a release we can also specify the sepolia net split block um i think it's it just makes sense to have have it in the same release because then we're not wasting uh more time um yeah it should just be a small change everyone should have already implemented the merchnet split block in their code and so it should just be setting the parameter for the support

danny

Danny Ryan: yeah i just wanted to say in terms of um i think it's valuable to do just so that we go through all the motions before mainnet that we do sepolia soon and so you know on that on that release time frame and then maybe because it's also easy to coordinate because of the fixed validator set and then deal with gourley after main net and deal with mainnet after mainnet

Marius van der Wijden: any opposition to specifying the stapolia merge block in the next releases for clients okay um then we'll

we'll uh make some calculations what we want the merchnet split block to be and we can probably just oh we don't we don't need to have a big discussion about it we make the the calculations and update everyone on the all codes about it and everyone puts their uh on discord about it everyone puts the thumbs up and then we can put it in the next release with the

girl dtt

Tim Beiko: yeah so uh just on based on gory's uh on gordy on danny's chat comment um so that means we would have the next releases going out from client teams

like next week for the gordy fork we have bellatrix happening on like the first week of august i i think we said august 4th then we have ttd on gordy happening on like the second week of august and i think it's like now estimated between like the 8th and the 10th or something and then maybe the week after that we have ttd happy er the the merge split block happening on sepolia so like yeah the week of like the 15th or something like that does that seem reasonable to people

Marius van der Wijden: i think we can we could also just put it in the same week as as one of the other things

so we don't know when gordy's gonna happen though right because the poa whereas with sepolia we can kind of know because the block times are are fixed now or at least we can know the earliest that could happen well you want to explain the power yes so merge

Marius van der Wijden: net split block is basically just an empty fork on the execution layer um that does nothing it's just a hard fork and we we don't really need it needed

but it makes makes p2p discovery way easier because we will verify the the fog id basically every every node tells us on which fork it is pretty early in the protocol and so we can we can verify that the other node is on the same fork as we are and if they are not then we can drop them so from my point of view we can we can just

have this fork happening uh one week after the release

Tim Beiko: well i guess yeah just from a communications perspective it's probably easier to just focus on the gordy merge because the gordy bellatrix forks will happen one week after the release um yeah so it's probably just easier to tell people gordy's happening and then after that sepolia is doing that and that would also match what would happen for gordy and for mainnet where like we'd do the gourley split block kind of in the same release as the mainnet merge but target it for later after uh like the midnight merge and then uh and and then for my net we obviously we do that just after after the merging a

separate

release

Marius van der Wijden: yep

Tim Beiko: cool any objections or thoughts from other crime teams or does that sound good for everyone okay we got some thumbs up um cool and then uh then yeah the the next thing uh we want to chat about uh paul i think you started this conversation on the on the cl call last week but the idea of having el clients activate the authenticated port before the merge happens uh do you want to give some quick conflicts there

Paul Hauner: yeah sure so the um the idea is having um yellow clients opening the auth port before the merge parameters are specified so um for instance on mainnet um turning on allowing us to use the auth port now even though it uh the merge parameters have not been decided yet for mainnet that means that users can start setting up their el and cl um exactly as it should be run for the merge um now rather than having to wait for the merge for rams because you've specified um this is particularly useful because we've just put in a bunch of stuff um about merge readiness so that we'll start logging to users so we wanted to do two weeks but we can't do it now because the other teams aren't

opening their ports but we're doing it one week now before prada will start logging warnings if you're not set up properly for the merge we want to have that a long time before the real merge so yeah hopefully that's enough information

Marius van der Wijden: yeah so we have we have a pr open for that for gas for a long time and um we also talked about it and agreed that this what we want to do so we just need someone to push the button

nice and oh i haven't tested all that other clients either so i'm not sure where they're at either

Marek Moraczyński: uh we are working in this way already so it's not a problem

for

netherlight

Micah Zoltu: is there a reason guest hasn't pushed the button yet marius or is it just around hitting the button

Marius van der Wijden: no one has gotten around to hitting the button i cannot i made the pr so i cannot push the button myself

well you can if you have approval i don't think so

it doesn't matter which one yeah

Tim Beiko: okay but this this will be part of the i guess you can have this as part of the

gordy merge release next week right if it's just clicking the button yes awesome

Gary Schulte: um

uh to be honest i didn't 100 follow that other than that we were going to uh have a a warning if the co has not uh got an engine api for the execution layer up to some some portion ahead of the fork is that right

Paul Hauner: yeah so the idea is that um we want to be able to have the uh consensus layer talking to the execution layer through the auth port we want to be able to do that basically from now and not waiting until the merge parameters are defined um yeah does that make sense

Gary Schulte: so yeah yeah that makes sense one of the uh one of the current configurations of baso is that

if we don't have a terminal total difficulty we don't enable the engine api um we could probably change that behavior so that if we don't have a ttd we can go ahead and have the engine api active

Paul Hauner: yeah cool that'd be super handy um yeah it helps helps users sit up there um configurations early set up their dev ops

early

Gary Schulte: okay yeah we'll get a ticket for that

thank you um an air gun i think we

Andrew Ashikhmin: already have the engine api available even if there is no ttd

okay awesome great

Tim Beiko: uh yeah that's really good to hear

um any other comments thoughts on this okay um i guess next up uh just to give a quick update on gordy so uh we we kind of chose the blocks uh or the epoch height and ttd earlier this week um so uh for anyone listening uh the crater epoch which will activate bellatrix and and kind of ready crater to merge with gordy is epoch uh one one two two six zero which is expected on uh

august 4th at uh 12 24 utc um and then the ttd that we're going to use for the transition on gordy is um one zero seven nine zero zero zero zero uh which we expect to happen the week after uh so the the the difficulty on on proof of authority which already use varies a lot but it should happen um sometime between the sixth and the twelfth and more likely between the eighth and the tenth um and i on yeah so that's when the gory emerges is happening so people should should be on the lookout for an announcement for that

um and then for the announcement uh if it's possible to have client releases out uh in the first half of next week uh that'd be ideal so we can just um communicate those by the end of next week does that sound reasonable to everyone okay no one complaining um so that's good uh and yeah if you're a staker or uh listening running through kind of the merge on gordy is the last chance you're gonna get to test everything before mainnet um so if if you're if you want to ensure that you know everything works through the entire process now's the time to do

it um if you don't want to wait for the gordy merge the roxin network has a public validator set as well so you can stand up a node on roxton and basically set up all of your configurations and it's the exact same process as it will be so even though you don't run through the merge kind of setting up everything to operate post merge is is the same um so that's something that people can do uh if they don't want to wait for the gordy merch but to run through the entire transition uh this is uh the last time uh yeah and

Micah Zoltu: this this isn't just for stakers everyone who is running a client should this your last chance to test the merge

and if you're in just yell right now you will need to install and set up access layer plan before the merge otherwise your node will stop working

correct

Tim Beiko: yes thank you um yeah so uh yeah not just stickers um and but obviously if you just run a node and turn it off and turn it on after the merge there's no like economic penalties but um if you want to stay up through the entire process uh you need to have the same infrastructure um yes and if you're in exchange hopefully you're already well aware of all this and um but yeah please start looking into it now um and uh the blog post next week

we'll have all the gordy specific client versions but all the clients that are out today support robson if you want to try that out before the announcement anything else on gordy okay

Danny Ryan: um this is a good time to talk about the shadow fork that's happening right now or does it

Tim Beiko: oh yeah actually it is

yes

Parithosh Jayanthi: yeah i can give you guys an update on that one um so yeah the shadow frog happened roughly an hour ago we did have a ttd

override earlier today i think we were around like the 98 fish percent participation rate before um shortly before we hit ttd i noticed the nimbus peso node ran out of space we have two of them so it's not a big deal but um yeah so that would bring down the maximum possible to like 95 percent and i think currently we're about 86 87 we're looking into the missing clients but it looks like prism nethermine's returning an error for a folk choice update and there's one tycoon other mine that might need some help on some other front and i think prism aragon is

stuck but it might have actually continued now i need to still look into that else post like a complete update once client games have had time to look into it um but because we run more than one node of each client pair um the issues also don't seem [Music] like inherent to one client pair like there are two prism nether nine nodes one is fine one isn't so it might not be a client issue it might just be the sync state the client was in when ttd was hit etc um nonetheless we still look into it and report

back

Tim Beiko: nice so we've gone from like issues with clients the issues with

client pairs to now issues with specific instances of client pairs

Danny Ryan: is the approximate number of block proposals equivalent to the approximate number of vegetation so something like 85

Parithosh Jayanthi: usually that's also i i just quickly ran each too and it looks like it's about that we still of course have to look into how many transactions are being included and um sync accurate past dissipation rates synch it actually looks really good at 95 for the entire hour almost so that's nice

Tim Beiko: anything else on the shadow fork

Parithosh Jayanthi: uh yeah we will be having a minor shadow pop next week um i think it's scheduled for the fifth conflict should be out and the other thing is we will be testing meb boost on girly shadow for tomorrow um as far as i know the relay is up but we want to wait until tomorrow to like have enough eyes on it so we can set them up manually and have a look at it with both teams present cool we'll report back on how that goes

yeah

Tim Beiko: thanks barry else have anything on this shadow fork okay um

okay then uh next up uh we have leo with an update on uh muv boost and preventing liveness failures even though mvv boost has some issues um yeah do you want to give a quick quick update there

sure i will be short this time um so our main priority is not to break the blockchain right we currently have this good enough setup that relies on a trusted relay and we are figuring out what comes next to make

things permissionless but we want to make sure that we test the conditions that could break the network so this is just to get some eyes on this issue that i linked on the mvp boost repository we will be making a brainstorming of the things that could affect um the liveness of the network um the most basic case like this i will insist this is already better to what we have from proof of work because of this sidecar design that we agreed to uh which i think enables us to do a lot of

experimentation without a lot of risk so in the case where there's one trusted relay and things start to become weird the solution is just to put offline the relay and then the consensus clients will just switch to local building so our point there is to make sure that this mechanism is in place on all the consensus clients we are relying on this and well then more conditions what happens if uh flashbots becomes evil and it has a lot of a lot of uh usage and

well the basic case the not so uh strong case uh the people who have permission to monitor and put the relay offline are like four or five so this is not just uh one person going wrong this requires like a coordinated effort uh that alleviates some of the pressure but still uh not good enough right so let's think about all the possible conditions we have the issue open about designing a relay monitor in the case that there are multiple relays that get a lot of a lot of usage but then we need to figure out what we

are monitoring and uh how this translates on an evaluation of risk for the proposers and what they are willing to sacrifice in order to get more reward or maybe this should be just like a binary this is a suspicious relay don't use it for now i'll get more permission less designs so if you have ideas if you have concerns you should do two to two and uh now that we are testing girly and preparing on on the test nets with uh with relevant data

it would be i think required to test these conditions so once we have uh a good amount of validators on girly using mbb boost and using the relay then we shot the relay for an hour and see what happens uh or we try some other like more extreme conditions that will shape the network and that will inform us like where where are the halls what things are vulnerable and i think we will be more confident to put this on production on mainnet at the merch thoughts

all right uh so i insist let's take a look at the issue we will be bringing this to the next week's call to uh talk to the consensus clients make sure that everybody is aligned and see what kind of uh checks can be implemented on the relay on mbb boost or on the client implementations thank you tim

Tim Beiko: cool yeah thank you for the update and i shared the issue in the chat uh for people anything else on the merge generally okay

um then next up uh we have uh an update from henry who's been working on eip4s for uh for the past couple months and we've had to move this update like across the past three or four corners called because we were so busy um so yeah uh now we have the time to go over it but uh yeah henry you want to give a quick kind of recap on what you've been doing and then uh kind of the the draft eip that you have

yeah sure tim um thanks so yeah hi everyone uh i want to give a quick update on this work um maybe just some background i'm not going to do a well the ip is pretty eip4s is pretty straightforward so um

and a really quick description is basically it's an eip that seeks to limit the amount of historical data specifically um not state blocks uh blocks receipts headers that nodes need to keep and um and it uh so the goal being limit the amount of storage for historical data past some age as well as limit the amount of p2p traffic for syncing that data um is quite general in that it's um you know it addresses this in a general manner in a way that would be uh that would be applicable both today and post-merge you know basically it says age out data past some certain um some certain age

uh the work i've been doing recently is a kind of a first step that we feel uh along specifically with eip authors that that would be a good first step and we have a good opportunity for this soon uh which is apply eip4s for pre-merge history so soon we're gonna have the merge point and um and then some time after that we could potentially say um hey you don't need to keep all the blocks and headers unless you want to at least you don't need to serve them uh if people want to sync those blocks they would get them out of band um that's kind of the high level context and um and so the work i've been doing here is well let's assume we were in that situation and we wanted to do this and and we have consensus and so forth

uh what does this how do we distribute these blocks what is it going to look like um and so i've got let me post oh great i see i see tim's posted everything in the in the in the chat already um so the first link is a link to a repo that has basically uh sse specs for um for encoding a runner blocks with the headers and receipts um into ssc so maybe a little uh kind of context here i think initially there was there was some agreement amongst a bunch of people who discussed this that well we could store this in rlp as is

the current export format um but i think everyone agreed that we wanted to move on from that for a bunch of reasons um and ssz given that it's we're using that extensively in the beacon chain um it it felt like a good time to move this data to that format um and well it's of course we use this in the beacon chain extensively um some of the nice things we get for free by doing this or the one key thing we get for free by storing this data and sse here is that we can we kind of get out of the box the hash root computation and um and all of that so with these block archives we can then uh provide the witness hash through just directly

through the ssc machinery that um that does that for us now the so that the format itself i'm not going to walk through everything i'll just kind of describe the high level outline but this is definitely something that i'd be interested in feedback on um well there's kind of two levels to this that's a general approach and then if the general approach is you know it is agreed on then there's all the kind of details of the ssd specification itself which um you know the more eyeballs we get on this the better and you know including down to like low level tweaks and and minor changes i think uh that you know it'd be great to have some some people scrutinizing this uh at some point um but the high level idea is this borrows from the beacon chain execution payload uh layout pretty

extensively but with a few adaptations in that you know here with we're talking about proof of work blocks right now so these need to have uncles and um you know there's a couple of fields that were repurposed um but it's but it's pretty close to that uh unfortunately it's not identical but it's pretty close or it's extremely close um and so that's the basis of it and then there's an archive header container i'm looking at that the first link that tim pointed which is actually the eip draft has the same information there's an archive header container uh an archive body is just sorry there's an archive body which is just a list an sse list of these blocks so we can get the uh the hash tree over that list you know rather than say

concatenate them outside of sse just concatenate them uh into a file we put them in an sse list that makes encoding decoding a bit more um resource intensive as you need to read everything in but and but it allows us to get the the hashing um and and then there's a a little header with a version and uh and a couple of fields on on which block range or range yeah which block range is contained uh following the header so uh so that's that's pretty much it um in terms of what the what the format is again you know i don't think this is the right place to go and read through every line but but there is quite a lot of sse definitions so feedback and and

uh will be welcome um in the repo that's that eip4s dash proto repo the first link there's a tool that can take input rlp and convert it to this ssd format and vice versa and um and print out hash reroutes and do a you know a bunch of basic manipulation of this format um yeah one one caveat here is i said it converts to and from rlp that is rlp given that this sse format encodes receipts as well um regular rlp exports at least the one that i know the best of the ones from get they don't have receipts so i had a

branch on geth that included receipts in the rlp export um that that's just a that was a short-lived branch um so the so you can't use those rlps directly but you can um there's a switch in this tool to do non-receipts and uh and then that will work um separately there's a pr going up on geth or that's up on geth i think that's some draft form that adds this to geth so you know we'll see if it gets in but i think there was some interest in that uh so ideally we'll get to a point where you'll be able to export this sse directly from geth and then that tool that i just mentioned that was my prototyping tool will still be useful for like examining files and maybe still

converting them and stuff like that but um you won't have to go through like all the gymnastics to export from get um so yeah that's roughly the current status uh i think that the next steps well of course getting feedback the next steps if i'm continuing down this path are going to be well actually doing a full export on uh on gurley and and then since we have the merge soon hopefully being able to see what that would look like and potentially reimport it um into a fresh note post post-girly marriage um the pr is up on geth and uh and yeah if you know but if if there's agreement and consensus on

this then then we'll start looking at the distribution mechanisms for these files i guess i should have just given a bit of context so the idea here is you know if you talk about the full uh export of mainnet up to the merge that's a pretty uh it was in the 300-ish gigabytes if i'm uncompressed if i'm remembering correctly now um and so compressed maybe it's a 2x but that's you know that's going to be a fairly large number of files uh we'll have to find out well they'll be we'll want to have multiple places to host and distribute them and then one place to host the hash root for all of this data um but that's you know that'll come a little later

so uh so yeah i think that's roughly everything i wanted to uh to go over on this again two links there feedback very welcome on the repo or in in the discord and there's a history uh expiry channel in the heath r d discord which we can use for discussions related to this and yeah that that's pretty much it any questions comments thoughts

Micah Zoltu: so you uh mentioned that this is uh the shape of these things are brought mostly over from the beacon blocks with a few minor modifications

looking at this modification that seems to be interspersed throughout it does ssz not benefit just in terms of modularity and reuse of code from putting all the new stuff on the end so that way you can just inherit from the beacon block

header

uh good question i might be missing something with ssc so you're saying if we if we put all the if we had exactly the beacon block struct and we added things at the end we could inherit

Micah Zoltu: yeah so like with rlp at least uh if you add things to the end it's much easier to reuse code than if you add things in the middle yeah just due to the nature of rlp i don't know ssz well enough to know if that is true there as well but if so it seems like a big win just so we don't have to

have like two different things you just have one and then the extension

yeah um i'm not aware of that i'll don't take a second look i think this might also be implementation specific i've been using the go fast ssd library pretty much exclusively um but yeah i well i agree that if we could do that that would be great i'll take a i'll take a second look to see if i missed something but i i don't i'm not aware of anything like that i don't think that's possible

Tim Beiko: any other questions comments okay uh yeah thank you very much henry

um and yeah it will be super exciting i think to see that on gordy um after i guess yeah just maybe my gut feeling is it would be quite valuable to run this full export on gordy right before the merge or like right after the merge whatever on the pre-merged data and then re-import it on a fresh note after like does that generally seem sensible to others as well

Micah Zoltu: i feel like at some point we should talk about whether we actually want this and we'll implement it before we go too far down the road and i think we've i last i heard there was not consensus that this is a desired path for ethereum i'm a fan personally but i don't want to waste people's time if

we can't get consensus

Marius van der Wijden: i think we don't have consensus on whether we want to drop the history from the nodes but i think we have con at least the way i engage it we we have consensus on that this is something that's cool to have as a secondary mechanism

Tim Beiko: yeah and i think it's almost like before you probably feel comfortable dropping it fully from the nodes you want to know that the secondary mechanism works reliably um is that does that make sense

Marius van der Wijden: yeah that's exactly what what i i i at

least want to see before i vote for that

Tim Beiko: so i think in that case then yeah definitely running the experiment on gordy and and showing it working is a really valuable first step um does anyone disagree with that okay um sweet uh so i guess yeah that's pretty much it there were just two quick announcements um first uh there's going to be another eip4844 breakout call

next friday at 14 utc the agenda is linked in in this agenda but they see some upgrade some updates on implementations the kzg stuff and uh some of the spec issues um as well um so yeah if you're interested in that you can show up there and then uh alex you had also something around the uh builder spec that you wanted to bring people's attention to

Alex Stokes: yeah i just wanted to call it out this is mainly for student clients but in the event that some of you are here which you are uh just please take a look it was around

essentially some kind of embargo that we'll have on memphis going through the merge transition itself we had agreed on a particular strategy in the last cl call i've updated the pr to reflect that so if anyone could just take a look and then we'll discuss next week

Tim Beiko: thank you and that's a pr 38 in the builder's spec repo

okay there we go

and question here which maybe it's better to discuss next week do you want some action from us like should there really be applying anyway until that period approaches

or are there some checks that we should do on the relay or should this be local just enforced by the

validators and proposers

Adrian Sutton: my gut feel is that it'd be safer to let the battle later enforce it so builder is available because if the battery happens to depend on on the relay it's kind of better for it to be there but i'm not strong on that

Paul Hauner: i would be tempted to lean towards

leaving the relay on as well um it's one less thing to forget to turn back on i guess but also not strongly held

all right uh well we have time to figure out the actual process in this [Music] i think it's sensible uh my ask here is like come up with crazy ideas of uh like announcing this like the first blocks will uh have no mbb boost really is there something that happened uh

seems very complicated like it's not a it's not a big window and it's going to be super hard to coordinate it to affect it in significant ways uh but still it would be good to make just the brainstorming of what could go wrong yeah this makes sense thank you alex

cool

Tim Beiko: anything else anyone wanted to bring up

Trent Van Epps: yeah i can jump in oh yes my audio okay

um yeah just really quick uh every two weeks we've been running the uh an open kzg ceremony call um for there's the fourth call so it's been a little over a month or two um yeah this is the we're setting the stage for proto-dank sharding but in order to do that we need to uh design and implement this trusted setup ceremony people are familiar with that that's uh made famous by zcash and many other projects uh it's a big coordinated ceremony to generate a number and then the number is input into the protocol so uh and then protobank charting would make

use of that number uh the cryptographic construction so we're working on that um as in parallel with all the merge efforts kind of like what henry is doing with uh 4-4 so if anybody's interested in engaging with this learning more about it we like i said we run regular calls and anybody's welcome to join and we hope to see many people creating their own in their their own implementations um so if this is something that sounds interesting to you please do put the put the link to the latest call and that will maybe direct you to more interesting things uh the specs repo is also linked there as well

but yeah just sharing that we just had our fourth call this morning a few hours ago and then it'll be again in two weeks if you want to join the next one

thanks oh

Tim Beiko: and there is perry do you want to give some context on that uh yeah

Parithosh Jayanthi: i don't really have more context other than one of the notes just decided to self-heal after like half an hour um we will still figure out what's happening there and i think the netherlands team might have made some heavy on some of the other issues

nice

yeah

Marek Moraczyński: i think one one of the remind the node self healed itself too but still analyzing requests from others

Tim Beiko: nice that's really really good to see sweet anything else before we wrap up okay well thanks everyone we'll see you in yeah two weeks uh august 4th again on a thursday um yeah have a nice rest of your week bye thanks all bye

we can start the weekend now right yes this is how you get an extra day off on this thursday all right have a nice day

cheers so [Music] [Music]

[Music] so [Music] [Music]

[Applause] [Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] so [Music] so [Music] [Music]

[Applause] [Music] so [Music] so

[Music] [Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] so [Music] [Music] [Music]

[Applause] [Music] [Music] [Music]

[Music] [Music] you

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.