All Core Devs - Consensus #123

Transcript

[Music] all for

h J

Danny Ryan: okay uh we should be live this is the

allore dev consens layer call 123 this is issue 916 in the PM repo okay um we'll hit anything on dab so testing adet updates as well as a very minor spec release hopefully going out tomorrow um a clarification on maybe some ambiguity in by root requests uh just for quick discussion and then a couple of process items from Tim um and if you have anything else we can get to it as well okay so first up what's going on with

the nub testing and Deets did I see that there's a Dev nut that's been launched does anybody want to give us an update do we have anyone from the devops team here did I start the call too early trying to train yall to show up on the hour okay um

see we will table that for now um any testing updates worth discussing today

Mario Vega: yeah I can I can uh talk about the hi updates there's been no major issues found so far um just a couple of ones but I the these have been mostly test related um but so far the three consensus clients that I have tested are working correctly um no major issue so far I will keep just adding test cases in the in the blobber side and also in the Builder side to see if I can find anything but so far not nothing nothing uh worth uh bringing

up

Danny Ryan: okay

Mario Vega: and another one is maybe um after I'm not I'm not sure how um how long it would take us but I think probably this week or next we might launch some equivocation tests on deet um with the blobber it's basically ready but I I guess that Parts would like to um have the Dem more stable right now before launching any um attack testing

Danny Ryan: makes sense per B you want give us update on

devet

Parithosh Jayanthi: uh yeah B you want do initial the updates

Barnabas Busa: yeah 11 uh we did a nonf

finalization kind of we took one third of the network off because we had to recycle the our machines for themet 12 and uh we found a couple of bugs and a few clients I'm not sure if ter is here to discuss that um another thing is uh2 is very stable right now we just started running blob to and uh yeah they now have blob 12 and of the clients are onboarded except some

Parithosh Jayanthi: yeah I think we found like a exit related issue on devet 11 as well as

something on re um there was also an interaction between nimbers and rs that had an issue in Dev 11 uh they're all being fixed right now so we probably keep 11 up until they're fixed and then once that's done we'll reproduce all we try reproducing all the issues on 12

Danny Ryan: was that the finalization the bug with respect to the finalization issues was that on 11 or 12

Parithosh Jayanthi: 11 okay uh but I don't think there was any finality related issues in itself it just happened the same time we submitted the exit so we assume they were related they weren't

Danny Ryan: I see

Barnabas Busa: the thing is the exits would have probably been handled fine uh but nimus would have voted on

incorrect it would have just said were invalid and maybe it have for away we don't really know uh what would have happened if have been no non finalized State

Parithosh Jayanthi: yeah and just to clarify the issue is not like a main net related one at all it's scope to just enun test Nets and the other topic we wanted to bring up was um now that we have devet 12 and it looks like it's fored without any Fanfare should we start planning girly Shadow for um and we want to know what sort of timeline we can plan for

that

Danny Ryan: yeah I um does anybody have any thoughts on that I guess what importantly what's the prism timeline look like to getting on Deet 12 is any anyone from prison here we might have lost terance because of the time change it's now 6 a.m. um oh Preston do you all have do you have any perspective on prism's Readiness for

done that 12

Preston Van Loon: hey uh yeah I'm not totally sure exactly on the timeline I think we're

still a few weeks away um I have to check with teren and follow up with you guys

Gajinder Singh: I think on the Denon call they said that they were two to three weeks away

Preston Van Loon: yeah that sounds right

is wise to B with the sh then without prison

Parithosh Jayanthi: yeah I'd also wait for prison before we do the shadow

Shadow Fork during Christmas

Tim Beiko: yeah we should definitely do

at least one before the end of the year I think um and yeah

Danny Ryan: Mario is asking what's going on with timelines on prism Preston or do you have any perspective on what the major hurdles are at this point

Preston Van Loon: hey um I'm not totally sure um yeah okay what it was I think we're yeah I don't know I have to follow up offline

Danny Ryan: all right we can get parents or Poes to give us an update um in the Discord

Parithosh Jayanthi: in the meantime what all do we want to see on devet 12 um I know Mario spoke about uh adding blobber and doing some equivocation stuff we're going to be doing that for sure we'll submit exits deposits there's already blob spam um anything else that we want to do any other scenario

Danny Ryan: assuming we'd run a slasher as well

Parithosh Jayanthi: yeah we definitely we do slashing as well

Danny Ryan: okay um and something Mario probably said this but just the equivocations with just the sidecar headers will be like a kind of New Path for the slashers to pick up getting messages from that gossip topic exclusively so that would or those like potential multiple gossip topics um so

that'd be interesting

Barnabas Busa: which of the clients slasher right now

Danny Ryan: I believe Lighthouse and prism have a slasher

that something

Pawan Dhananjay: yeah that was just a question we had as well does the slasher need to be updated or is it just assumed if Lighthouse is able to track the chain it can also produce the new slashing proofs yeah Lighthouse the thing that we have running on devnet right now it does uh include the blog headers from The Blob site C into the slasher as well so so we should be uh detecting any proposal slashings that come through the

way of uh blob site car as well

Danny Ryan: cool well we can give it a give it a test shot yeah I mean if we have time doing doing you know non-f finality uh taking portions of the network offline and that kind of stuff is is always a good see what's going on um it also if we're going to be running debet 12 for multiple weeks it might be worth U knocking on a couple l2s doors to make sure their stuff if they've been

doing development work works on it

Barnabas Busa: yeah I think we're going to be running probably end if will take another two weeks to get on boarded um I don't see a reason to relaunch it during like the Christmas week so

Danny Ryan: and what's our Mev boost Builder situation on dead net 12 look like

Barnabas Busa: uh we have 225 LS running it's only three noes but they seem to be somewhat okay uh we don't have M FL working because uh is doing some rek on that uh that is currently on

Hall so we don't have many two Productions so local bus are preferred over M buil blocks as soon as we have running uh ahead then I think we're going to see a lot more M related too

Danny Ryan: all right anything else on dev Nets and testing

Barnabas Busa: we have the channel so maybe he can discuss the nus SP that was covered on 11

Dustin Brody: uh yeah sure

um so so this so Nimbus essentially was was in the not validating um the uh Pro not not using the correct Fork um to validate voluntary exit messages um on the not the state transition um but the um sort of integrating blocks into its trusted database is is um so that ended up stalling um progress uh in it for devet 11 um and so there's there's that there and and there was there was a smaller issue

that that um kind of jointly um Nimbus and there was a nimbus W kind of both had issues there but that that was much less serious um this this is a consensus issue um and uh but you know fortunately only to

up

Danny Ryan: is that something we can catch in the consensus test vectors or is it a bit too stateful for that

Dustin Brody: well that's the issue um that was my first instinct as well and I think the ladder at least this is or say because of nimbus is architecture it's the lad because the state transition function is actually correct so when I got the state and block the preate and

the block the and just we have a you know zli analog um it applied it applied correctly because the state transition function fixed um to you know spec compliant um but the there's an optimization that nimus has that all the clients have I guess is batch signature validation um and the way that's implemented is outside the scope of this the state transition

and and and honestly that

Dustin Brody: that's probably going to be made that way for this part of it um it varies a little bit but for so that's it is interesting question in general where the architectural boundary should should

exist with any of these things um but but I think stateful is a good example and in particular what happens here is that it colle by the nature of what it does is it collects signatures across the entire block like all the signatures in the block

Danny Ryan: right

Dustin Brody: and this is something that um they would end up being attention between performance and um sort of s of test coverage um which we already see by the way like the the epoch transition White House has published a while ago this thing about

uh well

Danny Ryan: optimized version

Dustin Brody: yeah and and and right now there's very a really obvious tension between the test coverage right now if you do that then

you lose a lot of test coverage unless you very carefully this is why Nimbus hasn't done this as much only some because to achieve that level of level of performance means losing a lot of the test coverage of the indiv individual um sort of components of that in in the consensus spec tests um here we made a different decision and it ended up biting nimus I guess in this case but um where the performance was not feasible to leave on the table um for the epoch it is right for the

Danny Ryan: no I understand um it'd be interesting given as as the cons layer is f further integrated into Hive and we use

additional tools like curtosis if we can try to capture some of this in there um a bit further upstream or Downstream whichever your perspective is

Barnabas Busa: we Unos because it takes a long time for an exit or deposit to take place most of the time

Dustin Brody: but I would agree though uh with with the idea of of of further testing um or I mean obviously more testing is always good but more systematically figuring out how to incorporate more client functionality into um tests that are run and maybe more automated ways

whether it's Hive or gitosis or or something else um and I mean there are practical challenges there obviously with I mean Docker image building and Etc I mean just timing wise but if if can be figured out or things can be factored well so that more of these tests can be run I think that would be definitely useful the other challenge here and this is um something that um is worth is like how standardized and this is actually I think maybe a I don't know policy or or or you know this is not just like a software engineering question is how standardized should the behaviors be it's been observed before in in a number of context that um all of the client

you know as kind of table Stakes they all correctly pass the consensus spec tests they always do with all the dep deaths um and test Nets and anything outside of that is a little bit up in the air and and so the so is that desirable or not are these things that are intentionally kind of left ambiguous or are these things you know what what should be really nailed down by a spec versus what should be left deliberately paid so I mean

Danny Ryan: yeah I agree with that but still some of these like when the statefulness kind of gets inter gets in the way of processing valid or invalid blocks I

think it's still like spec um you know it's hard to argue that if you're doing batch operations that they should fail when they pass individually uh but I I agree that when you get to the edges uh especially when you start talking about like responding to network things and stuff that it's really hard to throw that all on conformance test um I definitely like I don't know if we've had a consensus we probably have maybe not live but like most of the issues around consensus have been around like things that work in isolation but then don't work in a more stateful environment uh regarding caches optimizations and that kind of stuff um so at least like some sort of like more

bulk operations in

yeah hi is

Dustin Brody: I'd agree with that I mean I think another um possibility is the gossip validation um and I so I think it's important so really crucially at least for me there's a a hard boundary between tests which depends on network and tests which depend which don't Network dependent tests are FY and fail I'm sorry but they they just do and I do not I want parts of at least the nimus and in the nimus definition kind of push for this actively where they never ever ever fail because of network weirdness or it can't access some external server um

other tests that's fine and and so in terms of the EF test I think that's a useful boundary as well and what I would also push for what I'm getting at here is to say that the things like got gossip tests there are many tests which actually could be done there are bulk tests there there more integration tests but they do not depend on external access um I would say it's a reasonable assumption and I we're just hear it call so we can if somebody disagre with me tell me or tell you know say say so but I think that people have or can have vctor things so that there is something like a gossip validation function there's a a something to there's some Oracle in the software that can say is

this gossip message good or bad or ignore or reject if this is the case given and that function probably is not doing any network calls itself and so I think one possibility is having a more formal test Suite around gossip validation um the only thing I would say there is that what Nimbus does deliberately and I think is I think a deliberate ambiguity is the ignore the accept reject condition or sorry accept ignore sorry reject ignore conditions um the by reordering the tests for performance reasons you can get different versions of those difference is the Purity scoring and that we'll

just take that that's fine but if it starts becoming well no you failed the test because you didn't put the signature verification last well

like

Danny Ryan: yeah like you might have to you might have to rap ignore reject is the same purpose

Dustin Brody: yeah but but otherwise I think that's an example of of what you're talking about where I think

Danny Ryan: even th those those can be moderately stateful I mean at least time like what is the system's time becomes a condition in there that is not part of the state transition um that's stateful there might be a couple other things in there though you need to be careful about

Dustin Brody: that's true we deal with that with fork choice though no to some extent

like with the fork choice test and

Danny Ryan: yeah it had to it had to be baked in there so it could be baked in there although some of the like the conditions or did you see this other message so it's like you'd have to give a suite of messages rather than just a pre-state um to so it is a bit more

is a bit more stap

Dustin Brody: I'm actually wondering I think and the other part is ignore is so I think reject can can certainly be tested I haven't really heard that but

Danny Ryan: because that should be just straight up

Dustin Brody: yeah yeah right so I mean by their nature there's once reject always reject on all of that stuff so that should be I I see what you're saying though nor actually is a real problem and I would say probably I would say out of scope I would suggest for a

first version of these um it's just too picky uh and it also resolves the ordering issue to some extent um the test ordering issue if you only pay attention to reject at all um um but but it's yeah anyway I mean that's an example I there are others I don't we to go too down that one picker Rabbit Hole too much but I but one can find other examples where I think one could expand the scope and certainly in nimus that by the way would capture a lot of the batch validation stuff

Danny Ryan: because

Dustin Brody: sorry go ahead

Danny Ryan: I was say I question whether reject is even valuable if it's because reject are probably

deterministic with respect to kind of things that would be caught in the state transition it's really those ignores that are probably more

Dustin Brody: yeah that's well Nimbus handles this differently though I can't speak for any other clients obviously but the Nimbus will tend to use the batch validation at that layer even

um so it

Dustin Brody: at least for Nimbus it would be a useful kind of additional set of of testing that it is stateful in a different way um but but I see what you mean that it probably won't in general catch a huge amount so that may not be the highest Roi uh thing to add uh there may be others I don't want to that was

just kind of a spur of the moment thought notation but I but I think in general I but it was a way of saying I I do agree with you that that finding larger um more stateful chunks if that state can be managed what another Hazard or risk of this I will suggest is and for people who have seen I know this is not the acde call but for people who have seen um the um execution tests they take uh significantly longer um to run in general I think and in their complete um vastness and part of the reason is there's several reasons there's more forks and all that but but like so part

of it is just that they are they kind of lean much more into this idea of doing these integration tests with fullon States um that take a while um they're slower tests um what the tradeoff there is CI wise for people I don't I don't no um but that's another consideration

Danny Ryan: yeah okay um how or if and how should we continue this conversation I know we've been ramping up CL stuff with respect to Hive um and also digging a bit deeper into some of the stuff we can do with curtosis so maybe it's just

a matter of making sure some of the issues that we do run into are are documented so that Mario and others are aware of them and kind of can see if they can be integrated well um but maybe there's something else we should do here

Dustin Brody: um I would I would say in in terms of like things which are not sort of to be completed on this call but sort of having a complete set of what are the protocol actions that need to be tested so particular for here what triggered This was um in the wild as it were exits like that that was that was the new thing in devet 11 that which approximately triggered this so whether that was intentionally chosen for this

purpose or not like I'm not sure the pre the previous Dev Nets could have done this like we've had previous denb denb Dev Nets but you know but but being more systematic maybe about saying like what are all the possibilities

Danny Ryan: yeah and seeing if we can catch some in some sort of CI instead of having to remember to trigger them on a dubet and catch them a little bit later um okay does anyone from testing want to chime in here or um and Dustin is is there anything to document on your end so that we better understand this or is it simply triggering a bunch of exits on the neb or is there like more uh more details

that are worth making sure that the testing

Dustin Brody: I I don't think so I I think it's basically just um the just more more um exits on to neb not quite yet we haven't released the uh um uh um or I haven't made the pr for this yet but um but yeah like um and so it'll just kind of pointlessly stall nimus until then but I that's certainly a my priority and as soon as that goes out and is running on the the demet 12 or five or anywhere else I think yeah then that bag sense yeah

Danny Ryan: cool and I don't mean to Hound on this particular issue it's much more just like the us all being mindful

of that there are these like stateful paths that we need to be trying to make sure we test and think about how Tes so

Dustin Brody: no I I I appreciate that absolutely and and I agree with it and it's like this is um and and as people as a system becomes more mature and and people optimize more and and sort of bake more assumptions kind of just over over time into the software um deviate from the you know the python pseudo code spec increasingly I mean gradually but this will uh become I mean OB just been happening from the very beginning since the merge but this will become more

typical

Danny Ryan: so Mario you had your hand up do you have anything

Mario Vega: so I think a write up would be very helpful and also if we can also o discuss this on the Denon interrupt testing call to bring it up again and just see how we can continue we can pick it up there and see ways that we can implement this in the tests

Dustin Brody: okay so just like a a hack MD or or when you say right what what would you like to see you know for the write up what what are

Danny Ryan: I think I quick happen hacking the you know the high level things that happen on the network and anything that's maybe interesting to document with respect to Nimbus like that that was a bulk

verification you know path or something because then that that might imply other types of bulk verifications that we should be

Dustin Brody: right I see okay right how how what what can be generalized from it because obviously this will I will say it's not solved quite yet but it's it's let's say resolved that the mystery is is has been cleared so sure okay

than Perry do you have anything

Parithosh Jayanthi: um yeah I think most of what Mario was saying as well but we'd probably be talking to see which parts we can put into Hive and which one we want to put into kosis one of the things I guess over the last few issues we've seen is that we just need some tool that can systematically execute a certain number of integration related behaviors so

exits withdrawals make sure there's a Mev block produced by every client make sure there's a block produced by every combination and so on and that sounds like it's something we can just integrate into ptosis so we probably solve it by a mixture of high vosis but yeah we we'll be discussing yeah that's my intuition an update

Danny Ryan: okay anything else on this

I'm not not for me

Danny Ryan: yeah cool all right cool um so we'll keep it kind of in testing land but if some broader you know progress is made on strategies and stuff here by all means bring it back to award ofs um um Terrence you hopped on uh just we're

trying to get a perspective on prism timelines and any kind of major hurdles that still exist um and also if there's anything we can do to help

Terence Tsao: yeah sorry I was a bit late so I guess like apology that we underestimate how many people were actually like offline and on vacation this month that's why prism is slightly delayed because of death connect and like and like the Thanksgiving week but yeah we are so like we ended up redesigning a bunch of stuff because of D night 12 so we added a new fire storage layer and then a new caching layer and that's why it's taking a while because without those like major revamp if we just implement the pr as it is it would have been faster but yeah I we're still like

I would say two weeks away but then like again like we can join that 12 which I think he just launched this to to to today as well so yeah you don't have to wait for us but but yeah we will join when we're ready probably in two weeks but yeah we should be ready for dry test net once it's out but yeah that's that's pretty much it

Danny Ryan: okay thank you um any questions for prison before move on

Parithosh Jayanthi: yeah if you guys have a branch um whenever you're ready just let me know so yeah I can R have um some integration

tests

y sounds good thank you

Danny Ryan: okay anything else related to testing and

minut on the them

Parithosh Jayanthi: we have a tool that can reliably do rops now um the question is just is does someone have an issue that was triggered by yog that we can toss in the tool to see if it can catch it plus that issue being fixed so we can see that it can't catch it after it's fixed

Danny Ryan: right so like an old commit as well as old release and a new release uh anybody have

a reorg related issue from the past that they can point Parry to if you can't remember can you please ask your team and then knock on Perry's door and Perry maybe drop this in the Discord uh for a broader ask all right anything else related to testing and

Dev Nets on Deb

Tim Beiko: not quite the Nets but we're going to put out the Gordy blog post today around Gordy validators being exited the later of three months after the for or

one month after mainnet last call if anyone has thoughts comments on that but otherwise the post should be up in the next hour

Danny Ryan: great okay um we have a minor spec release that is slated to come out tomorrow this primarily fixes some testing in Fork Choice testing as well as uh we're working on getting this um when clients can serve block and side cores by root uh clarifications on like um May should Etc uh I had a review I

put up last week and then did did not click submit so uh it's a bit my fault yesterday I realized that um so we're doing some final um stuff here I don't believe there's anything shocking um but hoping to get it done today and get a release out tomorrow if not uh release might come Saturday Sunday Monday um are there any comments on this issue 3551 that would be kind of the most we did talk about it on aoup a couple calls ago um so I don't think there's any surprises but I just wanted to give you a chance to service any comment or concern before this is finalized otherwise this is not breaking

um with respect to the dev Nets um so won't it won't affect you can you can and should roll out uh changes with respect to this to DEET 12 but it it's totally interoperable on the networking layer okay there's actually one other clarification that might make it in there this is uh PR 3544 um and I wanted to just make sure that this is capturing what is actually happening uh so it doesn't the by root request don't actually

say that if you're responding to um root a b c that you would need to send messages in that order um I would I've assumed that that is certainly the case uh that you know you're matching root zero to message zero root one to message one you're not doing a like you responded in some random order but I might be totally wrong here so before this goes in uh does anybody have a comment on whether these are supposed to come in an order

Justin Traglia: um also maybe some clarification on like uh duplicate requests like the same route and the same

request

Danny Ryan: so like route a AA should not be you're saying should not be valid or yeah or maybe you should just return the just a once

Justin Traglia: yeah exactly

Enrico Del Fante: well if that is a set then the order should not considered and also the duplication could be removed but if we want the order I feel like duplication should not be allowed and then we respect the order

Danny Ryan: yeah well the order can also be weird right because if it's a BC and you don't have a you can respond B and C and

which is the correct order by some standard but you still have to like do the matching properly right

the verification would be much more

Danny Ryan: um is anyone aware of how this functionality is actually handled or is is it kind of Ambiguously handled and maybe there's different functionality across clients at this point okay it doesn't seem like this is

top of mind and that there's uh that the people on the call have clarity on how this is currently done um we'll drop it in the Discord and try to get clarification from some of the more networking folks on teams and get this clarified soon um obviously things work uh but some of the ambiguities here might be cause of issue in weird edge cases um and it be worth clarifying and cleaning up all right anything else on this

one this is not going to go in the releas tomorrow okay any other denb items or just general uh spec items

okay uh Tim had a couple of small items related process Tim

Tim Beiko: uh yeah uh so smallest one um adding Fork folders to the PM repo so we currently have things like devet specs and whatnot like live randomly on hack

MDS uh we've had these main net checklists uh for a few of the forks um that also end up r living in random folders um so my suggestion is every Fork we just create a repo sorry every Fork we just create a folder in the PM repo um for that fork and and put all those things there and when the fork is over we just move it to the archive folder so pretty uncontroversial I think but if anyone

Danny Ryan: no even standard files that go in it it's just files are relevant

Tim Beiko: yeah yeah so I'm not saying we have to create you know like a main yeah yeah um but just we tend to and now they like either end up

in hack MDS or random places which is like a default place for people to shove stuff that's relevant to the fork that we're working on um and we'll we'll sort of get the and usually we we don't struggle to find them during the fork but it's kind of nice that this way we'd have them you know in that repo Forever After the fork um yeah sorry e panda Ops uh ha can be is not random but the and I mean even if we keep using hmds we can just even link them from there and you know um know that this yeah

Danny Ryan: you could drop a doc that said relevant notes if you didn't want to put it in there

Tim Beiko: yeah um so that was the first I just wanted to wait until I merged it to see if anybody had comments

but it doesn't seem like there's any objections next one um so the other thing that's kind of weird right now is there's nowhere to know what's actually in a fork uh especially for Combined Forks um so on the El we have things in these uh random little markdown files uh so this is the one for Cancun obviously on the CL um the beacon chain spec has a list of the eips um but there's not like a single place where we have like these are all the eips going into the fork uh the two place where they're listed for half you know each half of the network are kind of hard to find and like not necessarily obvious um so my other proposal is we bring back mea eips to

just list what eips are in a fork um so we used to do this for some reason we stopped a few years ago I forget why um yeah right e panda Ops the e panda Ops hacken is maybe the easiest place uh to find all the eips but this is something that people uh on the outside aren't necess certainly super aware of the other place the eips end up being listed at the end of their process is like on the hard Fork blog post um which is kind of weird to have to rely on the blog post to like figure out like where to look at in the IP's rep in the specs um so my yeah my proposal would be we add a

meta EIP uh literally just as a list of uh the eips included in a fork if we know the fork is going to be coupled uh like uh theb and uh and Cancun we just have a single EIP so we don't have the duplication of eips like 4844 4788 um if we don't know that the forks are going to be coupled we can just have one you know per side and worst case if the forks do end up merging together we just merge to eips or something um and we can either do this like right now for denune or you know start for the next work but it does feel like something where um yeah having a single list of eips for the fork somewhere is valuable um

especially now as well that you know if we that we split the eips and ERC repo we can imagine uh starting to add like more custom fields to the eips and whatnot um and aggregating them into a single Fork EIP so any thoughts on meta eips and whether we should do one for denune or H just wait to the next four okay uh one comment to do at ASAP I can get it done this week um okay two yeses that's all

I

Danny Ryan: I'm not I'm certainly not a

PO um we're we're happy with like how we bundle things into the specs on the

Tim Beiko: yeah I'm not saying we should remove them

Danny Ryan: I I know but the but a met reference somewhere especially because of the cross cross layer makes sense to me

Tim Beiko: yeah and I think I I think I can do this now but I would link the specs assuming the bot lets me um so you know saying like these are all the eips in the fork this is where the fork is you know defined for the CL this where the fork is defined for the E type of thing um okay so I'll I'll I'll draft it this week um and then this is urgent and just something for consensus layer folks to

start thinking about if they want so we have uh on the El side this weird status of like considered for inclusion for eips which are things that uh we that basically client devs think we should maybe do but end up being like a superet of what goes into a fork it's not clear to me if like having the status is a plus or not uh in the past it was helpful because we if somebody comes on the call and you know they want a signal of like should they keep working on this EIP or not this is like a soft signal we can give them but it's also let the confusion of like okay now we have this big list of stuff we might do or might

not do um and so I was thinking on the El side either we should remove this um if it doesn't add value and just adds you know confusion or if we keep it you know maybe makes sense uh for it to also be like used on the CL if if people want um and again now that we have the like split EIP process you could imagine making this like a a status of an EIP if uh if we keep it where it's like you know something gets proposed for a fork it it can be signaled directly in the EIP that it's it's it's being proposed um so I I have a link uh The eth Magicians in the agenda and there's a

bunch more context there um but yeah I don't think this a decision that needs to be made now but as we start planning the next Fork figuring out like um yeah do we want to keep this state that's higher than random ideas from random people but prior to accepted in the fork which is roughly what CFI was um but I think if we yeah it might be worth getting a more formal definition and like updating it if if both sides want to keep using um yeah that's all I had so I'll get them MIP done and I'll merge the uh Fork

repo PR

Danny Ryan: well any other questions or comments Tim

D

Parithosh Jayanthi: um what's the um do a tempature check on the idea of putting four fields on all of the eips and having placeholder Fork fields for proposed and so we can you know filter eips uh by that field to see when it was implemented

Tim Beiko: yeah I'd like that personally on thep side um I'm not sure what's the best way to do it but it would be nice to be able to click you know Berlin or uh yeah capella and get all the eips

that were in that

um all

Danny Ryan: anything else on this one all right any further comments our discussion points for today okay great um hope to you all very

soon thanks everyone

thank you thank you bye yeah bye bye guys byby he

[Applause] it's

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