All Core Devs - Consensus #132

Transcript

[Music] for okay I'm me just double

check

Alex Stokes: everything's working okay it looks like the screen transition also Alex your audio is quite bad right now there we go okay but it's only like part of the window I don't know Tim do you see what's going on and do you know how I can fix

this

Tim Beiko: so sorry what do you see

Alex Stokes: so it's like only recording like the upper quarter of the zoom window and not the whole

Tim Beiko: yeah so like um if let me open it the so when you have like a screen there there usually like a little red box that you can drag and drop to make like to make it bigger if you if you like hover over

e e

Alex Stokes: um okay this is kind of good everyone sorry for the technical difficulties I'm streaming and any let's go and get started yeah F to restarts I think I'm going to leave it as is because I've also just had a really delicate so hey everyone this is consensus call 132 I need to find the agenda what I keep losing I promise kick things off okay let's go ahead and get started it's

really hard to hear me okay can you hear me now can you hear me now uh yeah okay is it better now try this okay I on out okay may we'll try this is a

spider can you hear me now can't any okay is this better yes I don't know why I've is shoes okay can you hear now is this is this better than it was entire quality just a lot more quiet I don't know I'm like yelling at my

computer um okay let's go ahead and get started I think this might just uh magically resolve this is what I can so anyway okay Electra so uh the first thing to call out is we have nice specs release um of the initial Petr specs very exciting it's so quiet okay I don't know why I'm having his issues

Tim Beiko: it's fine now

Alex Stokes: you're the only one saying that though everyone else is saying they

can't hear anything

Barnabas Busa: yeah it's very very quiet for me too

Alex Stokes: let me try I oh I feel like this is going to explode if I try to it's something happens with my audio setup I don't know I don't know what's

going on anyway let's go and get started um I'm assuming you guys can all hear me now and I'm praying that the stream is working either way uh the first thing was Electra and so let's see here we have the initial specs release which is very exciting um I don't have a link handy but I can go get one in a second but yeah so Alpha zero is out and the idea is this is an initial Target for DEET zero so thanks to everyone who was involved getting that out uh special shout out to sh and Franchesco with help with the testing but yeah it has the four eips that we've included in pectra

and should be a stable Target for you guys to go ahead and start implementing so so yeah super exciting uh I did want to call out there's this question of how we're doing consolidations in Max evb and it looks like what we're probably going to do is have them in be initiated from the El and right now the way they're kind of written is they're originated from the CL this is fine because most of the processing logic that the beacon chain will need is going to be the same regardless of the source uh but if you drill into the specs you'll see there's not really anything written down around how a like validator could initiate them um I think the plan is generally for our

initial Dev Nets just to kind of have someone hack something together just locally to inject some operations to do this but otherwise not worry too much about building out like an operation pool gossa for these operations and all that um because we're very likely in devet like 123 uh moving to like an execution source for them just like 70002 so I just wanted to call it out uh if you find that part confusing it's because it's a little weird right now so otherwise yeah let's see the spec is out there's test vectors and yeah so nice work everyone

next up uh there's a number of

questions around different eips different parts of the spec um we'll just move on to the next one so there this question of how to handle denb attestations at the electro Fork boundary so EIP 7549 this is the one that's like changing how attestations work and we'll get in the situation where the last Epoch of denev will the decisions made in that Epoch will be includable according to the spec into Electra but the way that you make the MB is not compatible with how you make them in Electra so we need some way to handle this um and I wanted to bring it up just

to see what everyone's thinking there's a couple options or maybe I'll just stop there does everyone understand the problem okay we got a thumbs up if you don't it'll probably become clear as we discuss but there's a couple things we could do like one of them is just do nothing on Main net most people get attestations in pretty quickly and so like you know if we're at Max performance then really it's just like attestations in the very last slot of denev would have this issue and that's not ideal but it does mean that the specs can stay as they are

and it simplifies everything else because then we get into the other options where we do something to handle these attestations probably like the most comprehensive solution is that we just keep another spot in the block for all of Electra for uh the sort of the JB style attestations um we could do this it's just now there's this extra list that's kind of there for like just a few slots so yeah it's just more code to maintain and the questions like what do we really gain for it um yeah there's other Solutions like you could imagine clients try to broadcast both or or like you wait if you know that you're at the end of DB and like if

you don't see your ad station get on chain uh well I mean yeah then I guess it's a question of how you do this because you could imagine trying to broadcast if you don't see it included on chain then you rebroadcast but then there's like slashing concerns you could just wait uh maybe say halfway into the epoch there's like some design space here has anyone here looked at this and do you have any opinions on the path forward

Mikhail Kalinin: just a quick note note if uh if we don't like if we use the same field of the same station field in the block that we need to understand that Max stations per block is going to be reduced significantly so those arations are not

uh uh packed into more tight Aggregates that we use for with the CIP since Electra then they will probably not be accommodated um there will be not enough BL capacity for for that so it's probably it probably makes sense for the last uh if we want to do anything with that it probably makes sense for the last slot of uh the last slot of the epoch uh before electr for Epoch just to make them signed um yeah just to make this you

know index set it to zero so make an Electra like like Electro Station instead of the station I don't know how what other implications are having this

you're

Enrico Del Fante: talking about the option um suggested by that lion to uh wait a couple of V be before um setting everything to zero is it this what you're talking about

Mikhail Kalinin: uh no if yeah if if we take this option we

should understand that if we don't aggregate them so we have like basically we'll have eight attestations instead of20 per block at Max so we probably won't be able to and put 64 stations from the previous

Enrico Del Fante: yeah that's hav yeah I haven't thought about that implication of doing that so does it won't work at the end for other reasons right

Alex Stokes: okay so one option would be you have custom code your client to

basically say within the last slot but maybe the last like half EAC like there's some parameter here basically you would set the committee index to zero and the reason you do this is because then you can you know independent of having the validator touch anything who makes who makes the attestation you can repackage the old format into the new format so that works um you know there's implications around I think some of the Dos protections for attestations uh because they assume the committee index is you know a certain thing but might be fine

Mikhail Kalinin: um yeah so are we concerned that much if we

just lose the last

Alex Stokes: I think not but the question is like more about attack scenarios so like you know let's see yeah I guess if if you just ignore them I mean yes this is like the do nothing approach and it might be fine enough um so that might be the path forward right now is you know the way the specs are written it kind of assumes that this is just yeah you you ignore the ones that don't make it in a time and if we do this then that might be fine and then we can kind of analyze you know different attack scenarios further down the line and and see if we need to harden this but that sounds like a good path forward for now does anyone

Mikhail Kalinin: yeah

because yeah because if you those are stations will be applied to the PO CH anyway so which not be a b problem

the

Alex Stokes: the one concern would be if there are many like if there is an attacker who tries to delay for some reason then they wouldn't go on chain and that could impact justification so there could be some like weird finality delay around the fork if someone is really motivated

Terence Tsao: it's also Worth to keep in mind that those attacks are highly attributable a way so like we can easily tell that who like basically who's doing that I'm not saying that should be the reason to not to do it but that that's just one point of note

right

Alex Stokes: okay well it sounds like I mean especially for de zero we'll just keep it as is which is basically ignore the issue

Sean Anderson: yeah um so I saw de line had left the comment here I don't know if this is what enri was referring to but to me this looks like essentially like a slightly better version of doing nothing because it's not like we couldn't fit any pre- Electra ad stations in we would be able to fit up to like whatever the new limit is

Mikhail Kalinin: the limit is quite low though so

Sean Anderson: right

Mikhail Kalinin: in the best case you you you can yeah you can upate like seven attestations per block consider perfect

aggregation and just use just one one slot for the station current

toate the station

Sean Anderson: so but like isn't this just very similar to doing nothing but like slightly better

Enrico Del Fante: but then you have to deal with the complexity of doing this um translation in the code to gain maybe very few arguments in terms of security so it's maybe slly better but less less effective in any case so maybe

you

Mikhail Kalinin: actually if things will will be good

terms pation so these uh the first Epoch of Electra will accommodate all those stations from the last slot there will be enough capacity to do that

Alex Stokes: okay so let's do nothing for now and we'll just keep in mind that we'll probably want to look at this a little bit more closely and consider different options um but yeah this seems like a good path forward and generally just have this onone radar if you weren't following please go take a look um and yeah we'll we'll revisit it later

so the next one is a new EIP 8432 and the CIP essentially wants to think about how we are moving messages from the El to the CL so right now with 6110 we have deposits with 70002 we have withdrawals we're likely adding this sort of consolidation message from the e so we have all these things proliferating and the questions like how we want to structure this uh in the execution layer so this CIP is from live client do you want to uh maybe give a little overview

Lightclient: sure um basically the idea is

that on the execution layer we have generally not added lots of things to our block body and you know kind of our block header but with with these new messages that we're trying to propagate from the El back to the CL the sort of template has been put it put a commitment of all of those operations in the header put a list of them in the body and extend those data types and so what this proposal is trying to do is simplify the way that we do that so that we don't have to continually extend these data structures which at least it feels on the El side is pretty manual

task of updating min mini code sites where you're dealing with these and put it all into a single type so we're reusing the same Machinery that we have for the transaction types which is prepending prepending a single type bite in front of the rlp encoding of the transaction use that as a discriminator to figure out what type of transaction you're dealing with and then parse out the transaction data from that it really doesn't have a lot to do with how things are processed on the CL I think it would just be good to get thumbs up from any El teams here it seems like it's had reasonable reception uh and then get a thumbs up from cl's

that it's okay it's okay on your side that maybe these data structures aren't mapped one to one CU like right now on the spec for Petra on CL side these messages are individual lists with an execution payload so if you wanted to have things analogous across the two layers on the CL maybe what you would have is you would have a union of requests and you would put every individual request type that to me doesn't it's not really important it's whatever you guys think is is the best way of doing it uh yeah so I guess I can stop there any questions or thoughts if that's seems like a reasonable idea

Alex Stokes: so I think we would want want to

try to keep the layout the same across El and cl as much as we could and so really like I generally think this is a nice idea the only thing is you know if we need to go change a lot of the structure of the vzer specs it's uh G to kind of delay us getting to the

death net

Lightclient: I just don't want to put a lot of work into something that we already feel confident that we're going to change again like we can have the specs ready by tomorrow we just have to have people decide and I think this is still this is much more of a CL or sorry an e issue to resolve

I think

Justin Florentine: um this is Justin here

from Basu I think that we recognize the need for this it seems sensible the implementation looks good I haven't had it open next to the code to actually take a look at the implementation overhead yet my gut says it's fine um but I would like to have a chance to actually do that before making a stronger

commitments

Lightclient: do you guys have 6110 or 70002 implemented

Justin Florentine: we do have 6110 implemented and 70002 is about half done

Lightclient: okay so I think the main diff between what is done right now and what would need to be done is you would have to go in and replace the uh exits or um or sorry the deposits that you've added

to the header and the body replace it with the requests type and then implement the request type so the rework that would be done is kind of just renaming and retyping that value in the header the reason I'm like bringing this up trying to bring this up now is that if we add 70002 if we add consolidations then we're starting to look at like bigger refactorings of okay we've added three things to the block head or three things to the block body we got to go and delete some of those we got to put you know retool them into this single type so it feels like if we've only implemented 6110 it's a lot faster to fix that up than down the line

Justin Florentine: yeah fixing 6110 from our current implementation would be negligible there's no big deal

there

Lightclient: I don't want to put you guys on the spot like you can take a look at it offline I just want to try and get this decided by tomorrow so that we can get the specs out

Mark Mackey: yeah all right we can chime in a s in terms of wasted work it seems like especially if we end up adopting this the long term because it saves a lot of long-term complexity it doesn't make sense to not adopt it in the near term to save I guess part of an initial

devet implementation yeah Terence Terence

Terence Tsao: um do we need to come to

consensus on what this request type are inside the payload or they are outside the payload by kind of like a kind of like a envelope format um do you guys have thoughts on which direction is here

Lightclient: it feels like it would go in the payload but it's not really something that I feel strongly about so if people think it needs to go in the envelope because you're not going to put it in the actual payload type on the CL then we can do that like this the zip allows the flexibility it doesn't prescribe that it must go in the execution

payload okay um sounds like people will review this offline generally positive sentiment the one question that I think is pertinent to to maybe ask here is are there thoughts on how you would like to deal with this from the engine apx I also want to cut this spec tomorrow or Monday and on the engine API side there's two ways that we could go about it I wrote it in the PM issue if you want to take a look but the two ways are basically we extend the execution payload or the envelope whichever one people prefer with each individual request type so there would be a deposits list there would be an exits partial withdrawals list a consolidations list those are individual

elements element and those individual elements have only one type of request the named request that the list is named after so then on your side you would parse that out put it into the payload put it into the block or the envelope however you need to that's one possibility the other possibility which is slightly simpler for the E but I think it's kind of negligible we had one additional list either in the envelope or in the payload called requests and those requests have you know several different request types that could live within the list and so you would have to look at the Json field the type and determine what type you're dealing with

and then parse out that data based on the type field is there any feelings on either way for that so that I can look at putting that into engine API

I

Mark Mackey: um not a super strong preference but I feel like deserializing is generally easier when you know what you're expecting but yeah um I guess nothing would stop it either from being an array of arrays separated by type but I I think I think we could do either but

just in general de serializing is easiest when to type

Lightclient: okay that's one leaning slightly towards just having individual list of request types

Justin Florentine: yeah basically probably doesn't care I think I have a loose preference for individual request types

Lightclient: okay I think that's enough for me to go ahead get started unless someone feels strongly against that I'll get his spe out for that there or tomorrow people can review it and then let's solidify it

on Monday

Alex Stokes: okay great if there's nothing else on that we'll move to the next item here so there's a suggestion to rework EIP 7549 uh essentially to make the onchain aggregation more flexible M this was your PR do you want to give us an overview

Mikhail Kalinin: yeah thanks Alex so quick overview uh what we do here is basically uh switching from committee bits uh so to comme indices and this allows to uh

the same the same aggregate to have a yeah in one aggregate there can be um in one chain aggregate there can be uh several Network Aggregates from the same committee uh I noticed that this is quite common situation where a Blog contains several Aggregates from from the same committee from the same slot uh this is something that is constantly happening on the main app and uh this this proposal is kind of like uh has more makes this uh more like more room for more Aggregates

from from the same committee uh so what's what's the um what's the problem with like 7 7549 is that it produces the max of stations from 12 128 to just 8 which means that uh in theory uh the max number of uh Aggregates from the same committee that can be accommodated by one block is eight so you can do more and if if we want to more if this is something desirable uh we can go this path and uh yeah just allow basically one chain aggregate have several uh nwork Aggregates from the same committee and

for this we need to switch from committee bits to committee indices uh this is uh the way one of the ways to do it uh so the first question is whether it is really needed um probably potentially it can help with in the case of bad Network conditions but we uh there are many um Aggregates receip from the same committee and we want to accommodate them uh but actually uh eight is a already pretty good number I don't know uh so so the first question to C is basically is this is like having this dation any cause any um sort of concern do we want to um do something

about it do we want to make it more flexible um and yeah if if we want then uh we need to decide on the um how we keep commit indices basically what number of fights will what type we we use so basically Comm index fits into one by at this moment because we have 64 at Max and if we use commit index data type there is the data overhead so it is not significant but yeah we could you know uh make it as complex in terms of data as the as good Factor by using just one bite by using unit8 the problem problem here is that

we don't have un dat in the spec and I don't know why we try to not introduce more un types so that's basically the uh overview of this proposal

okay thanks um I believe there is a 8 defined it just might not be used but there definitely is one yeah um yeah I guess I have a couple questions like if eight if having like Max attestations at eight is an issue here like could we just go to 16 or like some bigger number and does that that would help right

Mikhail Kalinin: yeah that would that would help

but if we go to a bigger number then we uh should accept the fact that block size like theoretical block size theoretical increase

Alex Stokes: right would go up um you had a really ni you had a nice chart in the pr looking at like this issue that you brought up with having committee indexes be eight8 bytes versus the you know tight packing of the bit field that we have now and what I didn't like was with the u64 you get to a place where you know at like a million validators it seemed like the size the stations would like pretty much be the status quo which that was like a attractive benefit to

the CIP is that the stations on chain would get much smaller do you am I interpreting the chart correctly I guess is the first question

Mikhail Kalinin: yeah so you mean like so the size is pretty much the same as with the status quo but it can accommodate for more uh add stations like from for more commities for more slots

Alex Stokes: okay I see so you can still have them more densely packed okay so that helps

Mikhail Kalinin: yeah yeah yeah yeah so we we we could use like where uh in the original uh EIP yeah the original proposal there was an analysis of like different back

stations and basically to accommodate the same uh number of committees uh if we consider ideal aggregation so we could have Max atation St to to and which means that yeah basically one one as station slot can accommodate for one spot worth of attestations received from The Wire and here we can just basically increase the um number of slots and increasing the capacity of the block which also basically helpful in in the case of uh of yeah of network bad Network conditions because you can commodate for

more slots in one block

Alex Stokes: great franisco had an interesting question in the chat like is there some way to use a smaller type for theying multiple committees so like rather than have like eight bytes per committee index could we again somehow pack that down a little more tightly

Francesco D'Amato: just to clarify I mean like U let's say we want to say I don't know at most eight um attestations per committee then we we could just use three bits per committee and and just uh like where the the thing that we include is just the multiplicity like how many of them there are instead of the community

index

Mikhail Kalinin: yep but I think that if we want to do something like that then we could probably use 8 which is really um quite close to using a bit Vector with just one bit I mean like quite close in terms of data complexity yeah but something like that is also possible but again this is if we want to accommodate for you know or more than eight Aggregates from the same committee I don't know this is more a question

to those who want to the chain and see is it like any a problem

Alex Stokes: okay well so it sounds like to move this one forward uh everyone is not aware and it sounds like something we won't decide today uh might require a little more analysis but otherwise yeah nice work Mel and I think that's that unless anyone has any other comments so in that case uh mik has another EIP or sorry another PR uh to update part of 7251 do you also want to

give us an overview of that one

Mikhail Kalinin: yeah so is more related to 6110 but it it anyway uh leveraged on 7251 uh pending deposits uh pending balance deposits GE so the original yeah the reason for you know the original reason for having this proposal is basically um the 6110 uh removes the variant that the pop key and the pop and index yeah the index of other respon to pop key and this basically never changed

so there was because uh before 611 we have this uh large FL distance so no reward is possible Beyond this follow distance like no realwork is visible Beyond this follow distance so we kind of like having this invariant and 6110 breaks it so client implementations will have to make this POP key this cash Fork aware so on two different Forks uh the same index yeah can correspond to different pop keys this is something to handle in implementations and the idea was basically to have a deposit deposit que um explicitly in the State uh to have it

first finalized uh and then uh apply and then after this deposit queue is finalized only after this point start applying deposits start creating new validators and U in this case it also means that we are processing topups uh after being finalized so uh uh a bit of analysis here uh so I also I already mentioned the implementation complexity that can be alleviated uh the other things are uh we we uh in this PR uh the signature check happens only when the deposit is being

applied and since the number of deposits are limited uh by the activation chor number of deposits processed per uh ifocus limited by the activation CH uh we have a limit natural limit on signature verifications per Epoch uh which is also kind of nice uh because it helps to alleviate the attack Factory where uh someone just packs a thousand of deposits in the block and uh with the yeah before the spr a th000 signature verifications uh would need to be processed uh in this case yeah this tax is kind of like really not

that realistic though because of it it it really has a high cost um yeah also uh with this approach uh we can get rid of the activation eligibility uh which means it just becomes uh yeah there is no use for this um field in the B record so it can be repurposed in the future sure uh if it matters um yeah and the side effect is that top Ops needs to be finalized before they can be processed uh I don't think it's a big problem uh probably it has some positive

outcomes in case of inactivity leak and these kind of situations so no one can pump their um portion of State own with respect to the total amount of State and uh yeah so the the problem of this q that it will uh need to keep more um information more more data than it is uh in the original 7251 proposal and yeah this this is kind of like 176 bytes of additional data per every deposit slot I would say that before 7251

would not be a problem because all this information um uh that is coming from deposit contract either you create a new validator so you basically hold uh most of this information in the State uh so the state will not grw significantly but since in 75 7251 we have uh um we have the switch to compounding credentials while making a top up uh then probably have a lot of topups doing doing this uh switch and for topups this extra information is basically not needed so it will just you know waste more uh

space in the begin state but yeah so to to highlight the data complexity with 100 W you uh yeah also uh I I mentioned that the deposit uh processing is is limited by the activation chor so if we have like 100 whether is 100,000 in the activation chor it will mean that this deposit Q is quite full and will consume around 0 18 megabytes of data I don't know how big of concern it is so that's kind of like all view of this proposal and pros and

cons

Alex Stokes: so yeah thanks that was thorough um I haven't had a chance to look at the pr specifically um but yeah I mean I think you're reasoning to sound and it sounds like something we probably want to do unless yeah there are some complications with yeah either data complexity or something like that uh once we start it again I don't know if anyone else here has had a chance to look and has any thoughts

Sean Anderson: uh so I looked at it a little bit um I think it's probably worth doing or at least continuing to explore um but I will say we've merged some changes into we're working on some changes in

Lighthouse to make the finalized firsts un unfinalized Pub Key cash difficulty like more simple so that I don't want to like overweight that deciding on this I think this has like solid features otherwise though

Alex Stokes: okay cool so yeah again I would just say everyone keep it on your radar uh I don't think we' necessarily try to get this in for v0 but you know it'll assuming we want to put it into Petra then it'll come down the line

Mikhail Kalinin: cool thank you by the way small note uh

Fresco suggested and said basically that the activation eligibility book uh um like to make it no use for for the activation visibility we can basically add just an EPO to the pend in Balance deposit skew and do this finality St do process the do increase the um balance after it gets finalized so this is doable with much less uh data complexity

Alex Stokes: okay great next up uh we have a suggestion for yet

another EIP uh Perry are you on the call or maybe Tony

Parithosh Jayanthi: yes um eight yeah um yeah do you want to introduce it or should I

over well

Alex Stokes: as far as I know it's just suggesting we bump up the Bob count as

electr

Parithosh Jayanthi: exactly that's um pretty much it that we conduct a bunch of tests and a simple blob increase so that um any Focus from or any time that the client devs have can be focused on pure D research rather than anything else and yet we're signaling that we offer some

amount of scalability this year or some amount of BL increase based on how well the testing goes um and it's also tied to uh potentially including T EIP that also increases the head

Alex Stokes: right the one that would change call data cost execution cost yeah okay

Parithosh Jayanthi: exactly and when I look this EIP did not suggest a specific number but more of this is just kind of signaling today and then you know as things unfold as we get more mainten that data we'll be more comfortable with the particular number by the time we get to Electra is that the idea exactly and that most of the testing and figuring out the number part can be done

independent of Cent teams or not completely independent but mostly independent ofam

Alex Stokes: right okay cool um I think this is really nice to have like yeah we'll see how P shapes up uh I think we'll chat about it towards the end of the call if we have time but yeah I think uh our base case should be bumping the ball counts up at least for Electra um once we figure out how to do that safely on you have a hand up

Ansgar Dietrichs: yeah just wanted to briefly mention I I agree that I think it's it's a good idea especially with with 20 e that that kind of the worst case normal work size

we have some some room and we also had this kind of alternative EAP a couple like I think two calls back uh 7659 or I think that's not yet muched um which which would do of a similar thing but with a gradual um increase I think this the situation is a little complicated by the fact that basically Electro might not in principle ship together with P already right and so basically how much we would want to increase depends of course on this and depending on how much we want to increase I think it also that that influences whether we want to have a gradual increase or just a one time um so I think it makes sense to basically have those those two kind of alternative is out there so we kind of decide closer

closer to elra which on I think it's that we just say hey some sort of lob increase will be will be part of Electra and just one thing to flag um if we end up going with the simpler kind of that power just presented um there's a one time change necessary to the the way we do the blob base fee um adjustments so so in our kind of initial e we kind of bundled those but I might pull this out it's it's a really small adjustment but basically we would want just want to make sure that there's kind of 12.5% maximum change of the of the of the blob base Remains the Same and and currently unfortunately a quirk of how 544 works that if we increase the number of blobs then then basically that that adjustment

Factor also increases which that's not of course not wanted so so we have to like make one time change to to keep that constant no matter the the block count so if we if we don't bundle this then it will be a small separate DP but it's it's a on line change just to mention it right thanks okay yeah that's good to keep in mind

Alex Stokes: cool okay thanks for that we will scale the blobs with Electra one way or another uh I wanted to take a few minutes just to do a temperature check so the alpha zero specs are out um there's quite a lot in there how are client team feeling implementation wise

um it could be that you haven't really had a chance to dig in too deeply I know last time we discussed and like different teams had different amounts of progress on different of different subsets of the zps um does anyone have a status update there do you feel good about it do you not feel good about it any thoughts like that uh the context being we would like to get to Dev n zero say like the next month so yeah it's so there there might be quite a bit to do yeah Sean

Sean Anderson: um so yeah I think in the next month we can do that um one thing is related

to uh the generalization of the execution layer triggerable triggerable requests like if we include that in DEET zero that would be better for us because it's like right now we're implementing three different eips that might change this and we might be imp ing those just to Target the dev net whereas like then we'll use the generalized format in the future so just the common I sort of feel like if we included that in definite zero as supposed to just strictly um what our current targets are that would be beneficial

Alex Stokes: right yeah I agree and this is what like client was

proposing with combining all these different request types

Sean Anderson: right

Alex Stokes: yeah yeah I agree okay cool okay so let's see I think that's it on Electra is there anything else uh we want to discuss right now

okay looks like no cool uh next up some different spec and research topics to discuss uh one thing

just to shout out there was a post by Anders around issuance uh I think he just wanted to bring this to everyone's attention uh I'm not sure if he's on the call

Anders Elowsson: but yeah I'm here yeah

Alex Stokes: great do you want to give us a little overview

Anders Elowsson: yeah just 30 seconds or something I so I was back back back in January I was on the call and highlighted an e post that written uh where I sort of discussed by relevant properties ofs level that we need to consider when changing the reward card and now I finished a new research post that Ares a little bit more deliberate for change to the reward curve and so I would just like to encourage resourcers to take a look at it and and so in this post I go into a great detail concerning many tradeoffs that we must balance for

example conditions for S the stakers the compos composition of the staking set Economic Security and discouragement attacks Etc uh and so also I will link in chat and also yesterday I put up more sort of an educational post explaining the foundations of minimum viable isss and so I will try to write some more educational material in this manner also directed toward the community I think it will be important as well yeah

Alex Stokes: great there is okay excellent um so yeah everyone take a look and uh we'll just keep the conversation with issuance

going great so next up uh we can turn to Pi do there was a particular request here uh let's see I don't know if age is on the call but essentially there is a question around some of the details around mapping peers and their note IDs into which subnets they're on and I think this kind of touched this like Network shards refactoring that has been floating around um this has implications for pios and how you would like structure yourself in the network to do the sampling and also the distribution so yeah I don't know if anyone who's been engaging with that issue is on the call and would like to bring up their

questions

Adrian Manning: oh here we go H hey yeah yeah I can have few words um yeah so there's there's multiple aspects this one's part of pay part of just main it as it stands um with the that station subnets um essentially the spec as it stands uh has a kind of a a mistake from when we first did it mistake is prob not the password anyway that there's an improvement where we can um use the first bits of the node ID uh to map to the aration subnets which allows us to hopefully improve Discovery um so I've been trying to kind of get this

in for a while um but there's now added complexities when we extend this into p d uh the main reason I'm pushing for this is because uh there's two main reasons one uh I would like to just move ahead in lighthouse in mainnet just doing a simple version of this and then we're also prototyping foras to have it as a as a foundation for pias when we when we get down to pias we're going to have to add another p anyway to to formalize the actual mapping but if we can I just mainly want to get all of the consensus client teams to um at least have a look at it and I haven't heard of any like strong opposition so that we can start

prototyping with p and actually just put this into main it's entirely back is compatible but if all the client teams agree then it just becomes more efficient um the oppos like there is some technical challenges with P but as far as I can tell we can if we put in minimal version now which uh potentially doesn't have rotation we can add another PR later that adds the complexities for p d but mainly I just want to put it into Lighthouse now get everyone to agree and then uh everything is efficient for main it and it's also we can start prototyping for PS so I guess uh if you haven't seen this PR before and you're a consensus client team just please have a look and if you have a

stronger position just let me know before we start building it oh going too deep down that b that's about it thanks

Alex Stokes: great thank you uh has anyone had a chance to look at this any other SE teams sounds like not yet but yeah please take a look and it sounds like this is a direction we want to go in so let's make it happen Okay um I think otherwise that

was everything on the agenda is there anything that anyone else would like to discuss right now do the other question

Łukasz Rozmej: so I wanted to clarify uh what's the current status of inclusion list EAP because it was uh we had some reservations on the elite and I'm not sure what the end result was

right

Alex Stokes: yeah this was one other thing to discuss so I think on the last execution call uh yeah they're definitely were some

reservations and I think I was essentially going to see if anyone wanted to bring it up to this discuss on this call um it sounds like to me there are some concerns around implementing it especially in light of account abstraction I don't think anything's really changed there uh but yeah I meanone like on on the call like to uh get into this EIP I think we I think it was cified but also at this point we have quite a bit in P already

Łukasz Rozmej: I think it was even included that's why I'm raising this if it was only C F I wouldn't raise this but it was even I think included

Alex Stokes: it was never included

Łukasz Rozmej: okay never included then my confusion

then

yeah

Mike Neuder: I would say nothing no new advancements um the 374 issue is going to exist no matter what um there's no Silver Bullet there so yeah writing a short dock on kind of explaining the issue but I would say at this point there's not much um confidence that we could get it fully resolved in a way that would be happy for Electra at least that seems to be the sentiment broadly

so yes Al yes

Saulius Grigaitis: yes I have a couple of questions so so is is there a solution for test

vectors as the spec is progressing very fast and the published test vectors uh they get outdated very soon so maybe some client teams build the test vectors from this PC or or is there solution for

thisa

Alex Stokes: right well there are the test vectors for the 150 Alpha Zer release um is it releas or yeah yeah okay great Barnabas has link so yeah generally when we have a spec release we also like make all the spec test vectors from the spec and then release those as well

Saulius Grigaitis: okay so so this then than zero likely will

Target some spec release some exact spec release that will have test vectors released too

Alex Stokes: yeah the intention is Alpha zero although if we change something with respect to uh this one EIP what was the number the one with the request refactoring that we were talking about let's see let me find it there's way too many messages in the chat 8432 uh so that might have some implications for just how we like structure things syntactically but otherwise the functionality is all in there and Alpha zero I don't really see any other major changes with respect to

that and then that gives everyone a clear staple Target for de zero

Saulius Grigaitis: okay thanks so another question on on D working group telegram chat we were discussing today uh an issue where uh essentially on the if an avable block is is imported in a First Choice then the vs of that block May influence uh the for Choice uh and essential the weight of of of the fora uh so and I remember that there were some discussions before and that

actually the reason uh I believe that was the reason why we don't uh right now we don't uh import uh blocks uh that doesn't have all the uh blobs available uh and maybe there is some person in this chat uh in in this call that uh uh that knows a bit more about security the issues of this approach where uh unavailable blocks are important in imported in F choice because on this telegram chat there was no response from such

person

Alex Stokes: okay and so could you just State the question again like the concern is I'm importing un available like I'm importing blocks into the fork Choice with un available blobs and the question then is like what to do about that

Saulius Grigaitis: yeah so uh yes some malicious um uh malicious validators may vote on these unavailable uh blocks and this could caor is it clear it's a bit tricky to explain

Alex Stokes: well I mean if I'm following my understanding would be that these blocks wouldn't go into the fork choice right

so like I don't know how yeah but Francesco was offering that it should go the for choice just filter out

Francesco D'Amato: sorry yeah just what what to clar what what I was um saying in this chat was basically today what we do is to just not import blocks that are unavailable um I think that that's to that's basically fine today but it wouldn't be fine if we move to Pier Das with the trailing for choice I think even today it's debatable that it's the best thing to do but I think it's it's okay and there's not much of an issue with it but um what changes when we go to Pier D with a trailing for choice is

that uh you can even go from so like today um you can only go from um availability being false to True like is there available first being false and then true when we move to P for Choice it can go even in the other direction from True to false and yeah this basically creates like kind of different scenarios that are not um you know you cannot see today um and I think what we should do instead is basically to not use these data available to gate the import in the for choice but to use it just as a filter so when you're running you you just import a block in for choice but when you're running ahead you you don't basically go down a branch uh where uh like basically you get to a

certain point when you're looking at children we block and you filter out the children that are unavailable um so just yeah just like as a simple filter directly when you're running the for Choice um and yeah there's like various reasons for that um I'm not aware of like a problem with doing this but yeah the question was you know when the decision was made for fre for four to instead use is it available to gate importing was there some specific attack that people were worried about or yeah basically why it was that why was it decided to do that and what what's the impact of that like maybe I'm missing something

Alex Stokes: does that clarify

okay yeah

Alex Stokes: I mean this this clarifies my uh FL the explanation but I mean we are looking for a person which uh which knows why in the current spec in the neb spec we uh I mean why exactly it was chosen to not import unavailable uh blocks or or blocks that doesn't have all the uh blops so is is there such person in this chat and if not then all that so someone know right well with 4044 I mean it's just like strictly safer to do it this way right like you you just cut off even the possibility of

these questions if like you just wait until you know everything's available

Saulius Grigaitis: yeah but if we are discussing to change it uh in beust then it's likely we can do it right now in with with the current

LS

Alex Stokes: maybe I mean if 444s working well enough I don't see why we need to change it

Saulius Grigaitis: okay but it also should be related to the thing that uh uh we do not uh do any validator duties if uh uh payload is uh invalid so it's it's in some sense it's so if the payLo is not validated yet so

it's in some sense it's a it's a similar problem

Alex Stokes: yeah I mean I think it's the exact same reasoning so before i44 like yeah like you can just say don't even consider it with respect to Fork choice so you don't attest to it don't try to put on top of it um for exactly this reason with peer dots if we do move to some trailing Fork Choice it does get more complicated um and then yeah I think you'd need to have like a more like a richer view I think like Franchesco was suggesting as to like what's what's yeah the words get overloaded but like what's uh you know what's um I can't even think of one that's not valid or available but

basically you would have some notion that like this block is here and it's almost like pending maybe that's a good word for it it's like pending in the fork Choice and then you just have to wait for more information to to move forward

Saulius Grigaitis: anyway if anyone knows this someone who did the the security analysis of of this thing uh and if there was explanation to to do that uh the way it is now in the net then yeah please invite this person to us working group and we can proceed to discuss there

okay sounds good does anyone have anything

else I think that's all we had on the agenda for today and if not we can go ahead and wrap up a little bit early I'm sure you're all very busy uh with texure zero so good luck record

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