All Core Devs - Execution #111

Transcript

[Music] so [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] so [Music] [Music]

[Music] [Music] [Music] so hello everyone uh welcome

to awkwardev's number 111 uh off schedule this week uh yeah awkward devs off week edition uh so we have basically a lot of stuff about london to discuss today um appreciate everybody coming on on the off week um maybe it's worth it i posted this comment in the agenda but just uh in the last call i said i would check in with the different client teams to kind of see what their bandwidth was for london what their preferred scope for the upgrade was and what their thoughts were on the other different eips um so i can just run through that very quick to hopefully frame the conversation because there was

a lot of things where everybody was in agreement on um the first of which is basically everyone said they would rather see a smaller sized london um rather than kind of a larger one uh the only team that wasn't you know 100 in favor of a smaller london um basically was in favor of just less upgrades in general so i think you know they they don't necessarily want a much larger london um with regards to the timeline for the upgrades so uh i had proposed like two timelines one where we forked my net around mid july one where we fork around mid-august um two teams said they would prefer the mid-july one

one for signing the difficulty bomb so around mid-july i think the difficulty bomb should be off to the extent that blocks are about two percent larger um and then around mid-august it was more like eight or nine percent um so the first team you know wanted to make sure we were aiming for july so that if something went wrong worst case we'd end up in august whereas if we went wrong in august and went to september we're looking at like 30 percent larger block times um and similarly another team just felt that the july timeline was kind of a a stretch for them but it's something they wanted to aim for and uh and you know worst case if delay it a few weeks if we can't make it rather than try and aim for august and have a larger scope

um and then the other i guess thing that came up is uh obviously if we keep london small in scope there's a bunch of other eips that people have brought up have discussed that they'd like to see on mainnet and given the focus on the merge there was a fear that maybe if we if we keep london small then we won't see those eips on mainnet for at least another year so i asked all of the team if we had an utter upgrade in parallel to to working on the merge after london you know could we work on that at the same time as we work on the merge oh i have the audio thing in the chat is it because people don't hear me

i hear you okay okay good uh and let me just check the comments on youtube okay no weird comments on youtube so i think we're good um okay so yeah so sorry i was saying yeah so if we if we keep london small obviously there's a bunch of eeps that won't make it in um so i asked the teams if we could work on another kind of feature upgrade in parallel to the merge and whether that would delay the merge or not it seemed like it for most teams it wouldn't kind of like we're doing right now where we had berlin and london in parallel then right now we're gonna have london in the merge and once london is out then potentially we could have you know the merge and shanghai in parallel um there wasn't like a hundred percent certainty on this

though uh and you know people said that realism would help figure out how how possible this is um but it's definitely an option that we can explore and then yeah regarding the specific eips so there were four we talked about eip2677 that was uh the i forget if it's doubling or capping the size of init code um but basically nobody pushed for it very strongly and it would add a bit of testing overhead for the upgrade so it seemed like you know nobody wanted to have this in london 2537 um so although it's already implemented in a lot of clients um what was uh what was mentioned is if we do change the library the

blst and if we change uh the gas prices then we need to obviously do extra testing and extra benchmarking uh if we were to do that then um then it would probably kind of grow the scope for london significantly um and we could either you know either we could include it in london as is without changing the libraries with the implementation that clients have or we could if we wanted to do those changes it's something we could prioritize shortly after um and even if there wasn't another feature fork some people mentioned we could maybe do this at the same time as the merge if there was a strong desire for it um third one was 3403 so i think this one

and the last one were the two most uh discussed but 3403 basically no one opposed to it if uh we think it will help the network security alongside 1559 um but at the same time you know it felt like a solution where a lot of people had quibbles with it so some people thought it added too many edge cases and it should just go ahead and we should just go ahead and remove all the refunds all together like the original proposal other people said we should kind of come up with a more elegant mechanism and and and kind of have a broader overhaul um and that would obviously take much more time and couldn't be included in london um it didn't seem like anybody's kind of quibbles were strong enough to block it if we think that you know this is

valuable to have in london um but it's definitely something we should discuss and then the last one was 3074. so i think there you know some teams were strongly in favor some teams were opposed i think even the teams in favor said that it seemed like something big and somewhat contentious to include in london especially on a short timeline um so this is definitely something that like would be worth building another feature fork around um and the teams that were kind of opposed to it uh the two main things were you know wanting to have like a security audit which is already in progress and also just wanting to have more time for the community to digest it and kind of get comfortable with the changes and whatnot

um so that's kind of the summary there uh i'll stop here i don't know if people have comments thoughts questions uh about this martin i see your hand is up yes i would like to just uh make a brief update about 3403 i don't know if i should do it now or later yes so we have this peeping call uh me and italic and discuss it a bit and there were questions and after that vitale came up with an alternative scheme uh which yeah we're iterating on a bit now but the basic idea is just lower well it's three parts lower one of the constants the story

as to reset gas from 15 000 to 4 800 by doing so well that's one change another change is to remove the refunds from self-destruct and the third change is to reduce the so right now there's maximum there's a cap on the refund you can only get refunded half the gas tube consumed that would be lower to one-fifth so the first the change to to delete to remove the refund for self-destruct this is self-explanatory it would make guess the v2 of gas tokens moved and the second change of just lowering

that reset gas limit would make it so that the first version of gas tokens where you actually reset a storage slot and get some gas back you do still get gas back but you you're nothing only slightly below 2 000 gas that you get back and the interesting quirk about this is that if you are using a gas token your cold access to that gas token will cost two thousand so you would be netting out zero uh and the effect of this is that if you are using if you're using if you're resetting a story slot which

is otherwise useless you gain nothing but if you are truly reading i mean if you're using an actual story slot which which you are reading a value from um which is useful to you in your in your computation and then you set it to zero because you no longer need it then you do get the refund because you paid the access cost when you read it and made use of it um and the third change to would simply reduce the block elasticity so that you can't have this two times two factor

of what's actually being executed in 10 million gas but it will be lowered uh a lot making the execution per a gas in a block more deterministic um yeah so and i think one one benefit of this version of the the refunds would be that um well for one we get rid of this incentive to use one as the new zero if you're a contract developer um and for another it's actually even simpler than 3403 because it just

changed it it keeps the same mechanics but changes a few constants there so it currently exists in not in an official eep form do you have a link to like i don't know if there's a hackmd or just a write-up okay great if you can post that in the zoom chat or awkwardness chat that would be great uh thanks uh and scar i see you have your hand up yeah just say like a quick question for that i mean that that sounds really interesting i was wondering um because imagine you were saying you're still iterating on that do you think this would have a chance of of still being relevant for london or is

it too late uh sorry can you hear me yes yes sir yeah i got i got a phone call just as dancer was starting to talk uh did you ask me something oh yeah i was just wondering uh for this new new kind of alternative to 30 70 due to m 343 uh could that still possibly kind of like be ready in time for london or was that something that would then only arrive at a later date uh no i think we can have an april in a couple of days um so i just thought i would bring it up here to prepare people that there is a new alternative coming um which

is even simpler than the existing one and uh hopefully without the um without these ugly words which some uh people were complaining about that it uh yeah makes a strange incentive to leave small things with at one instead of zero and so yeah with regards to timing you know if we want the aim for this july london uh fork minute um it means we probably need clients ready around uh mid-may um and then just looking you know at like the alcor dev schedule uh we have one next week and then we have one

that's basically mid-may so i i feel like if we want to have this in london we basically just need to agree to it on the next call so if you know if martin you can have an e-belt early next week um then it gives kind of the rest of the week for people to chat about it and we can probably make a decision about it on the next call yes sounds good cool um but yeah i yeah i i think you know getting rid of like these complexity and and also like the incentives of using one as a zero i think is is really good um sweet so i guess yeah we'll come back to

basically the refunds on the next call um aside from that so uh you know for the three out of eep so 26 77 25 37 30 74. it did seem like you know the the rough consensus when i talked to the clients one-on-one was to keep them out of london to keep the scope small um does any everyone kind of agree with that does anyone have a strong opinion against hey go ahead so yes i just had one question i i'm just curious you know for 25 37 if there's anything that you know sort of the core dabs would like to see with that um so you know is is the plan to use

blast and if not you know the i think there were some very very minimal like you know gas price changes like a couple constants so i'm just trying to understand like you know is there a plan to do more technical work on that and if it is just changing the gas prices you know is it better to put that out later or to just do it in london i guess i don't know mika paul and scar do any of you want to answer to that that was the question for client dubs yeah exactly yeah so so okay so leave your hands up but yeah if anybody wants to answer to kelly's kelly's comment please go ahead yeah i guess i can

so all the testing and cross clients all of that has been done on the existing implementations and if these gas cost changes are based on the assumption that the blast library is used which in turn means that all the implementations should or would want to switch to that then i think that is a big project or at least i mean yeah my understanding is the gas price changes that were suggested by alex were not

um they were they weren't based off of blast so they're based off the current library uh it's possible that they may be a um a new release of that existing library but you know it's not an entirely new library so i just wanted to maybe clarify that the gas price reductions that were suggested were suggested for the existing library not uh not with a library switch yeah and it's very possible that they're minimal uh i'm sorry to say i haven't looked into what the exact implications of those gas changes are like and how how large they are okay yeah i mean maybe i could just

follow up with you martin off and and give you the quick diff i mean from what i understand there was um a couple of the the pre-compiles were a simple um you know literally a constant shift like from seven hundred oh yeah yeah i don't i don't i don't mean that they would be like indicating being a large endeavor to implement i'm i'm just concerned that maybe the gas cost changes make them unfit i mean become a denial of service vector computational wise so that aspects need to be considered uh i'm not claiming that's like a blocker for doing 2537 um

yeah i'm just saying if there is maybe a bit of work that needs to be done and if we want to switch to the lst that will be even larger and i know oh go ahead if clients are happy with the current gas costing we can always in theory um release bls with the higher gas costs and then at a later four could reduce it like once bls is on chain it's pretty easy for us to adjust gas costs as needed to reduce them if we find enough data that shows they should be reduced or increase them if we're seeing notice a denominator attack vector so i would say if we want this to go in sooner

we pick the gas costs that we can get everybody to agree on and then we can put work for reducing gas costs off to post london or post whatever yeah i mean i do think that makes sense mike in particular if there was the desire in the future to switch to blast then gas costs could be reduced even further below you know what's what's suggested in the document now uh since those gas pricing is not based off of uh using the boss library we get last into the client libraries and then after it's in all the libraries or in all the clients then for the next fork after that reduce it so we don't have to do that simultaneously yeah and i i think it seems like a

pretty good uh approach in general to when we introduce a computational intensive pre-compile to be moderate you know be conservative about the gas at first and then as we see deployed on machines and people various people who can run test and see yeah experiment with it then we can lower it like we did with the modex kelly exactly um and just one thing i you know would want to make sure i know i think a while ago when i talked to open ethereum about this you all said if you wanted to do 2537 it would require kind of an audit

or something like that so um yeah i'm just curious to hear from open ethereum about how that would work in your your roadmap how realistic you think something like that is for london assuming there was no changes to the uh the current specification hi do do you mean for the bls yes or yeah as we already said um we have this implemented but uh i think dragon said that we need to have like uh an external review of the code so in general i don't think that would be a problem for london

yeah and i guess maybe just one one comment on that for the open ethereum team there are blast does now have rust bindings that could be used if they wanted uh to use the library that had undergone a security on it so that that would be an option if they're uncomfortable with the current rus library that they have is to switch to an api compatible uh alternative library that has undergone on a security review um micah paul and ensgar are your comments about bls no no okay sorry yeah i'm good

go ahead to say um with evm3d4 we were within 2x last time i mentioned it so we had a bunch of breakthroughs and now i'm even better uh doing even better than 2x this is runtime and gas and to blast to the speed record [Music] and so worst case if you know if something doesn't happen or something doesn't work out uh you know we're looking at less than 2x slowdown if we just do it with evm384 that's it got it thanks for sharing um so i guess you know it seems from like what i'm hearing now that people are mostly fine

with bls but uh i do recall yeah when i was talking with the client teams everybody wanted to keep kind of a small scope for london um so i don't have to implement it i don't have a strong opinion here but yeah what are people's thoughts about do we want to try and include this for london given that we already obviously have 1559 um and then this gas refund eep that will come next week um or some other version of it um yeah i feel like this question relies a lot on if we want to have a feature for shortly after one then because i don't think people are saying that we need bls too you know as soon as

possible it's more we would like to have bls before you know if there's a one-year gap yeah that was that was going to be my comment as well like the i think we're tackling those questions out of order we first need to decide are we doing a follow-up feature fork and that will greatly impact like my feelings on should the stuff go into london or not and i guess that makes a lot of sense the challenge uh people had with determining if we would do a feature fork after is the uncertainty with regards to the work from the merge um because we so even though the interface in the merge you know is pretty straightforward um some client teams mentioned they might have to do like performance work

and stuff to just get it working um but yes if if people i don't know if people think we can do another feature fork in parallel to the merge um that obviously changes the conversation i see thomas is in favor i don't know geth open ethereum basu what are your thoughts on this well i i don't know if i'm speaking for everyone on the guest theme but personally i do prefer smaller forks uh more often than this very

large forks so i guess generally i'm i'm more in favor of a feature fork shortly after than clamping them together um is anyone from base uh what is shortly after me and realistically is that like a month and a half after or is that three months after i would think more three months if we look at just how berlin happened so like if we have just you know if we basically we're gonna stop working on london um you know like have a client release in june

and that basically means assuming nothing goes goes wrong but that's basically when we can start working on the next one as we're just like waiting for the test nuts to fork and whatnot um and so if you look now like for uh for from berlin which was mid april all the way to mid-july that's roughly three months right like four to seven yeah um so that means like three months after july i think yeah october um october-ish is probably the timeline and then obviously october is when it would hit main net but then again if we if we have the test nets fork and with not six weeks before that it's kind of like around august the the bulk of the feature work on that fork is is basically done

so my my concerns with this a little bit would just be that i think at least that broad community sentiment was that people could potentially i could imagine like being okay with another feature fork if it wouldn't impact or they delay the merge right and and like a lot of these comments here were addressing that like this could be done in parallel but like but i i at least immediately it seems like in october um feature fork would basically just be an implicit decision that we just give up on any potential for a uh merge this year because then i mean the delay between that fork and the the merch would of course be at least be another three months because it's like an especially like big big

fork of course and and so i do think that this kind of implicitly breaks with with this um assumption that it wouldn't impact uh emerge at least while merged this year would still be possible on its own um and so i was just wondering like is there any room like as you were saying uh historically it might might take about three months for the next focus or something like that as like is there any chance that a future folk in even something like september would still be some like possible because i think uh implementation wise if it's really just something like bls plus um um 3074 something like that both of those i think i'm always already implemented so the question is like how much effort is it really and

what's like what's the the shortest possible timeline to a feature for that that that is somewhat realistic with speaking my question so there's a couple comments in the in the chat uh you know saying that an october feature fork takes into consideration working on the merge uh in parallel um and that doing it any sooner than that would mean we can only ship stuff that's already implemented basically so maybe 25 37 but not like 30 74. um and yeah yeah so i guess yeah that was and then yeah a few comments also from both i guess basically nethermine saying they would prefer to keep london skinny um if that means having a freak

if that means having another feature fork um danny you have your hand up yeah i'll just echo what i'm gonna say i mean that's why i asked if this is a one a one and a half month or three months you know what's the delay between forkster because then if you have a fork late october or november um i will echo what andrea said and that the coordination overhead of even if something is is completed and ready of doing another upgrade the merge uh within like plus or minus a month from that uh becomes ambitious at least i also you know i think we are

attempting at this point as you said earlier in the call to get information uh from the the the rayanism hack and and the refinement of the specs there in terms of like better understanding a potential timeline and complexity and in that context i think it's difficult to make a totally informed decision on the on the potential marriage timeline and thus it's potentially difficult to make the decision on the the other fork timeline which then makes it difficult to decide yeah yeah it's all connected yeah um although i guess um sorry i'm reading the chat um yeah so

i guess um if like so there was a desire for like almost all of the teams to keep london small um and you know i guess we need to figure out is that like better than er or you know something we value more than guaranteeing you know the inclusion of something like 25 37 before the merge right um because i think if we start if we add basically more features to london uh beyond 1559 which everybody says is kind of one of a very large feature already um then we we likely are gonna delay london um and that means

for sure there's not the opportunity of another fort um and so we basically have to make you know london as big as possible and that's something that you know most client teams seem to not want um on the other hand if we keep london small we can't like guarantee that there will be a feature fork now because we don't have enough information about how it would impact the merge and and whatnot um but as that's being you know worked on um there's definitely stuff we can move forward so you know all this conversation around bls seems like it it's not necessarily gonna gonna delay the merge and then 3074 is the other eep that you know would have to be implemented um and i think if we were to have

another feature fork we want to be very mindful that like we want to keep it small so i don't think we i i don't know what else might come in it but yeah um oh and thomas says adding features to london delays the merge even more uh than another feature fork in october because the team is already focused on the merge right now um so that's also something that's worth considering like right now all the teams are kind of focused on london and the merge in parallel and so we if we had another feature fork we would focus on you know shanghai and the merge um and then it's just a question of like can the timelines work right um so yeah oh gary uh micah you have

your hands up i'll go ahead and go um yeah so it i mean it seems um we discussed in uh in a team on uh baisu that uh 3074 is really kind of the only substantive portion of this feature fork that we're discussing the other the other uh canada deeps don't seem like they're terribly difficult um so the scope of a feature for it could almost be like a mini feature fork and given the uh kind of speculative timeline for the merge um it seems to me that we can't really i mean

it seems like if we want certainty around london we should just go ahead and go with the skinny london and and know that a feature fork um shouldn't have a huge scope uh depending on the outcome of the the audits for 30 74. thanks yeah in a similar similar camp i think that it feels to me based on the conversations here and the status of the merge that we should go with skinny london um because that won't offend anybody everybody seems on board with it and plan for a follow-up merge in october and then if it turns out that the merge is being held up by that we can pivot like so if if we

sorry follow-up fork um if if we uh find out from rayonism that oh the merger is really easy we can do it right now then we'll we can drop the october fork and do the merge if we find out from rainism oh there's a lot of gotchas that we didn't think about this is going to take a while then we're already on track for an october fork and everybody's happy with that as well so i just i'm worried about planning for the merge when we still are lacking information i feel like we should plan for the information we have and then be prepared to pivot if we get new information i think that's reasonable yeah i know that is it oh go ahead alec i was wondering is it possible to plan a feature fork but just to leave open until the very ends the decision of

whether the future fork gets activated a month before the merger or month after the march yes and i i think the two things we probably want to be mindful of is like yeah having a quick date and that means having a small scope um so it seems you know like just over the past few weeks the two kind of big eeps that people really want to see but that clearly are hard to fit into london are 25 37 and 30 74. um i think if we want to have you know a fork that's quickly after london and that doesn't delay the merge as much we basically have to accept that these are the two big eaves we'll put in like if we have

another huge feature coming in um obviously that delays the whole thing and and not only the implementation but just like the time to agree on that um so i think yeah if if you want to have another feature for shortly after based on you know the information we have now um we should probably just already signal that we want to keep it small and it's really stuff that was important but couldn't make it into london i think that's generally a good plan for all of our feature forks is that we kind of try to get a rough consensus on what's going in it as much in advance as possible um unless we're gonna go with the exact opposite plan

of work on things until they're done and then just put them in the next fork but it sounds like that's lost favor lately um and sky you haven't just you know just very quickly wanted to retreat then though for probably like people listening and and so on just just to be very clear that like the planner would be to kind of just have a feature fork ready afterwards but like be completely like just completely depend on on the progress on the merge side to to decide on orders so even if there was only a slight delay or something the order would just be flipped and so basically the merge will just be done like it will just be executed once it's ready and like the feature work will basically just manage and just be kind of like applied at the first

kind of like possible moment where we are free but like the basically there is no we would kind of commit on on not impacting the merge timeline at all basically right i think that's fine uh and obviously so also to make something clear if we were to take this feature fork and put it from before the merge after the merge i'm sure there's some technical overhead with that that seems like it's kind of small price to pay uh to have the merge earlier um but yeah do all client teams agree this generally makes sense so keep london small you know plan for a feature fork i don't know if it's you know mid-october or late september but around that timeline

um if the merge is ready before uh we obviously do it before and that means we'll have to keep working on it in parallel um and then if the merge is ready shortly after we do the merge shortly after i don't hear any i'm i'm on board i'm on board with uh i think yeah i'm on board with that i think anyone strongly against or generally against okay so to summarize then it means that for london we have the stuff that's already in the

in the experimental uh devnet so uh 1559 uh 3198 the bayship code and then the difficulty bomb um martin you're going to put together an alternate refund eep for us to consider on the next awkwardness call uh but hold on uh yeah let me not take you for credit so i just presented with alex's idea here okay and yeah because he was late to the meeting okay you know but we have been working on an e-flat there's just some uh formatting stuff at the end a bit more left to do and i think we can push it out fairly quickly cool and yeah so if we can discuss that next friday uh because we do have a call

next friday given this one was in our band um it seems like it should be pretty easy to implement and won't delay london then and and then you know there's nothing else in london so no 2537 no 3074 um but as we're done implementing london we start looking at a feature fork uh for shanghai uh which would i guess potentially have those two eeps we can we don't have to figure that out today um i would oh and ansgar has a comment about which fork should be called shangai i feel like it's easier to call the feature fork shanghai we can just call the merge the merge because everybody knows about it but um

it's really not a strong preference is the merge even a fork um okay so i think this answers the question that the verge is the verge i um okay so i think we're all on the same page at least for london uh and for naming for the forks um and then the other thing uh i guess the other thing i wanted to ask about for london is uh we have this included in it about the difficulty bomb um 3238 and we all agreed

a month or two ago that we wanted this in we kind of don't have a choice um but uh we never kind of discussed the the period there was some conversation on the thread but right now the eep would push back difficulty bomb uh to may 2022 um are people generally okay with that i know uh light client and myself would have preferred march 2022 but it's not like it's super strong opinion um i think october i mean if we want them we're planning on emerge or a fork in october then it should be october because it's a great forcing function to make sure we actually stick

to our plants so uh like clients suggesting december 1st which is maybe a bit less a bit more pragmatic um i don't i would be fine with december 1st it feels like something has to happen before the end of the year whether that's shanghai whether that's uh yeah whether that's um what's it called uh the merge yeah okay so do everyone agree we obviously can't time this to the day perfect so november 30th versus december

1st doesn't make a difference um but trying to get it around uh yeah around late november um early december uh so i'll ping uh afri was the author oh god i think what helmets is trying to say i don't know if he's gonna make or not i think what he's trying to get at is that once the holiday season starts um it's very unrealistic that we will get anything done so that usually starts around thanksgiving which is third week of november like just traditionally that's when people stop being available to do anything productive so if we do want targets this year which i do personally then i kind of agree with them that it should be targeted you know we should expect to get something out before thanksgiving

yes but ideally we don't need to have the bomb go off right so if the bomb goes off on december oh sure yeah if the bomb goes off any time in the holidays then it means we're forced to release before the holidays so exactly i understand that good point so does anyone disagree against the november 29th december 1st range um cool okay so i'll leave a comment on the on the eip to make sure we update it um and i guess so those were uh the two big things um the other one was you know if we agree to the london

timeline of trying to get it out uh mid july um it feels a bit early to set fork blocks for that uh so does it make sense to set four blocks you know probably the next call or order one after um yeah when when the p so and to be clear it's like around mid may we would need client releases so like two weeks or two calls from now um so when would be the best time to just set the blocks for the test nets and potentially maintenance could we have candidate blocks for the next meeting yep i'm fine with that um so yeah if

if someone wants to look at uh i i'll share the comment here that i had rough dates for um but if people want to try to find blocks that are nice around those dates um we can we can discuss it at the next meeting are we 100 on mid july or is there any desire to try and push up a couple weeks like the beginning of july if we're only going 15 59 so i guess it depends um might yeah i would say mid july and the main reason is it gives us a lot of time on the test

nets and it gives us a good buffer between the last test net and main net so because 1559 is such like a big change i would rather have kind of a long rollout period but it's not a super strong opinion uh thomas also says mid july does anyone feel like sooner is better okay no one pushing for sooner so i think yeah we should probably aim for mid-july then um i mean i think i weekly push for sooner but i'm you know i'm not the one who's releasing the clients so yeah and i i do think so you know uh

there's a comment about tools and whatnot like it is something that a lot of people have shared with me that uh they felt like with berlin we you know we probably didn't take enough time for like 29 30 and explaining that out and whatnot so i think 1559 is definitely something that tooling even though they they don't strictly need to support it they want to um and and i think uh yeah if we can give them time to get ready for it people will appreciate that um sorry i'm i'm just curious what are the what this tool and you're talking about so basically all the libraries right like libraries stuff like web3.js ethereum js um all of the folks like infera etherscan

and whatnot um so basic and because 1559 changes the block and the transactions uh anything that that deals with those has to update um yeah um right no that has to update yeah just trying to provide a better experience exactly so once there's definitely like a strong desire by all of them to be ready for 1559. um and yeah and every time i talk with like tools or builders the feedback we get is like it's almost too fast it's never like this has been rolled out too slowly um so yeah i yeah i think it's probably good to have a a long delay basically between the time

where we say this is happening in july and july um because otherwise people basically don't pay attention as it's being uh worked on and it's not a hundred percent final to be fair i i would rather just spend 15 minutes and figure out some blocks for the london hard fork today and then ship it one week earlier than you know spend a week and decide on the blocks next week but why i mean we haven't even merged the stuff into the clients yet please not go ethereum i don't know if it makes anything go faster if we set the block

today rather than in a couple weeks i'm just saying i think that people were saying that people want to build these tools and it's good to know like when that deadline is but if they don't get that deadline until next week then that's one week longer it takes for them one like one week longer of the period time they have to build but if we give them that deadline today and move the deadline up is the same amount of time but if we i mean we basically say a date now right yeah so are you saying yeah like client are you saying so say we said today that like you know the date was july 14th are you saying that if we set the blocks now we could have it like july 7. more or less i mean that's that that's sort of what

i'm saying but again like i'm not super strongly in favor of doing anything i just think that this is something that's been in the works for a really long time and you know one week earlier is not you know i think that's okay especially given all the things coming up after the london fork if we can do it earlier that's that's good what would like a week earlier basically mean that we would have to have clients freeze also a week earlier basically like then may 12th already and is that realistic yeah i think that's where we're also bottlenecked right uh

it's like we need sure that's true um so and and i also feel like the other unknown is we you know we still have an eep that's not even an eep yet um so i yeah i know thomas uh nethermine seems in favor of saying the block numbers get slightly against i don't the people have strong opinions so i think i don't know maybe just keeping the dates for now given we're not 100 sure and then next week we can set the block numbers and we can also next week look at like how ready clients

are and whether those dates actually you know make sense so we can say july 14th is almost like the you know it's it's the date we're going for but if everybody's ahead of schedule then we we can potentially move it forward but i'm just cautious of doing the opposite like it's probably best to say let's aim for july 14th on main net and then say we can actually do july 7th then the opposite i agree okay so the people listening you know you can aim for july 14th for a main net fork for london so start preparing now um and then

there'll be forks in kind of the month uh or so before that on the various test nets um yeah um great so that's i guess all we had from last time for london um i know like client you also had a small uh a small eip you wanted to discuss uh 3521 which changes the access lists in uh from 2930 yeah the so you know the the very short summary is right now if you want to create an access list for the um a contract that the

transaction is immediately executing in so the two field in the transaction you have to pay the 2930 cost of that address to provide keys and for it to be economical to provide keys for that that immediate target of the transaction you have to use about 25 storage slots before it's more you know we were more incentivized an access list versus not and this basically reduces the cost of this initial um of the ad of providing that to address in your access list to just the cost of call data and the reason that this is okay to do is because 29.29 already adds

the transaction target by default to the global access list so it's basically being charged twice right now and with this change in cost it's economical to use an access list after you read about five slots so this is a really small change and i think some people have have uh brought it up in various different channels any thoughts comments yes um yeah i already posted my comment on

there magicians uh i mean in general i agree with what you're saying and it's uh it's ugly uh however i think that it's not it's solving a small problem uh it doesn't solve a big problem that if users like blindly just add slots they may well when they submit the transaction it may fail early because something changed from when they made the access list so they actually actually was included in the block which makes you pay the full cost for everything you were going to access in case the transaction had followed the path that

you thought it would uh but since it exits early yeah you're just paying for nothing so whether or not and what parts of the state to include what parts to not include and that is in a tricky situation um it becomes slightly less tricky if we remove this particular word i mean we help solve a little bit of a very complex problem um but yeah so i personally don't think this is very important to get in urgently but i do agree

that this change from life science is good and in the right direction uh but i personally don't see that we need to like rush it then that's just my i have no really strong opinion about this i'm glad to hear what other people think uh thomas has a comment in the chat that it makes sense but it requires discussions as better solutions might be possible um and then ansgar says like it might be a good fit for the feature fork uh thomas plus ones that anyone else has a strong opinion yeah i mean i definitely agree with

martin i think that i think it almost is starting to incentivize people to use access list without fully understanding the ramifications and you know it's something to always keep in mind that your access list that you generated time t is not going to be the same transaction list as needed at time t plus one and that's a tricky thing to communicate so i'm pretty happy unless there's people who want really wanted asap to push it off to for further discussion cool thanks um so i had one last thing on the agenda um this very kind of process thing

uh but we have this considered for inclusion status that we didn't use a ton for london because um i guess 1559 was uh the the big one um and uh basically we had you know considered for inclusion was the status where we would we would give to a neep uh if it looked like a good idea uh but you know it wasn't ready to be included in a fork and we i think we implicitly kind of reset it between forks and a lot of the eips that are proposed for a certain fork kind of go stale for the fork after so this was just a proposal that like if we put something cfi it automatically kind of resets between forks

um and people just uh you know have to ask for it to be considered again for the next fork uh basically like kelly did for 25 37 so it's not like an extra process um but yeah i just wanted to see if that was okay with everybody and the main the main reason to do this is otherwise when people look at this cfi list they'll see like a bunch of old eeps that you know someone proposed for istanbul or whatever um and uh you know it's not actually being worked on or being considered by core devs so having you to reset every fork is just like a clear way to keep the list up to date no objections um

okay so i'll take that as people are good with it um and i guess for uh um yeah i guess for uh um london we don't really have any cfi eeps because we kind of moved everything into upgrade directly but uh you know when we start discussing shanghai we can we can definitely use that again um and i guess one last thing i see martin has a comment on the agenda about not trying to make too many decisions on the off schedule awkward devs um and we should probably keep the regular slots for any hard decisions um

i guess i generally agree with that uh and that probably just goes towards like picking the blocks and confirming everything here on the next call but do people have thoughts or comments on that my solution to that is to make the this an official a cd call rather than an office call um i'm a big fan of more regular meetings it feels like our current bi-weekly meeting or alternating weekly meetings are way too full and i think we're at a point where we need to have more frequency and so i would vote for just saying this is an acd call and we make decisions on it or at least going forward we do that so i guess there's two different things

one is like you know the decisions we make today i think are pretty valid but it'd be good to confirm them next week and two is making this uh is making this regular it seems like there's not much appetite to making awkwardevs weekly uh anyone feel strongly that this should happen aside from micah i i sort of like you good start i was just going to say i sort of feel like if we use breakouts more liberally that would probably reduce the amount of discussion on all core devs i think especially the last few meetings we spent a lot of time discussing

and you know going back and forth on something that really could have been discussed in a breakout room and then people get to come back and sort of i also shared what the conclusion was yeah so my um i agree that would be ideal we've been trying to do that for like 6 to 12 months and just failing repeatedly repeatedly repeatedly and so i think that we're at a point where we need to start punishing ourselves for not succeeding with that and like it's kind of like hey we gave you guys we gave ourselves a chance to fix this without more meetings it did not work we are going to have more meetings now like sucks to be us we should have done better um and if we can start doing more

breakout rooms and our meetings get empty then we can start canceling them which would be great um but i feel like the current holding pattern of don't have more meetings and also don't successfully do breakout rooms and don't successfully do async is not scaling well like it doesn't work as you know we have more people involved and more and more stuff is happening like the merge and stateless and all these other things are coming up we do have the merge calls though right like so i think this is one thing um and i don't like my i guess i don't my opinion is it feels like we do get through most of the urgent stuff like there's always stuff that's like lingering and i think that's kind of okay it's not the end of the world

um yeah i would i guess i would prefer if we had more topical meetings like if there is something that we need to take like a quick or important decision on we probably should but i don't maybe i need to look through examples of stuff where we we didn't kind of make a decision quickly enough and we should have had more breakout rooms but it feels like you know for london we're on a good in a good spot where the decisions are kind of made and and and we have time to to deal with them um there's maybe some topics you know like obviously 3074 is one where we need to dive in and have more discussions and i think there's been a few calls on it already

and we can definitely have more um but yeah i'm not sure i guess what are like the things that we don't have time to discuss here so i think the things that we're struggling on isn't that we are struggling to decide on like fork blocks or whatever it's more that we don't have enough time to actually discuss like we have eips they get held up just on discussion not on coding um the obvious canonical example of this is bls right we've had bls done for 12 months and every single client and the only thing holding us up is just not spending enough time coming to consensus like that's to hold up for bls it's not code it's not engineering efforts none of those things it's just people talking to each other and coming to an agreement on it and so um like so we end up the solution

we have to that is just don't implement bls and i i that's just again canonical example i've seen this on a number of eips where we end up deciding to not do a thing just because we're not spending enough time talking about that thing and coming to agreement on it whether it's async or sync or breakout or acd's whatever we just need to talk and agree on things so they unblock so i feel like i have to yeah i have to think about that more off the top of my head one thing i feel like one of the causes for that is also that we end up having stuff that's just more urgent to talk about in a way

and like for example for bls when we knew it wasn't gonna make it into berlin um then you know all the berlin topics became kind of higher priority um and then i don't know yeah the challenge with london was like the 1559 was already such a big change and do we actually want to put anything else in and you know how do we do that in parallel to demerge um and i guess yeah like thomas says it seems like we're pretty much in agreement on bls today um yeah i like i feel like like i see you having an extra meeting definitely helps like it solved a lot of problems that we've had for months like just one extra meeting seemed to do

it maybe we just got lucky coincidence i don't know but it really feels like having twice as many meetings um was a solution like it fixed our problems so i guess in the chat people are suggesting that i have more readings but not everybody else which i'm fine with i feel the same actually it's actually teams calls and during the last week that caused that much of an agreement and this in this meeting to go smoother it's not just because we we had this call today uh practically went into the summary everybody was all aware of the decisions the communication everybody expressed their opinions and that's why it was so smooth today so i was just a great thank you to team for for that work

it was fantastic effort thanks um i mean i'm happy to do that every you know between every call with every client team but sometimes i feel like it might have too much overhead i can definitely i'll definitely do it like when it feels like we need to figure out a lot of stuff between the next the calls like for example before next week i don't think there's a lot we need to do um but yeah i'm happy to keep doing that my only concern i had while doing that is i don't want it to seem like things are you know happening behind closed doors and whatnot so i think it is still good to you know summarize the outputs here and give people a chance to you know discuss it but if it helps come to agreement quicker um i'll i'll definitely keep doing it

um okay so yeah let's start with this i'll keep yeah i'll keep picking clients and trying to chat with them when we need to to come to decisions on stuff um anything else anybody wanted to discuss or we can end this meeting early for the first time in like three months oh thanks to tim yeah i'll take the credit yeah we're gonna hang out the cool team's gonna hang out on this court lounge after the call where you can chat about 30 74 or any unrelated topics if people are interested and also we have mentioned this in the

chat that we are going to have a community call of on 3074 on monday at 1600 utc awesome well thanks everybody appreciate you all coming in on the off week cheers have a nice weekend everyone thank you bye bye bye thanks thank you everyone thomas does have a mic [Music]

so [Music] [Music] [Music] [Music] [Music]

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

[Music] [Music] [Music]

[Music] you