All Core Devs - Execution #190

Transcript

[Music] than [Applause]

Tim Beiko: and we are live uh welcome everyone to acde number 190 uh pretty light agenda for today um yeah so uh some Petra devet uh and 7702 discussions and then uh two quick shout outs or three quick shout outs um and that should be it um yeah so I guess most important uh thing today uh Petra and devith one I guess first off um maybe Barnabas or Perry do either of you want to give an update on like the spec and and sort of infite of deth one and then we can

chat with different teams uh about their specific progress

Parithosh Jayanthi: yeah I'll talk about Petra and then babus can do e or and or P um so Petra uh I can share the link to the spec but the decision last week was that we would basically do the same as devet Z with the main change being uh EIP s San 02 there's a thread in the interrupt chat where we're collecting status as well as which branches to use um I think some CL devs have already posted their branches and El have mainly indicated that it's a work in progress so there's no there's nothing to really use right now uh so that's the current status we're just waiting on um ready branches

to start with

Tim Beiko: thank you and yeah so uh there was the there was the 7702 change and I think we had a couple PRS um mostly in the execution API uh and a few on the engine API anything else on the specs for the Petra devet one and maybe yeah before we do e and pias uh I guess on the El side do any teams want to share specific updates about where they at and uh yeah how how the work in progress is going if not I will call on

you and base you I see a lot basic people on the screen

I

I can give an update um so regarding 7702 um we have like a first uh version implemented um we had some questions the gas pricing of the operation but I think it makes more sense to discuss this uh offline um but yeah we have like a first version that's um some some tests are missing but otherwise I I think we are more or less good to go

Tim Beiko: got it and 7702 was the last blocker like the last thing

you you needed

yes because the stuff should have should be ready for

for definite one

Tim Beiko: awesome thank you

yeah

Marek Moraczyński: so nether mind we have draft PR of all the changes needed for packraft definite one in branches now we need a little bit more time to review them uh merge them together and write some uh un need tests yeah but that's it

Tim Beiko: got it

I have a more of a question yes if you don't yeah so my

question is the E testing I mean Dev net one is going to be separate from the definite one for a picture right yes that's okay got it thank you

Barnabas Busa: as in what uh the idea is that we're going to be having on top of Prague so uh we would need to most likely have to rebase on prag on top of prag that's what we agreed on yesterday on the euf call

Tim Beiko: yes so we have

um yeah so so we have uh eof spec on top of prag and that feels like the right thing because there's no world in which we do eof before

prag

Barnabas Busa: the only issue that can be is that you will have a harder time debugging eof bugs if there's still uh some Prague bugs present so

Tim Beiko: yeah and I guess I don't know it's even if that's true it still feels like the right

approach in a way because like we want teams working on the the core of Petra yeah and you know fixing those bugs so I yeah I I it seems more reasonable than like basing it on top of the previous fork and then having to potentially like rebase it on prag really late in the process and then also finding all those bugs um but this is yeah I don't know if someone has a strong opinion against this okay and we get yeah we can go back

to the EOS Dev discussions a bit after but I I'd be curious to hear from other teams just on the the like uh Petra devet one um yeah how things are going um Andrew

Andrew Ashikhmin: uh right so uh about one we have a draft implementation of 7702 but um I haven't reviewed it yet so it's I'm not sure like how far it's it is from a mergeable version uh uh we haven't I don't think we have tackled the changes to the engine API but hope I don't know I haven't looked at them

hopefully they are not that major uh and I have a question about an update to 7251 because it seems that like the um uh increase the max effective balance because previously it was a purely C change now it has an an e component so we haven't implemented that yet but I'd like to just double check that means that for devet 1 we effectively have uh 7251 on the L

side right yes

Tim Beiko: that's correct so the is it the is the pr you're talking about the one I just posted in the chat the E consolidations yeah yeah yeah yeah yes so yeah yeah we agreed to include that in that net one

oh

Andrew Ashikhmin: okay so yeah we have to implement that as well got it

Tim Beiko: okay thank

you you anyone from reth or gu Orum JS uh yeah oh sorry from red

Dragan Rakita: side uh we started implementing 7702 it's only missing AIP and uh it should be like finished like V

or something like that yes basically before the next

ACD sounds good yeah eum GS

Parithosh Jayanthi: also has the similar object we are working on 7702 and maybe in a week or so we'll also be uh ready with it

sweet anyone from gu

Tim Beiko: okay um no one from gu uh it seems um okay so uh clearly yeah there's still

some work to do on the El side here we can check in on the next call um the one thing uh I guess this is a bit out of scope oh marus is here this no one not from rest speaking from guest speaking so okay I

can I can do it

Marius van der Wijden: um we still missing 7702 um I think and yeah we should implement this this week and be ready for defit one soonish

Tim Beiko: awesome um and I guess okay on the 7702 front um I think yeah we we should leave

the spec as is for devet one but if we look in the future uh for devet 2 we we still didn't quite find like a revocation mechanism we were super happy with um I I guess yeah has anyone does has anyone looked into this are there um yeah are there updates just on on the spec side for 7702

Lightclient: I've got an update that I wanted to share but first I I've been offline for the last couple weeks I wanted to hear if there were any updates not related to this new revocation idea that that I opened a draft PR for yesterday maybe if Aragon has something that they found

during the last couple weeks looking into the revocation mechanisms

Andrew Ashikhmin: is s deep on the call yeah yeah uh yeah

there was a comment from frano in the a magicians which discussed about account based revocations and uh yeah I think that's the best solution that I can put forward right now well uh so maybe life can uh look at that later on

Tim Beiko: what was the idea of the account based

appication

it was basically uh keeping track of um the template addresses that you

revoked in either a system contract or or for the uh EA's storage itself and when a 772 transaction arrives uh the um the execution L will basically check if um yeah the template address is um already revoked and if it is then it's it fails

Lightclient: any yeah I responded to this on these magicians and I as I said like this we we can imp this as an ERC I really see no reason to implement this in the protocol

Andrew Ashikhmin: I think there was another idea

with Max Noms but I'm not sure about uh what's the current thinking about that

Lightclient: uh if it's the same mechanism with maxn that we had previously approved in 3 74 I think it works okay but I I didn't get the impression that most clients like the idea of having some way of bumping the nons in larger increments than just one so that wasn't a super nice aspect of it uh I don't know maybe it's worth me

just mentioning this other revocation idea that yeah come up with CU I do think it's a little bit similar to what sud is asking for the proposal by fenio on East magicians was basically trying to address the fact that it's not as easy to see what types of authorizations you have in the air at any given moment and it's difficult to know like what has been revoked and what's not been revoked there's design patterns that avoid these types scenarios but the reality is that maybe we won't know how wallets are going to use this and um to have a more

defensive mechanism an idea I think vitalic mentioned it on the last call or maybe it was in a breakout room but instead of having the authorizations be these temporary things that must be included with a transaction to set the code in the account we can instead save the authorizations so that in the account you can actually look to see what code the account has delegated to at any given moment and this definitely changes how we think about 7702 and 3074 because now you know we're not providing signatures every time you know once you've authorized the

delegation the delegation is there and if you want to revoke the delegation you could send another authorization to change the code to something else even the zero address maybe so it is changing how we think about the authorizations in a lot of ways but ultimately it feels very similar it feels like it provides the same functionality while also avoiding these issues of having the outstanding offs that users and wallets might not remember and it feels like it resolves this discussion that has been ongoing for a long time how to do revocation because because the offs are no longer required every time you use the account

they are just single use authorizations now once you delegate to a in a in uh address of code with an authorization your nonsense bumped that invalidates that authorization that authorization is no longer valid so that's kind of the idea it feels pretty good to me in general so far if anyone has concerns would love to hear them the one thing that has come up in my mind is it starting to look like a protocol level proxy and if we do that we need to be very cognizant that this doesn't become a way which smart contract developers use for

applications so I could imagine if this was like really cheap type of thing to do it might be better for say Unis swap to deploy pool contracts using this like eoa proxy method and I think that that is something to avoid but in general it doesn't feel like there's many other major concerns with this approach

um Eric hi uh yeah

so um obviously just getting into this because it's a new suggestion but uh I voiced some concerns in the the mafia chat I think that this actually doesn't provide the same

capabilities as before so I think it actually does limit the usage in a pretty meaningful way which is instead of having a recommendation of generally using sort of like a single smart contract or even just to use something that looks like a 4337 contract here we're basically saying you can only do one thing you can only use one contract at any given time you're committed to that contract uh um and that's a big change because both 3074 and 772 all of the versions until now basically allowed you to have a design space of how you leverage this capability um and uh that

like that this this this is a new design space it hasn't been resolved what's the right way to use this and this literally puts the limitation and says there's only one way uh and it has to be a single account that's connected to a single account uh for forever kind not forever because you can change to another single account um so I think it's a pretty big

Tim Beiko: can you can you go into maybe a bit more detailed into like what's a use case that would have been possible before that's not anywhere

yeah so uh I thought about an example again like it's a very preliminary example and I think it's worth differentiating between use caseing capability there's definitely less capability here will over time

understand what are the use cases right yes but I think just a simple idea of a use case could be I might have uh an account that I have for very long-term things like key backup right now eoa has like the backup problem uh what if I have some long-term account that's very optimized for security that helps me avoid uh um like you know not having access to a keys or handling will and inheritance and things like that and on the other side I would have like more short-term account that is for example delegated access to a private key that is less permissioned in my account or batching or gasless operations or things

like that that are more day-to-day I could do that with the previous version I cannot do this with this new version I'm not saying it's a great idea maybe not that's correct

Tim Beiko: why can't you do this

Lightclient: that's just not correct

unless if I understood it correctly once they have 1772 the delegation active I cannot do other 772s at the same time that use different code

Lightclient: you're you're over indexing on a very specific design pattern that was coming about from 3074 from the last design of 7702 would you can do is you can delegate to a Smart account that has a plug-in system that allows you to add other plugins that do exactly what you're

saying the functionality is retained it's just in a different mechanism a mechanism that's much more forward compatible with the future of having everyone using smart accounts

I

I agree that there's other ways of implementing this but it's a different thing you're basically saying you can design a different it's a different thing but the ultimate functionality is the same

Lightclient: what you're saying is the functionality is different and it's not well the functionality the way that we get to the functionality is different but the end result for the user is identical

not exactly because if the user install calls a malicious plugin for some reason your plugin system is not perfect then in this situation that

malicious plug-in will have access to much higher permission actions or like to a different every 772 message

you sign has root access to the account

Lightclient: if you sign a delegation to a hot wallet that is insecure for some reason even though you had an ultra super secure backup recovery mechanism that hot wallet 7702 invoker thing that you signed to has root control of the account could steal all your funds so it's not a reasonable argument

I

I agree to that but again you're saying basically that that system that has two wallets is not a valid design by anybody ever I'm not sure that's a statement

I would

Tim Beiko: I don't think I don't think that's

the that's the argument though the argument is can we find something that we're comfortable shipping the L1 that introduces a lot of value to user um and has you know minimal kind of side effects in terms of the design restrictions um so obviously there's like a trade-off where like the most permissive thing you could ever do will have the most security risks and like I think we've heard from many client developers that they're uncomfortable if um you know say there's just no revocation or optional revocation doesn't get used a lot um so it's it's it's not about like can you enable every possible use case but like can we find some set of use cases that are valuable for users um that we think leave the

protocol you know secure or at least that the tradeoff we making in terms of the risks we add you know are are like sound um and yeah it is it is very possible that like at least a first version can't accommodate every possible use case but it's like is that still a net Improvement on on today um and I will highlight you know like Marius has this comment uh saying we can always ship nothing but but like we should sort of see this as the status quo in a way where people have been asking for something like uh you know 3074 or similar for like many many years and the status quo for the past five six years is we've shipped nothing because we

haven't found anything that you know satisfies the sort of constraints around security and and like exess expressibility so um yeah just want to say that's the angle through which I would look at like I wouldn't compare against like the perfect alternative but against we ship nothing um and is this something that gets us you know closer to shipping something that's valuable to a large set of users

um so

so I think just my point of view on this is I think the current version is better than the new suggested version not definitely not saying we shouldn't ship anything definitely should have revocation in the protocol we were proponents for that from from when it was introduced uh but I think the new

version is just not any Improvement on the previous one I think the previous the existing version actually that the one that has been merged in the last one we think it's just better

Tim Beiko: uh um I think the concern there is it's just not better

Lightclient: like you you should come up with a something that's possible in the old version that's not possible in the new version because the new version actually provides more value in the 2. DI menion about resolving the outstanding offs that we don't know about because it's recorded on chain and resolve the revocation debate that we haven't resolved still those aren't fixed in the current version of 772 or in 3074 so the old version is not an acceptable solution yet and this one is

a something that is potentially acceptable everything that's possible in the old 772 and 3074 is possible in the new 7702 I want to be very clear about that

I see frano has his head hand up

yeah so I was just looking at this proposal haven't seen it before um can you comment man on on how this interacts with cross chain replayability it sounds like because the nons is incremented unless you broadcast and actually publish the o to to all the chains you want um at the same time you would have to regenerate the o

later um if you want to submit it to a new chain is that right

Lightclient: the off should allow for being you know having valuable chain ID if you use chain ID zero it should be replayable on other chains if you do not and you use a specific chain ad then it's only valid on that chain

but by being tied to the nons uh it seems to be tied to one chain anyway am I am I getting that correctly

Lightclient: if you have a new account with not zero everywhere then there's no problem but yeah if you have already utilized your account in other chains and the nons is different then you would have to individually sign messages right

so I

feel like this is one place where it diverges from the current spec and and you have some patterns that are definitely not doable in particular maybe when you you combine using as AA and eoa at the same time which uh a lot of people have raced and it I don't think there's like a clear understanding whether that's a clear consensus on whe whether we think that's what's going to happen

um Eric

yeah just as as a thought why not have the the new version where that's how we handle long-term withstanding uh

delegation but still at the same time allow 7702 calls that have a signature in them execute the code they sign so do you still have the way to do like the ad hoc quick thing that like the specific delegation in a separate process without changing your long-term delegation but then you have your long-term delegation active maybe that's the solution that gives us both options

Tim Beiko: I guess the one immediate thing I can see is just you're effectively creating two features that do pretty much the same thing

yeah um Richard has a question around like uh how this impacts the mop codes and and uh whether it was um yeah whether it it is makes things more complex I don't know like Cent you have thoughts on that

Lightclient: it's definitely more complex all op codes that interact with the account with the accounts code in some way would need to be modified we're basically creating a new or creating a kind of a pointer in the protocol to say if I loaded some

code and it was of this pointer type then actually you need to follow the pointer to load the to continue loading the code and this is going to be more complicated we're making things more complicated as we go but I think it it's not too too horrible and we need to resolve the questions around revocation and around um perpetually valid authorizations and this feels like a good path to doing so

Tim Beiko: I guess okay Anar oh sorry let's you Richard

yes I just wanted to follow up

Richard Meissner: I was not on the same question I wanted to have a another comment in general but yeah there is a comment on this topic of

complexity first I would first s this but if not for me it was the General first of all I do like the new proposal but I'm biased here primarily because for me this proposal is closer towards also as met said it um uh said on the way towards this upgradability real AA pass but in general I'm fine with versions but I like this proposal the downside of this proposal for me is what was mentioned earlier in the shed that you cannot basically just deprecate it again right like because there potentially the the current version of 7702 is very very nice since it has no onchain impact can just deprecate it a lot easier at least in general I still

think um for me the worst outcome would be to have both at the same time the current version and the proposed version because this feels like we going into a scope uh scope creep which and then we have to have while we have the advantages of both we also get the worst of both so I'm not sure if this is really the preferred outcome and I would rather say either we say hey we you know revocation is how it is and we don't go um with expensive schemes or complex schemes where you can bump nonsense than it is how it's currently is it's optional and people can opt out which is the current version and I think there are quite some advocates for this also happy with that or we say we go with other one where we say hey okay we limit

it where you can get the certain functionality only if you bake it into the account that you gate to but then you have a strong replay protection because they can always only basically have upgradeable accounts and protocol for uas um but I think having both feels very dangerous um also when it comes to specifying it um and here generally I agree with Matt that I think the new proposal solves a lot of questions with maybe some drawbacks but it solves this biggest question right now around this revocability which or like with yeah if that is the biggest question and if I think also here it would be interesting to hear also the Aragon team I know it's

short term so maybe not in this SC but what they think about this because they were the most vocal ones around the revocation at least if so they're probably only

once yeah

Andrew Ashikhmin: yeah I need to look more into it but on the surface of it the new proposal looks good

Tim Beiko: so I guess yeah

Andrew Ashikhmin: and I agree that we we should like we shouldn't like make 7702 super super generic and have like op like different various different flavors uh all all available at at once that will be

horrible

Tim Beiko: so I guess yeah I does feel like people need time to review this you know more thoroughly and to be sure the pr has only been out for 17 hours right now so um it's not like people have had a ton of time to do it um do we feel like it's worth scheduling a separate breakout on this or do we want to just review it async and um discuss it on the next on the next award Dev um yeah it would be nice if by the next call we we had something that uh people were generally happy with and that uh we could use you know whatever new version whether it's this one or a tweak of it as part of defet 2 or something like that

um D Daniel

yeah just to to clarify something

I mean I mean it it comes a bit what you said right now about definite 2 for definite one would we then implement the current version yes because I mean but the the proposals are quite different so we might uh Implement something that afterwards we have to throw away after a few I mean not everything but part of it of the code we have to throw away after a few weeks because 7702 is changing again so I don't know how much sense it makes if we are very sure that we will change it to continue working on the on the current spec

Tim Beiko: I guess my understanding from like

what teams previously shared is it's like probably less than a than a week of work to finish 7702 for most El teams if that's the case it feels like that's still the quickest pass forward uh but the other look the other approach is we just removed 7702 from the next devnet altogether um I don't the the one thing I would I would want to avoid it is blocking the launch 7702 based on like this draft PR um yeah so I yeah I know that yeah last time it felt like there was still some value in having the old spec in the pr even though we knew it would change uh

but I don't know if we we thought it would change less that it's currently changing but I yeah I know yeah

at least my my question the last time was that what there were discussions around the nons handling and the revocation but nothing else which seemed rather small yeah but the current spec um is a completely different approach to to how we how we how we do the C obstruction in this case so I I would very very different

guess yeah

Tim Beiko: the teams feel like it is generally if we feel like it's I think the the Alternatives is we just do the death net without 7702 the people feel like that's a better path forward

yeah

Richard Meissner: on this one personally as more on the wallet side Dev for us it's super helpful to even with the current version not with updated version to play around with it and get a feeling for it why we can obviously try to set up local test Nets but if it's nowhere implemented then we it will be also harder to get up the local test Nets right like so this is where possible and I mean I know the AUM team doing an awesome job they're pushing stuff for this even for 3074 having something like this would be super helpful and they having um it as part of the death net would make this a lot easier

Tim Beiko: um I don't know any other El

teams feel like we should either keep it in or or or take it out if there if there's no other strong objections I think I would just default to leaving it in because um yeah there is value in having it and and like um there's also some risk of issues when we take stuff out of Dev Nets uh as we we've seen time and time again so I yeah I would keep the devet spec as is um and obviously when we test devnet one like it's probably not the most valuable use of our time to test all the different uh

parts of 7702 but like yeah it doesn't seem like it's going to delay us a ton um so okay so let's keep it as it is um we can I'll post after this call in the Discord to schedule another uh 7702 breakout before the next acde um I'll look at all the dates that don't have a 14 UTC call uh in them already but um yeah let's try and have another uh another 7702 Breakout by the next ACDC and um hopefully by then we have a final spec that we're that we're happy with um anything else on the

topic okay uh thanks everyone uh yeah I think this is this is good progress um this was kind of a long detour but uh we we were going to talk about eof and P Das death Nets but before we go there anything else on just Spectra devet one stuff um aside from eof and pias do we have a rough Target date uh so it seems like there's at least a couple El teams that should be ready within the next week so it would be kind of neat if even if it's not all the all the teams if we could get devet one stood up with the subset of clients before ACDC uh that'd be really

cool my sense is we can get at least a couple uh a couple LS um and on the CL side it seems like things are are ready as well so let's try yeah let's try to get a partial devet one set up by ACDC and um yeah see see how we do on that front anything else on Petra devet one okay uh eof uh Barnabas you started talking about the eof death Nets about half an hour ago um you want to give us a status update there

Barnabas Busa: yes we had a eof call yesterday and uh we have agreed that we're going

to be testing eof after pectra so after Prague uh which means that each Cent team will have to base their UF code over their Tru code and uh we have the ethereum package already updated with eof so time team should be able to test

already awesome thanks any team updates on the

Marek Moraczyński: yeah I know that nethermind implementation is um kind of ready but we are still failing some tests so so it's not ready we are working on it

uh

thanks

uh at Aron uh we are passing all the validation tests uh and it would be it's just a suggestion it would be nice to have a actual blocks so we can execute them and test it as well uh yeah thanks

Tim Beiko: so when you say blocks you mean just like some blocks creating eof contracts and like calling various up codes and stuff like that

yes yes

it would be nice to actually test the behavior of the software if we had an actual blocks with the transactions in them I mean e

transactions with them yep oh yeah one more thing is that we are not fully ready yet since some instructions are not implemented yet but the validation test uh I mean validation steps are already done I mean so far the latest execution spec uh passing yep

nice thank you

Tim Beiko: and then there's an upgrade uh an update to from RE in the chat saying they're passing State and validation test uh work has begun integrating eof into Foundry um anyone from the base or get

side

Danno Ferrin: I pasted the Readiness Matrix in chat that shows the uh implementation um status Basu has them all implemented um I'll let get speak for them but the radius Matrix we should when you have your updates please update this spec file

cool um yeah any gu updates

Marius van der Wijden: um sure we uh are passing all except for one test from the uh stack validation and uh I'm currently trying

to make the state tests work um but they are based on PR so I need to rev first um to get uh everything to prod um and make the make the make the actual functionality work

Tim Beiko: got it thanks so I guess next steps obviously getting the rebates done uh finishing uh these implementations and if someone has the bandwidth maybe adding some uh full block tests um yeah does that seem reasonable no objection um anything else on eof people wanted to discuss

e is

Danno Ferrin: going to move to the

implemented call is going to move to bi-weekly we'll have a meeting next week and then we'll move to weeks off of ACD um we went to weekly when we had a lot of um uh spec updates but now of the spec updates has gone to basically none now um it's mostly a testing and implementation calls so we can do a lot of that async

Tim Beiko: awesome yeah that's a good sign um sweet anything else on eof and then um yeah I know we might not have everyone uh to discuss this here but uh any updates on the P Das Dev Nets or implementation I guess I doubt

we at devet yet

uh death

Barnabas Busa: one will be based on Alpha 3 as well so each uh client team suggested that that would be the easiest to do cool so the enr uh change would need to be applied uh I'm not sure if any c people are here but uh the idea would be to be up and running also within the next week or two maybe if P death Def One awesome

Tim Beiko: any other comments thoughts on the P Das work okay anything else on Petra at

all nice well okay great then it seems like things are moving along uh just three quick updates then uh first off uh we discussed in the past a couple times wanting to have a formal place for uh people to leave like high quality reviews on eips after some back and forth um it seems like something that it's hard to standardize you know some eips will get audits some eips will get a really good comment on the pr some eips will get a great comment on E magicians and so some an idea that uh we came up with to uh address this and track it is that when theps have their discussion threads and eth magicians uh we can basically make it the job of the

EIP author to keep track of all these reviews alongside with uh you know updates to their eips and and um and potentially issues or or questions that still need to be resolved um so I I posted this draft in the chat but the idea is that when you open an eth magician thread uh you know for an EIP you would get this as like a default template to fill out uh we obviously can't force people to use it but it's kind of a a nudge towards doing that um and because client teams are the ones who end up reviewing these eips and making decisions for them um if anyone has feedback on like stuff that should be in this template or stuff that should be framed differently um either we can discuss this quickly here if someone has

something to want to share but otherwise I would just yeah move the conversation to eat magicians um but yeah that should hopefully give us like an easy way to keep track of like these are you know if like solidity leaves some significant comments on an EIP and they don't want to show up every two weeks to say them over and over then it should be basically tracked in the first post of the the eth magician thread on the EP um yeah any thoughts comments if not uh okay next announcement uh Perry the eth clients repo

Parithosh Jayanthi: yeah so to introduce the organization to El devs that's this um

GitHub orb it's called e clients and it contains the at least from the CL view the canonical configs for seia hsky as well as minet it also contains all the checkpoint sync endpoints and potentially I think yasik was mentioning um potentially in the future also sources to get error files and stuff like that um the idea is that there's at least one admin from each client team so it's a joint resource that's maintained by every single client team and we can use that how we see fit uh right now there's just admins from CL teams and almost every CL team is represented there so we wanted to start adding the El teams

in there as well so that we yeah we round out all the client team um admins there so there's a thread on um on all C devs I can just share the link to the thread um if someone from each team mentions um who they want me to add and I can just validate that and go ahead and add them thanks

Tim Beiko: thanks uh um okay yeah let any questions comments okay um and uh light client has a unrelated question but we have some time so what's

the latest on dropping premerge history Petra any updates there we I don't think we've discussed it here so um okay last call if anyone has updates okay so no updates on that um and then okay last thing I asked uh in the Discord if people wanted to have an acde uh on July 4th everybody wanted to uh no one said they would be celebrating and missing this um I'll be out but uh Alex Stokes will be there running the next acde um so we'll have it at the

same time time two weeks from now anything else that we want to discuss before we wrap up okay if not well thanks everyone um I'll post a recp on the R&D Discord and um yeah talk to you all soon

bye thank you thank you by bye thank you bye-bye

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