All Core Devs - Execution #139

Transcript

[Music] [Music] [Music]

thank you [Music] [Music]

[Music] [Music] [Music]

[Music]

Tim Beiko: okay we are live uh for awkward abs number 139 um we have plenty of merge things to discuss today and if there's any time left over uh we have two quick updates on on eips that people wanted to present um first thing uh i guess is the roxton issue that we saw yesterday um

does anyone want to give a quick recap i kind of wrote a recap but if anyone else wants to just run through what happened that would be that'd be great

okay i believe that's your job tim

Tim Beiko: okay okay i guess i uh i'll read from for my document but hi level um what we saw is um the robson hash rate go up like 20 30 x overnight uh we always kind of knew this could happen but previously people did not mess with robson as much um and this kind of led uh the network to hit the terminal total difficulty for the merge before the

beacon chain for robston was even live so genesis is scheduled for may 30th i believe um and and this kind of just put things in a weird spot where like validators were or sorry upgraded nodes kind of thought that uh ttd had been hit but uh the beacon chain did not exist yet um and and um the amount of like money that it cost to raise the hash rate on robson is is quite trivial so you know even if we raise the ttd like twice three times 10x um it's quite possible somebody might just mine enough uh might just invest enough to mess with that number as well

um and so basically in order to prevent uh that we've kind of moved to a solution where um we override the ttd to an incredibly large number have the beacon chain go live have bellatrix happen on the beacon chain and then uh override the ttd again to a number that we expect to happen fairly soon and so that means that like up to up to bellatrix being activated it's basically impossible that we would hit the ttd the number we chose was about twice the total difficulty on the ethereum main net which on robson's hash rate would take about 250 years to hit um so we're safe there but then yeah once bellatrix

is hit the the plan is to choose another ttd which we expect to happen soon and and um upgrade this again um i guess just for people listening you know that this can't really happen on mainnet and the reason is that for this to happen you know well this was caused because the beacon chain was was basically not live yet and because of how hard it is to predict um hash rate on test nets and how variable it is obviously i may not the beacon chain is live um so that's not a problem uh but then there's still this potential problem of like what if ttd was hit before the bellatrix upgrade was live on on the beacon chain um and there the reasoning is well we

can we can predict hash rate you know uh fairly well on mainnet and and most likely the not hash rate would be going down rather than up because we approached the merge um so the odds that like a ton of hash rate would join the network and force us to hit ttd much earlier than expected is quite low um and and depending on like you know like basically if we if if we saw hash rate 2x overnight on mainnet it means there's like now enough new hash rate to conduct a 51 attack and like proof of work security guarantees weekend a lot by that point so we can have like pretty reasonable bounds on the ttd uh on on mainnet um and the worst case is usually like it just happens later than we would expect um

um but yeah for test nets given that like gordy is is obviously on proof of work and uh sorry robson is obviously on proof of work and it's easy to manipulate same with sepolia uh it seems like what makes the most sense is just saying this very high number let bellatrix happen and then um and then sell it to another ttd that's that's much

lower

Marius van der Wijden: um so yeah one one question i have is why do we need the ttd and bellatrix why not just make bellatrix um if like if we don't specify a ttd for bellatrix then we will look at the

look at the ttd from from from the ether1 chain or the td from the eth1 chain and just ignore it because we don't have a ttd set so i'm i'm i'm a bit confused why we need to set the ttd for bellatrix to happen and why we should not just schedule bellatrix and then set the

ttd now

Mikhail Kalinin: do you mean that why do we need tgd to be a part of cl clients binary or do you mean that why do we need to set ttd uh like to to like deploy a real gtd within the bellatrix

the second

just yeah this yeah

Marius van der Wijden: why do we have it have to have it in one release and i guess we don't

but

Micah Zoltu: i'm going to throw out an answer um in the spirit of the internet and saying something wrong someone will correct me i believe the reason is that the clients as consensus clients as currently written um bellatrix kind of they expect a ttd to be available when with bellatrix like they need something for that value they need to put something in there um because they have a constant somewhere in their code and they need to set it to something and so we need some number to be in in that spot when bellatrix goes live or whether the bellatrix clients are released i should say um that number can be giant it can be you know you ate max that's fine uh but it

needs to be something and that's why when we talk about we need a ttd for bellatrix i believe that is the reason um now someone can correct me

Mikhail Kalinin: yes but uh as i understand what marius was saying is that we can put a free placeholder then for a tt value a pretty large number and then wait for real tricks to happen then like cut release another another like series of releases of clients with the reality is that what you mean marius

Marius van der Wijden: yes or like the easiest way in the way i would just like i would have thought that clients would have implemented it is if

we if we don't specify a ttd with bellatrix then the bellatrix fork will update the uh make the consensus changes but not um verify the the the td from the uh from the execution layer chain against i against what we don't

have so

Tim Beiko: i guess given that all the testing of like the past year has happened with a ttd on bellatrix it's probably much safer like and it achieves the same outcome to just have like a really high value rather than to try and change the code now and have it say like if there's

nothing do this um is there like i'm curious to hear there's a couple cl folks on the call like i don't know do you feel more comfortable with one way or the other

Marius van der Wijden: um i think it's like i actually think it's fine to set it to some really high number um but yeah i i'm just like i i think it's it's it's it's a bad design decision to um that has been done previously and we can like it doesn't make sense to turn it around no it's just for

the

Mikhail Kalinin: i think it's it's like not a big deal now i mean we can set it to like very large number uh but yeah this is what we're going to do with on sepolia but on the main net uh like uh what we're gonna do with the sepola is to set the reactivity after bellatrix happens right uh but yeah for the mainnet um i'm not sure about that that's like do we want to have

two releases so i i announced right here yes i

Marius van der Wijden: think we would want to have two rounds of upgrades

sorry

Micah Zoltu: yeah and and the reason the reason for that for those listening and who

overall discord is that having your test nets follow the exact same pattern as your production network is very valuable um it also impacts third parties so third parties who want to be able to follow the sifolia upgrade and they set up the runbooks they set up their scripts if your institution you may have a big infrastructure that you need to go through and you have checklists and all these things having that be exactly the same for test nets and mainnet with the only difference being like you know whether it runs on client a or client or host a or host to b is very valuable for those people and so i think it is important that we should follow the exact same procedure for the mainnet launch as first pulley launch even if it feels kind of unnecessary on mainnet due to uh difficulty being much harder to play

with

yeah i feel the same as what mike is suggesting does anyone oh sorry go ahead

Mikhail Kalinin: i just wanted to ask about how much time would it take to upgrade second time do we expect the uh like the same time to um to upgrade to users upgrading their notes in both cases so

Marius van der Wijden: like can someone explain like really quickly what's in bellatrix and why should we not just schedule it right now with a really high ttg and then set the ttd once

um yeah

Tim Beiko: i guess for the same reason that we can't schedule the merge i assume there's still some testing

well

Marius van der Wijden: but like scheduling the merge is something different right

Tim Beiko: oh

right scheduling the

Marius van der Wijden: merge means setting the ttd and scheduling bellatrix is in my opinion it should be in my opinion something different from scheduling

the match

Tim Beiko: i'd be curious to hear from cl clients here but it does feel like the the code that like

cl clients have today is not what they expect to have on mainnet and i don't know what like the diff is here but yeah um i see some prism deku folks

Ben Edgington: uh for teku uh it depends when we showed you it i think i mean i i think we are basically production ready and could go but um uh if we're scheduling it a month out then you know that that would be fine but yeah it all depends on dates yeah not not having a date doesn't doesn't help having a date helps

Terence Tsao: yeah that's i think that that is same with crystal as well

Tim Beiko: okay but so so because like you know i don't think anyone is arguing that like we could run through the mainnet merge in a month and so if it's like realistic that like bellatrix could be scheduled and you know call it a month or two and give us some time to then uh yeah then then make it really easy to set the ttd um that's probably a discussion worth having on the cl call next week um but yeah if i think that would because the and the reason i guess to take a step back is i think the the biggest downside i can see with this approach of

two releases is just that um yeah you're just kind of waiting around for a while at the end right like where you basically upgrade your client to bellatrix you know and then bellatrix happens but kind of nothing happens on the network because bellatrix is just waiting um and then um and then you have to like run through this whole upgrade cycle again and if we're just sitting around waiting it's basically just a waste of time but if we can if we can save that i think that's the biggest downside that that there isn't this approach

Micah Zoltu: if all if all the clients have a ttd override config setting i would be personally comfortable with um

having a fairly short time window between the ttd announcement and the ttd going live because anyone who can't you know quickly upgrade their client because they need to do some some additional testing or whatever can simply just do a ttd override instead like you don't actually need to do a full upgrade if you don't want there's two options tdd override or download the client that has the ttd baked in and both of them are viable and you can choose which one you want but that makes me more comfortable that we don't need to you know have the usual you know one month between scheduling the the hard fork and then the hard fork happening because you know clients are already out there they've been out there for two weeks already we can just say in two weeks is when we're scheduling

right this

Tim Beiko: just yeah this assumes that

the el clients are already up there which like in this case where we schedule bio-tricks already might not be true

um that's like

Micah Zoltu: i guess what i'm saying is i think the time between the el cla all the clients being released with the ttd hardcoded to a giant number and the time between the merge that's the time period that matters that choosing the ttd you know it does need to be some amount of time before the merge but i don't think it needs to be the usual like you know one month before

Tim Beiko: no i have the hard work yeah i i would agree there i'm curious if anyone disagrees with that okay and i guess

based on that um this can also be like different for test nets and mainnet um so given that for like robson um we've agreed we've basically agreed to a ttd of i think it's 10 to the 32 if if if i'm right uh but 10 to the something which is about twice what's what's the number on mainnet um clients i think are expected to have releases either today or monday with this new value um and and and we're going to publish those like early next week um and then bellatrix is expected to hit on june 3rd um oh 10 to the 23 is the number thanks for this um so bellatrix is expected next next friday on june 3rd and because

it's a beacon chain uh fork they happen at an actual time stamp so it's usually quite accurate um so that means like the the quickest we could choose this new ttd value is like next friday on on june 3rd um how long after you know and then i expect we either need new client releases or not like we can also just tell users to run the the ttd override flag um so like early in the week after like around june 6th or 7th we can probably have a blog post up with this announcement um how long after that do we want to wait until ttd happens on robston because the

original plan was june 8th it obviously seems incredibly close to have like a blog post on june 7th and hitting ttd on june 8th um what what are people's thoughts about like that delay between um yeah basically having chosen a ttd for robsten post bellatrix and and um having it actually hit the network

Marius van der Wijden: um i think we should try to go for the the date that we already said

Tim Beiko: the eighth surgeon's all right yes so that so that means we might be in a world which is like a blog post announcement coming out on like the seventh like all the clients are set already there but then the fork happens the ttd is hit on robsten like 24 hours later

Micah Zoltu: we don't am i correct understand that we don't expect clients to be ready until the seventh

Tim Beiko: no sorry so um actually that's no that's not true we can be ready quicker than that so i think what we can do uh is i'm not sure what time uh bellatrix is scheduled for on on the third on uh on friday the third

but basically as soon as bellatrix has happened we can pick a ttd value and maybe even like before like obviously if we know that bellatrix is going to happen in three hours and we pick a ttd value that's like in three days or four days um and and we can also pick a ttd value that's like in 10 days and then add a hash rate to make that happen quicker um so like on the third we can probably have like agreement on a value and then you don't need to update el clients they can all just pass a ttd override flag um and i suspect though just like the time for us to decide a ttd value and then like uh kind of announce it to the community and whatnot

it means it probably happens on like the monday that people get aware of it um and that's and i guess we can make it quicker if we don't wait for client releases clients are obviously free to then release versions and like advertise them to your users but we can have like a kind of an announcement that's just focused on the flags um with a note that you know that maybe your client will have a released version out um so that means basically by monday you can expect like the ttd is like known and communicated and then you kind of have 48 ish hours before the fork hits on

robstep

Micah Zoltu: i think it's important for those

listening in um to understand that we do not have fine-grained control over when the merge happens exactly like in terms of timestamps and this is very very true on test nets and it is somewhat true on mainnet normally when we schedule hard forks we can get pretty close to where we want them to be like we shoot for a certain time of day with the merge everybody should be prepared for testnets and mainnet that we may get the day wrong um and for test tests we may get the week wrong as we saw with robston right we got it we're wrong by like several weeks and with maidenhead i i think being off by days is not unreasonable and so all users should be prepared for that like when we talk about scheduling things for the they're scheduling things for you know

this date or that day um users need to be aware these are best guesses for us we're trying our best but the way things are designed we don't actually have control i mean it's a censorship resistant system that we don't actually control we only make suggestions and the system does what it does

Tim Beiko: right and and in practice what this means is like say we choose something on the third which we expect to be even you know like on the 13th and we can then have ash power to like reach it a bit quicker um there is still a world where somebody like puts 100x the amount of hash rate on on robsten and it ends up hitting over the weekend right um like i don't think there's anything we can realistically do to prevent that um

so yeah there's on robston and this will also be true on sepolia there's like always a chance that like as soon as we pick the ttd value somebody shows up and we hit it like hours instead of days later just because the cost is so low to mine on those

test nets

Micah Zoltu: um if you're listening please don't troll us

Tim Beiko: you'll be disqualified from any future airdrops i'm kidding there are no air drops um does that does anyone oh sorry go ahead

mikael

Mikhail Kalinin: yeah i just wanted to clarify that we are setting a reality on six right

Tim Beiko: uh we would set it on the third i think it's true because at least it gives at least i would prefer setting it on the third because it gives people the weekend as well to upgrade uh update their new their nodes um and the third is when bellatrix happens so we can either set it a few hours before bellatrix or a few hours after um but like probably around this time on the third because this is when people are like generally online um and we we might also like there's a consensus layer called on the second so i think um i think on the second uh

we can maybe have like candidates ttd's and like you know that assume that things are stable and then assuming like nothing goes crazy uh before bellatrix we can we can probably reuse just one of those candidates um yeah

okay i see yeah yeah i think it makes sense and yeah it's far as far as i remember it's gonna happen like the bellatrix is gonna happen like at 10 pm utc i'll just double check it

Tim Beiko: okay okay so that means it's like this right now is like uh 2 p.m utc so that means bellatrix is happening like

quite late you know it's happening like six hours from now um i still think we can probably set a ttd value like around this time but it does become a bit more risky that like someone could just mine a bunch and um i i don't know how much it would cost to like bring something that's like two weeks out to happen in like less than six hours basically so there's a question in the chat like why can't we keep it really high and reduce it the day before it's basically it's like the lag between we need to communicate this num

this number to people like we can't just like choose i mean in a perfect like if we controlled everything over the network we could literally choose a ttd and and have it activate 20 minutes later and it would have really high precision but it's like how much time do we give people to like look at their clients announcements read the blog post um and so it feels like the on the order of a couple days is like the the minimum and given this is a test net um i think for my net we probably want something even even longer uh assuming we need to go that route but

Mikhail Kalinin: um it's actually going to happen on june

2nd at 10 pm you to see from what i can see from the conflicts

Tim Beiko: okay nice okay perfect so little tricks yes okay so that means then i think on the cl call next week we can have a bunch of candidate ttd's um and then at the very least you know people will be aware of like what are the options and then we can reconfirm that number uh basically 24 hours after the cl call once bellatrix has happened um so that like friday 1400 utc roughly um we have a ttd for robson does that make sense

okay

Mikhail Kalinin: um i also have a comment uh yeah or kind of an idea uh does it make sense to to shadow the bellatrix on the mainnet uh and this can cut it in the same release as um like the virtual release were girly and said like two weeks after girly and if everything goes well on earth then we can just you know have this kind of you know probably two weeks three weeks or whatever we find

reasonable

Tim Beiko: and that would be basically after gordian that means battle tricks on my net would

happen roughly around the same time as like the merge on sepolia or something

Mikhail Kalinin: um what do you mean

so like i thought yeah gordy's the next testament i think i i thought we agreed with you oh robstead gordy basically um oh

Mikhail Kalinin: sorry then i just mixed them the last one there's there's one thing that uh setting early uh bellatrix epoch might trigger there's a lot of validators that are running uh they're not running an f1 node and for those guys selling bellatrix will force them to actually sync so we need to give them time at least and

advertise that they need to start syncing their their their engines and that they need to be synced by the time that the electrics hits

Tim Beiko: okay that's a great point yeah

Parithosh Jayanthi: um which might actually be a nice feature because by the time ttd is hit then we know that people are definitely

synced yeah okay

Tim Beiko: so i think yeah it seems like there is like a general feeling that we can do bellatrix earlier than midnight uh than the ttd on mainnet i would move this conversation to the cl call next week just to make sure that like um we have all the cl teams chiming in um and and daddy's not on this call today but i'll make sure to like also bring him up to

speed on this and uh so he's aware and and we can kind of draft what that could look like um but either yeah is there something like alongside the last test net um so that then when we move to mainnet we're just setting the ttd we know bellatrix has happened and from users perspectives it's just like download a new el version and maybe the cls have like slight improvements but they should have like consensus changes

yeah we should also consider that once billetrix happens then cl will start querying el4 at least for the exchange transition configuration and the pl is not upgraded

because it will start complaining with messages and the logs so we should also consider that

Tim Beiko: oh right so if you're querying yeah if you're querying an el that doesn't have like the paris code basically then it will send weird log messages is that

right yeah and yeah and it will it will try to connect to engine api endpoints so we will have to release els as well and els should be upgraded as well so that yeah

Tim Beiko: so we need els to be at least aware that there's a thing called the engine api

uh which only happens in like a specific release with like eip3675 is that correct

Mikhail Kalinin: right it's it's it's basically paris right yeah okay so we'll have to release code yeah we'll have to release paris and uh gelatrix probably at the same time and yeah the upgrade should happen the upgrade to paris should happen before the electrics hits the main

net and

Micah Zoltu: i believe someone correct me wrong but i believe if you took um the a client today like the robston client let's say whatever client you guys are using to test execution layer on robson um

that should work through mainnet as long as you have ttd override is that correct assuming we don't have to change anything between now and then so we know code changes like a person doesn't even need to upgrade their client from now until the merge they just need to set the ttd is that accurate assuming they're running a robson client today

like they just like

Micah Zoltu: switch it over to mainnet and they're good

Marius van der Wijden: they need to change the chain config of course but other than that they can use the same

software

Micah Zoltu: there's the is uh does guest not release one client with money chain configs and it's not just like dash dash config mainnet yeah like actually

okay okay yeah so yeah so so in theory um people can't upgrade today like their whole setup they can upgrade paris bellatrix clients today and so again assuming no changes they're good to go for the merge is that more or less accurate

uh well not for aragon because um as discussed we've only prepared an alpha quality release we're still making fixes and improvements for the merge okay

Tim Beiko: right and i think to be clear like what mikael's plan was we do this when we're doing like the last test net and so we would hope that by then

clients have like releases that are very close if not exactly the same that like will hit mainnet so we don't

Mikhail Kalinin: yes the plan is simple because uh we would i don't think we would like to have uh the bellatrix scheduled before uh the last uh just that is upgraded and sometime plus on top of this upgrade right to um give us time to if anything goes wrong

Tim Beiko: yeah i think that that makes sense thinking like bellatrix happens like a few weeks the month after the last test net hub upgrade basically

um and it's but it's scheduled at the same time

yeah yes and yeah if everything goes right and if everything is okay we just don't need to cut new releases and go with it yeah and i mean clients

Tim Beiko: i think i suspect in practice some clients might choose to cut the new release with the updated ttd value but um yeah it's not like a strict requirement basically

Mikhail Kalinin: i think that clients should release uh here yeah that client should be released with the the realtivity value but users will

have a choice between like upgrading and or overriding

yeah oh right then potus

Tim Beiko: has a comment that like the ttd override value isn't uh required in this spec so like i guess in theory like you know this from a spec perspective like the client releases are the way that this happens and then but yeah we we would just probably list both and if some clients just does one or the other we can just highlight that it's not the end of the world so i guess just to like recap all this

so for robston specifically um you know clients are gonna put out releases uh in in the next uh days with the huge ttd value if you've already downloaded a client release by the way that had robson ttd support for like the value we hit yesterday you do need to upgrade uh your ttd value to the new uh the new one um we'll have an announcement about that um basically we'll have an announcement about the the the new robsten clients early next week which will have this pretty high ttd hard-coded in it and then once bellatrix has happened uh on june

2nd uh we'll choose uh i guess realistic ttd number um that will confirm on june 3rd we will probably choose that to happen like in in theory 10 or so days from then but then we'll try and add some hash rate for it to happen around june 8th but that's like a very rough target we can't really guarantee that um does that generally make sense of people for robston okay and then for mainnet we'll confirm this on on the uh cl call next week um but the rough idea would be that

when we have the client releases go out for sepolia which we expect to be quite uh quite final um we would also then set a slot height um or slot fork epoch i'm not sure what the right term is on the cl side but basically we would set the the epoch or slot number on the beacon chain where bellatrick happens on mainnet um meaning that then uh once that has happened we can just choose a ttd value uh that's like a couple weeks away and all users will have to do then is update uh either update their clients or run the ttd override flag to have the the right

value for mainnet does anyone have like strong objections for that um police what do you mean about the jwt stuff

oh

Potuz: so the engine is supposed to be a secured connection i'm not really i'm not really following how it is but i i thought that uh clients haven't uh execution clients are are not really finished with that so i'm not sure if they're actually enforcing that it's authenticated so i'm just wondering whether or not having this finished before we set up uh the bellatrix for

epoch is a requirement or not

Micah Zoltu: yes

Marius van der Wijden: so so for gas we have the authentication uh finished and required and on eight eight five five one you can optionally enable the engine api on uh the default http port so 8545 without authentication if you want to test something the only issue is that if you don't if we don't specify the if you don't have a ttd specified the

[Music] authenticated part will not be opened and this is something that we're thinking about changing that we have the authenticated port open by default even without ttd specified so that you can test okay so so that you can test uh your stuff uh without having to specify

a ttd now

Marek Moraczyński: we in measurement we also implemented authentication and we are working in this way that uh if we specify uh port in any uh

in any part uh we will authenticate it and if we add engine api but we need to explicitly say that the board is not authenticated

Tim Beiko: thanks basu and eragon i'm curious what the status of this is

Gary Schulte: yeah basically implements job authentication we uh we actually have a flag that uh can enable or disable jot authentication the on on the engine api uh currently the default is set to uh disabled for test purposes but pretty soon probably next release we're going to flip that flag to make it default on and you'll have to explicitly disable it

Tim Beiko: got it thanks

Andrew Ashikhmin: in aragon we have implemented the jvwt authentication and moreover we have removed the unauthenticated port completely okay that's only possible with with the authentication

Tim Beiko: so it seems yeah from the el side at least we're good um i do think that we should not be forking the last test nets until it's like implemented across like it should be the default behavior across every client but assuming that it is then it means that we can obviously that this is not a problem to schedule bellatrix on mainnet as well does that make sense

okay um anything else just regarding robsten and like this kind of ttd bellatrix timing okay if not i think the next thing i i want to chat about is like the sephilia beacon chain so the the actual first problem we hit on robson was not this bellatrix scheduling but it was like the beacon chain did not even exist uh which obviously is is not the case on the ethereum main net um so what are people's thoughts about like

when and how we should launch the sapolia beacon chain to make sure that we don't hit um a similar issue uh on when we

reached the polio

Micah Zoltu: what are the constraints to prevent us from releasing this fully vegan chain like right now like what's what's the thing that's holding us back

Tim Beiko: uh perry there's there's nothing holding us back we could we could launch one next week if we want it's just a bit of coordination that's all

i

Micah Zoltu: i feel like we should just do that if then if there's nothing actually preventing us from doing assuming we should just focus on doing exploration and making it

happen so we don't have to worry about it later

Parithosh Jayanthi: okay um should we just launch it and leave the bellatrix information on set so when we then decide that at the future call

Tim Beiko: i think yeah go ahead

Micah Zoltu: my personal preference and this is as not a client developer so i could be totally wrong on this would just be so with the execution clients um you can set them so that like with genesis they already have a bunch of forks set like credit justice block is there a reason we can't just launch um the beating chain with bellatrix already live from day one just with the ttds of

infinite like so the bellatrix code is ready but the tdd is far in the future

so we can also do that we i think there's some clients that don't allow you to sell it to happen in genesis but it can happen at epoch one which isn't that different says six minutes later um sure but yeah we can do that and just set ptd to be in oh

Micah Zoltu: that's my vote

but

Tim Beiko: yeah i i think their their argument towards not having bellatrix at first is like it mirrors more of what we have on main net so like the current the or the current beacon chain main net basically has uh altair activated but not bellatrix um so i can see an argument that like we

would uh yeah i could see an argument that like we would want to maybe replicate the main net conditions

Micah Zoltu: um but it's not like it's super strong maybe we just at least have it so we have um genesis and then reach

finality and then altair reach finality and then bellatrix and then reach finality so at least we go through like the full life cycle um on each fork yeah what i mean because there might be coordination things we

Tim Beiko: want to test for bellatrix right like that there might be value in selling bellatrix at like a future date so that we can like do something with it um but yeah i don't see any issues against

like doing genesis and altair um i guess the one thing i would maybe say oh sorry perry you were going to say something yeah

Parithosh Jayanthi: i think i agree with with you on that like we can have genesis and altair and just leave bellatrix as it is because we still haven't just reached a final decision on how we can handle mainnet and once we know how we're going to do it on mainnet we can then replicate the same thing on

on support here okay and my only finances oh yeah michael go ahead no i was just gonna say the same yeah i was just gonna say the same thing very

upset

Tim Beiko: okay yeah sorry my last point was just um is this just something we want to check on the cl call with the cl teams as well because like they run the software for that um like there's no rush to do it like this week versus next week we just want to do it like well before sepolia forks um so is it worth just like saturday checking this on the cl call a week from now

Micah Zoltu: i personally see no problem with um perry launching the uh sifolia vegan chain over the weekend

honestly

Tim Beiko: i guess i don't know there are some cl folks here how do you all feel about

this

Micah Zoltu: i don't actually care um again i'm gonna i'm gonna single you out yeah i think since it takes so little time to actually set one up we can just wait until the cl call next week i think the one week difference is not going to make a change we're not going to much separate next week or the week after anyway

okay oh nice i just phil from loadstar sorry i had missed you

Tim Beiko: before um okay sounds good so like yeah we'll we'll cover that as well next week uh on on the cl call but basically it seems like at least from the el side we have agreement that we want to launch it as

soon as possible run it through altair and then wait a bit to figure out what we do for bellatrix um anything else

on sepolia a

Micah Zoltu: quick question about bellatrix um just for my own notification and others listening does bellatrix contain any consensus changes that happened before tpd or is it just code that act all activates on ttd like is there a

trick that is not the ptds that's consensus it has changes in yes it has changes in

in the block body structure at least okay and there is the ability to work sorry go ahead i think i'm lagging so go ahead

Mikhail Kalinin: yeah it's just it's monitors for execution payload to be non-zero and it also looks for el to and queries whether it's the block the terminal a terminal block exists but yeah that's what it is

Micah Zoltu: so so if you have two clients and they do they need to coordinate when bellatrix happens prior to ttd like is

there a bellatrix hard fork on the consensus layer that happens and then at some point later ttd hits and then more changes occur or is it just you know you deploy your clients whenever as long as they're before ttd and it doesn't matter when before ttd like is there actually wire protocol changes that will cause clients to get disconnected from the network if they are not on bellatrix while their peers are on bellatrix yeah they all need to change with the fork and then they wait until ttd

number base fork basically that that would mean that okay

Tim Beiko: does that answer your question

Micah Zoltu: yes

Tim Beiko: okay there's one more question about robson in the chat basically uh in the days before we published your option ttd are we confident that enough of the nodes running on robson will switch your configurations to prevent the long-running proof-of-work fork um i think this is hard because it's like mining robsten is like not economically rational

in a way so like the people who mine it might keep minding it um i i do think we can probably get like infrastructure providers and like uh basically kind of all the the the like yeah large kind of tooling and and projects that people depend upon to like update so that like from an end user's perspective sending a transaction like your transaction ends up on the rops and proof of steak fork uh only you know even if it's only been like a few days but um i don't like i suspect we will have some people staying on the wrong side for robson

because like they missed the announcement i don't know i don't know how much more we can do for that than like how valuable it is like if you're just still running on your robson proof-of-work fork um because you didn't read the memo until two weeks later like how how bad that is basically um yeah i don't know do people have thoughts on that

Parithosh Jayanthi: i guess my main thought there is we have been saying for a while that robson will be deprecated and the only reason we're going through all of this effort to make

it nice is for the people who want to test the merge through it so if anyone's not interested in testing the mods and we don't have to really worry about them because it's a dedicated network from their perspective

Tim Beiko: yeah i think that makes sense um i guess how many nodes are actively involved it's hard to know from a node's perspective i think we can generally reach like most infrastructure and tooling providers quite easily on you know quite short notice um and especially like i think a lot of them are following robson now because of like the issues we saw yesterday so um i think it's it's

kind of clear to people that something is happening on robson but um the long tail of people is just pretty hard i i i don't know of a good way to do it beyond just having many announcements and that's also i think i guess the the cost of getting it wrong is quite low if you're just a random person running a node and at some point you realize you're off the wrong chain and you kind of do a google search and see that there was an upgrade on robsten yeah does that make sense okay cool um

okay anything else on like their robson sepolia beacon chains if not we also have uh gordy on the agenda but i i don't think that we've had any updates there i don't know afree did you have anything you wanted to cover about gordy specifically

Afri Schoedon: no i just wanted to say that it's fairly easy to come up with a total uh difficulty at a certain date because uh the total difficulty per block was fairly stable on girly and whenever we come up with a date it's fairly easy to come up with the numbers so i'm basically just waiting for for us

to come up with a date so we can do some nice pseudo palindromes

Tim Beiko: i love it um yeah and i saw you you've registered a bunch of validators as well uh i believe for gordy current gordy signers is that right

Afri Schoedon: yeah i'm prepared my girl is china to also validate prata so i'm on both sides of

the merch nice

Tim Beiko: um okay um anything else just on testnets generally if not um there was an

engine api pr uh that danny wanted to bring up but then he did not make the call i don't know if anyone else had contacts on this um basically adding the get payload bodies by range uh pr to the to the engine api and mikael i saw you you chimed in on this as well

Mikhail Kalinin: yeah i can quickly briefly just describe the idea of this reversal so yeah so there are two methods instead of just requesting payload bodies which is a list of transactions just by hashes

there is another one uh but bodies by range which which means that there are two parameters the third parameter and the number of payloads to which one is are requested from the el and el is it is optional for el client to support by wrench request and this wiring request is about to leverage the linear storages which are uh and make this kind of optimal queries over linear storages which is not the case for

bodies by hash and if yeah if if by range is not supported there is a error code um in this pr and the cl should fall back to uh by by hash which which is basically called bodies by root but yeah i'm calling it bodies by hash because there is no roots there is no root notion on the outside so that's basically the idea of this proposal

Marius van der Wijden: i'm just skimming through it why should we return like if if if the middling

block cache is missing and we don't have it why why should we return why should we not return anything or why why should we not return just nil but just cut it out i think my like my intuition would be if if you have a if you're requesting an and and blocks you're getting end responses and some of the responses might be no

Mikhail Kalinin: i think it's better to address why your comments

so let's have a discussion there yeah

Tim Beiko: okay so yeah if i guess if e alkyne teams want to chime in on this uh in the next couple weeks

that would be good

Łukasz Rozmej: uh this proposal is before the magical science or what's what's the timelines here and why is it needed

it's

Mikhail Kalinin: needed because uh cl clients would like to duplicate like basically remove bodies these bodies from el er execution payload bodies from their storages which will reduce significantly the disk space used and uh i'm not i don't think it should happen like right at the merge so it can be a soft work

i guess

Tim Beiko: does it require to be activated as a fork no like yeah i suspect

no

Potuz: but so i i would like to say something about this we we have this feature ready and we decided not to ship this release candidate with it because it may affect robson but if ruxin goes fine we're gonna we're gonna release it and start testing it live i think it's actually the other way around we would want this to be ready before the merge because otherwise it would mean a database migration for us for everyone so it would be much better for all of us to actually have this before the merge and then don't force our users to

migrate or resync their clients

Mikhail Kalinin: oh you mean so the schema will will be changed on your end

right

Potuz: yeah so the way this works is you just don't you don't save the bodies and then you just request the bodies from the execution layer if they ask you if they ask you for blocks

Tim Beiko: andrew

Andrew Ashikhmin: well i think if we require it before the merge then it will delay the merge because we haven't implemented it yet so i would do it after the merge

Marius van der Wijden: i agree

Mikhail Kalinin: yeah i agree um

by the way uh what do you use for uh this feature on the l side there is no mat this kind of methods implemented yet are you using the east get blocked by hash

Potuz: i believe so so raul is not here in this call he's the one that implemented it but i believe so i think he's calling block by block right so we do have this feature implemented today it is what it is under test right now so but then i i think i think the api itself is nice to have but it's not a mandatory type of thing yeah

Mikhail Kalinin: um yeah i'm not sure if it's gonna be safe to use this method because you will

have to yeah best blocks block by block i mean how much stress it will make on el clients if it won't work

this way

Micah Zoltu: so um similar to how we have version name for the uh peer-to-peer layer it feels like we're probably going to want conversion name for this um has that been for this uh the engine api since it is critical part of the infrastructure um has that been thought about or explored or already solved

Mikhail Kalinin: we we decided to have like conversions uh since there are there is there are not many methods in there we decided to have a version by method not like version the entire namespace and that's like what is stated in the spec currently so if you update the methods or semi-semantics or blocks or a structure structures data structure so you just like upgrade one method and add that version to the end

Micah Zoltu: and if there's a new method do you just

probe it and see if you get a method not found back

Mikhail Kalinin: yeah that's interesting yeah i was also a bit thinking about it how do we want to like say okay so this is shanghai this is the methods that we use for shanghai and the versions that we use for shanghai and this is like the next release how do we want to scope it out as well yeah that's a good point a good question to think about

Micah Zoltu: i feel like now that we're closing in on the merge we should probably uh put deep thought into like what that whole story looks like in terms of like how do we add methods how to remove methods how do we upgrade methods now like the upgrade methods part is kind of solved with method versioning but we still need to deal

with new methods and and deprecated methods between layers uh we don't have to do some this call but we should probably talk about that before the merge happens or at least before the first

uh version change

Tim Beiko: yeah yeah i think that that makes sense um and just to wrap up on this specific call i think it's pretty clear from el teams that we don't want to have this be requirements for the merge obviously especially if cls can um kind of hack this functionality by just calling every single block by hash um but yeah it would be good to just have

some comments on the specs so that um yeah the the general api makes sense but we're not planning to implement this before the merge does that make sense everyone okay um okay so the last thing i had on the merge front was uh basically following up on the difficulty bomb um so um i i've checked earlier this week and i think your average block times are like at 13.7 ish

um seconds uh there was an update like tj rush's chart posted a couple days ago which shows that like clearly you know there is some impact from the bomb it's still kind of quite mild um but uh obviously these things kind of get uh exponentially worse every about 100 000 blocks um and i think last yeah okay so there is like another prediction on this um on this thread uh which roughly targets that like around august is when we would hit 20 second blocks uh then in july we would probably like the second

half of july we would be around like 18-ish seconds and like the second half of june the first half of july would probably be around like 16 and a half second box um and then uh like very late august early september we'd be back to like 25 plus second blocks um i know there was like some conversation on the discord about this uh this week uh i know thomas you had a trend about this on twitter yesterday um but i'm curious to just hear from different kind teams generally like where do people stand regarding the bomb um yeah thomas you have your hand up so go for it

Tomasz Stańczak: yeah what ideally prepares to agree today if possible for the bomb delay by three or four months and just set the date when we introduce that to the

client

Tim Beiko: okay um anyone else have thoughts on this uh ben

Ben Edgington: uh i i don't want to advocate for moving the bomb because um i just want to keep the pressure up to get this thing done however if we are doing paris um early along with bellatrix that does give an opportunity without a separate hard fork to uh set back the bomb by a small amount

three to four months i think is is uh giving ourselves too much of an out i think we need to keep the pressure on but a couple of weeks at least take the heat off the block time on

um on mainnet got it uh andrew oh you're on your dendrew

Andrew Ashikhmin: oh sorry uh sorry i agree with this thomas i think we should delay the bomb by three or four months and uh just to do it and uh if the merge happens earlier than great because we shouldn't like put pressure for the sake of pressure we should

uh test it thoroughly it's a big change the some some pressure is good but not too much like yeah i i would say three three four months and uh it doesn't mean that the emergency is delayed by that much

amount

Tim Beiko: got it anyone else have thoughts

Péter Szilágyi: um i mean what isn't done yet for the merge

testnet deployment rollout has been bumpy um i mean

oxfam

Péter Szilágyi: was pretty clear that it's going to be a messy situation since it can be attacked in both ways but i guess that's kind of on us for not launching the beacon chain before setting the ttd

Tim Beiko: right i'm curious the other thing uh though that we had uh discussed uh beyond so like i know aragon mentioned that like the release they have for robson is an alpha but i think the other big thing that we wanted to look at was uh like hive test coverage i know mikael you've been spending a bunch of time on that

Mikhail Kalinin: yeah and myself and yeah mario

and yeah barry and marius are working on this coverage and i think we we have a pretty good progress on that and from that perspective i can't say that we will not be ready by uh by like uh before fork in the last test net so it's like i gotta say that it's like definitely a no-go or stopper like fantastic perspective i think we can do this and i would not uh like delay the bomb just because of what happened with robsten we're still planning to have an upgrade on june 8th as we planned before and i don't think it should be like anyhow linked to

or anyhow be reasoning behind like to leave the bomb i'm not saying that we should not like uh push push back the bomb sorry but yeah uh what happened with robson is not a reason for doing this as from my perspective

got it uh thomas yes

Tomasz Stańczak: always in favor of bombing in and actually i think it works and i always loved it and i felt that it was keeping us uh having to push the to be ready for the for the releases and may not always know how to push the release if it was uh starting to extend the block time so i think it's already hitting in

we know that it will be delaying the blocks it's actually some significant effect on the network i think the pressure is uh is there like i don't feel that generally at least talking about nethermine so i feel that there is enough pressure to keep the team going uh it feels like it's a bit too much pressure uh to like test all the destinations one after another uh get the feedback configurations proper re-testing with all the combinations sync times uh coordination of infra now um with robstan with tumor testnets with some additional education and just saying there's a stable version without touching it

i simply think that it will take uh time to do that properly and we already are in that place so if we delay bomb by three months uh it will keep the pressure at the level where it will keep the pressure to the most likely time when the main net will be merged and it's not affected by the robson at all so i was i was thinking of just three months delay for a long time that it's the most likely thing to happen it's just no i think it's a good time to raise it because it starts to be actually like late if we if we decide in two weeks and we say that then we add it to the clients in two or three weeks after decision because we need to prepare the releases

with dots then it will be four or five weeks from now when we would delay the bomb and you know it's also additional hassle to to prepare the release for the bump delay so we don't want to rush it now we don't want to do that every two weeks by two weeks like then we would have to do that every single

chord f call uh lucas okay just to have um um a

Łukasz Rozmej: comment maybe on peter that what peter said that's in my opinion a bit um what shows the readiness are hive tests

and this shows like unhappy paths instead of what we are mostly testing in shadow forks so yeah looking at hypestes every client has multiple tests failing and maybe we'll be able to

to fix those issues before before emerge but there it just just generates more pressure

Tim Beiko: anyone else have thoughts on this do do we have a time to wait at least

until we see upgrade on drops and how it goes eventually before we make this decision right like and i think you know one thing uh for sure is i would like us i don't think we can really make a decision today given there's like no eip there's no like actual proposal for people to review it does seem that like the people who who want to delay the bomb like a three four month delay is like what what seems to be like uh proposed um so just to put this in perspective it means that like

we're basically in june now um that like three months from now would be july august september so it's like on september 1st we'd be like in the same spot as we are today um um basically where like blocks are starting to slow but there's you know from an end user perspective it still doesn't make like a noticeable difference um so yeah we'd be like roughly at that stage in september um um and yeah i guess yeah this is like a bunch of conversation in the in the chat about uh about your your point around big blocks do you want to take like a few seconds to just kind of tell people about your concerns there

i

Potuz: i'm just worried that it's not something that we have been actively testing uh the consensus layer is very very sensitive to timing issues if we get large blocks that take long to execute would may would affect attestations would affect which nodes the way nodes are syncing nodes that are the get these blocks close to the fork would stop sinking for a little bit until the engine catches up if we see this situation with forks for example would make me very very worried at the time of the fork and i would want to test it so i actually suspect that not delaying the

bomb would actually delay the merge because we want to test this

Tim Beiko: so what i guess what i don't understand is why do you assume the blocks themselves would be bigger um basically are you assuming that like people would raise the gas limit or like why because like the bombs just means that blocks are more infrequent but it doesn't change

like the vlog yeah correct so this was in reply this was a

Potuz: reply of the bunch of people arguing that we should uh raise the gas limit at the same time to account for uh the blocks being later

Tim Beiko: right okay yeah yeah so basically that if if like people are unhappy because like say there's 20 second block times then they decide to like raise the gas

limit 50 because of uh they get like roughly the same throughput um then you get much bigger blocks right

Potuz: but it's yeah yeah so i think the timing difference by itself is if the blocks stay small enough and they just are delayed between the timing between themselves is not the same as the slot time that we have now this this is not an issue these are the very worst can affect like eat one voting but i think we've tested this already

Tim Beiko: okay got it um anyone else have just comments they wanted to make about this

okay uh maybe one more thing i'll pick on from the chat uh marius you mentioned that like you think it's actually too early to discuss the bomb pushback like and and that's like kind of the opposite of what thomas was saying so yeah do you want to elaborate on that a bit

Marius van der Wijden: uh not really no okay i think um uh there there have been a bunch of great arguments for doing it now and there have been a bunch of ones for not doing it now um [Music] i i really want to avoid us having to push back the bomb twice

i think that that is the the worst thing that we can do i think pushing back the bomb once already is really bad because we have to uh update all like we have to schedule another fork and it's not about the scheduling it's not about the um it's about the coordination of the of the of the community and i think we we might lose some people if we schedule another um delay

uh pushback i think it's like it's fine to do it on a technical merit but i'm not seeing a technical merit at the moment um and i think teams should really really strive to hit the timelines and um yeah it would be really good for you guys to for for us to hit the timelines that we set ourselves that's that's all i can say

Tim Beiko: um okay

so and then yeah there's another comment in the chat about like combining this with paris um realistically you know paris is only gonna happen after like the other test nets have happened uh maybe like roughly around the same time as sepolia um so like you know there's no world in which like this is less than like a month or a month and a half away which would be like i don't know mid july ish um which is uh somewhere between like 16 and 18 seconds block times if this chart is correct it gets very hard to predict uh once the

bomb actually goes in um but like for the people who like want to delay the bomb this does that like generally make sense as a timeline like where we make the decision about like including it with paris but there's if if we kind of do that it means we for sure will hit at least 16 probably 18 second block

times um thomas

Tomasz Stańczak: so i'm looking at the charts that was uh it was included as a block time prediction uh by tokeji from 24th of may that's attached to the discussion already today and i think we're planning now the merge for august

right this is the optimistic scenario that uh probably the biggest optimism optimists were talking about august and this chart is showing like 25 seconds towards the end of august right so is everyone uh happy with the with going towards 25 seconds

blocks

Andrew Ashikhmin: uh yeah i think that's the big problem because uh we are artificially reducing uh the the capacity of the network and it's a disservice to the users uh i was also thinking like maybe we can

combine the merge delay with something useful like because this this idea was surfaced that we said the the ttd for the main act to something artificially large and maybe we can do that alongside uh delaying the bomb so it's kind of not our final merge release or some semi-final and the the merge itself is not happening yet but we are doing something useful for the merge along with

right yeah

Tim Beiko: and that's kind of what i was suggesting and i think if if we were to do that we would still hit at least 16 if not like likely 18ish second blocks by the time that happens

um so it's not like uh it's not uh 25 seconds obviously but um yeah it it does mean that like we we do hit

longer block times

Andrew Ashikhmin: which is already bad enough like like we should try to improve the capacity rather than

hurting thomas do you think that we definitely want

Tomasz Stańczak: to push the merge at the time when the network is stable predictable where people think that okay if the merge changes by one or two days that we don't have to rush it when people will not be

in the last week taking crash decisions because if they miss it then suddenly it's 30 or 45 seconds and it's already that causing uh turmoil with what miners do so if at the same time as we introduce merge miners keep voting the changes on the block sizes and the block times change it's just a lot of additional um additional variables to take into account when calculating when filling how how we plan so i simply want to operate in the conditions where network is very predictable and there's no additional pressure from different sources about like how we should act

Tim Beiko: right

uh okay and marius i think you had like

another comment um yeah i

Marius van der Wijden: i i don't i don't think 20 second block times are bad and uh in amsterdam we we kind of made that like had the overall view that at degradated user experience for two months is worth it if we can ship the merch faster um yeah i think we're looking at like um i don't know five seven

ten years um of of like things and so i don't i don't see the point in focusing on on two months of of like slightly higher block times

Ansgar Dietrichs: um yeah i was just curious if someone could put like a specific number of like a days or something on the delay that in like an additional fog for difficulty from delay um what mean because i mean i know mario said earlier that like having i think it's marius having more than one delay would be the worst case um i'm just wondering why why that would be the case why can't we just have a really

small delay and then potentially have another one later if it's unless it's like a big big extra uh that's

well yeah go ahead andrew

Andrew Ashikhmin: i think well i think like small delay the problem is that uh we don't want to delay it too often like delaying it by two weeks then we decide oh no two weeks is not enough then delayed for by two weeks again and then so on that that's kind of wasteful uh and to uh tomorrow's uh point uh i disagree i think well like our priority should be serving the users

of the network uh and the knowledge is on their means to that end and to my to my mind if like what's the downside of delay in the military if we keep paying the miners it's not a big deal it's much much better than hurting the users in my

opinion

Tim Beiko: thomas

Tomasz Stańczak: one thing that i wouldn't agree with is operating under assumption that not not delaying the bomb speeds up to delivery uh so i i just see all the engineers working at at the limits now so you know it starts starting productivity so

i don't i don't think delaying the pump is actually spinning sorry not delaying the pump speeding things up that that people magically generate additional firepower to to hit those times

Tim Beiko: uh peter

Péter Szilágyi: okay i i think we're kind of debating two fairly far out uh extremes one of the ones not delaying at all the bomb the other is playing it by three to four months which some people find excessive uh would the middle ground work for example what would happen if we were to delay the difficulty bomb by say two months

that would maybe relieve the pressure of getting to 20 second block times and we would not have to bear the burn from the community that ethereum is too expensive to use yet we wouldn't just lose the [Music] the timeline completely so is there a specific reason why we would like to push it by four months instead of just giving we're just pushing it by little to leave breathing obviously two weeks is pointless but let's say i

know one two months that's

Andrew Ashikhmin: it sounds well to my mind two months is

is reasonable two months is kind of a good enough time that to help us go through the testing um thoroughly and like improve improve the quality yeah so i i would be happy with two months

Tomasz Stańczak: my suggestion for free for months my suggestion of three four months was based on the calculations based on the fork schedule and assumptions of around uh two months of the of operating with the frozen code with preparation for mainnet and communication with the with the community about like the

details and confirming like what's the adoption adoption percentage of all the new clients on both sides and so on and so on um but don't take it as a like something that i say either three months or nothing um it's definitely just a suggestion that i believe that three or four months is the most likely effective uh delay but yeah i'm open to support any solution that will make us start preparing the eip and start preparing releases with the bomb move how exactly what what's the exact number of blocks that you move it by and this can be decided in the very last

moment so i just don't want to not start

preparing yeah i i

Tim Beiko: think that that makes sense i guess based on this my like my rough feeling is that if we were to delay it like two ish months delay that's maybe coupled with paris uh in order to uh like minimize the amount of client releases that go out um so it means you know this delay would happen like at the towards the end of the test nets but give us like some breathing room between the last test

nets um uh um sorry tim yeah what what what is paris so uh basically if we do put out a

Tim Beiko: release of yeah if we

put out a release of uh the consensus or the execution layer clients uh that is um where we have like a really high ttd uh at around the same time as we uh plan uh kind of the not the shanghai sorry the sepolia uh fork um so that we can hit bellatrix on mainnet before uh that's maybe like the right time to also have a bomb delay uh when we're releasing something that's like basically we hope to be stable for mainnet but uh we also uh need to run through bellatrix before so you can just have a hard fork with the bomb at the same time um yeah that's kind of what i meant

Péter Szilágyi: but i'm not really following what so setting the ttd on mainnet doesn't make it the hard work so as long as that tv doesn't hit it's just completely relevant whether it's set or not

yes correct yeah yeah so we set it up yeah that's right go ahead we need it for the exec for the consensus layer and correct that's what it does yeah so it's like so this yes yes yeah we needed

Tim Beiko: we discussed this like the first half of the call but i think the idea is like we need to put out a release uh or we would like to put out a release uh which activates the bellatrix forks on the consensus layer on mainnet roughly

around the same time um as we have the release for test nets like the fork doesn't activate at the same time but it's ideally the same software um at that time it would be good if there are cl or sorry el client releases which also have the merge changes that are ready even though they're not activated and so what i was proposing is that the same kind of release also contains like a bomb push back with a hard fork in parallel basically

Péter Szilágyi: um yeah but what does why does it make this paris or

okay it's just because

Tim Beiko: yeah because the the cls need to know uh they need to be able to query a

version of the el client which like knows that the engine api exists and so that's what i'm calling paris yeah

Andrew Ashikhmin: and it also may contain this fork next value for uh we can actually set it to something realistic for the merge as that means to and that will actually be part of the or like you can think of it as a

hot fork so no actually you can't do that because if we hit that before the ttv triggers and all may not fall apart yes so

Tim Beiko: we're we're already over time um i do think like obviously we're not going to make a

decision about this today um i think someone who feels strongly about delaying the bomb should try and draft together an eip that we can maybe discuss on the next call a bit more um yeah and uh i'm happy to like help put you in touch with previous bomb delay eip authors if if someone wants to wants to draft this um and i think in parallel it's just worth thinking about like what the activation of of that would look like um you know what are the right parts in the process to couple it with but clearly we're not going to resolve this in like a minute and a half on this call

Micah Zoltu: real quick clarification question when

you say two months two months from what two months from the time we released this patch or two months from today or two months from the plans

made in the ttd you want to swerve some blocks yeah adding that two months worth of blocks around 400 000 blocks on to the uh ttd calculator two months from the original bone yes timer

Tim Beiko: so two months that means that like two months from now so now we're say we're calling for june so that means that in july at the beginning of august you start having like 13.7 ish block times rather than having them right now

um yeah so if you if you write the eip it's like a pretty simple eip to write you literally take the number that's in the last eip and you add two months worth of blocks at like a 13 second average to it okay we're already five minutes over but i said we would stay five minutes over in the chat for the two people who had eip updates so if you all can bear with me another five minutes i think we can cover those and uh hopefully have like a specific bomb vip to discuss on on the next call um george you had an update on 4844 with some optimizations for the transaction

pool

George Kadianakis: hey tim so i feel a bit weird doing this like sharding um discussion after this very important like merge thing but anyway since i'm supposed to talk about the eip um i'll give like a very short update uh the idea is that we want to do proto-dunk charting at some point after the merge happens um we are gonna introduce blobs into transactions with proto-dunk sharding uh we got reports by peter i think in amsterdam that the current approach of like

verifying the blobs and the commitments in the transactions is pretty slow in terms of like you know when you get a transaction on the mempo um it it's pretty slow to verify and this might cause problems like tos and stuff so um we wrote a pr which makes this process of verifying uh proto-dunk shouting transactions extremely much faster by introducing kcg proofs because before like we were using kcgs just for building commitments for the roll-ups and stuff we were not using kcg proofs anywhere in it so by using cage proofs we're able to like verify transactions

much much faster like from 40 milliseconds per transaction to like 2.5 milliseconds and the same for blobs um i'm not going to go into the math of how this works i i try to write a pretty comprehensive how-to on the pr um that requires a bit of knowledge about kcgs but not too much and yeah this is like the summary uh let me know if you have questions and maybe we can discuss it in the next acd i don't want to take more of your time

sorry i was muted on youtube okay so i

just said i'm gonna post a link to the pr chat in case people want to give feedback on on it um and then last thing uh we have peter who's been looking into eip 3537 2537 which is uh this bls precompile eip that uh has long been kind of uh pending um and and he was also interested in trying to revive that and look at what the current status is i'm peter you wanna give us a quick update

yeah thank you tim yeah uh because we're over time it'll be as quick as possible and uh uh quite kind of concise so like as kim says eip2537 enables uh a pairing operations

in the new uh pre-compiles it's just a quick reminder that we are only one step away from the activation of this wonderful eip so this you know activating this ip could unlock you know a lot of new use cases on top of ethereum ecosystem so the summary is that the implementation of eip 2537 is actually completed it's in the code base right now it's actually only depending activation of this you know functionality and it's not really that hard and uh the activation of this functionality uh actually just uh enabled the pre-compiles by uh editing the core uh slash uh vm slash contracts dot go file so just to

enable this just like what we have done for the byzantine istanbul or berlin and although maybe there's another point to mention but there could exist another you know uh implementation that is you know slightly more performant uh regarding to gas consumption and running time compared to this existing implementation but you know as this work has been you know already done merged into the uh code base uh i believe that you know we activate this bls existing uh 2537 implementation will be the best uh it's just a reminder and to revive this uh thread to the community thanks

yeah thanks is it is it only implemented in uh go ethereum or is it also another mine basu and aragon

Kelly Olson: i know it's in at least uh i believe nethermind and one other have implemented it um i also know that marius is starting some fuzzing work on uh that set of precompiles and geth versus blast and then also you know basically the everything that these two clients are using so there i think there is still some active work going on uh with regards to security for uh the pre-compiles and on the performance i do think it there is about a 2x performance gain with the other library so obviously still a decision to be made about whether that's that's

where it changes

so we've been fuzzing the killig implementation against uh gnark um consensus gnark for a half a year now and i'm currently adding blst to that fuzzing thing and it's on oss first so it should be pretty good

Kelly Olson: fantastic yeah and blsd has been fuzzed against um relic and um some big numb libraries as well uh in oss funds for about a year as well

Tim Beiko: okay um cool yeah given we're 10 minutes over i think we can wrap up here um thanks a lot everybody and uh yeah talk to you all next week on the consensus stair call and then two weeks from now uh on this call uh and don't forget to upgrade uh your robson nodes in the next few days um yeah thanks

everyone bye [Music] so

[Music] [Music] [Music] so

[Music] [Applause] [Music] you

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