All Core Devs - Execution #148

Transcript

foreign [Music] [Music] [Music] foreign [Music] [Music]

[Music] foreign [Music] [Applause] [Music] foreign

[Music] foreign

[Music] [Music] foreign

[Music] [Music] [Music] [Music]

[Music] foreign [Music] [Music]

foreign [Music] [Music] foreign [Music] [Music]

foreign [Music] [Applause] [Music] foreign [Music]

Tim Beiko: okay so good morning everyone welcome to

all core devs 148 after basically a month off um we have a bunch of stuff to cover today I think the main thing I I hope we can get through is basically just getting your view from the different client teams around you know where they're at generally what they see as priorities going forward for Shanghai um so we've had a bunch of time async and in person at Defcon and in other ways to just like discuss all the the potential VIPs all the stuff that's been cfied a while back um and so I think it's it's valuable to just take time to to go over yeah how

each team kind of sees that so far um related to Shanghai I think there's also two specific topics beyond the actual eips themselves that are worth covering so one is just how we do the fork Activation so we discussed this a little bit in Bogota but um basically you know how we want to trigger the fork and there's different implications there um and then there's a devnet that's already been stood up for some Shanghai stuff so it'll be worth covering that as well um and I think then if we if we get through that we still have time uh there's a couple other sort of important uh topics that aren't directly related to Shanghai but around the engine API um a new eat uh protocol version and um

all the issues we've been seeing around Gordy uh yeah and so if we can get through all that it'll be a good call um yeah I I guess you know just to kick this off um from the El side first like there's any incline team just want to kind of share you know over the past month uh as you've looked at like all the stuff we could be doing next what do you think are like the priorities what do you see is like important and and um where you would like us to to focus on

Marek Moraczyński: um okay I I can start with another mind update and uh I'll review so we have the Raptor merge

PRS for all candidates for inclusion for Shanghai of course we are testing in the reviewing 10 we also implemented uh the activating self-destruct and transient storage op codes uh so far we synced a Shandong tested yesterday we run and pass ethereum eof tests uh if it's about who withdrawals we need to adjust them to the latest spec Implement test on our site and check with Marius test vectors about priorities my viewpoint is that current candidates for include inclusion are good choices for the next Harvard if we added something

big we would delay withdrawals for sure and I believe we don't want to uh and we can work in parallel on other eips maybe perhaps I I would consider adding small eaps like deactivating self-destruct that is my opinion

Tim Beiko: got it uh thanks uh Lucas I see you have your hand up

as well

Łukasz Rozmej: I can weigh in one thing so in my opinion the biggest priority right now is to Define scope of Shanghai in the next hopefully um four weeks or something so we can plan accordingly uh to that and to move accordingly to that so that's probably

the biggest priority

of all

Tim Beiko: right yeah and on that note I guess just uh I was talking a little bit about this uh before we went live to some people I think at a high level today if we can sort of work through with all the client teams see is like priorities what their current views are um and then on the next call there's obviously a bunch of like EIP Champions that have stuff proposed uh we could make that call sort of the main one for people to come and advocate for those and my hope is like the call after that so like four weeks from today we sort of have a pretty clean uh a pretty clean list for Shanghai that doesn't move uh so we should have like probably an idea today of like you know if there's stuff that every single client team thinks is

important then it probably makes sense to move forward for that um but then yeah in the next call or two we can we can sort out all the potential editions um but yeah I I think every client team I've spoken with has like echoed that like getting even almost even more importantly than like what the list is getting a sort of finalized list for Shanghai in in the next month or so is really important to allocate resources um anything else from

nethermine oh I think that he saw

Tim Beiko: okay thanks uh Andrew I see you have your hand up

Andrew Ashikhmin: uh yeah I agree with Merrick I think the current list the the current CFI list is a good one and I would add to it the uh self-destruct deactivation if 4758 it will simplify at least Aragon's code base significantly and it's also a prerequisite for

local trees

Tim Beiko: thanks um Peter

Péter Szilágyi: so from the get teams perspective we had a little debate on how we kind of use

Shanghai and what we do is important one and essentially um if you look at the Shanghai and the proposals they are kind of there are a few big proposals you can included in a few smaller ones the smaller ones like for example disabling the self-destruct is uh on a transient storage I think those are relatively so from an implantation perspective they are not in quotes relevant because they are relatively simple to implement there the effort is mostly about making sure that they work correctly so it's probably the testing effort is more significant so we're kind of on these smaller features dollars I think our opinion exactly how whatever people

would like to go with we can definitely go with although we do support getting rid of the price to do as soon as possible however on the bigger features um within the team we kind of have a few champions for three specific features um live client is while the withdrawals is something that people kind of take for granted that it's going to be I think really in Shanghai so that's definitely been worked on or actively by the lifetime like that and as for another two main features one of them is which was brought up quite a lot on in that con was 4844 and uh for interning on the missed those

workshops it might be a bit of a large larger tasks to tackle but at least on the execution layer It's relatively simple and straightforward paip and it could allow a lot of scalability so we would really like to have that included in Shanghai and at least Marius and myself are kind of pushing towards that direction also the e68 update that we proposes of is going on the same path and as for the third large feature set marking would be like a champion the eof stuff

so um that one I'm slightly on the bench with as I'd would like to see some so there I guess the the two possibilities of getting that include is one of them is just getting the UF support without any actual use case which the rationale behind it is to try to keep it minimal the changes another rationality is to get the US in with some actual new use cases um I'm fine with going to the minimal approach too if we can actually Define these future use cases in advance so as long as we know what we want them

to enable I think that's almost time so kind of that's the that's the state of that that's how they get team kind of sees Shanghai and um yes the these three larger features are kind of it can so generally we as codeps overall kind of suck at shipping new features but it might be interesting to try and get more than one big feature too since we also suck at the shipping hard works so it's um uh it might be interesting to find some of the uh Middle Ground between how many stuff we

add and how rarely we should

Tim Beiko: yeah okay there's a ton of hands up but thanks for that Peter that's really helpful perspective um uh Matt from Basu I think you were next

Matt Nelson: yeah no um and we have a little bit of a different opinion but at the same time you know I think what Netherlands uh put out was pretty much in line with what we were looking at we have some of the candid PR's from the list pretty much wrapped up besides testing um you know our our perspective is that it really depends on the complexity of 4844 whether we want to include that you know we haven't done enough scoping to understand fully on our side uh but the the rest of the candidates on the list

may be with the exception of eof um should be relatively straightforward for our team um so you know I think EOS a little more discussion to Peter's point but other than that you know the only kind of unknown is what the actual complexity of 4844 will be in terms of what we need to implement in tests um and also with the consensus layer side do we want you know how will that look in terms of delaying the the features that we would ship in Shanghai or at least you know complicating that that question so that was kind of where our team landed um but yeah it's definitely definitely okay with the rest of the candidates on the list and already have a lot of that in Flight also for the including the things like uh transient storage and

self-destruct also are on board with that especially considering that you know with transient storage a lot of the implementations are already written um so I think that we should just you know push for those kind of lower Stakes things as long as again to Peter's point the testing is is thorough and understood

thanks um yeah I think Lucas you were next Lucas demarius and Andrew yeah

Łukasz Rozmej: yeah I want to weigh in on proto-dunk shardin 4844 so we had a big discussion yesterday about it and there were some concerns so uh first concern is that the scope isn't finalized the the spec is really still evolving and we are afraid

that it will went and go in a way that I could imagine that's some minor things were changed up to the last moment not up to last one but quite quite far into the pipeline and it it's uh it creates a lot of tension it creates a lot of like uncertainty on some things for us so um if we want to include them I would like to have this spec finalized in a month and then in the next month and then we can uh take a final decision based on the scope because um yeah that was the biggest uh like uh unknown to us how big is would be the

final scope and um we see that as a problematic and we we don't want to commit to something that might change in the future Etc before the actual release and potential even uh postponed Shanghai itself and we would like to get redrawals out of the window uh sooner so yep those are our concerns on for 844 that still developed in terms of spec a lot

Péter Szilágyi: got it oh yeah Peter slightly sorry uh 4844 is not the product sharding that's built on top that's something after that 4844 is just to block transactions

Łukasz Rozmej: ah okay okay so

um so I'm not championing that so I might be a little bit confused here

Tim Beiko: uh I think the so the 4844 still has some moving Parts on the spec um and and asgar maybe asgar uh you commented a couple times about this but do you want to give maybe an update of where things are at with this spec and and what do you expect we can get done in the next month or so

Ansgar Dietrichs: right I I think that only possibly but maybe it's good enough so um I think basically um there was one more moving piece from a couple weeks ago the free market that's um we've done this like on one small question left but I'm very confident resulted in the next four weeks and there's also like a very like some small

and certainly left around uh the specifics on the critical side like there might be one additional parameter that the pre-compile uh is supposed to return so like very small changes there uh I I don't think yeah I basically think it would be very reasonable to to to could come to a species within the next month or so um there might be some more moving Parts under kind of the networking specs side uh I'm not 100 certain about that so if someone else on the call could talk to that

um yeah that's not my favorite studies and

Tim Beiko: I think maybe the other parts that we could probably see moving is like some constants so like from an

implementation perspective it's probably not a huge change but like say you know the actual blob size or the retention period on the CL deciding you know whether it's like 500k or 256k so those constant I suspect could probably still change as we do more testing but it shouldn't alter the implementations significantly I guess

Ansgar Dietrichs: um right and I don't specifically see a reason why if we wanted to I think we could also make more or less final decisions on that within the next four weeks or so yeah um but but yeah you're right like I I don't think there would be an issue with still changing them at a lighter point but if there was strong desire to just

make final calls so I think we could do that

Tim Beiko: um okay back to the raise hands Marius

Marius van der Wijden: uh yes so um I have some I have some issues with uh uof that I would like to discuss um I actually I actually sorry I actually quite like it um the only problem I see is that the state eof is in right now with the proposed eaps it doesn't actually help us with anything and

um so we would need to for eof to be really useful in my opinion we would need to get rid of the jump test analysis and uh maybe also have the stack validation um and so we need to create we need to put uh like have another hard fork with at least two eaps the problem is um that uh contracts that are deployed now between between now and uh real eof or like the the useful eof uh will could still have a code that is

not um that doesn't have these these validations in place so we would have at least three versions of the evm we would have the normal version we would have eof version one which has the eaps in that we have right now and then we would need to have the EO F version 2 which has like the full validation and getting rid of the jump test analysis um the problem is that we need to maintain three different versions with three different like kind of security guarantees and if we changed something across all versions like I don't know repricing

uh repressing an OP code then we would need to maintain six versions uh or of it um all of a sudden and um the problem I see is like we can very easily shoot ourselves in the in the foot with this and um I would really like to see the full version of eof going in um the problem with that is I don't see us realistically doing the full version of eof within uh within a couple of months and so

the way I thought about it or the way I would propose would be to delay UF and focus really focus on withdrawals and Bank sharding and then get your in in in in a hard Fork after um after Shanghai um I know that's like it's not it's a bit contrarian to to what others have said um but I just don't want us to shoot ourselves in the foot again with this and then having to maintain something and the the thing is like with with uh old hard Forks we can eventually with

uh histories we can eventually get rid of these rules um but with eof we can never get rid of them because there will always be contracts on on the different um on the different versions so they will we will need to maintain the different versions of

the EM indefinitely

Tim Beiko: thanks um yeah there was a couple comments in the chats about the eof uh yeah Thomas do you want to go next and then uh if we have Alex from the eof uh EIP we could we can do

hitmaster

Tomasz Stańczak: yeah so my proposal is a bit unusual so

I was thinking that uh eof is definitely a right direction and something that I fully support although I wouldn't like to see it being rushed to mainnet still I think it requires a lot of testing and people would uh possibly be able to test it in parallel to many other changes and almost like the eof can be parallelized in the work streams because evm itself is uh very independent from many other changes that we work on so proposal is to actually either build the test net or include eof on the desk Nets ethereum test Nets with versioning and keep improving the versions of that one until we find the version that we're happy with and only then push that change to

the main net which would lead to Tesla's ethereum tests to be not entirely consistent with the mainnet however only for the smart contracts that would be on different versions so you would say that I'm not sure if I would have to limit those those versions of evm to only interact with other contracts with the same version for the sake of testnet not to cost additional trouble uh but this is the idea then we can then can over time collect everything that is needed for eof to have its final form and whatever version will be version 5 version 6 then say this is the version that goes to

main map yeah

Tim Beiko: right I guess there's two ways you can

do this either on the new test net if you don't want to you know if you want to break things a bit more or have the existing test notes yeah um Alex do you want to give an update from uh from the Epsilon side and just yeah your perspective is like championing eof of what you think could be like a good approach here I don't know if you have

a mic though yeah

Alex Beregszaszi: um yeah maybe just like a brief update um the reason we split them into different VIPs initially was due to um

the idea was that it would be much more easy to review um you know those changes in isolation but even when we started with the first version our goal was to to get this full feature set which the the five VIPs accomplish and one of the main goals of that is uh to also get rid of dynamic jumps um then the last two eips well there's there's one AIP the very last one which is the stack validation that I kind of consider as optional um it just simplifies the evening implementations but it's it doesn't um give like a user visible feature it

could speed up the evm but that's about it um however if you skip that then we likely would skip it forever because that would mean a version bump um and regarding the I guess in terms of like uh maturity of the changes the first one is of course 3540 and 3670 those basically Define the structured those I believe have been or at least have had some kind of a a review already um obviously not like a uh you know merge ready review but I think some that there were more eyes at it and implementations in multiple client

success for those um then the following one was the static jump um I think that change is relatively simple um and that I don't think that there would be any changes to to that feature um however the the biggest one is the function sections uh which hasn't hasn't received too much attention from core Dev so far um so that's the only bottleneck in in getting this um you know fully accepted um we do have implementations of that in I believe in two EVMS um but obviously it's not the not covered in like uh as much as the

other changes are um and then lastly we wanted to change these last three IPS to review status from draft because we don't really expect too many changes in them um before they've gone but that just fell through the cracks and we have been in discussion with the Soleil team regarding the the usage of all of these changes um and Daniel responded to some extent on the research Discord um to to stay the the Viewpoint of solidity um yeah I think that's all I can really say um from our perspective you would prefer to have the full set

um and want to go I think the stack validation as I mentioned the very last dip that can be debated whether to include or not but the others I would say should go into anything

Tim Beiko: and when you when you say single set um I mean you know would you rather have a single protocol uptake yeah but would you rather so say that like the the trade-off was like sort of this minimal eof that we have now in Shanghai versus the whole thing in like the fork after do you think it's better to delay to have the whole thing or is yeah because because the we're sort of in this in between uh in between States now where we've like cfied the first half of it not the whole

thing um yeah so I I'm curious like do you also think like even if it requires a delay having them all together is better or having this like subset ASAP is is actually valuable um if we can't get the whole

city

Alex Beregszaszi: I would say even the subset is valuable but obviously way less than 24 set um got it the the preferred outcome would be having all of it in Shanghai of course yeah

got it um thanks that's that's really helpful um yeah go ahead mirrors quick question for

Marius van der Wijden: for Alex

um what's what's the status of uh like the support in solidity for it is it like are going to be supported is it something that solidity wants or it's going to support and what about other languages like I don't want to do the the simple subroutine uh thing again right whether like the language devs say we're not going to support this

Alex Beregszaszi: yeah I mean obviously there's an overlap between the the people in epsilon and solidity um and so the discussions were more um you know more close um there is an implementation of most of the features except of the

um the function sections and and solidity um and but it's it's on the on the to-do list for us to actually implement it um besides that we had discussions with some other language teams um including the the half team and they were interested in actually supporting the function sections as is um but solidity itself I mean they had a they had nothing against it uh of course um yeah they are I don't think there were any blockers um it it is seen as a useful feature

generally

Tim Beiko: yeah and we had um Daniel from the

solidity team comment on Discord yesterday he can't make I don't think he's on the call yeah now and he he couldn't make the call but I pasted his his thoughts in the zoom chat here um okay Andrew you've and thank God you've had your hands up for a while so yeah Andrew

Andrew Ashikhmin: um I agree with Marius uh I think it's better to uh Implement all eof changes in one go with uh the goal of disabled and dynamic jumps and um um I also agree with Thomas that uh it's it's kind of an almost an independent

chunk of work and we can uh you know probably have a separate uh test net for it so I would think about eof changes uh as us dedicated eof hard work which is which might happen after Cancun or with Cancun or what not but kind of try to think about enabling two two sets of hard folks Cancun and eof1 and then that's when we have everything ready for eof we just synchronize on whether it goes with Cancun or after or before and I have two additional uh concerns

about eof uh the first one is as far as I understand it we need to pick uh between if 2315 and 47.50 because they both deal with the functions so that that should be resolved with which one of them goes and my my second concern is whether um where the eof will help or or hinder code chunking in local trees so maybe someone knowledgeable about local trees perhaps Guillaume could double check that eof doesn't hinder welcome or even

helps potentially so yeah I would I would I would extract all ARF work into a separate dedicated hard work

um yeah there's a comment by Alex and it doesn't hinder chunking and that they worked on it before vertical trees um on that front Alex

Alex Beregszaszi: Yeah so basically uh the the headers and yeah all the headers are up front so they would be in the first Chunk in the local trees in the virtual tree and uh everything else would be in uh in

subsequent chunks and I believe the first chunk well the first like 128 chunks are cheaper anyway um and so I I think it works well with

Oracle trees

Andrew Ashikhmin: don't we have to align to somehow ensure that boundaries between code sanctions uh like don't uh like um play nicely with with code chunks so what if your uh code section sanction is split between two code chunks or if somehow you your code chunk is uh in the middle of uh intermediary like intermediate value

like push push data what not so is is it a problem at all some kind of misalignment between a code section uh boundaries and code chunks

Alex Beregszaszi: uh I don't think so so in in the in the code chunking uh regular evm code you need to know um the code offset uh which is taking up one byte of each chunk um because of jump test analysis um now you wouldn't need that in UF um you may need to load the first chunk with the headers um but then you can calculate all the offsets based off that and I don't think there would be any any downside effect beyond that

Andrew Ashikhmin: cool

Tim Beiko: um Greg messages he couldn't raise his hand up but he had a comment about your point around like 2315 versus eof uh Greg do you want to take a minute to to talk about that

unmute

Greg Colvin: can people hear me I don't know if my mic is working okay 2015 is simpler than the 47.50 functions and the other surrounding stuff uh give slightly less uh security guarantees rather than saying that all functions take a specified number of arguments and return

a specified number of arguments it simply proves that all functions that the same functions everywhere it's called takes the same number of arguments and Returns the same number of arguments so it's simpler but if we're going with the full Suite of eof I will happily withdraw 2315 in favor of eof and I very much support the full Suite of eof I also support getting it in sooner rather than later because I've got work I'm doing that I cannot go live with until I'm able to reverse the control flow graph of evm code in linear

time and space and until I can generate machine code from byte code in linear time and space so we have to get rid of dynamic jumps and replace them with subroutines and I've been trying to do this for years so every month that we delay it delays the ability uh to you know to compile byte code to machine codes we delay it for months we delay it for years so it's really so close to ready to go so I'm getting frustrated by these these constant delays we couldn't get it in before the merge we couldn't do it during the merge

and I'll quit whining that's all

bye-bye

Tim Beiko: thanks yeah um and okay that's good to know though the you know the 2350 it can sort of be superseded by 47.50 um if we if we go that route um bankrupt you've had your hand up also for a really long time

Dankrad Feist: uh sure yeah so I uh only have a very small comment on EF because I'm definitely an expert on this but I kind of feel like I want to add to like basically Mario's feeling that um like having a minimal version uh seems not ideal to me because I'm reserving an extra version uh seems a very high cost

um because it has to be maintained forever and it will also be an extra version with every upgrade of the evm that comes orthogonal to this like op code changes and so on that will not be reflected in eof versions uh so yeah that's just my small comment on UF I also feel like it should be much more of like trying to make the first version something that's really worthwhile um and the second small comment I had was with regards to Lucas on an API changes uh what I wanted to say is I think like actually the the um this is sorry this is on 4844 um so I think what actually it is true that

there are still small changes going on right now um but uh they are like what at least okay so there's one on the free market I guess but otherwise so what's happening on the cryptography API so the high level of that is actually completely settled the only thing that uh that is happening right now is like something that would be deep in the library and so I think it actually doesn't affect client teams implementing this at all so they they can work with the current API as it is um got it thanks yep that's it for me

Tim Beiko: um thanks and I guess yeah we also have a couple folks from CL teams uh on the calls I see some teku Lighthouse folks

and I don't see everyone The Grandin um oh prison yes I guess they're probably all here um but I'd be curious to just hear like quickly from the different CL teams like you know after hearing all of this what's like your general view on things and and yeah um I don't know I can pick on uh Paul if you want Lighthouse to go first

Paul Hauner: hey sure thanks Tim um I think um mostly from what Shanghai involves for us it's just withdrawals and EIP um 4844 so where the opinion that withdrawals needs to go in so I think that's a given for us um 4844

um still a little bit on the fence I think we probably need a little bit more data and the around how it's going to affect the network before we can make a call on it but I'm Keen to work towards making a call we're implementing both of them I think something useful from our perspective is that we're keen to see for it for for always built on top of um with tutorials when we're doing test Nets but I think that's already a given um yeah that's that's all I have to say on the matter

thanks uh Terence yep

Terence Tsao: hey everyone so um with prism we definitely agree with Paul that withdrawal is a must but withdrawals also less complicated much simpler I believe that we should have a death net in the next one to two weeks

so that's very exciting to see I saw 444 we have the luxury of like coinbase and optimism contributing so we're kind of like more like on the local side I guess but yeah so I mean for us we're I think we still remain very bullish for including 4844 I think the unknown here is first is is is is the best concern it's the size of the target at Max I think like um with testing we can get into a pretty good idea on what we should use but even I think today one megabyte megabytes is too big I think we can lower it to 256 and 512. I think I think at the minimum that's going to

dramatically reduce the concern and now another one is kcg ceremony and I think that's being worked on right now so I'm definitely curious to hear more on the timeline

Tim Beiko: um yeah there was a comment about the kcg ceremony Trends do you want to give a quick update on that before we go to other CL teams

Trent Van Epps: yeah was this in the chat or what's the context

uh wondering what's their current timeline for the kcg ceremony

Trent Van Epps: oh yeah yeah sure uh so we have an audit with Sigma Prime which starts in a couple weeks November 7th uh that'll run for a little bit and then we hope to wrap everything up and have it launched by late November we're working with

ethereum.org Team to tighten up the website uh in the past collaborated with the PSE team but now we're getting to a point where it's in a good place and once it's publicly launched um it will run for about two months uh give or take we want to make sure there's enough time for as many people as possible to participate but yeah that's the the general timeline is should launch before the end of November

Tim Beiko: and as I understand it um we only need the final input or output of the ceremony for like mainnet so like even if when say we even had the test Nets go live with 4844 but

um if we don't have the output of the ceremony then you could just plug in the different number uh when we moved to mainnet and it doesn't really change anything implementation wise is that is that right

Trent Van Epps: to the best of my knowledge yes but uh maybe somebody else with with a better understanding can jump in but yeah yeah

um thank God

Tim Beiko: I don't know if you're still here but that might be helpful to know like when do we need the final output basically

Dankrad Feist: yeah I mean yeah I I mean it's it's really just it's a file with a list of constants so yeah like I mean basically definitely before the main net hard Fork

but I mean I think um even it if it were uh yeah like just at the time of the client release it would be fine like there's nothing new to test like the the cryptography works exactly the same whether that's like some testing version or if it's a final trust setup

Tim Beiko: got it thanks

Dankrad Feist: yeah I'm also very optimistic that it will be very easily done by then I think the team is working very hard on that and I think it will be fine

Tim Beiko: got it um any other folks from the CL side

want to just share their perspective we can also just take the test net ceremony output for

like testing so that we have some realistically looking

Tim Beiko: right yeah uh Phil

Phil Ngo: yeah so uh basically for us at lodestar we Echo the same sort of comments from Terence um we're also getting uh good positive support from uh some of the other contributors so uh there were some things that were addressed in terms of blockers in the 4844 calls but other than that um they are being addressed uh so I am optimistic um with 4844 and of course

withdrawals cut it I'm any other CL folks

yeah Tech move

Enrico Del Fante: here and we definitely have the vision that the withdrawal will be easier compared to 4844 so we are discussing each other that we might prefer to have them separate and having the withdrawal first and then the 4844 later also to have some chance to do other uh time for doing some cleanups and refinement with all the things that we already have for the merge so having some time also to go settle down and have better better things in place with the help instead of continuously adding

stuff but this is the uh these are yeah these are our

comments

Tim Beiko: got it um before we go to endscars there are any other CL team

[Music] unless uh less something serious will show up on the test net uh that will block any of these two features uh with the robots or four eight four four okay I think that would be nice to you know uh in the next upgrade got it thanks

um and I think that's everyone um okay uh and scar is um this sort of I'll I'll just I'll just okay yeah I'll read it from from the chat um and okay so there's another yeah there's

another comment by Alex in the chat around uh you know there's sort of this implicit assumption uh of like you know there's a high cost to each upgrade and that means we need to do big upgrades um but would it be simpler to like potentially have more smaller upgrades and quicker rollouts um we I guess yeah oh Peter yeah yeah so um we tried to do that since uh Shanghai and Shanghai the.com Shanghai and uh it always failed

Péter Szilágyi: so it sounds in theory it sounds nice because you have quicker more frequent

Cola but in practice uh it takes us forever to test the hard work generally clients are kind of lagging on on commenting stuff so we always have to wait until everybody picks up their thing and just rolls with it and then we somehow need to debate on Oculus for one test and that's for the other test and let's wait until it survives or they survived okay we're tweaking again we need to test again and it's just this very long procedure and it actually makes sense that it's long because you don't really want to mess it up but that kind of person feels that it doesn't matter whether you do frequent artworks or rare hard works you always need two to three months of just

wasting time rolling it out so if we do three quick small hard Forks that still entails nine months of or at least six months of extra useless types of the sake so it's again it's kind of a balance as to uh I would say that sometimes it's worth the crime in one more feature than to

to weight it off thanks uh mirrors yeah so what

Marius van der Wijden: what really um uh convinced me of this was um in in Bogota Peter said

that I think it was something around the land if we were to push for withdrawals only with quotes and and maybe some the currency of eye stuff then we can probably um have a hard fog in February March and so for it for four will probably come in like September or something but if we put it both together and do do everything we only have one big hard Fork then it might be June uh June or July and so we will save

two or three months if we if we put them together it's uh yeah just uh it's more realistic to have have these bigger bigger things I I don't like it I would also prefer prefer uh like smaller hard Forks because it's easier to take but the bigger hard books are just way easier because we need so much time to roll it out to the community we need everyone to update their notes and everything that's where the most time is spent

great

Tim Beiko: so I guess to summarize kind of all of this um it feels like withdrawals is like a

given across everyone uh um oh okay sorry so uh do you want to comment on why Berlin in London came so quickly um I think the reason for that is like basically we had really started the work on uh 1559 in advance so while Berlin was still happening and then Berlin had like a relatively long roll out period across the multiple test Nets and I think during that period we did manage to get like clients to start working on London um in in sort of parallel as we were waiting for Berlin to happen um so I think yeah it's it's possible to have Forks follow each other and to like use this

sort of down period as a way to like start implementing more stuff in clients um the it did feel like it was like you know pushing people a bit at the time and there was the difficulty bomb and all of that um but I don't think it's impossible and maybe the other difference is um it was only El teams so the the coordination was like slightly less um so it might be you know it might still be possible to do something like that um but um yeah it I I wouldn't say it was like trivial to do either um yeah and I guess yeah to kind of go back into what I was saying like at a high level

it seems like every single team is is sort of on board with withdrawals being a part of um of Shanghai um I haven't heard anyone mention anything about all of the small kind of utter CFI the eips but from like conversations with client teams and the testing teams in the past month it doesn't seem like there's any opposition or like you know or that there are a ton of work so like the stuff around like the warm coin base the push zero limiting and metering init code um it seems like most teams have either a PR in progress or um can easily make one there um

so it seems like that's kind of a pretty solid set we have then there's probably like three buckets that we've discussed so first eof whether we want to have it as uh as it's currently specified have it as a bigger uh as a bigger kind of bundle with everything coming together and and if we make the bigger bundle whether it should go in Shanghai or not um then the second bucket is obviously 4844 so I think uh you know there's some concerns about like how ready it is and how big of a change it is relative to everything else and then the third bucket that we're mentioning is I think every El team has mentioned that like uh removing self-destruct is something they would

like to consider and then 1153 is sort of mentioned here and there as well um so I guess like at a high level you know between like uh between these things is there any client team that feels like there's a big thing missing there or is the sort of like withdrawals plus all the small stuff um 4844 EOS and then self-destruct 1153 kind of the big things um Andreas you just raise your hand

Andrew Ashikhmin: uh yeah I think just just a small comment about 11 53 I think um it's nice to have but it's not as urgent as to be considered for Shanghai

that's my two cents

Tim Beiko: okay uh Maris uh sorry I just have my hand up but um same thing I also think 1153 isn't that important okay um oh and Ansgar you're against self-destruct you wanna share why I don't know if your mic is working

now let me

Micah Zoltu: give the quick argument which is that there are contracts that depend on

it and will break and we just historically have tried very hard not to break people right and not just uh gas tokens like actual people using it from a long time ago

Tim Beiko: yeah and I think as I understand it the breakage that would be introduced uh for self-destruct with the specific EIP so EIP doesn't remove it it converts it to send all which sends all of the eth back to the uh the color um but doesn't destroy the contract there's one pattern that breaks which is um using like create two just and then self-destructing contracts and re-instantiating a different contract at the same address I think that's basically the main one is that correct

yes

yeah yeah but that that's all also real anti-pattern and

Marius van der Wijden: we need to remove it anyway it's just not like that's the fact and the earlier we do the less people actually write software with this weird pattern in mind and uh so I I would be for removing it as soon as possible so like there will be some people that are bricked by this um and it's it's unfortunate uh but I think the longer we wait with removing this

um the more people will actually shoot themselves with this

so

Micah Zoltu: I don't think that the latter thing is true I think basically from what I've seen and heard there's basically one legitimate contract that actually used this pattern and it was a long time ago and since then everybody's been advised not to and no one has since and this person um did it before that advice was popularized and so um if we are going to break self-destruct eventually but now versus later seems inconsequential but that is a very big decision to make I think to declare is that we are going to break a legitimate immutable contract that is on chain not upgrade not upgradable and it's not going to work

anymore

Tim Beiko: um Andrew you have your hand up

Andrew Ashikhmin: um I think uh I think self-destruct like removing self-destruct is um where is critical for simplifying the code and to align vehicle but I would suggest if we want to consider some kind of uh maybe transition measures or not breaking contracts in the analysis uh by this maybe Jupiter I think there was a some analysis done some kind of some time ago they identify they identified one

contract Pine core or from pine pine finance and there they say one possible solution is to allow self-destructing a contract if it was created in the same transaction so I would say if I I would say that we should declare Our intention to remove self-destruct in Shanghai and we with the default option just to to turn it into send all but if somebody screams like between now and the next call that oh absolutely you will ruin my contract then we should discuss how to uh by possible solution but if nobody screams then maybe it's

not that important and we should proceed

Micah Zoltu: someone someone is already screaming uh that's why like I actually want to get rid of self-destruct but on the same time there is someone out there who is saying this will guaranteed break my thing that I deployed five years ago

Andrew Ashikhmin: uh if it's only if we only allow this particular scenario when a contract is self-destructed in the same transaction then I guess it's fine because it doesn't entail it's kind of a virtual self-destruct and it doesn't entail an unlimited database uh deletion so I think we could cons could

uh could consider such limited mitigation but people should uh definitely uh raise their concerns now and then we should discuss them that's my

my opinion yeah uh Peter so Justin has been

Péter Szilágyi: some discussions on the chat about why or why not group selfish truck and I wanted just to emphasize one use case where we were really self-destruct it really really bothersome specifically that self-destruct has a fixed gas cost however if you have a client that implements proper pruning disc pruning

then in theory I could just self-destruct the passage contract if the I mean if the contract would have some straw and that would entail deleting gigabytes of State data from what block to the max essentially the work required to execute that operation would be insane and uh and then the only hacky solution is that well if this contract is huge then what yeah okay we're not going to throw that yeah that's it and that's essentially how our code currently works and that's that's kind of bad and the point is that if we if self-destructure becomes a Noah then um

yeah so so essentially self-destruct is one of the last remaining operations where you have a fixed gas cost but it can entail an unlimited storage cost for a pruning time and that's what we would like to avoid not to have these unlimited unbounded factors

Tim Beiko: thanks

again

uh yeah so I indeed talked to someone in Bogota that was that approached me about this specific topic and like Andrew said it would be nice to to be able to have a special case that if if during the creation contract like the Australian creation transaction some

would call self-destruct then it should be able to it would not affect it should not affect the the state and therefore it should be allowed the only problem with this is that in the vertical tree context uh you would still need to add a like an indicator that this address was missing before so um I'm I'm sympathetic to this uh to this request of um you know making self-destruct uh like behave differently if the contract is deleted in the same transaction that is created but there's a lot of complexity involved with this and we should not make this decision take this decision

lightly

Tim Beiko: yeah oh there's another comment uh in

the chat is that it can force ether into contracts that are

non-payable

Micah Zoltu: um I believe the current proposal would still allow for that because we're just changing

its symbol okay oh right

Tim Beiko: okay yeah I see so if you do send it all but then the or self-destruct today but then the address is is an unpayable contract yeah withdrawals can do this as well um oh Peter is your hand up again

yes I just want to put that I think somebody also mentioned it but I just wanted to emphasize the research that if we can identify one clue a hand block contracts that that are legitimate and get broken then I think it's perfectly

fine to to have to special case them I mean we already have the right family contact special case in the yellow paper is super ugly but we can actually surgically fix the few issues that remain so it's kind of strange we don't really want to throw the baby out in bath water so if self-destruct is obviously bad and it will be obviously better to get rid of it except that through contracts maybe we can just have a solution for those two contracts instead of doing a completely different generic solution that happens to work for them too

Tim Beiko: right I guess though the challenge with

that is it's almost like what we did with eof you probably need the first band deploying new contracts using the opcode and then you need to retroactively sort of analyze the cases um so clearly yeah it seems like you know this is a Direction people generally want to go in there's a lot of like edge cases and uncertainty um I I don't know if someone wants to like wants to I guess try to investigate those in the next few weeks so that we can have a clearer picture um because it seems like

including you know making the current EIP CFI as is doesn't give us like enough unless we wanted to explicitly break you know those contracts and I think there's clearly some some concerns there um so yeah is there anyone who want to like look into this more in the next few weeks to see if we can come up with uh you know proper solution and and something that we can then consider for for Shanghai um because I think as is it's probably under specified foreign says he can look into this uh thanks

Jared so um yeah I I guess for this one we can just discuss it uh further once we have a better idea um it's good to just start talking about it so people get aware that this might happen um and so um yeah uh yeah so that's something they should they should watch out for and I guess yeah back to like the two so it seems like the two other big buckets are basically what do we do about eof how do we approach 4844 um I think so for for for eof um there was this idea of like having a

special test net to see if we can like get it implemented narrowing down like a a a a version which has um kind of support for for all of the operations um and then you know some people seem to think this is realistic for Shanghai some people disagree but um is is that something that would be worth doing like trying to set up a sort of 4844 devnet which um we gradually you know add or we we sort of specify what's like the minimum set of features that we think are are valuable for like a a full eof so beyond what's already cfied um and see you know if clients can

implement this um I guess a bit like what we're doing with 4844 in parallel um yeah I'm curious to hear from from Yale teams like um okay and Scar disagrees that if we want this for Shanghai we have time to do a special testnet um yeah curious to hear from

from others well

Marius van der Wijden: we already have a special test that mostly for you uh oh there's a shangdong one yeah it doesn't have it doesn't have withdrawals on it

Tim Beiko: and so what yeah actually yeah what is um Can someone from like the JS team just get a quick update on what is shendong and what's in there uh yeah sure uh hogger here from from

the JavaScript team um yes I'm always live thinking all the time here um along these discussions what uh how how the Shandong test that might fit fit in here a bit um yes Shandong is actually it's kind of a bit of a small experiment from the JavaScript team so Mario's once tweeted about the kind of like the more or less settled uh Shanghai earpiece and and then we had all these implemented and thought that might be a good publication to to test our client implementation and set up a small test stat on this and then we made a cooperation with ef devops and set up this Shandong test net and um yeah in the shendong test that we actually have yeah we have these two eof um earpiece um added so three five four

zero and three six seven oh and then these these other kind of like uh Saddles here CFI uh erps like rom-con coinbase and push zero and and limited meter element code um erps um yes and again there's kind of like a small Chestnut uh uh experiment balloon and um we launched this kind of like two weeks ago and we had to restart it yesterday because of some actually uh um your F box uh yeah and it's running pretty well and and uh yeah we it's kind of like um never mind I wanted to join as well or did join as well they're syncing as well

and um yeah that kind of like our contribution with some small experiments if there's maybe some space for pre-heart fork test Network which fill in a bit in the gap of of this long time period where we actually don't have test net because the heartfrog is not not yet

just settled

Tim Beiko: nice and I guess yeah is would it be valuable to try and activate the like two or three missing eof heaps on that as well um or I guess like Ansgar was saying you know it might not be enough time to actually generate insights and like tweak them and whatnot

um yeah so we're relatively flexible with this kind of chestnut setups we um I already thought it might be a way kind of like to that we stay a bit on board of board here if this turns out to be accepted by the community and and uh somewhat successful and uh yeah this is my kind of like be a tested serious uh that we do where we were really yeah where we really try to reflect kind of like the current situation of the or the state of the discussion in the in the Codex calls or so so that we kind of like we start with such a test net every eight to ten weeks or so and if and just losing from the from the hard Fork just

put in the erps which are kind of like probable to get included in the next or in the next one or two hard Forks so that might be a way to to go with these

testnets

Tim Beiko: got it thanks uh Andrew you have your hand up

Andrew Ashikhmin: uh yeah to my mind we need uh three test Nets one is for withdrawals and uh the smaller smaller Apes that go into Shanghai like warm quad base pool zero limited meter init codes right so like about the four four ribs in Shanghai maybe plus potentially self-destruct uh and the other two test Nets would be uh if 4844 and eof because we don't know yet

whether if 4844 will go into Shanghai or not and the same for

eof

Tim Beiko: right I guess if we so if we do that right if we split in like three test Nets um then how how much work is it to like merge things so say you know we have these three test Nets withdrawals and the small eips is kind of like the basic Shanghai you know like for sure it's it's gonna happen then if we have this eof uh test net and this 4844 test net and we want to merge like one in three or one and two or one and two and three how much extra work does that does that create for us um Peter

Péter Szilágyi: yeah so I think it's more like having a separate uh I think the idea is that everybody agrees with their roles and the small stuff should go in so that's kind of a sanity check that uh that the base of the hard work is complete and then the other two tests that I think would be just these proof of concept things so that everybody's kind of on the same page and does it work doesn't get to work and if it works and it can we would probably end up with creating a Campbell desktop or something so I think the idea of these multiple test sets is just to send a picture how people's implementations are and just to help us decide what to ship and then whatever we decide okay we're going to

the final list of the app which will be text that we just either launch the last test snap temporary test that with those changes everything included or

Tim Beiko: and I guess one thing that would be nice with that so like uh the CL folks were saying that um 4844 is being built on top of capella I assume this means that if we had this like call it minimal Shanghai test net which is basically this what's in shengdong now but it might be even less than what's in shangdong because if you say you remove the eof eips um then I assume that withdrawal test net could interrupt with the capella test

Nets on the CL side is that correct and we could like start testing withdrawals ASAP basically um and I know Alex Stokes you've been thinking about this I don't know if this makes sense you're always sorry you want to add withdrawals to

shut down

Tim Beiko: uh right yeah I guess you know don't think of it let's not anchored to Shanghai shangdan but like say we had a test net that has on the El side withdrawals and then all these other small dips you know push zero uh limit meter init code and whatnot not eof not 4844 that can interrupt with the capella

test net on the CL side correct right yeah so I want to get to withdrawals test net and if there's a few other sort of uh you know quotes smaller evm things uh those are fine

yeah

Tim Beiko: so I guess I don't know my rough proposal to move forward would be and and also like because client teams have said like it's really valuable to get some clarity on on what to focus on um should we move withdrawals and like these small eips to be you know fully included to Shanghai um leave eof as CFI um I don't know what to do about 4844

um but then focus on getting this test net uh that's running withdrawals along with all these small eips on the El side and then just withdrawals on this on this on the CL side um have that across our clients then in parallel we can work on the 4844 devnets like we've been doing already um I think on the eof side there's clearly like at least this desire to try and get the whole thing so I don't know if it's realistic to if there's enough resources I guess in across some client teams that to come up with like an eof like a full eof devnet basically as well and so if in the next month we could sort of try all those two

things we might be in a good spot to then see okay what's what's actually involved with 444 what's actually involved for uh eof um but know that like we already have this core of stuff moving into Shanghai um yeah I'm curious does anyone have a good objection to that yeah I was just wondering so would you suggest that we actually add um withdrawals to to our Sundown testnet and then also remove the

eof stuff

Tim Beiko: uh basically yes if it's shangdong it can be another test net because I I imagine it might it might get complicated to just you know tweaked out

but yes what I would suggest is we move basically the warm coinbase CIP the push zero one limiting and metering edit code and then the withdrawals we move them out included for Shanghai we start working on a devnet which has those four eips in parallel we can have a another devnet that's uh that supports basically full eof so to try and see what's like a version of eof that we could ship and and not then worry about having to upgrade the having to upgrade the version really quickly um um and then in parallel there's already all this work happening on uh the 4844 devnet so we can keep working on that

and just from like a the code management perspective we would assume that like both the eof devnets and the 4844 devnets kind of build on this um you know call it Shanghai core uh implementations that sounds good to me Tim

yeah

Tim Beiko: um okay so no objections there um so I'll move those to included um and then yeah I think on the next call okay Mario

zoned out sounds good uh he'll realize Monday morning when he signed up for so that's good um and I think okay so I'll move those eip's included um I think on the next call when we have all of the kind of other eips come on as well we can maybe make a decision about like do we want a CFI 4844 do we want a CFI more of the eof stuff and then um you know if we have some some better data on self-destruct or or also like 1153 and BLS we can we can discuss all of those on the next call but at least we for client teams I think it's clear that like getting started on withdrawals uh makes sense and then uh you know looking at the eof looking into 4844 and seeing if if we can kind of

make progress on those the to get them in a good spot for Shanghai um seems like a good Next Step the other thing uh I think that's sort of this starting a discussion on now for Shanghai is how do we want to think about Fork Activation so we discussed this a little bit at Devcon um basically the idea is that um uh oh 868 what do you eat 68 after um I thought we could finish the the activation discussion anyways today but just so people are aware basically if we if we choose kind of the CL side activates using an Epoch uh which is cleanly mapped to a timestamp

um because time and epubs just like map together well on proof of work we would use block numbers there was a big drift there um with upgrades like withdrawals we want to ideally coordinate when they happen on both sides so you want you know withdrawals to activate uh on the CL and then immediately be credited on the El otherwise you get a bunch of weird complexity um so I guess I'm curious to hear from teams like what do they think is the best way to deal with fork activation uh one obvious candidate is to move from using block numbers the timestamps on the El uh but there's a bunch of weird um edge cases that pop up because of that um so it it's worth I guess and I guess

when we're thinking about like planning Shanghai this is something where if we need to change the activation procedure as well it does add some some work um yeah so I'm curious to hear from client teams like what did they think about that and and what do they see as like the the best option for activation

Marius van der Wijden: so we had a we had a discussion about it in Bogota and I was the only execution uh layer person there and so the consensus layer teams kind of convinced me um I did Implement um to be clear they convinced you of

time stamps being deactivated sorry yeah yeah convince me of timestamps um I was uh I I also implemented uh Shanghai based on timestamps on the execution layer uh which was possible um there are a few questions or like a few things that can can come up um the fog id1 is um we can just use the timestamp as next Fork to calculate the fork ID so that's pretty easy

the more interesting things or the more interesting questions uh for execution layer clients are around retrieving stuff by block number basically right now you know before you retrieve a transaction by a block by block number or receipt by block number you know which rules to apply um but after this we don't know which route to apply to the thing that we just got either from the network or from the database and we would need to read the header of the block first um or we would need to uh

access so if we if we were to change something in the receipts based on a fork we would need to always uh fetch the header first to see if this the header by number first to see which rules to apply to to the receipts it's not a problem right now but it might be a problem for other clients so it's not a problem right now for gas but it might be a problem for other clients

Tim Beiko: oh Peter

yesterday

Péter Szilágyi: essentially the I guess the reason is that when you retrieve a receipt of transaction or any other

stuff from the RPC currently you do not get back the block timestamp you only have that the block hash and the block number so if you want to check which work is happening you would need to implementation of cash however in this case I I mean we could set if time stamp all of a sudden becomes discriminator then we could add the timestamp to the to the result of these requests and then you still have the same amount of

information so that part mobile

Tim Beiko: so I guess

is there something less worse than this basically to consider my feeling is this is like this obviously introduces complexity but there's not really a better alternative does anyone have like a strong disagreement with that if not they are probably yeah you might not see I think it's I mean it's a good enough idea that we should maybe just try to roll with it and see if anybody finds something interesting yeah and I guess is it worth having your sort of EIP or meta EIP I don't know to Define this so that like clients because I understand there's like two parts of

it one is like the activation but two is like the implementation details which might vary by client but is there some part of it that we want to standardize kind of like eip-2124 but not not quite

standardized

Péter Szilágyi: seems a bit much but maybe does have a document which highlights that okay once we switch over the time stamps take care of API method aapm method via API method C because they need some extra

jobs

Tim Beiko: got it

Łukasz Rozmej: um yeah so we showed the standardize Json RPC right so right okay I think we should make those changes

explicit that if someone uses it can can count of those being there

Tim Beiko: okay I'm and I guess so if this is the route we're going I think we should probably Implement that in sorry this like minimal Shanghai devnet so that like we basically assume it Forks on the timestamp and go from there and I think this is roughly what people have been doing in existing devnets already um so does that make sense to people and then once we have like a first devnet or two we'll probably know exactly how we want to change Json or PC and we can open PRS for that um but yeah does it make sense for this

first like withdrawals and small EIP devnets they use timestamps and and we can go from there oh Peter

Péter Szilágyi: so I guess one interesting Quirk could be that if I set up a Genesis for uh for a test map system then essentially every previous hardcore have really fine with block numbers and then um this one will be defined and maybe future ones will be defined by a timestamps if the the previous works are not all aggregated into block zero then I can imagine a scenario where essentially if you say that okay London will happen in block number 10

but the timestamp of block number one already exceeds already puts us into ships right unexpected weirdness that can happen if people just reuse the same Genesis as So currently you can just reuse the same private Network Genesis for your own testing purposes and the timestamps people need to be aware that you actually need to change your Genesis every time you speed up

a video

Tim Beiko: right okay yeah that's worth I and I I for the definite I feel like we can just have like 10 minutes or whatever be the the trigger or something like that but I agree yeah that's a edge case we should document

somewhere I'm not sure where to go okay so uh just because okay we only have four minutes left and there's two more things I think uh we should really try and cover so 868 by Marius and then Gordy um I there's a separate call to talk about Gordy but at least give afri a minute or two to kind of share it so that uh folks who are interested can can show up and discuss that

um Marius 868 yes um so if 68

Marius van der Wijden: is the newest version to the east protocol um and it basically we have we have two ways of sending transactions

um we have a broadcast and we have an announced uh retrieve scheme you announce the transaction hashes that you have and the other person can fetch the the transactions from you um for uh blobs four four eight four four we don't want um people to broadcast these transactions because this will increase the the load on the network uh quite a bit and so we um we we want to we want to not have them broadcasted

um and all they have them via the announcements um but we would like to have if 68 which adds the transaction type and the transaction size to the nodes basically you're announcing the transaction hash the transaction type and the transaction size and so your peer can choose which transactions to fetch it is written in a way that it can be implemented and rolled out right now um so like it it helps us in the future with 4844 but we can roll it out right now and yes we would like to roll it out as soon as possible

so that we have a lot of people moving over to 68 as soon as possible

okay uh Peter

Péter Szilágyi: yeah just after that the thing of denial of service letter that we've seen on the education client site for 4844 is a big block for that for that kind of large that in in uh Bogota we're talking about 128k transactions and broadcasting them to square root number of peers means that on the order of magnitude you will pass the same transaction across every link seven times or more and several people

get a lot of duplicates and when transactions are a few kilobytes that's not relevant but on transactions when you have these larger transactions you really don't want them to um clean from broadcast mode and once and this announce mechanism simply allows us to say that okay if it's the last transaction then we're just going to announce it so we guarantee that it will cross everything will appearance at Max retrieve it once so it's kind of like the optimal Network bandwidth usage the cost is that latency Y6 will be ever so slightly slower but I think that's perfectly reasonable for Block transactions and there you don't get thousands of transactions per second readily images

so being the block transactions it's it makes them a bit special and you can this this protocol extension allows you to to handle it especially and decide how you want to

help you

Tim Beiko: got it okay we're already at time um sorry um there was one other thing I skipped over on the agenda we're obviously not going to have time to discuss it today but I would encourage people to review what async and we can cover this on the CL call because it's relevant there as well um but basically uh this this proposal to add the block value in response to the get payload call and the engine API and this would help uh basically validators compare local blocks with

blocks provided by third-party relays which is something that we've been talking a lot about lately um so I posted I posted the issue in the chat I think if people want to review this before the next uh CL call next week that would be great and we can discuss it in more details there and then lastly uh just before we wrap up uh afried do you want to give a quick rundown on what's happening on Gordy and um the the call that you have scheduled next week to discuss this

Afri Schoedon: yes thank you I keep it very short so girly is in a really complicated situation due to the supply issues um it's currently easier to buy girlies

and to get it from a faucet which is not the way it is supposed to work so um I created a discussion with potential ways out of the situation on the issue of magicians forms it's linked in the PM thread please click on it if this is important for you and I have scheduled a community call next week where we can discuss part out of this past out of this situation in detail um and yeah I would not underestimate this because this will affect not only infrastructure providers and application developers but also might affect our work for protocol engineering and testing so if you could spend some time to dig into this thread

and maybe join the coin next Tuesday at 3 pm UTC I would really appreciate it thank you

Tim Beiko: thanks um yeah it's been kind of weird on Gordy recently anyone had final thoughts or comments before we wrap up foreign yeah thank you everyone I think yeah we had a lot of good conversations today um I'll make an update to the Shanghai spec um and then for anyone listening on the next call we'll try to cover a bunch of other potential proposals for um for Shanghai so if you have something that you feel really strongly about next week or two weeks from now is the time

to show up um yeah and and then I think if the eof people on 4844 people can also show up two weeks uh from now we'll probably want to continue those conversations as well um but in the meantime yeah for client teams uh withdrawals and these other small Shanghai eips are probably the uh most solid to be focusing on um yeah thanks thanks

a ton everybody things tended you thank you bye thank you bye thanks bye thanks bye [Music] foreign

[Music] [Music] [Music] foreign [Music] [Music] [Music]

foreign [Music] [Applause] [Music] foreign [Music] thank you

[Music] [Music] [Music] thank you [Music] foreign

[Music] [Music] [Music] [Music] thank you

[Music] foreign [Music]

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