All Core Devs - Consensus #105

Transcript

thank you [Music] [Applause] foreign

Alex Stokes: I'll be taking over for day today this is consensus layer call 105. um digender doesn't look too packed which is good um let's see there's one in the chats for people on the call it's issue 747 on the PM repo so let's see here what have we got today I think I'll go a little out of order here uh and first let's talk about client releases uh the first thing is that we have I can do the specs release the latest one here is version one three zero rc5

Lionel and I think the main thing this does is that the actual compelling for Epoch that we've agreed to for mainnet and ah there's some stuff for the nap and we'll get to that in a bit um yeah do any of the client teams want to go around and just uh speak to the Readiness I think some people have releases maybe everyone has releases out now

Terence Tsao: prism will release early next week that's the plan

Alex Stokes: great thank you can be done uh in a few hours

um certainly by tomorrow never mind we'll release today uh gas

Marius van der Wijden: has released yesterday or the day before

yesterday early next week

for Lone Star

Sean Anderson: uh so we released for Lighthouse but we're releasing a hot fix for that release tomorrow I think

Alex Stokes: okay great so I think that was I went on a call I can't see the fullest but um yeah so people either have released or they will in the next couple days it sounds like so if you're listening be aware you know follow the usual distribution channels and uh update your notes

Tim Beiko: yeah we should have the blog posts we should have the blog post up hopefully Tuesday ish Wednesday at the latest for people listening

Alex Stokes: okay great and that gives us a bit more than two weeks something like that so it should be plenty of time and uh everyone keep an eye out for the blog post and yeah nice work everyone so that's it for I mean that might be it for capella is there anything else anyone wants to discuss about capella at the moment uh then we'll move on to 444 and up stuff

Parithosh Jayanthi: uh just one thing we started singing some me net nodes and once all the

releases are done we'd have them in a shadow folk and I guess that would be the last um attempt at the transition publicly before we hit it on main

menu

Alex Stokes: okay great thanks Perry um so one more minute Shadow Fork uh with the final releases that'll be nice just to you know give us one more go at things um not expecting any issues but that'll be good to confirm and yeah any other capella things while we're here

Tim Beiko: Frederick do you want to mention the bug bounty

yeah

yeah sure sorry can you hear me now

Tim Beiko: yes

Alex Stokes: yep we can hear you okay

okay cool yeah sorry I was unmuted yeah so the uh the Dog Bounty for um uh specific issues which has been increased by 2x so there's a 2X multiplier for any vulnerabilities that affects the uh chappella code paths so yeah go ahead and start looking for more vulnerabilities um as the max Bounty payout for Sao Paulo specific issues is now up to half million dollars

Tim Beiko: is there a tweet about this that we can

share

I'm still waiting for the um I don't think the banner has gone live yet no it hasn't so the the banner will be updated on bounty.itarian.org soon and then I will make a post about it or a tweet about it

Alex Stokes: okay great yeah that's exciting and uh anyone listening get to bug hunting uh so Terence thank you for bringing up

the med boost Community call I'll just plug this while we're here uh the main thing will be to discuss capella Readiness uh for Memphis operators relays Builders you know that that whole cast and crew uh the next call for this will be March 30th uh at 16 UTC 1600 UTC so 4 pm and um yeah maybe I'll just toss this link in here let me grab that and yeah please attend if you can uh especially if you're listening and you operate a relay Builder or something like this okay I think we can move on to genev now

uh there's not too much on the agenda the one thing is this PR and actually shouldn't apis 392. uh is G11 Tech on the call

Gajinder Singh: yep hi

Alex Stokes: do you want to give us a little summary about this so it looks like we want to at least I suggest adding proofs to the skip Bob's engine API

Gajinder Singh: right so uh with basically Bob's now decoupled the network wrapper uh for the blob transaction for El has uh will now also include blobs and there is a PR for that on eip6610

so now since the El has the proofs it can just uh pass on the proofs to the CL uh using get blobs bundle and cl just needs to verify to batch verify whether the kcg is blobs and proofs they all match and basically then the block production can follow the normal

path

Alex Stokes: okay so this is just saying because we now have the proofs you know available with the ER we can just pass it on to the engine API to the CL and do the

verification there at a high level that sounds reasonable um has anyone else had a chance to look at this PR I haven't been able to look at depth yet does anyone have the wrong number on like um our loan does the compute proof take I I guess this is mainly for optimization yeah I mean something like 14 milliseconds or so but if I'm looking at this correctly this is work that would already need to

be done right this is just kind of moving around where it happens so it's not that we're adding extra latency or something like that

Marius van der Wijden: no the work doesn't need to be done because the proofs are already in the transactions right so producing building a blob Now does not require Computing any proofs right

Gajinder Singh: so proofs are already in the transaction uh so El just needs those needs to pass it along and with respect to CL uh basically it's uh it is sort of a very keen thing that CL only needs to verify whatever it gets from from El and not really generate any proofs or commitments on its own

Alex Stokes: okay yeah again make sense a high level um everyone please take a look and uh yeah take an interview to the pr uh Mario set of questions on chat to discuss kcg Library startup times so I guess some of them might be slow uh Mario do you want to say more

Marius van der Wijden: yes so something that Mario discovered during uh testing for 4844 is that now every test execution um on the 444 Branch takes a couple of seconds and this is because of the startup time of the the evm binary which has to initialize the the kcg library and

um I think he said that uh this is going to be fixed by the kcg library that is used in 4844 at the moment um but it's this is something crazy I think it's kcg I'm not sure

Alex Stokes: okay

Marius van der Wijden: and uh yeah so but this is something that we we should really discuss like I I know that in order to load the data they have to be like in order to

initialize the library that has has to be a bunch of a bunch of curve operations right in order to uncompress the points and uh yeah I'm I'm not sure how long that should take but just I want to remind the the writers of the kcg libraries that we will have to pay this initialization costs for every test basically and for everything so it makes sense to optimize it even if it is in the normal node it is only done once but during tests it's done over and over again

Dankrad Feist: so I believe there are two things that

happen actually on Startup one is the uncompressing but I think the long time that takes several seconds is because we currently transform to LaGrange form by unstarted and actually both of these could be changed in principle like and we could store the whole setup in LaGrange form and compressed and then like it should literally just be reading it from this so um I think that could be changed it could take milliseconds

Marius van der Wijden: yeah that would be really good

Alex Stokes: okay yeah that sounds good uh we can

talk to the ckg maintainers and anyone else working on those libraries so look at that and yeah if it improves startup time so then sounds like we'll get around that issue so I think that's all we had on the agenda today for dinab uh anything else on anyone's mind

I mean the SSC stuff is still kind of ongoing um question is if we want to move some parts of it into the net like the the withdrawals Port is um signature scheme for the SSE transactions

right

Alex Stokes: so I believe there was a 44 breakout on Monday uh maybe someone here attended and could give a little summary I believe this was discussed there at least briefly

this

Tim Beiko: short uh I think the the decision we made is just to wait until all cordevs makes a decision so we like it seems like there's a lot of stuff to like discuss around SSD um and in the meantime we're just gonna keep the spec as is and if there are changes that happens we'll obviously retrofit 4844 to support um to support data you know before compatible with whatever uh design we'd like to uh

to go forward with but um yeah I we didn't we didn't specifically uh come up to a solution on that or anything it's not clear what yeah I think that makes yeah and it's not clear like how much time clients have had to like properly dig into SSD given like uh we're shipping uh Chappelle right now so yeah it seems like there needs to be more conversation and and kind of I guess diligence that on it by different client teams

Alex Stokes: yeah I think that makes a lot of sense I know it's a pretty big change especially like the long tail of everything we could try to do in terms of converting

these different accumulators and Things Different serializations uh and yeah at that point it becomes like much bigger than just changing a few routes um but yeah I think that makes sense just to keep 444 as it is now and um yeah definitely something we could change down the line if uh if needed and I suppose that's on the acde process to uh to resolve that

yeah I think so yeah

Alex Stokes: okay thanks for calling it out Eton uh anything else for the net that anyone wants to discuss right now I'll take that as a no

so the only other thing we really have on the agenda is just sort of moving down to uh either different research questions discussions open discussions uh one thing that was called out was the name for the upgrade after janab there's an eighth magician's post here brainstorming e names uh anyone have a favorite here they want to chime in let's see looks like some leading ones are Electra enef we got an Electro in the chat either way more lectures okay everyone seems like Electro

yeah so I think uh these magicians post is the place to chime in if you want to participate in that conversation uh definitely also anyone listening in the community uh take a look if you if you want to be part of the naming process and yeah although I can just sit here looking at the chat there's a very broad support for Elektra oh yeah and then we'll need some you know Fusion name and calls out prolextra which is pretty funny um yeah um I think that's probably that didn't really didn't seem to be too much discussion

if we don't have anything

yeah

Alex Stokes: I think it's pretty much open discussion now

Marius van der Wijden: I would really like to drop the El name uh and I think the combined names are kind of horrible I know that some people don't like this because of the possibility of a hard Fork happening on one but not the other layer um but I think we can we can kind of burn the Brit this bridge if we get there so yeah I would really like to drop the names just because it makes everything

so confusing and it also confuses the it makes it not only confusing for us but it also makes it confusing for the community because they now have to they they see basically they see three names right they see Shanghai they see and they have to understand that all of these three names are the same thing and also I would say that dropping one would want to concluded only having a fork on one side and just give it one name could you repeat that

Alex Stokes: you kind of

dropped off that didn't quite come through your concern was that people don't like this because we might have a fork on just one side but you can still do that and just have one name

Tim Beiko: right now this is the name looking at the the name tells you whether it's one side or two side but arguably that's a small benefit

Alex Stokes: yeah the way I see it is like having the greater resolution is good for you know people who are working on clients things like this where it's like having that extra tentacles for Resolutions really helpful at least it can be um but yeah I agree with what people are

saying that like it is really confusing uh sometimes I'll even get tongue-tied talking about them and like say something you know some weird other name trying to refer to you know one and a half at a time yeah I mean I don't think it would be crazy to just move to one name is yeah go ahead

Pooja Ranjan: I think this is a good opportunity for uh like eating drama developers to kind of educate ethereum Community to learn all about ethereum like till day there are people who thinks that it is it too and I have read articles and like reputed uh news uh websites saying that

ethereum has moved it's a consensus to each two it's now each two so if we are having this two layer concept we are trying to educate them in terms of suggesting that ethereum works in on two layers and these are the changes the people interested in learning more about execution layer they should follow the execution repository and learn more about that and definitely execution development team has their name so I kind of support these two names it's just that we need to start talking about it early on like we did it for dinner I don't think Dana will have that kind of problem that Shanghai and chapela had similarly um yeah that's my thought

yeah

Alex Stokes: okay thanks

um yeah I mean just you know to be respectful of everyone's time I don't think we're gonna solve this right now on this call uh maybe at Ryan said is magician's post or something if you feel strongly and we can move the conversation there you know I think we'd also probably want to bring the stalk or doves and uh get the get that take

sorry what was that it was a little purple uh sorry sorry I haven't heard of myself Tim what's the one combined name why

Tim Beiko: it's so much more fun it's less a

better SEO as well you know how many hits do you get for chappella outside of ethereum versus Prague I like it yeah not a hill I will die on but yeah if if the concern is technical like if the concern is actually like we should just tell the community one thing and we should only understand one name I'd much rather it's like a fun new name than like prag um we can find some random Stars nobody's heard about but yeah ideally two or three syllables

Alex Stokes: uh anyways

so I think yeah I think if you care about this anyone listening you should uh someone should make an easy conditions post and we can make the conversation there otherwise we'll just talk in circles about uh bike shedding names for the next hour and that being said uh anything else anyone has I think otherwise we could just call an early call today I'll take the silence as no so yeah thanks everyone

um and yeah I think the main thing if you're listening is just look out for the client release blog post something like two weeks from now um I think that was right and all right was that one week yeah sorry more like one week from now uh that's important to go right so keep it keep an eyes on the blog and yeah otherwise thanks everyone and I'll talk to you all later thanks for hosting thank you

thank you thank you thanks Alex bye Jesus

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