All Core Devs - Execution #189

Transcript

[Music] J oh [Applause]

it's than

Tim Beiko: good morning everyone we are live for all core devs uh number 189 uh main thing on the agenda today or

at least most important thing is finalizing the the Petra scope um the biggest question there seems to be around what to do with eof and then potentially uh how we'd approach a blob count increase um thank you to all the teams who've likely out their positions and Views uh before the call I had some time to read through all of them um they're all on the agenda then Mikel had a lot of uh uh spec issues around picture that he wanted us to look into so go through those we also had another breakout room on uh 7702 and um yeah spent most of it discussing some concerns around

viability so it's worth getting this group's opinion on those um then a last Spectra thing there's a proposal by Gom about deactivating EIP 158 um as it has some implications with portal sorry with veral after that is Portal uh after that I had some potential improvements for awward EVS how we run network upgrades and uh how e magicians plays into that and then uh testing teams has some comms stuff they want to talk about and lastly uh sh out to the first perer D Breakout out next week um hopefully we get through all this and so first on the list uh so the Petra scope discussion um so on the

agenda as I said we have an updated views from Basu ethereum JS nethermind re had uh shared their views before and then the E the EF devops team had shared um their view of like all the potential Forks we could do and what it would mean from like a testing perspective um so I think the only uh two teams we didn't uh you know hear from uh in writing were gu and and Aragon but we we have heard a bit from them on the last call um reading through all of them this morning it seems like uh pretty much like everyone across Bas ajs nethermind and ref would like to ship eof um

relatively soon so before the veral fork um and then the question is whether or not we want to combine it into like uh whether or not we want to combine it with pectra um some teams rais concern around the scope of that other teams would rather have everything together in one for fork um and there seems to be also like a pretty common or like broadly shared view that um if we even if we do split the forks out like if eof is a separate Fork we should keep this minimal like people don't want to to do a uh a fork with like many other features in addition to eof uh before veral um so I guess I'll pause here um anyone from any of the client teams want

to add more color or Nuance I thought I just said and if anyone from G or Aragon specifically want to share their perspective um yeah that'd be great yeah

go

Łukasz Rozmej: uh so from my perspective I personally would like to uh ship uh Fork that is more or less implemented at the moment with some minor changes might still go in but without any major changes uh I would consider e actually implemented so it more depends if testing and uh would uh delay the fork but I would like it to ship in

2024 uh and then I'm open if anything else important comes up that is more urgent than vericle trees and for that for example pust might be or something else that will be uh ready later maybe epbs for example uh with inclusion list if that's have a different iteration uh then I'm fine if we decide this if it's more urgent than uh vericle for example and will be ready earlier than vericle uh to be shipped to ship it earlier so I'm kind of um or this because my reasoning is also because prag is already quite big uh I wouldn't call it small uh making it even larger would increase the risks of uh shipping

it in time uh whatever the time frame is as well as bugs and just increase the complexity and I think we should ship in uh small Forks probably you know are a lie in my opinion but we shouldn't also aim for extremely big Forks because they increase complexity of testing and and shipping Etc and uh it they cause delays so that's my stance

thank you um G

Guillaume Ballet: yeah so you were asking for perspective U I've got some perspect some New Perspective I have tried to run a transition on the more recent database

which I hadn't done in a few years and with 10K which was the upper bound uh sorry 10,000 leaves being translated per block uh we already are over the two week two weeks limit which means the state has grown way faster than the 2022 estimates um that was on the database that is about a year old um the state is growing now the question comes about the usability sorry the the feature like shipping features just because we can Fe ship them now including e but not not only uh I don't think this is what we should be doing we should be figuring out what we really need to do right now and my

understanding or at least my fear is that the more we wait the the bigger the the veral translation will take the longer the veral translation will take uh is e really that urgent I don't think so I've read um I've read several Arguments for for shipping it in Prague the more I read those arguments the more I realize no they actually like there's no nothing that really justifies e to begin with like dragon has published something I I read it with interest I asked a couple questions my understanding is that everything can be done without EF I think e still doesn't have a very uh strong case um and uh we are delaying verle just because it's

been coded doesn't mean it's been tested uh yeah I heard about the two test but for when I I have understand understood as Kari and other people it has not run on a test net uh so you are not ready like eof is not ready we don't know um so that's one thing uh as when it comes to shipping eof and other features in yet another for in between pectra and veral well once again the state is growing time to wake up time to start uh taking the problem seriously

Tim Beiko: thanks um Andrew

Andrew Ashikhmin: um yeah from my point of view if

we can if we agree that both V and E are good things and we should deliver them both then my thinking is that um if we inut the EF into Spectra and then deliver vle that will be the fastest way to deliver both that's that's my intuition so that would be my preference youf inra uh and then vle um if that's if we are not happy with that then uh I am fine if e is excluded from pectra and then we deliver V in the next for I Osa my least uh preferable uh option is to have a fork between pectra and and uh and burco

to ship e because here I agree with Gom it will uh the state is growing and is I think V is more important than EF so I I uh yeah that would be I think to my mind that's the worst outcome

thanks um Jan

Dragan Rakita: uh just to address the statement of growing urgency for the verle we are talking about 10 20% of the longer transition time UF is not going to increase the state and three additional months that we will need to ship additional Fork are

not going to delay work for a lot if you're talking about 10 20 percentages not even that it's not like 2x so framing that inclusion of the E is going to Dam damage the ethereum is really bad to be honest that's it for me

Tim Beiko: thank you um Matt

Guillaume Ballet: uh sorry can I just respond to this

sure and then that's you that after

Guillaume Ballet: yeah I'm not saying EF per se is going to like the the size of EF contract I'm aware very are smaller uh well at least that's the claim and the

Hope um but I'm talking about the time it takes to deliver yes the state is growing Maybe by 20% uh per per year but but my uh my data is from last year so it's already uh it's already grown much more since then so and then once again uh the the state uh the claim that it can be implemented in three months doesn't mean it's going to be delivered in three months just a yeah just some Precision but I'm not blaming e for everything uh it's e and other features that do not that as a whole delay

delay

Tim Beiko: got it um

Matt

Matt Nelson: yeah no I mean I agree with Andrew here that this is essentially an opportunity cost and that if we kind of delay eof beyond the vertical transition that it might be hard to deliver at any reasonable timeline and the two Fork approach also seems dubious from a scope perspective uh and you know there's also the during during our testing are more efficient than what we have right now and I know there's a few ideas kicking around on how we can improve the performance of the transition um so I I kind of echo the point of reth and other folks that the transition time might not be the end of the world here especially considering uh the l2's position of posting stayed involves in these other

kind of reductions that we're taking but yeah I I I mostly see this as an opportunity cost from our perspective of of if we don't ship eof prior to veral it's going to be a long time before we see anything meaning full in the evm like that

thanks um Ginder H you're muted G there sorry uh it was mut uh so as you

Gajinder Singh: as you know what as you know uh from our blog post what the perspective of eum GS te is and uh we see that e if it has to

make the window it has to make the window by q1 uh for that uh you know uh the defet for EF needs to start as soon as uh p is shipped out and maybe if we can ship it out by October and uh so that that is our team perspective but uh in terms of uh in in in my opinion uh refactoring work on top of us will delay work at least by uh 3 months to 6 months uh with in so I think we can we we can try to uh do it in a quarter so it will delay at least by a quarter and uh that that is something that should be take

taken care of that you know it might ship workl onto 20206 rather than 2025

Tim Beiko: thanks um let's do Lucas again and then

CH

Łukasz Rozmej: uh so from my understanding so while understand it can be very frustrating especially for the people working on it but even if we go from twoe transition to 4-we transition those additional two weeks are so small in grand scheme of things to everything else that I just I don't know why why we are uh over uh stressing on it right in my opinion is okay it takes two weeks more that's not the big

deal

Guillaume Ballet: thanks well what I'm telling you is that it's not two weeks uh it's already two weeks a year ago so that means it's about uh well okay if if we ship next year which we W because of all the the extra two forks apparently or at least if that realizes uh we're already at three weeks potentially four is it uh is it uh going to stay linear probably not because my estimates were linear and clearly just from data a year ago the growth is not linear at all it depends uh it depends on what events happen on the Chain there's no guarantee it's going to be one month if we Ship by 2026

Tim Beiko: thanks uh

dragon

Dragan Rakita: I want to say that TF is one man job basically it's localized to evm and it requires one or maybe two people to implement additionally there's a b big uh group effort on the testing that's already started so we are not just starting e now the implementation spec and everything around that all the in finalized basically State

thanks uh Camille

Kamil Sliwak: I just wanted to quickly add the perspective in from the solid compiler I mean like for us like uh like I know like it's like uh on the client

side it's a different matter but like for the compiler youf is like a huge Improvement in terms of like uh implementation time for future food to deliver for example will be we already have like a lot of uh workaround we have like for things we didn't like we had to do before we had like feature of thef but we'll probably rewriting those parts of the compilers so in terms of that like having to write it once onf would be like a huge B to us and also some of the eaps that are included like access to the bigger area of Stack would help like also in the terms of like movements like those stack toos that are pling users so overall we're very

strongly in favor of of having this in PR as soon as possible

Tim Beiko: thank you so I guess from all this discussion um what the caveat that I think um yeah gu uh like obviously on the veral side is is kind of against included yet and uh it seems like like client is at least uh more in favor of keeping the the Petr scope as is um like it seems like pretty much every everyone else thinks that like we should do eof before veral and then the question is how this relates to like the current scope um with kind of some

people saying it's like better to breaking out in two forks and others saying it's better to have it all in one fork um one thing um I guess one of the risks I see of having everything together in like a single Fork now is that it lowers the speed at which we can test stuff across all the client teams because you know nethermind is working on some EIP and then WTH is working on another and Bas is working like on a third and it's really hard to get like uh you know like a new devet up where like we're testing all three against each other because they don't have the same subset of eips ready um I guess my suggestion based on this discussion would be um to include eof in like the

same Fork scope as Spectra to signal that um you know we don't want to open up a whole other Fork which would have a bunch of of different things in um but then to use kind of Dev Nets as a way to sequence like okay okay when should teams have stuff ready implemented um and and and and this kind of allows us to you know like make sure that we're testing cross client stuff uh kind of in a a gradual way um and and that we don't end up in a spot where like yeah we're waiting three months for everyone to have implemented everything and there's like not any cross try testing going on um and this would probably look like you know devet one is all the stuff we had in devet zero with like the spec fixes

um I'm not sure what like a definite 2 would look like if there's like some first set of eof eips that Mak sense to bring in and test um and I feel like if we if we go with it that way we can also potentially make the decision to like break eof into a separate like activation um uh yeah break break eof into like a second uh activation like they've you know decided to to potentially do on the El side with um with with pieras um but we sort of don't have to make this decision now right like we can um yeah we can keep moving on the devet um try to like coordinate cross client testing

that way and then if we see that you know everything else is literally ready to ship and then eof still needs a couple months of testings maybe we decide to um yeah maybe we decide to like uh separate them at that point um and like yeah there's two comments in the chat right now that like multi Forks have more risk and have you know more overhead um so I agree with that and this is also why I wouldn't want to like make that commitment today but rather like say that it's all part of the same Fork by default use devet as a way to sequence like what we prioritize in terms of testing uh on the multic client front and then if we see that um if we see that uh you know like for

some reason eof is going to delay stuff like for a very long time we can then make the call to split it out um I don't know yeah what do people think about something like that um I know there's a couple hands up that they were up before so

Greg Colvin: I'm I'm I'm sorry because the conversation veered while my hand was up and in the chat I still see discussion of whether we should do this at all and so I'd like to say just a little um we've been trying to get in what amounts to eof functions for about 7 years now I showed up seven years now and said Gee I can pick up my

research and within a year or so we could actually have a compiler from evm by code to machine code and that should help with everyone complaining that the evm is too slow evm is too slow I kept hearing that when I got here it was known evm is broken and for 7 years we've been trying to do what we needed to do to be able to compile evm code to machine code in linear time so that we could do it on the blockchain with it not being a denial of service ATT tax surfice and that has been impossible for

seven years now attempt after attempt to get it in every single time people come people go we explain again why it's necessary we're told again it's less important than anything else and it just keeps rolling and I had wanted to write this thing like before I retired uh and at this point I just turned 70 I'd really like to write that compiler before I die okay

Georgios Konstantopoulos: um this is Georgio from rest for what worth we have written a jit compiler um for evm without having eof so it's not necessary per se to use the

eof for that we do know that it makes the code produced more efficient and two we do know that eof removes the need for live jump dust analysis which is a very expensive operation which is part of the reason why jit could not be safe to do near the tip MH um would like to Echo some of the earlier points that the ethereum platform also serves its users which are smart contract developers the rest team also maintains The Foundry project and we have very good understanding of what do smart contract developers want and need and I think somebody wrote in the chat Ben Adams that yes large contract sizes and no out of Stack errors um are actually indeed

one of the most common solid the errors um and we really strongly believe that these should be fixed ASAP yes there might be other ways for fixing them for example there was a swap andan op Cod proposal a while ago that didn't come with eof um sure yes you could do it maybe other ways given there's a set of features you can get do it at once I personally think that's it's a huge benefit and also dragon from our team who spoke earlier he shared the whole document with like 10 bullet points for application developers uh benefitting so I guess I'm kind of confused at this point around why we're uh discussing this I think most teams have said they

like it solidity has said they liked it Viper has said there is some also some extra small things that they need to do uh they prefer to do some of the reentry things but also supportive um let's just do it why are we it is a bit confusing where we are where the conversation is at right now because the chat has been saying we don't mind extending the vertical transition by couple days the data says State growth is going down so that is a confusing argument in the first place and you have a bunch of application devs telling you this is a good feature um so yeah it's just confusing why we're considering not doing it given that most

people have voiced support and yeah I think the question is around the Petros scoping and not around on the you know what to do about veral it's literally do we do pectra now one fork um to Forks 2024 2025 so should we scope the conversation to that

Tim Beiko: okay yeah I guess that's kind of what I was proposing um and I think the I think it's really hard to predict like you know how much work eof is going to be how much it will delay things and all of that so I think you know what we what seems like everyone wants is to not extend the pectra scope significantly

Beyond potentially adding eof so like opening up another Fork would do that kind of by default um so you know putting everything in one fork um but then again like using Dev Nets as a way to coordinate on like what we prioritize in terms of implementation work what are we doing cross cine testing on and then you know if we find out later in the uh in the development process that for some reason eof is you know like a few months delay that we'd rather not have and we'd rather ship the rest of Petra we can make that decision to split it at that point um I think the the biggest risk I see of like increasing the fork is just like yeah again one client team is

working on like a subset of eof eips while the other one is working on like Petra core and then we we literally cannot ship anything um before everyone has done everything and we can't even test everything before everyone has done everything and that slows us down um so I think if we have like relatively like strong prioritization across what we test on dev Nets that would be uh like a way to manage this

um and I see team is there a world yeah sorry for interrupting you is

Georgios Konstantopoulos: is there a world where we do devite one stat with ap 7702 and all of the stuff that we agreed on the last time um and and you know maybe we do divet 2 three the same way and

then around divet 4 say around whenever it is we also add eof on it

that

Tim Beiko: that would be my proposal like I would do devet one for sure

almost like

Georgios Konstantopoulos: almost like a stretch go

Tim Beiko: yeah yeah but yeah and I think people should start working on it and like we'll keep you know adding some static tests for eof in in in the meantime but like yes I would not add I think like for devit one we have a bunch of stuff that came out of interupt that we need to test in a multi client setting I would isolate those changes you know get them tested on defet one ship that have it be uh you know stable then you know layer more stuff on top

um

yeah

Georgios Konstantopoulos: um yeah so it seems like CFI in terms of people working on it doesn't mean anything

Tim Beiko: yes so I would right now if we did this so I I would propose like we include we basically include the whole Suite of efps if this is and then you know if in the future we did we decide that like we need to split it out let's do that but I think by default we'll assume it's all shipping together um and yeah again just think we need to be mindful of how we approach Dev Nets but the devet specs are kind of independent from the fork spec so we already have a way to manage this separately

so I guess

Georgios Konstantopoulos: we' be supportive

of that

Tim Beiko: yeah okay and I guess yeah from the other client teams um basically including including it uh in the in the fork and then adding it into the dev Nets uh once we've tested everything else um okay Bas Su support kind of oh sorry yeah

Mir yeah

Marius van der Wijden: yeah as I kind of wrote in the chat I don't think that's a good argument that no one would start working on it because people have already started working on it even and everyone has started working on it everyone who needs to work on it has started working on it sure but I think I

don't really but um I don't think it's a great argument to say people will only start working on it once it's included because the people that need to work on it already working on it

Tim Beiko: that's fair but I do think like it's like stronger people are saying like we want want to ship this you know around Prague and I think that's what it like meant to highlight like changing the stuff like whereas there's other stuff you know like in the CFI that we probably won't do do or even try to do in prag so I think moving yet makes it like a bit clearer um if not for us like at least for like the I think the rest of the community um yeah

so I

guess but so

Marius van der Wijden: so just to make sure I understand don't most client teams have e implemented and at the risk of being too provocative are we not discussing whether G should allocate more resources to do it

Guillaume Ballet: I thought it was uh all you needed was one person to spend two months on it that's the claim your team is making right so we have one person working on it for over a month now that should be enough right

Georgios Konstantopoulos: okay great great yeah sure that that's okay with us I think I also think that's not the productive way to approach the conversation you young with all due respect and so I guess I wonder is what that what we're discussing

because they I that implementation Matrix I that showed which teams have implemented it

Tim Beiko: I think you know testing and devops also like making it like a focus on their end like so yeah I think you know clearly

Georgios Konstantopoulos: yeah exactly exactly exactly

Tim Beiko: okay yeah um but like yes I think on every client team there's someone who's been working on it um and like I don't suspect uh this would change uh you know if we include it like uh but like yeah it makes it clear like what's the full scope okay so to summarize yeah what I propose is we include all the eips in prra um basically the whole list uh you know I'll post the link but there's like

12 of them um and then we do devet one like we don't include them in devet one uh we do devnet one which is just like an iteration on what we had in devet zero with like the 7702 uh which we probably need to discuss after because it's not you know formally included but assuming 772 is included we do that we do um we do um like the changes that that uh we made to 2935 basically all the fixes coming out of interrupt we use that for devet one I think when we're ready to do devet 2 we decide you know like what else we want to include but I think having teams all coordinate on um having teams all

coordinate on like okay this is the next devet that we're targeting and this is where you know we should make sure that things are production ready is probably the most like productive way to move forward rather than having these like yeah 20 IPS that uh people are are sort of working on in in different uh yeah different capacities um does that make sense Barry um and then yeah meis has a comment saying like yeah want to make it clear that we can still remove eof uh even if it's included and yeah I think that's always sort of been true but so far it

seems like people want to actually do it and try it and then um and then yeah once we know how you know how well is going um we can decide if we want to split it or yeah postpone it or something like that but yeah having that be the defa default path that it would ship Al together in Petra and it would be minimal delay

Georgios Konstantopoulos: oh to confirm them that this mean that a teams are expected to implement and test the E B the EF testing team will be expected to start shipping or allocating actively resources on the eof testing and we should be able to start pinging them and maybe even

help them ship this more because we've been doing that already and I wonder like if now that's considered priority and we should go ham on it

Tim Beiko: yes and then the one caveat is like yeah for cross client testing stuff yeah we probably don't want to do uh um yeah for cross client testing stuff we probably don't want to prioritize eof right now until we have like just yeah implementations that are further along for both eof and single clients and then the rest of Spectra in the multi client context

Guillaume Ballet: um just reing on this isn't that what the the testing team is doing right now working on the that was my understanding

Georgios Konstantopoulos: yeah I'm just confirming

the case for everybody's context

Tim Beiko: um and I guess yeah Mario from testing uh you want to give yeah you're

dos

Mario Vega: yeah so yeah we've been working on including UF tests into the execution spec test in the uh for the past month and in the last couple of weeks uh we have uh really good progress um I think um if we keep up this way I think we F we should be able to fully cover um and I would I wouldn't say in less than a month I but I would say like maybe two months we will have full and confident coverage in execution spec tests um the great thing about uh

how we have been working now is that we have this isolation between euf and the rest of the prag e piece but it is really easy to just join evf into the full PR test set when it the when time comes um uh so now we have like this um releasing uh pre-release schedule um we have not done pre a pre-release for euf now but we will do in the maybe this week or or early next week we'll have the F the first EF only uh pre-release and it's really easy um for us to do so so we have been working really hard on the framework to make these things easier um to have features and in this case you have feature uh release only

for a test so that we will um try to make these announcements a little bit more clear uh in the future and we will uh have the test sets uh ready for for for you guys to consume

okay uh po yeah I I just

Potuz: I don't have any take on eof uh at all uh but I just wanted to mention uh that I haven't seen any studies like when people propose to include this or include that in a fork I haven't seen any report on how uh how

are these features testable in an independent fashion from the other ones that are already being tested and already being uh considered for inclusion the issue being that adding a feature even if it's been already worked out the testing is not linear with the number of feature is quadratic every feature that you you add if it cannot be tested independently it needs to be tested against every of the other features in an independent factions from the remaining ones and I think this has to be taken into account we are it doesn't seem to me that people are considering the amount of testing and the complexity of testing and how it increases with any feature that is added to a fork not against I'm just asking whether or

not this has been worked out if there's a report of this can be tested independent of that and so forth

Tim Beiko: yeah I guess do any of the eof or testing people have a yeah perspective that

Parithosh Jayanthi: yeah that's also been the point that I brought up in the eanda op uh document as one of our concerns um even just looking at all the CLE eips there a lot of them that have interactions between eips that we don't even know what parts to exactly test and yeah I think adding more and more is just going to make it even more complicated but yeah I do agree that at least the

benefit of eof is that um you can test it quite a lot in isolation uh while that won't be true for most of the

CLE IPS

Tim Beiko: thanks um and Charles your hand has been up for quite a while

Charles Cooper: uh yeah just um wanted to reiterate Viper's position which is that I don't think that UF is that urgent I mean like the see it in obviously I've been contributing um but uh eips for preventing re-entrancy are are are more important for users I think from a prioritization perspective um because um users are trained sorry smart contract develop ERS

are trained not to have non reeny protection sorry reeny protection um because of the gas cost and if it's cheaper then people will use it more whereas UF you know has some performance improvements and quality of life improvements

Marius van der Wijden: um it would be great to um so as far as I've s seen from solidity they they like EF but they also not been very pushy about it um so I don't know if compiler teams are not really pushing for it because they need it and they need it

done yesterday then I don't really see the urgency to it

Charles Cooper: for compiler teams EF has a lot of quality of life features um I don't think you need eof to prevent stock to deep Viper doesn't have stock to Deep like I said it does have quality of life improvements it improves performance um but from my perspective preventing reeny is like a huge massive security hole or whatever you want to call it foot gun for users and um EIP 7609 is small you know and it would let us prevent it at the application a lot more cheaply and

easily

Tim Beiko: I guess yeah from my perspective just um it seems like on the client side like everyone or there's like pretty broad consensus around eof and um yeah it's not clear to me how much support there would be for something like that and and I think what's also pretty clear is if we do move forward with eof there's very little bandwidth to do anything else it would already be the largest Fork by far um yeah I don't know Lucas dran is this what you want to

Łukasz Rozmej: uh yeah so this is about the AP 7609 a bit so uh we would be also uh for

the CIP though I think it needs a bit more analyes from uh eel developer perspective uh we uh want to run some benchmarks on it uh basically we also provided some feedback about um decreasing the cost a bit less so increasing the cost that was uh initially offered and we also think potentially warm uh s loads could also be decreased in price uh but yeah uh I think it needs a bit more analyzis uh and like a benchmarks being run actual numbers before we can fully commit to it but um it is a very small because this

is gas repricing basically so could also be uh I I don't think it's like exclusive to e we can also think about including it uh either in pectra or the next Fork after pectra uh yeah that's basically my comment on

on the CP

Charles Cooper: yeah I'm happy to like incorporate feedback um like fiddle with the pricing schedule a little bit uh there's some more benchmarks that I want to run unfortunately I've been very busy with other things um and any help with benchmarks is actually really appreciated um but yeah I mean I'm happy to fiddle with it more U but I think the thing I want to see is whether it gets in in the large you know

and can talk about the details later

thanks um J

Dragan Rakita: yeah I would like to say that I think this meeting is really good example Why Us in communication is very important because when I joined this meeting I was assuming that we are talking about if we're going to have one fork or two forks to be honest and now the this basically from few few people from the call they'll Shi in discussion if the Sol doesn't want it or not if the EF needs to come before

work

Tim Beiko: we've kind of Hing diminishing returns with this conversation and there's a bunch of other stuff on the

agenda we're probably going to have to kick out so um yeah unless there's any like strong objection now I would move forward with including e and pectra um again this is the entire list of eips um they're all relisted in 7692 um and then um yeah scoping devet one which we can do we can like finalize async uh to not include eof to include kind of the other uh pectra eips to make sure we get cross client testing on that um I think this will help you know uh everyone sort of prioritize multi client testing for everything non eof keep working on static testings for eof and then uh we can see what the best uh

scope for future def Nets after defet 1 is so yeah I guess yeah does this make sense okay um then next up I think the probably second most important Petra decision to make uh on this call is uh 7702 so uh we talked about replacing 3074 with that EIP it seems like there's broad support to do that um and then there's still some spec issues around uh 7702 so we discussed them on a breakout call yesterday uh but didn't quite get

to like a final conclusion on them uh but in short uh there's some concerns around just how we handle revocability um I know Andrew uh you posted about them on the agenda for today do you want to take a minute to just walk through hopefully Andrew's here otherwise I think suep from Aragon you were on the call yesterday

uh yeah so I I think it's about uh we feel strongly that we should have in protocol uh revocation and that it should not be optional which is what

is there in the current version of 7702 it should be a a mandatory um feature um and we are sort of exploring ways to uh have that revocability mentally revocability while also providing the W providers of enough breathing room to um you know maybe innovate and not it's not being too constraining uh so I think maybe yeah this week and over the next week uh we will be coming up with solutions for to that um we also decided that if there are no good solutions that we can agree on then we sort of move ahead with the version of 772 which is uh pointed out

in light client's PR

thank you um like sign we can't hear you if you're talking can you hear me uh lightly but yes uh okay okay now it's now it's good it's okay yeah yeah yeah

Lightclient: uh yeah I was just curious to but if you had a perspective on what the difference with the 772 proposal on revocability is versus what is spec for 3074 and was

accepted in Petra right now

Sudeep Kumar: um 3074 uh I think it had the same problems I don't think the problem of theability was was Sol there

Lightclient: right but we accepted 3074 into pectra with this property and Andrew even came out and said that he was very supportive of 3074 now that we have a way of having in protocol revocation even if it was sort of optional depending on what nons you chose so it just doesn't I don't really quite see what is different about the 772 proposal versus what we seem to agree on with

3074 like this is kind of why these this was put into 7702 because we were under the impression that this already addressed the concerns from client teams

Sudeep Kumar: right I think I think the scenario is uh about uh changing the uh changing the smart wallet and like they existing uh previous authorizations which uh which can still be used I think that's the major uh scenario that I'm concerned about and so yeah I think we should have a way to for the user to kind of revoke that which is baked in protocol and does not rely on

uh of Trust on what providers

Lightclient: is that not what is in 7702 right now like we have an in protocol revocation mechanism in 7702 for this exact purpose

but but it is optional the the bit is is optional

Lightclient: and it was also optional in 3074 and we have to rely on wallets to use some of these optional things like we rely on them to use the optional chain ID that exists in transaction types to avoid cross-chain viability

um yeah but yeah that's the

scenario that I'm concerned about and you know if that that gets answered sufficiently uh if if we trust like the if there's a good mechanism to do that in um in the proxy contract like I think there was a gist by you uh so I think yeah I'm willing to change my mind on that so yeah maybe I do need a few days in that

thanks uh yeah I'm addar you you

Ansgar Dietrichs: you mentioned uh proxy contract but like light client said the rication is in protocol if the nons is um like is specified so like why in

the proxy contract do do we need to look into it it's like in protocol like how you were asking

uh I I think uh like clients just had a way to uh kind of revoke things in in the proxy contract level so that that's what I'm referring to

oh and yeah it's yeah it's

Ansgar Dietrichs: uh but no like that that was how it was in 3074 but how it is in 7702 is that it's in protocol level not even on proxy level so even better

MH

yeah that's what like I'm willing to kind of change my mind like I was coming from a position where um you know it should be mandatory and it should be at a protocol level and maybe I was not okay with having it in um you know kind of trust the smart wallet providers for that uh but I I think yeah like like I said I'm open to kind of uh the change in perspective uh especially after like leing like clients uh just so yeah I think I need a bit more time on that

Asar

Ansgar Dietrichs: yeah I just wanted to to say that um kind of the 7702 authors have also

kind of bra brainstormed a little bit on on potential kind of solutions for this and it does seem in general that indeed I mean many people have been unhappy with this general property of 7702 that you kind of have these sign that are floating around and can be used in unexpected moments at at any time basically and well I think the Aragon team right now is the only team that actually basically would have this be a blocker for them I think a lot of people share that General uneasiness and so in principle it would be preferable to find a mechanism where you basically have a more permanent way to store the currently active delegation Target for an account on chain and then basically have specific operations that ideally also signed over the account nons that basically bump that delegation Target to

a different delegation Target um there are actually several ideas how to do this so for example you could basically either do it I think the most elegant way at least in my opinion would be to just basically use some sort of special UF version just temporarily until we get to ver with then we could um have it more natively stored in the in the um as an extra account field or something um and basically slightly change the way 772 interest work so that basically you have two different versions one of them changes the delegation Target and Des signed over specific nons and then you just have a flag of like hey this account is supposed to have delegation active for this during this transaction would not have to come with the signature at all so the only problem here is that in terms of PR we are

already like relatively late in the in the in the pork um process of course this will take a little bit more of time of to figure out um and so yeah I already said that earlier in chat like if we end up kind of having having some sort of smaller scope of pectra that is ready to early and we're thinking about what to split out to me basically it would be worth taking like two extra months two three extra months making sure we have the best possible version here of 7702 because it does seem like we there's a scope here that would basically make everyone happy

Tim Beiko: so I guess given that um and I think yeah people generally want 7702 and you know we had included 374 in the past um I'd kind of do something similar

to what we did with eof so I would include it in the fork and maybe not have it part of like devet one or you know even Dev that to if like uh we're not we're not quite happy with uh where the spec is and then spend the next you know month or two like two months feels like it's probably bit too long but say like the next month actually uh ironing out the spec so that we have like a a revocation mechanism that's potentially better than what's proposed now um it doesn't seem like a huge EIP to add a bit later in the process like you know on say devet 3 or whatever um if uh even if we change nothing um but then this saves client having to like Implement different versions of it um if we we

feel there's like a high likelihood it's going to change um so that makes sense people like yeah

georgeos

Georgios Konstantopoulos: ER quick question so if devet zero spec was what we did in Kenya and if we don't do 7702 then DEET One spec diff from def zero would be just the EAP 2935 changes

Tim Beiko: yeah removing 374 2935 changes I feel like there was something else um and I know Mikel has a bunch of small changes he wanted to cover as well so maybe some of those

Georgios Konstantopoulos: ah right

right but

Tim Beiko: um but yeah so like high level uh yeah high level we

would uh remove 374 from the death net uh and potentially not have 7702 and then basically spec changes on like every everything that's already there um yeah so does this make sense to people including

37 and

Georgios Konstantopoulos: and sorry like Richard asks a good question was it already formally decided to replace I'm sort of yes based on what you just said maybe worth so

Tim Beiko: like last call we basically removed 3074 because we knew we would not do that given that 7702 was still being like was like a better alter alternative so I think there was broad consensus that like we we'd rather do

772 than 374 the reason we didn't include it on the last call was because we uh saw there were still some spec issues I think you know there still are today but like if we are kind of trying to finalize the scope in terms of what eips will be worked and iterated on I think it makes sense to include it um but then yeah not have it as part of the Deb net in the same way we're we're uh holding off on eof so that um yeah so that we don't get clients like reimplementing different versions of EIP if if we can avoid it um I think this does mean though like I guess this does mean that the 7702 people and like account traction people like need to make this a priority in the next month or so to uh yeah and I guess yeah look like client said you

know we can consider putting it in the next um in the next evet too like if if we feel we learn more by implementing it as is um then we do by like then like the time we save by not implementing yet like I don't have a strong opinion there but we should just be mindful that we're we're likely going to put something in and and tweak it so so I guess to start like anyone against having it in the fork regardless of which death net it lands in if not um yeah anyone against having it in the devet one spec even though um even

though it'll likely change um you know based on yeah iterations okay and then Anar said that's like you know any final version would probably share most of the logic so probably minimal changes so okay let's move forward with 772 in the fork um add it to the devet one scope so devet one would basically be um everything that was already included plus 7702 uh minus 374 which were already removed and then e is not uh included in devet one um and then yeah I think probably the next most important thing

is to go over these uh spec issues that Mikel uh brought up um unless there's anything else left on 772 people wanted to discuss okay um in that case uh yeah Mikel hopefully you're still on um I guess in the order that you've put them I'll but the yeah first one was the execution API PR

Mikhail Kalinin: yeah U thanks team I'll just G briefly go uh through all of them if anyone has any comment uh raise your hand or just interrupt me um so the first one was the um y trigger it

request as a side car so during the last week we've been exploring the idea of um um processing the El triggered requests uh like uh withdrawals deposits um and consolidations potentially as a side card to the execution payload so basically um it means that they're not a part of the execution payload but the execution layer returns them uh in the get payload um method call so CL can take them and uh incorporate them into the beacon block body and keep them in the beacon block body and then can send them to um El uh why new payload method to validate them um this idea was uh

this idea is appealing because uh the main the consumer of those requests is C uh so let's just keep this data in the on the C side and Y will not have to do this uh all this uh work related to storing them in the block and yeah and some validation can be admitted so it's a kind of like alternative to 7685 EIP which is general purpose request uh EIP and yeah after a few iteration on that uh we conclude that uh the original um design kind of breaking the um optimistic Sy and one of the edge cases and to avoid breaking the

optimistic sync we would have to keep uh at least requests root uh in the execution payot header in the execution block header uh so the commitment to those requests needs to be kept on the um El side and uh it creates a cross- layer complexity where you have data on one uh on on C side you have the commitment on the El side and you have to uh verify that the data actually matches the commitment and yeah there is a discussion threat in this u in this PR uh so the conclusion the final conclusion is that uh with after itating on this um uh it seems to be um really a

quite marginal um benefit that this uh proposal brings uh and the engineer complexity kind of in my opinion personal opinion outweighs the um the benefits so um I tend to personally I tend to leave everything as is with 7685 and forward uh just wanted to bring this up because we brought this up during the previous call and yeah this kind of an update on this stuff um next is El consolidation spec

Potuz: um so can I can can I quickly comment Misha on that on thatal in particular uh it's not that it's a killer but I would

be against and strongly against any commitment for get payload to return something that needs to be included in the beon block because I would want to have I mean I'm it's public that I'm strongly advocating for epbs and I want to have that separation of concern of concerns being kept so that the bom block should not be uh contingent to the payload already being present anything so withdrawals deposits whatever it is I do not want to have the Bon block depending on something that the payload needs to have because this breaks the flow of

PVS

Mikhail Kalinin: right and it does not break it doesn't breaks with the um blobes and the kg commitments as of today

Potuz: well it it is more or less the same situation it requires that then the builder needs to send the blob kcg commitments in the bid so that's why it's not a killer but whatever whenever you break this separation of concerns that the payload needs to include something so that the beacon blood includes it includes it then that thing will have to go on the bid and it makes the Bing process more complicated

so

Mikhail Kalinin: got yeah yeah yeah thanks for sharing this

yeah okay well

Tim Beiko: okay so closing this PR yeah okay okay cool next one is like the E consolidation

Mikhail Kalinin: yeah e consolidation spec uh we had been uh working on the E uh e trigger smart contract the system smart contract um dur in the interop uh we have uh it's this smart cont track finished need to write some tests uh as a followup to the smart contract uh there is a PR to the E 7251 which is the max effective balance increase uh which introduces the alter gr consolidations um and uh it has the the

spec now uh it has the smart contract code there is the U transaction um to deploy the smart contract um so uh and also there is the corresponding uh change to the engine API which introduces consolidations it would be great to get some early uh feedback on on these two PRS before uh we can before basically we merge them um yeah also ideally we have this in devet one but uh it would be great if uh someone can check the that this transaction actually deploys the code and yeah I'm kind of U I did not do this check and yeah I need some help here um

many thanks to like client who who's who has worked on this uh on on the similar stuff for 7,002 uh and yeah the spec and the smart contract basically leverages on his work pretty much okay so the next one is uh the uh align withdrawal request with one uh with uh the EIP and consensus pack there is the this this PR is about renaming it renames the uh validator public key to to The validator POP key as it is in the as it is uh yeah this changed to the engine API so the engine

API uses this long validator public key name while the EIP and consensus PC uses validator pu key and I I think that uh this as far as I can see in the comment B has implemented it as well there POP key and the engine API so I think that this discrepancy will fight us here in there uh and it is better to do the renaming and align the names everywhere in all the spec documents uh the problem is that basically the El and cl has to do adjustment on their on their sides uh so and yeah it would be great to have this PR merg soon so please take a look rise your concern

but I think we just merge it and have it foret one probably also uh it needs to be taken to account for high tests that uh yeah that needs to incorporate these changes well okay and the last thing uh is the um SL discussion around engine uh get payload bodies uh requests uh we we are extending payload bodies by uh deposits withdrawals and consolidations now and uh uh the question is actually we already have these uh methods uh version two of this uh of the payload bodies

method in the in the engine Epi spec and Sean actually um came with an idea that we we we could extend the we1 uh data structure and and extend actually we1 methods and in this particular casee it can work because it's backwards and forwards compatible uh but uh I don't know if want to do this uh from my perspect from the spec perspective and probably from testing perspective it is cleaner to introduce V2 uh but from the um uh uh execution layer client perspective it's probably easier to keep you one and just extend it instead of uh introducing couple of new methods and do do some pumping so it would be just

great to have more to see more comments uh in this um um in this PR that introduces we too and yeah so we can make the right decision and ideally also uh if we if we want to change if we want to switch back to V1 and just extend them so ideally we can do it before devet one yeah that's pretty much all I had for today thank you

Tim Beiko: thank you um I guess my proposal for all of these so like the first PR uh the one that had issues with epbs we we closed that one but then for the three other ones uh one of them I guess is already merged so um

by default I guess we would include it but then um the uh the E consolidation one I would lean towards we include it in devet one tentatively and like uh over the next week or so people can review and then uh ideally we merge it before ACD DC next week so that it's clear by then that like you know this merged PR is included does this make sense for everyone okay no objections um oh Sor is a message

Alex Stokes: I was just saying we didn't really test consolidations in De at zero so be prepared for this to bring up some more bugs but generally yeah I think

this is the plan to move to e consolidations so I think what you said makes sense

Tim Beiko: so um okay last agenda item around uh potentially pectra but uh potentially another Fork so Gom you had posted around deactivating EIP 158 uh because of some uh potential interactions with veral um yeah you want to give some context on that

Guillaume Ballet: yeah um I mean the the general idea is that from from what I gather uh ip58 was a temporary measure that was meant to to avoid some some use case uh that

has to do with with the Shen attack today the the this this turn of event cannot really happen um and now with 7702 we have the problem that you can again find some contracts that uh would be uh with an empty n with an empty code hash sorry not contracts precisely EAS you would find EAS that have an empty nons that have uh zero balance that would have an empty code hash and uh they would therefore have to be deleted with EIP

158 the problem is that this these EAS because of 7702 would have state would have storage and that storage would have to be deleted except with veral you can't uh this is one of the reasons why we disable self-destruct and I would argue uh we should treat EIP 158 exactly like we treat self-destruct namely that if you start creating an account uh and immediately delete it or uh gets that that then gets deleted by EIP 58 in the same transaction then it should be uh it should be removed or not make it to the

state but once it's made it to the state it should remain there um yeah otherwise we will find ourselves with dangling uh well potentially dangling Storage storage slots in the tree which uh might have some NE negative impact at a later stage uh which is I'm trying to remember there was an EIP Push by Gary that it was about deleting uh these uh this storage sorry it was not about deleting the storage but we resolved it by saying during the vertical conversion we will delete those uh those storage slots uh yes 76 10 thank you and uh yeah we would find a new with 7702 we open up a new

way to produce uh to produce this kind of uh this kind of situation um so if we disable uh if we disable S store in 7702 we could somehow avoid this problem but I still think from a purely correctness point of view uh EIP 158 should have the exact same behavior as as self-destruct and yeah that's that's the gist of the of the of the argument um I'm just wondering if there are counters to that

Tim Beiko: I guess uh one question or like the comment back ongar is you know depending on how we uh change 7702

this like these accounts might not have a nons of zero would that be like assuming that 7702 incremented the nons would this make this change obsolete or would we still need it for some other reason

um I

Guillaume Ballet: I would argue we still need it but at least form Co coherence between the behavior of self-destruct and one well the current 158 but yes we we discussed that was actually the first idea to in increase Don nons uh we had the conversation with several people in the guest team and it appeared that was going to be fairly tricky to do uh when there's no reason to keep 158 around so that was the argument it might it's the

simpler the simpler approach uh but yes we could potentially if we manage to increase the NS exactly when we need it that would be a possible uh way to to circumvent this problem as well

Tim Beiko: got it uh I guess so yeah there's a comment on Dragon saying like it would be nice to have this discussion async um so we can like understand the issue better um so I I guess my proposal would be um yeah if we can have like an EIP or Proto EIP for this um yeah that that's probably like a better way to Anchor the discussion

Guillaume Ballet: um uh yeah I mean that would be the point but I'm also trying to get some uh

early feedback before I spend time WR writing the the EIP I saw a comment like yeah I'm on mobile so I don't really have all the comments but I saw a quick comment by uh by uh luk wookash no we it cannot be activated at the same time as Vero it has to be activated at the same time as EIP 7702 otherwise we would have well or we decide to delete all the storage slots during the conversion as well but the problem is that more accounts more empty accounts will find themselves with storage and that's uh yeah that's uh that's the risk actually wait no because then you could be you would be able to delete them okay yeah I

guess it can be delet activated at the time

Tim Beiko: but yeah so I guess it seems like there's like you know no objection or like no like it generally seems like a good idea to spe out um yeah any other comments or thoughts okay thanks yum uh next up uh I believe we had Piper to talk about uh 44s and portal um are you still on Piper

Piper Merriam: I am hello everybody all right um so we had our Summit um we've we've discussed kind of

like what eel client integration looks like looked at our last client to join the network um I'm curious if we to hear from El teams um possibly individually on kind of like what y'all's stances on four fours on this um we uh our last client that entered the network took six months to implement our spec they did that without really uh asking us for any support they they read our implementations they read our specs they implemented our uh cross client tests and it took them about six months uh to implement history Network um I think that that timeline can be sped up uh

especially with support and help and guidance um so we think that if this is a priority for El teams that if El teams uh are able to get started on 44s integration um in the next roughly two months that it is very reasonable to have some of those teams be done by Devcon and those that aren't done to have really significant meaningful progress done and delivery ideally probably by the end of the year uh this is an effort that like our uh that the portal teams are absolutely here to support um and if El teams are interested in running with this uh we're here for it um so I'd be curious um to

hear from any teams that have opinions on this whether this is something that you'd like to do um yeah that's the gist of it

Tim Beiko: thank you um there's a question by Perry yeah if the security has had time to look at portal um is the implementation audited or reviewed um or just like yeah what's the General Security status

Piper Merriam: uh to the best of my knowledge no I'm not aware of any security teams that have looked at or audited portal

Tim Beiko: um and then yeah comment by Anar around

the seems like every cent team can decide whether they want to bundle it with their main client um uh yes the um I I I think that the recommendation would be that clients Implement um their own uh client to the network but bundling an existing one is absolutely an option and I don't know this is a conversation I'd be happy to have with any client team who's trying to decide which path they want to take um I don't think it's a decision that we can you know it's it's not a decision that I can make for them or anything that any other questions comments and I guess is the history

expiry channel on the R&D Discord still the best place uh to chat about this stuff

Piper Merriam: yes uh the the history XPR Channel we're monitoring it actively if people have questions we will be there for it um I think the timeline for delivering this this year runs out in about a month and a half to two months that's about the timeline where if we were going to ship this by the end of the year um it would be good for client teams to get started in that timeline and similarly we'll all be together in person um for Devcon later this this year and and if client teams get started and get working on this that sets us up to have a very

uh impactful and kind of like meaningful in-person event around portal at Devcon um within that timeline

Tim Beiko: so sweet anything else on the portal

Piper Merriam: um Can El teams report on where they're at with this I I gotten a lot of Silence in these questions and I'm curious to hear back from El teams whether this is a priority for them because if it's not I can anyways I'm curious to hear the answer to that question

Łukasz Rozmej: so overall it is a priority we had I meeting yesterday with uh portal

team the problem is that there are so many priorities it's sometimes uh hard to uh juggle everything correctly uh so it's the less urgent priority compared to for example the hard Fork right uh but yeah we never mind we'll be working on it and we will prioritize it

Matt Nelson: it's a similar answer from the baser team

Guillaume Ballet: uh with gu I don't think we discussed it yet uh So currently it's not a priority if if it makes sense we're happy to revise that uh but yeah we haven't really uh we haven't really uh looked into this

yet

Piper Merriam: cool uh any teams who are interested in scheduling a meeting or talking about this more asking questions we're here for that thanks guys

Tim Beiko: thank you um okay wow I think we made it through all the technical stuff on the agenda um so I had um I had a doc that I shared uh on the agenda as well so uh we had some conversations at interop uh and I've been having these similar conversations with many of you for much longer time around ways we can like tweak the cvip process and use ethereum

magicians better to uh yeah make things more efficient um I think yeah there was a bunch of proposals in there um but like I think maybe the two that are most uh like important or like that like yeah would be good to have live feedback on are one um this idea of having EIP review requests so um I think it's come up a lot that uh when people present the IPS on aord devs um most folks don't have like context on them and and then it can be kind of a like yeah low value discussion because people have not gotten up to speed um so one tweak uh that that came up was the idea that um

when people put eips on the agenda for the first time um instead of having like a Long Live conversation about them we just uh you know like bring up the concept like does anyone want to review these async before the next call um so people basically get uh two weeks to look into it um and then you know we sort of default only discussing something live on the call if there's been like a like a review request uh made before and um yeah so I guess I'll pause here like does anyone have uh yeah an objection to that okay uh if there are no objections

yeah if there are no objections to like this uh I think we can give it a try and and see how it goes it's a pretty easy thing to switch back um the second one's probably like the most uh yeah impactful and you might not uh make a decision on this today um so uh people uh when I ask people like whether they thought uh this CFI status was useful people said generally yes but it's kind of hard to figure out what it means and it's hard to see like what's all the eips that are proposed what are like the CFI ones and then which ones are like actually confirmed for the fork and um as we were discussing just you know earlier around eof even when we like quote unquote include something in the fork there's

always a chance that we we take it out um so one proposal I had to make this all kind of more legible is um adding uh a stylist before CFI that's proposed for inclusion and this would be like the canonical way someone could propose an EIP for a hard fork and what they do is just uh open a PR against a meta EIP and add their EIP in the list under like a PFI section right now it's kind of weird where like on eath magicians people sort of propose them they propose them on the alord dev's agendas um and there's like the eth magician thread and some GitHub issue in the uh CL spec report that like tracks the proposed theps um and it's just kind of a weird you know hard to

find resource that like is is effectively like um yeah like not like lives kind of separately from all of the other information around um around the fork um so yeah this would just add a section to the hard Fork if you want to propose ANP for the next hard Fork you open a PR um this gets merged in CFI basically remains as it is today uh if we want to formalize it some more like there were some ideas around um there were some there were some ideas around um um you know as soon as a single client team you know would like this to maybe be in the fork we CFI it or as soon as two client teams bring it up we CFI it um so and and to ongar's comment like you know CFI earlier in the process

to like give the signal to people like okay this is the subset we're actually considering and then what I would also suggest is we rename included to scheduled for inclusion which kind of conveys a bit more that you know the default path is we're going to ship this but as always if we find some security issues or some you know Blocker we you know we reserve the right to take it out and then once the EI once the hard Fork ships and we move the EIP to final uh we currently clear all the CFI stuff from the from the meta EIP so what we would do is uh clear the proposed clear the CFI and maybe rename scheduled for inclusion the included which kind of denotes that it's actually live and on the network um so now we only have three

minutes I'll pause here any thoughts comments and I guess yeah one last thing I would not do this for pectra like I think it's pretty far in the process uh to like change things so like this would be for like the next fork and onwards okay if there's no objections on the call then what I'll do I'll open a PR um to like formalize all of this and uh get some feedback on that um and we can can discuss it later um it's not a super time critical thing um and yes I guess yeah before we wrap up um there is

a breakout on pias and a breakout on epbs next week uh or sorry the epbs one is tomorrow and the P Das one is next week I'll post both issues in the chat and then lastly with like two minutes uh there was uh something by the testing team around Comm Channels with client teams um I don't know if someone from the yeah yeah

Mario Vega: so yeah basically the proposal is to we have as as it is right now the R&D Discord server it has like testing channels all over the place uh there are several places uh where one has to go to obtain different information for testing so we are proposing now that we create a

new subgroup channel um just the way that we have like uh uh pectra sharding cross layer and so on we will have a new subr uh call testing which could be the new way should be the new way that uh we one gets their uh testing uh release information and all the testing related uh discussion happens so this will be like the one stop uh for for the client apps to go and to check testing information um we have a link in the in the agenda that you can uh go into and take a look if you have concerns about this change uh please just uh raise your voice and we will try to make it uh better but yeah if no one opposes I think we could go uh live with

this one um but yeah thanks

Tim Beiko: okay I know we're at time um any quick comments otherwise um yeah otherwise let's yeah uh Mariel do you want to maybe post this link in the alev chat uh so people can comment on there but if there's no objection and some support then we can make this change in the next uh next week or so

Mario Vega: yeah absolutely I will uh send the link right now

Tim Beiko: awesome thank you um anything else before we wrap up okay well yeah uh thanks everyone I

can't believe we got through the entire agenda um yeah see you all tomorrow on the epvs breakout um and please check the PM repo for all the other breakouts of the next week or so and yeah talk to you all soon

thank you thanks thank you yeah by thank you

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