All Core Devs - Execution #107

Transcript

[Music] [Music] [Music]

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

[Music] hello everyone and welcome to ethereum core developer meeting slash all core devs meeting number 107 uh we're going to jump into the agenda but before i do that just wanted to give a quick 10 second announcement i said a couple months ago that i would be

stepping away from the role of all core dev meeting organizer and the person who does the streams and runs the calls tim baiko is going to be taking up that role starting next all core dev meeting so thanks everyone um i already thanked everyone last time so i wanted to do that again but uh i will be here to if tim needs a backup and if there needs to be something where there's a neutral party if like tim is conflated in something like he's in the uh pocket of uh of an eip and you know someone needs to be here to be more neutral i'm happy to come back so um thanks again everybody and let's get started on the meeting all right so berlin updates um

eip 2315 that is a huge topic that was talked about throughout um the week maybe even to the weekend i'm not sure um can someone who's i don't want to put you on the spot too much light client would that be possible for you to give like a 30 second or something summary of like i guess the reason why people are asking to remove eip 2315 and if you have an understanding of the other side why people want to keep it in kind of a thing or we can have someone else do that i just haven't been following chat that closely the last 24 hours to know the latest

yeah i can try and and really briefly introduce this so i i opened this proposal about three days ago and you know this is an incredibly irregular proposal and i you know i didn't open this proposal as a political or personal agenda i just opened it because i saw um i saw some comments from the solidity team on twitter and the ether magicians thread that i found pretty concerning regarding the usefulness of 2315 i you know introduced those threads into the all-court devs chat on discord and there's been you know a ton of discussion about 2315 about the process of accepting eips and i think a lot of the you know the

through a lot of the discussion you know we found that i believe that we found that 2315 in general seems great on the surface but as we started digging down it didn't quite you know address what it was claiming to address it it claimed that it was going to bring more efficient contracts to mainnet and i think that the solidity team did a reasonable job of showing that it's you know a very small gain of efficiency if any and there are other things that we could do to achieve very close levels of efficiency that aren't as big of a change as 2315.

also claimed to improve static analysis and you know we still haven't had a lot of people with the strong static analysis backgrounds go through this eep and really you know share their thoughts on it but from the discussions it appears that it doesn't really change um you know what we have today in a big way if anything it increases the number of of um ways that the code can flow from one place to another and i think a lot of the people who oppose removing it despite these claims are you know people who a don't want to set a precedent for a movie geeks the last minute which you know i i definitely understand to agree this is like a very irregular

proposal and it's not a good precedent to set um you know i am not the right person to like you know technically say why i don't think this eip should go in i'm just trying to boost the signal of other people who've shared their thoughts but i feel in terms of removing it the best thing to do is to not put eips on mainnet that you know don't provide immediate use to people and that's the reason that i brought this up and then on the other side basically yeah you touched on the kind of the other side of the issue which was this could set up a bad precedent uh it's being taken out in the 11th hour this opens up some people not everybody but some people have kind of said this opens up kind of yeah a precedent for an attack vector in

the future where people can pull out eips at the last minute we need to have better structure for this and we're not going to focus today's conversation on how to improve for the future we won't even talk too much today about how we ended up here from a process perspective because most of us have kind of agreed in chat that the process is broken pieces of it weren't followed other pieces of it were followed but then got changed later due to us updating the eip process you know itself after this eip was an accepted state um and even before so um without going into that i want to hear other people's um thoughts especially people who have been heavily involved in this on kind of where they stand on this uh and specifically

anything that like kleiner i didn't touch on as far as a perspective that we didn't hit on um uh like why it should be in or shouldn't be in um because i think there's a few open questions one of them being from the client implementers what's the effect of removing it in the 11th hour as far as release times and as far as like messing up with the code base and stuff uh i'm going to have asked a question a bit different question so at least yesterday i think there was a consensus that the eip would remain would stay and and that's it and we were just looking

for a final confirm on this call so did things change are we again debating whether to keep it or not yeah that was my question because i haven't had a chance to go through deeply into the chat except the last maybe two hours of chat or so where it was kind of like not a lot of discussion going on oh yeah i was gonna say one thing that did change over the past 24 hours since we had that kind of consensus to keep it in is the viper team uh kind of came out and and said um it would be that 615 would surely 23 15 would be useful for them as like a stepping stone towards eventually uh having like a more

complete overhaul of the evm um but that seemed very unlikely to happen and i think there was also some comments about whether this was actually the right stepping stone um so a lot of like what keep keeping it seemed predicated on the idea that viper would be would be pretty excited about it um and it turns out that it might not even be very valuable for them and and that was kind of the i guess the big change in that right it's not an appropriate stepping stone uh to like have kind of this halfway functionality yeah um martin actually can't make it today um and so

i think we can only just take from what he said right so i guess the argument here would be that even if there's a good stepping stone it would be better to kind of take a step back and figure out like what is the longer road map that either it or something different is a stepping stone to and then revisit it at some future time yes and also that there's nobody who like i guess stepped up and again it was a pretty short period but it doesn't seem like there's anyone who wants to take on that whole road map so it's like why are we doing step one of n um if you know nobody's gonna do two to n and we're not even sure if that's the right first step but assuming it was it just seems like there's not

much interest or or or likelihood that the future steps will get done interesting okay um the decision ultimately comes down to client debs as it does because that's what they're putting into their client and we do need to come to consensus on what goes into clients um so is viper here can they give their perspective i think we basically have solidities but if christian wants to give kind of a 15 or 30 second like overview of their position on if it should go in or not um if they have a firm one that might be helpful um i mean i'm not a client dev um

oh i guess i should i should put it this way from the perspective of the usefulness that it would be in solidity if you could reiterate whether in what ways it wouldn't be useful or if it would be damaging because that's also been a point of conflation if it would be damaging not in a severe sense or like a security sense but in a tech debt weight sense sure so i mean at least from my point of view the main problem with this eip was is that it never really clearly stated its goal so it was never really possible to evaluate whether it achieves the goal and i participated in modifying it over its lifetime and i made some suggestions to change it

and this was with the idea in mind that it uh would that its goal is to ease some kind of static analysis whatever static analysis means in that context um but at the so and it ended up we ended up disallowing flowing into it for example and my current point of view on that matter is that it would be better to allow flowing it if we want to have something like a jump stop returns up um course uh from from the solidity compiler point of view we just don't have to use the op code so it isn't really uh uh yeah a negative point uh to have it but it adds complexity to the

evm it adds uh complexity to both evm implementations and i don't know other mechanisms that analyze evm code debuggers tools and also for example um i don't know components that run on chain and analyze uh code that runs on a sub chain for example um okay yeah i think that's about it and then finally um or not finally finally but danny you just posted some stuff that martin said in chat um sorry maybe one one final point i mean also the the very important thing here is that this does not just

add a new op code like multiplication up code or something like that it fundamentally changes the control flow of for the potential controller of evm programs and it's very very difficult to modify it after the fact got it um danny you just posted some stuff that was like said from martin but it was a little out of context what's your what's your read on what martin said um i just added some context and that it seemed peop a lot of the people that maybe wanted to see uh 23 the 22-15 uh go in kind of saw it as maybe a stepping stone to get to some of the more full functional functionality described in 615 um and martin was saying and he was one

of the co-authors of 23-15 although not a champion um said that he doesn't really even see how it can be a stepping stone like even if someone were to champion it it just kind of adds more technical debt along the way if that is the ultimate goal um and i shared a link to one of those links direct links in discord okay um but yeah i i i picked that up and casually reading i'm not claiming to like sure thank you though what was that james and uh another thing that came up yesterday for martin is that if we do if we were even if we remove it in say next hard fork the code we still have to be able to have it in code

to process for the blocks that it was enabled even if it's disabled in the future got it um and then now just to try to fast track to a decision or did anyone else have anything just off the cuff right now um i just wanted to compliment quickly what danny was saying at morgan said um and i think there was at some point a consensus after a lot of discussion yesterday that related to this stepping stone idea that eap 23 15 is not very useful on its own and that's when the whole discussion on the stepping stone started okay um this keep in keeping in mind that i believe open ethereum has at

least a release candidate that has the cip nether mind has a release with or without block numbers i'll have to get clarification on that that also has this eip i want to keep their perspective in mind and just get that very quickly from them before we go to a full decision so if we can start with nethermind where are you all at on this and what would oh you need another release anyway oh and you added bls in the current one got it okay so if you uh if you want to speak aloud feel free otherwise i can go to um yeah sure um so for us switching on off uh is technically no problem at all it's actually just a configuration switch so users would be even able to

switch on off both pls and eip 2315 in the current version or the next one uh we have pushed the release but without the main net block numbers however weave the test and block numbers and we're planning the next one where we fix the problem with bls that we've included and yeah just to summarize 2315 i was very eager to quickly act and potentially remove it as fast as possible in case there would be no one saying they would use it and that was my reaction to solidity's team saying that they think that that wouldn't be useful for them then viper initially said it could be useful that was enough for me to keep it included that's why it's there

but if you say viper team says the same that it wouldn't be very useful that i prefer not to have it okay um open ethereum uh if you could give your perspective on this yeah we already have really skated involved but as same as thomas in that mind it's just flipping one flag and for disassembly for the 20 23 or 15 if there is not no benefactor of the usage of this aip i think we can leave it later just remove it for the bullying okay uh we would need to uh do another release to take out

uh 23-13 okay does basically have a position on whether or not to keep it in berlin or not based on the most recent stuff and you don't have to necessarily it can be uh we are going to go with the flow but just so that we kind of have it for the record yeah um abstain for now okay um and then i guess finally geth yeah so with regard to gas team we did a major release but we deliberately omitted the berlin block numbers specifically because this this issue wasn't closed and uh

basically just looking back at the last three days it was a different decision was made every three days sorry every day so either way uh we need to we must do a release before before robston and we were aiming to do it either today if we need to remove some code i mean if the decision is to actually nuke out the cip then probably will only do it on monday because i don't want to quickly hack out something and do a release i don't want this in that responsibility but but i mean it's doable now whether or not uh we would like to keep it in or not um well i don't want to i would say this is my personal opinion i don't want to put guests weight in it

because since we are the majority client we i mean we could force either way and i really don't want us to to do any of that so we're kind of accepting whatever the decision of of this call is without saying i mean without uh objecting to it but on a personal level i do think it is a very very horrible thing that uh that we're even talking about this specifically because there have been a lot of people put in a lot of time and this whole topic was closed so from the perspective of those people who wrote this eip and got it finalized i think it's uh personally i would really question

whether so if it happens to me i would seriously think over whether i would like to remain in this ecosystem or not so that's my personal opinion okay still i'm i'm at the point where so just to say i will still say that if everybody is convinced that there's technically no merit then obviously the choice is to get rid of it but i do think it is still a very very nasty move understood i think a lot of people share that concern regardless of which side you're on that this sets a precedent at least temporarily that is not very good um so i think after hearing all that

um in my personal opinion it sounds like we're leaning toward removal um i don't think there's been enough evidence so far that this is going to do anything but add tech debt if we don't have confirmation that there's going to be the stepping stone updates afterwards to really make this eip something special um i think during the process there was things that were assumed by the core devs because of what was said in previous meetings light client outlined outlined them really in detail and a thread that's linked from the agenda um and the it's actually an agenda it's an issue in the pm repo that greg started about the removal or light client started i forgot but um

so there's kind of that angle but all that being said regardless of kind of how we got here it's sounding like people want to take it out uh more so than not and that um although it would set a precedent i think there's a lot of changes coming to the core developer meeting so on a personal note i think precedents don't have to stay and we can do a lot to try to prevent this in the future but the but on a personal note i would i would lean toward taking it out because the risk of tech debt and not being used is a greater burden on the clients the code base than setting a bad precedent but anyone have other opinions that they want to speak up on now or dispute the fact that it's looking

like rough consensus is tending toward removal i want to echo peter's statement that we need to be considerate of the follow-on community effects if we only focus on at this stage the clients in the protocol i feel we have too narrow a view i feel that the demonstrating community consequences may be subtle but they'll be far-reaching and um i mean it's not we have two awful decisions to make and let's keep it in or take it out and we need to pick the less awful one and i have great fears that um doing this at this stage um like peter said is going to have crippling effects on willingness of community members to

contribute all right uh i'm loving the hand raising function people are doing thomas and then micah yes yes quickly for the process so it's it may be seen as 11 hour but i jumped very quickly to join night clients concerns just because i remember it quite clearly also i cannot find evidence that i asked this very question like over half a year ago i looked at the cip and asked on the call why don't we have very clear examples of use cases of it and the response was something about the compiler builders that they will use it and i said okay i don't have that strong opinion but it looked bad to me

and that's why when i've heard light clients saying that solidity team says not very useful i was just waiting for a single person and i think we do appreciate work of community but it's not about like when someone does a lot of work it's also important to to do that you deal diligence it's a protocol and be careful both like we spend a lot of time as clients as well we implement it immediately some work so it's not like we rejected dcip and we didn't say we appreciate that work we've done it we've tested it we prepared it for the release and then we've learned that the really basic due diligence of asking the potential users of the feature

uh was not executed and the question is yeah great um we're gonna do micah then artem christian uh like client james i i might have been out of order but either correct me or we can just go in that order uh i'll keep this quick just because i've already said it in chat but for those that haven't followed chat i'll give it a short synopsis of my position i brought up my concern of the 11th hour thing which i want to keep saying that is not so much that oh this is against the process it's that engineering decisions take time and in my career as a software engineer there are many many many many times where i have

been proposed a question and then given an answer and then after i slept a night or two my answer changed also it is difficult to reach out to everybody on a short times frame and so like for example we didn't know the viper was going to use this until viper just so happened to show up on twitter i think and say hey we want this we don't have connections to everybody and so changing decisions at the last minute uh like we all even if we all think today this is a we should take this out that doesn't mean we're wrong i think that tomorrow and it doesn't mean that we're getting you know input from the people we need to be getting input from such as you know maybe there's other people who are building tools that would really benefit

from this and we're not hearing from them because they just thought this was going to go in they just kind of walked away they're like oh i'm going to come back in three months and berlin's out and write my cool tools that i'm looking forward to so that's really my issue with the last minute thing okay um who did i say was next artem maybe uh yes so i think we should remember one thing is that uh accepting eeps it's not about uh giving other people badges of owner for what they did for the uh how great they are or how their proposal grade is um it's not about a badge of honor it's about improving the protocol and i think it is

this a virtual disguise that we saw in the last minute before the hard fork that this eep is essentially useless i mean uh consider it that we have effectively dodged the bullet other which we would have to deal with otherwise and uh we got here because the current e process and i would say the awkward dev uh call process they are both broken and there is nothing bad about uh making a u-turn at the last minute if we understand that we do not need this eve we don't need simple subroutines that we then we shouldn't include them even if it is at the last minute i mean

we should improve the protocol not scar it and um just scarring the protocol uh if we know we're scaring it is just dumbfounded okay uh we got a christian uh like client james uh tim in the vitalik um yeah just also one quick comment if you look at the history of this eip you see that it was always uh disputed and we're always arguing about how exactly to to to define it and i hope that it's not just my impression that in the end it's not clear that this is really the best version of it

and because people note that removing this erp would create a bad precedent and would prevent people from participating in the iep process the other side of the coin is that uh they have been they always have been concerns about this eip and if these concerns are just ignored then this is just another way to basically tell people that uh or to prevent people from participating in this erp by raising concerns instead of by creating eps okay got it um and then uh light client i definitely agree very much so with

what artem and christian just said but i also just wanted to say that if we were having this discussion before 2315 was included you know it's pretty clear that 2315 would not be accepted given the current sentiment and you know a lot of people are saying we should be concerned about the knock-on community effects about turning things around at the very last second and how that's going to affect the people involved in eep but i think that there's just as much of a qa knock on effect if at the highest level of ethereum people are choosing to you know you know cater towards people's feelings and the you know it's thought you know how the the process was done rather than making the protocol

as best that it can be and everyone on this call almost seems to agree that 2315 in its current form is not making the protocol better okay um let's see james and if christian if you do you have something else or could you lower your hand um it's a general feels bad man situation for me but what would um help me feel better is if we would one make sure that like clients issue gets added to the notes so anyone who wants to go back to the history has an easy way of getting that from this call and the other one is if we scheduled say come back in six weeks and make sure we have it on the doctor

to talk about the process and how we're gonna improve it okay um and then uh oh ten did you attract yours uh i did but now i guess based on james comments like i can totally dig into this and uh like client you've done an amazing job already about this specific uh issue but yeah i agree we should probably wait until we have a bit more distance to like think through what went wrong and how we can we can improve things here um yeah yeah there are plans to have people in the future for like one of the process improvements for the future is to have people from the ecosystem be a liaison more so than just myself or tim has been

in the past to connect people to review this stuff from the community or from the core devs etc uh vitalik yeah i just wanted to bring up the more the more general points um that like it feels like like even going beyond me 2315 we need a kind of better ways to get feedback for for uh kind of incoming eips earlier rather than later i mean even just one example of this is um this uh removal of refunds uh thing that i just submitted i think it was either one or two weeks ago and like after this i actually i mean did get some good feedback of some

uh from some applications uh that would be negatively affected by it in its current um current reform which is like good because it kind of gives opportunities to think about different versions of it and so forth um but like in all of these um cases like there's like it's always better to get that to get that feedback even one week earlier rather rather than one week later like basically when fewer people have kind of committed to it and just make it easier for ideas to either fail fast or be modified before anyone has even tried implementing them so i guess would be curious about people's ideas about how to kind of make that communication look

better in general yeah it's something we're already looking on with looking at with hudson so i suspect we'll have something to announce in the next couple weeks uh but definitely yes something we need to be more proactive and i think especially as we get the things that uh uh are related to the merge or there might be some more and more breaking changes uh we need to get much more proactive in reaching out the people uh and and getting their feedback early on yeah one thing that i've started doing is just making these some reddit threads the last couple of days like i published one yesterday that says like here's a list of things that might break and so you know please talk about it but if we can do more of that i think that

would definitely be helpful uh james is your hand up for any final comments or was it just left up nope i need to find the button again okay thanks everyone for your comments i thought this was really good i think that this can definitely spur change and it sounds to me like the rough consensus is to remove it for this hard fork and um good news being it's a nearly complete eip if someone does want to come in and champion it since greg has withdrawn as a champion and withdrawn the eip um per process i believe someone can become a new champion and unwithdraw the ip is that right micah create a new ap eip you can copy it it's all cc zero so just make a copy of it it's your own

that's right that's that's why yeah that should have said that way um so um yeah in that case um i think it should be i think the rough consensus is it should be removed does anyone have a strong veto against that wants to make any counter arguments otherwise we can say that's the decision okay so for the note taker we'll be right back oh yeah go ahead no so i would like to add just one thing everybody should be aware of it is that uh removing eips is we're entering a bit uh on chart category in that uh

in over the past few months we had various tests the yellow test nets with various transactions and people had time to play with it we had the test suites and everything to check it the moment we remove an eip we enter uncharted territory in that we don't have a test suite which works without vcip we have never done a test net which is without the cip so there's the risk of a consensus fault goes up astronomically now in this particular case it's a pretty standalone piece of code so probably the dangers aren't too high but in general it's a super risky move um light client had a comment about

reviewing the test suite recently is that not what you're addressing though is this more of just a general risk thing oh peter you're on mute if you're talking no well i was generally referring that um so nobody tested out whether so okay now everybody's going to remove other clients are going to remove their eip implantation let's maybe we're going to do a release by monday and then for robs then we'll just see if it blows up or not so there's nobody nobody will have time to actually try it out that all the latest released clients properly cleaned out the

ip or not okay thomas so that's the only yeah so just want to trace what i wrote in the chat so according to someone yellow v3 syncs without eip2315 included which means that was not a single test code call in the yellow v3 for this for dcip so it's not like we didn't have we actually didn't have a test for it included we have it for it removed interesting so that's uh that's i sorry i i'm going to interrupt that's not really fair because uh so dcip was introduced way way back and uh the purpose of yellow v3 everybody was focusing on transactions

on the type transactions and before that theology everybody was focusing on bls so the fact that eurov3 doesn't contain any test transactions is because everybody already assumed that [Music] that part of the code is kind of works and it was already tested and people were focusing on it so there are reference tests that cover all the scenarios of how um the sever teams are supposed to work you know failing to flow in you can't jump in you can't enter these first you can't pop too many off can't make the stack too big light client over the past day or two has updated those tests and kept there was a test in the in seven scenes there's also tests to verify

that five c d and e um op codes are supposed to be supposed to throw invalid operation exceptions so there is a pr out there that updates the reference tests it gets us the same level of coverage we had before we decided to pull it out to verify that it's functioning properly and there's also some hidden gems in some of the unit tests like um if you have the um it's not explicitly part of the test but if you have uh bls uh still registered as a pre-compile there are other tests that will fail so i think we've got well i mean since since 50 23 15 is not in the yellow test nuts we've got the same amount of test coverage coming out of the updated tests that that matt garnett updated and i

just verified a few minutes ago that basically runs clean with them when you take out the op codes and that wasn't the case a few hours ago when i didn't have the invalid opcode tests put in so it verifies that they're invalid up codes and it acts like they're invalid codes when it hits it okay um and so peter your your concern was just to make a general statement not to have a veto is that correct am i reading that right right yes yes oh okay sounds good okay in that case it doesn't sound like there's anyone doing a strong veto against it no one coming in with any further comments on this therefore we will remove it from berlin now i think we can move on to the next

part of the conversation which is berlin timing um tim did you want to kind of go over that and some stuff around robsten timing sure um so roxton is scheduled to fork march 10th um this is five days from now robson is also proof of work and and has a highly unstable hash rate so uh in the past we've seen the fork uh vary widely in terms of when they actually happen um and now every single client needs to put out a release you know to do a minimal amount of testing and we we would like to uh put out at least a blog post that advertises berlin in the release numbers for all the clients um so all as

i say it seems it seems pretty hard to do it all in like five days um so i yeah i guess i'm curious what are people's thoughts about just the general berlin schedule should we move robson back like a week should we move potentially everything back um yeah and i guess i don't know my preferred approach is probably we move robsten back a week or something have it have it fork uh like whatever the second testnet forks um and then keep all the other dates the same so we only change one block number um but it's not a very strong opinion okay dana or is your hand just raised

from earlier okay um what comments do people have on this if no one has comments tim let's just make a decision i mean yeah my my proposition would be we push robson back a week um and we need to find a new block number we you know we can do that uh we can do that on like outside of the call um but at least this gives us you know like from five to 12 days to have clients out and and and advertise the release and we keep the other test that's

unchanged so push up one week oh that's don't yes so that's what that's what i would say so i think right now it was i believe robsten gourley rinkeby and mainnet and and robsten gordy rinkeby all had one week apart so then we'd have you know nothing next week then robson and gourley and then ring could be the week after something like that so just a quick uh opposition uh i'm i don't mind postponing robson a bit i think it's not not healthy to have two networks fork at the same time because then you kind of need to monitor two things and if something goes wrong you need to somehow fix two things so if we want to keep the girly that

numbers i would say that maybe let's do roxton a day before or or two days before to that way we can still we still have more time to do releases but let's not screw up two things at the same time sure yeah yeah that's fair so right now just i'm looking at the dates uh gourley was planned for march 17th and ring can be for march 24th um both of which were wednesdays so we can absolutely do you know robsten i guess the thing with robsten is you know we make we might have some drifting in terms of the time uh so i'm not sure what would be like the right day to do between the you know 15th and the the 26th

that would make it uh i guess as unlikely as possible to fork at the same time as gordy or ricky b why can't we just try to aim for example tuesday just 24 hours earlier than girly okay yeah so we can aim for the 16th of march what was that peter oh peter might be off me okay he's good now oh it might be okay i was just saying that yes that that would be my guess um with the block numbers but got it um artem um did you have a

comment or did you retract it with your hand race um well i do have a comment that um given the screw-up that we had with 2315 maybe we should push back everything a week and then go on twitter go on ethereum magicians go on other discussion forums and gather more feedback on the current berlin eaves because maybe 2315 is not the only contentious eve that uh didn't get enough feedback oh god no yeah i guess um strong then guys pushing it back yeah i would be too personally just because like a lot of them have been

vetted completely i feel like in our opinions or someone correct me if i'm wrong but does anyone have an opinion that any of the other eeps have had any wishy-washy feelings during the time of their bringing that up during stuff like or that it's not been straightforward with stuff like testing or things like that well just to make it explicit right like the other eeps is a gas scotch change 2565 which has been benchmarked and you know like the impact of that is just gas pricings um then the other big eep is 2929 which also is a gas cost change and the two other eeps uh 27 18 and 29 30 are eeps that are there

to mitigate the impact of 29.29 so that means that you know the two only things we need to assess the value for are the gas cost changes and those are things that are much less you know we know that there will be breakage uh in the community you know for from 2929 and and we've dealt with that for with 27 18 and 29 30. um but in terms of just like does this provide value to users it's it's much more straightforward uh than adding a new feature because we're just changing the gas costs okay uh offery um i would actually propose to keep the block numbers even robson and just make sure that we have a minor

on the correct chain because i believe we can have if we can have releases out by monday then we can uh have a fork on robson as soon as possible and once we hit the actual ford number we could um we could uh we could just have robson as very early test that um i guess the counter to that is are the releases going to be on monday which i thought i thought we said that they were going to be tuesday maybe some of them or later tuesday yes but this coming week versus the pushback we're talking about is for

two weeks ah like if death releases on monday we're then waiting until another full week before we release to robsten which is what's currently proposed oh okay so are you agreeing with that afri i think i'm confused on the dates maybe if you could go over again what you were proposing so the robson i just did the mass if we assume a 13.8 uh second block time on robson then we have exactly uh 4.98 days was five days for robson and if we see uh one two three that's actually wednesday so if we have releases by monday or tuesday and then and we just we as core

developers or client developers or other enthusiasts in this broader group here make sure that you have a proper miners running on the correct chains and we could just stay on this date uh on wednesday even though it might cause breakage but then we have early uh insights into this hard fork on robson and we can start testing whatever we want to test with berlin on robson earlier instead of delaying it another week that's my proposal but uh it's just completely up to you dana if history is a guide robson is going to fork no matter what day we put on it because miners put zombie miners on there and they forget to update it and there is going to be a fork that

does not have it so you know this is probably a good thing if we organize we get more people to get more hash power on the fork side whenever we do it but to take a couple steps back um my my top preference would be to leave it in my second close preference is to leave it in and do it on schedule and the one that i would have issue with is if we touch the main net block when i talk about community effects that's another thing that's going to come on if we set a block and then pull it back too often those are the kind of following community effects so i think we need to make if we're going to take it out we need to be and do it at this late an hour we need to be willing to to to go to extreme lengths to to keep

the to keep the keep the train on time okay other thoughts just to summarize some of the dates that nethermine said they would have something by sunday open ethereum would have something today it sounds like or the next day and then geth said they would have something they would be able to release on monday okay um so offray's plan would could technically work assuming that's also true for basic and offers plan is keeping the same block number right just so if i'm gonna be reminded yep keep the block number

and make sure we have a minor ready to mine in case in case something's happening okay more than one minor right like i think to be safe we probably want all the client teams ideally to start a minor on robson um if possible yeah um i'm okay with that tim is there any or anyone else have like a strong opinion of changing it um yeah my preference is changing as little as possible and then more time on a test that's generally a good thing so if we can get away with it yeah i agree with that i think i it would be great if we can get a

commitment from the different client teams that they can run a robston miner and then at least we'll know there's at least like four entities mining the right chain on robsten and you know uh that should be like yeah if we if we need miters you know we just rented off a nice hash there's enough money power on nice ash to line robs and solo i believe necessarily about assuming sorry go ahead peter sorry um i think i have a slight delay so i don't think it's necessarily about uh hash power more than we should ensure that every client has a minor so that we know that things are

in consensus yeah and that people are paying attention pretty closely to it yeah i think the ef can do that i can talk to the devops team and ask i don't see why the ef couldn't do it i think we've done it before i think we've done it before i would personally prefer every client run their own miner because then at least they can monitor things go wrong as we actually oh of course i'm just saying for i'm sorry when i say ef i mean can geth run their own minor that would be through the ef's infrastructure peter can you give an up down on that i honestly don't care i can run it on my own laptop too okay cool um uh ever other clients can anyone commit to doing that

or at least a majority of clients commit to doing that yeah i already had one set up with uh the 2315 code i'll just make the changes and then push up the miner again okay nevermind we run rosten nodes but we will not be running a miner that's fine um i can i can help with i have a computer i could turn on for mining to monitor okay well we'll should be to do the open the nether mind help another might be minor yeah and it's again less about hash power is that we have a chain that is running that we can be testing on while things are crazy on roxton until it gets corrected um and then open ethereum

yeah i think we have unvalued it on robston but to be honest we need to check that okay okay um i think it's leaning toward let's keep things the same and just be extra diligent on that day to monitor the situation with everyone having their own robston node on the right chain then just let's talk offline from us about how i could help okay any other comments on this peter yeah just a question um so we've mentioned that the live client already did the the updated tests as far as i know that's just an open pr is there any chance of having that pr

merged in so that people can actually pull an updated repo and test it just it would be nice to to have the tests in the repo updated before we make the release is anyone from the test repeal here um i guess martin will be back monday as my assumption i guess martin will be back monday i can work synchronously with anyone who can help get it merged you know as soon as acd is over i just don't have the control of merging it is martin the only person that can merge the tesla reason so there's a couple people on the

ethereum test team but i'd be comfortable as long as we sort of say hey like client make sure this happens and then if you can agree to do that yeah so as long as we can find someone um james can you help light client find someone um i guess it would probably be dimitri or martin and dimitri is russia if i'm not mistaken yep so i don't i don't do time zones well so i don't know if it's night or day for him but yeah let's go ahead so peter that's a good idea and let's work toward that and i'll james if you can get with light client and then light client if you need any

other help just go into all core devs chat and we can try to connect you too thanks okay sounds good we're not changing anything about the um the timing then uh the uh berlin announcement uh where me puja tim james uh and trent and a few other people are working on that it's gonna be a blog announcement that's cross blog uh meaning the blog.ethereum.org will not be the only place it's posted it's gonna be posted across uh stuff like my crypto's blog status and nimbus's blog um i think git coin has a blog we're posting it on so everyone's going to have the same blog updated and we're all sinking in a chat

room about that um that's to kind of start to spread the word better and also make it so that the ef isn't the only one like it's less of a factor if like that blog of the ef gets hacked and people change the block number or put some crazy announcement or emergency fork it just makes it a little better that we start making it a habit to decentralize the announcement um anything else on that tim or james or anyone what's that great when we when were we gonna put that out like tuesday maybe or just when the client teams release their update yeah as soon as we have all the client teams released uh we're yeah the blog post is literally ready and there's just a placeholder for every client

cool monday at the earliest then that is it with berlin updates thank you everybody uh thank you for being cordial and having a good decorum as well um i'll go ahead micah the announcement is for the main network block is that correct uh what are you talking about for all because i think another mind is not correct me wrong here thomas uh another mice not planning on putting the main network block in the release that's coming up um we can now if everyone else pushes the main block if that's agreed we are fine now i i didn't want to do that two days ago but it's fine okay yeah i don't know if it's necessarily a requirement that we're

making all the clients do that either that i think we left up to clients no we said yeah it would be best if everybody's on the same page just so it's simple you know like it's not the end of the world but it is simpler if we can just say this is the client version for everybody rather than saying you know this is like for test nets for nethermine for main network base you for test nets for open ethereum for mainnet for geth it's it's not the end of the world but if all the clients can have the main net block it simplifies it a bit okay yeah if we need to push it anyway everyone will have to make some updates quickly so um i hope we don't have to push it unexpected so we'll include the main block as well yeah and we'll have the

infrastructure up to make a wide announcement to the community if we do have to push it but that obviously is something that is not planned right now it would have to be a security or other type of thing that would happen all right anybody else before we move on to potential london eips all right let's get to it um first one uh this one has some popularity behind it i've heard of this one before eip1559 a fee market change um there's a link in the agenda where when you click on it it goes to the issues where tim talks about oh wow there's a lot of emoji up votes on this one uh and other stuff um about the proposal to include it

there's a little bit of discussion in there uh tim since you've more or less been some like the champion of this um in the last year or something if you want to go over where you think it is and why it should be in london and what it is i guess in a sentence what it is and then the rest sure so sure so 1559 was put forward a few years ago by vitalik uh it changes the ethereum fee market uh we've discussed it a few times on el cordev's before um and you know the first few times it was discussed uh a couple years ago there were there were some technical concerns raised about it um and then about i think exactly a year ago now yeah

uh the basic team started uh checking it from a technical perspective again uh to try and address some of those concerns that were that were raised by all core devs uh after about a year i i think we're there um so we we've linked uh kind of an issue and in their issue with all of the kind of client changes we've done we've solved issues around how we handle legacy transactions how we deal with the transaction pool uh berlin will solve some issues regarding uh denial of service attacks um that uh that were potentially problematic because of the the large block size under 1559 um so the you know i think we're in a spot where the eep is uh kind of sound there's definitely a

lot of work to do around everything that's kind of adjacent to the eep so you know updating all of the json rpc specs and whatnot and we've we've started um we've started some of that work but it's it's not complete um but i think that from uh yeah oh abdel comments abdel uh is the the technical lead uh on basic who's worked on this but he has a comment that we've done also in economic analysis of 1559 which was done by tim rough garden who's a leading uh leading professor in in the field of game theory and computer science and we've also done a lot of performance testing recently so we uh we basically created a test net that had a state as big as mainnet and bombarded it with uh

with transactions for a long time to see if nodes could process them and it looked like everything was fine there um so all this to say i think you know we're in a spot where it's it's ready to be included in an upgrade there's still some work that we'll need to do with regards to uh like i said json rpc uh some more reference tests and whatnot but that's a pretty standard thing um when we when we tend to include eeps um and i think there's i guess a few reasons why we should make a decision about it for london sooner rather than later uh the first is it's quite a big change so if we do include it in london um i think you know it becomes kind of the big thing we can do in london um especially given the the timelines are

quite short um and it'll have a big impact on on what else we can do um yeah i i and that's that's probably the biggest one um yeah i'll stop here oh okay thanks um other comments on this there may not be much because everyone's pretty familiar with this by now i would hope um it's been pretty highly advertised in the community um anyone have comments otherwise i can give my comment on the call that happened recently yes peter i have one tiny comment so if we

um if we go down the path of including 1559 then my request is to couple it together with the with the deletion of the refunds or the rework of the refunds depends on on where that eip goes because the problem with refunds is that they essentially can double the amount of gas that can be consumed in a block and 1559 can also do the exact same thing which means we can end up with a 4x block size and that that's a bit screwy so it would be nice to essentially if we can include the removal of refunds then that actu actually stabilizes a bit

uh the effect of 1559. so that's that would be my request one question there um so there's i and we're gonna talk about this i think right after but there's like three proposals for for dealing with refunds now uh one of them is we straight up remove them but then the two other ones are kind of more moderate in that they over time phase them out and and whatnot um i assume if we have a proposal where the refunds are phased out rather than removed directly we'll be in a spot where for a few i don't know for a few months probably uh you will you would still have 1559 and refunds you know mostly uh mostly uh uh possible

right yeah um i mean i'm definitely like i'm definitely not in favor of any of the facing out approaches because i just i don't really see what benefit they have um i do have a couple of ideas for how to do something a little bit more moderate than removing refunds completely um so like for example i have one proposal where you have a version of refunds where the refunds can only cancel out the 20 000 gas costs for adding new storage i mean i'll probably like formalize that into an eep at some point um but like we definitely need a little bit more time to uh um kind of just juggle between the different options and come to consensus on which ones are better

so how much time is that though because i think we're wanting to figure out in the next how long two weeks uh or so yeah i think if we put our if we put our minds to it we can get to it in two weeks okay um peter did you have something before and then william after that um so i just wanted to react to i think tim's comment that um there may or may not be a time period when when both refunds and eip 1559 is active from get's perspective um i mean since berlin already makes storage access a bit more expensive that

removes the problem i mean i wouldn't say removes it from what alleviates a bit the problem plus uh in gas we do ship snapshots which uh if basically with snapshots we're pretty happy that uh we don't know of any denial of service vectors that that people could abuse so from our perspective it's kind of fine from the client from a technical perspective that if if there's a time period when gases are a bit screwy it's more like on the long term it's it's healthier for everybody if the block times are stable and people can so the thing is that if if the block time is super stable then

you can easily decide whether you want to bump the gas limit or not whereas if the gas limit can or the block time can vary 4x then it's it's super it's it's much harder to say that hey let's bump the gas limit because you don't know what the effect is so that's mostly the perspective why stability is always good okay uh real quick vitalik if you want to give a retort to that because i think you were wanting to say something and then we'll have william introduce himself and speak up well more more in agreement than a resort but just generally i wanted to point out that like gas prices are very high and a lot of users are suffering as a result of this and there's millions of dollars being spent on transaction fees a day uh so like i pers like i personally am

in favor of uh you know some like moderate gas limit increase and doing what we can to create safety margins so that that actually can't happen safely i mean so like be so reducing variance like like basically if we have room it's probably better to spend that room on it i'm on an increase than it is to spend it on a yep a proposal that'll just allow more variants to exist for some short time okay so this is about yeah peter's bundling comment that from a guest perspective they would want one of these in there to kind of help hedge some of the stuff that 1559 would enable uh william did you have something on 1559 and if you could give an intro to yourself oh hello i'm william morris i'm a

co-founder of bitcog we do dex trading and among other things we market make gas tokens specifically while we're on the topic of 1559 i've mentioned in the discord the possible fork choice uh issue i think we should keep that discussion on discord for now um uh if uh if that is a major concern it could mean that one 559 does not provide elasticity even in the short term but regarding forex specifically i don't think forex is a huge issue uh as a temporary uh state growth situation um or even block processing time because uh ethereum is so underutilized right

now quantitatively i believe we can validate blocks about 1000 times the current size there's especially after 2929 which would mitigate a lot of the dos effects of for example s load but i'd prefer to table the rest of this until we're on topic for refunds okay uh vitalik did you have something not on this topic okay and then uh peter did you have something on what williams said or on 1559.

what william said or on 1559 yeah i just wanted to report on that 1000 time block processing so essentially currently the you can create super heavy blocks for the network so given a 10x even a 10x increase i'm fairly confident we can stop the network and we're not talking about a thousand time increase we're talking about that the next increase yeah yes like to be clear like when when i say i'm in favor of um moderate increases i was referring to numbers like 15 to 20 million like definitely not these uh big multiples that people are thinking of okay and we're tabling that for a moment

until we get to that piece which will be after difficulty bomb delay for 1559 are there any other final things i mean i've been seeing indications personally that everyone's in favor of this a lot of the core developers have participated in either the testing or review of this um i don't really see any opposition except for from minors and that was addressed in part or not addressed that's the wrong word it was um i guess able to be viewed by everyone but from a call that we had recently a community called that the ethereum cat herders put on where we had participants from different mining pools and then different stakeholders in the ecosystem giving their opinion um and what came of that was in general from everyone that i'm kind

of i talked to some people who watched the meeting and kind of looked at the comments online about the meeting and it seemed like the miners were in the minority of people who did not want this in primarily because it would be cutting into their block reward incomes or their transaction fee income specifically um and there was some risk in their opinion of a either a network split some of them thought or security issues with hash rate dropping things like that um if i didn't get that right someone can correct me but that's kind of what i got from the miners perspective otherwise uh what else do people have to say on 1559 before we kind of go to a yes or no i um had just a question

because the timing of london is going to be pretty determined by addressing the um the ice age so i just wanted to make sure that core devs that we that the clients all like we're comfortable with the amount of work and time we have to implement 1559 and all the clients that haven't already done so difficulty bomb delay was going to be shooting for uh what i guess when do we think the difficulty mom's going on it's like july around july was when we were going to do london to address it yeah so it's going to be ready for july uh on mainnet it might be later but i think it's good to aim for july that means that you know the test nets

need to fork in june and like in may we basically need to set the fork and be kind of done so that means that we basically have march and april to like implement and test the eeps right are there clients with concerns about the timing and vitalik did you have a comment your hand is still raised oh sorry my that the hand being raised was a mistake i'm lowering it no problem um all right thomas did you have an opinion you put it in chat i didn't know if you wanted to also say it yeah i think that's the 1559 is such a big and important change that um i definitely wouldn't like to delayed by just

uh long discussions about other aips being included or not in london so i have two proposals either to separate tip1559 release into a its own its own thing it's on a network upgrade with any other eips needed for it to to behave properly but i don't think there are any necessary or to start talking about shanghai at the same time as we talk about london so we can show community that if they discuss the ips there is a slightly longer timeline after eip1559 after london then they should discuss inclusion in so yeah very good point just quick comment with

regards to the eep that have to go in with 1559 um i think one that we do want is the difficulty bomb delay and the reason is that if we don't have it coupled together uh miners can just decide to not upgrade and it makes it much easier for it to stay on the old chain um it's and you know they can still do that if the difficulty bomb is is pushed back like it's not a completely uh it's not a very hard technical change um but it does mean that they would need to actually fork a client uh make a release um and and and what not it's not a big problem to fork the client really

it is to distribute it though right there's a difference like yes it's a small technical change but then miners have to go out and advertise you know download like our you know get dash miner um fork and and use that and then there's you know there's not much of a value prop there whereas if they just stay on the old chain um they don't need to actually convince people to go and download and move over to their chain so the technical the technical part is the small one the coordinating around a new chain part is the very hard one and i think that's like the main value we get from the difficulty bomb being coupled with 1559 yeah i think it makes perfect sense to couple it uh it's it's a very small change technically and that's important one schedule ahead and

uh yeah sorry i just omitted it but it's quite obvious that it could go in together yeah yeah yeah and i i would i would hard agree with thomas's point of we should minimize what goes into london and be open to talking about stuff that's interesting and we want to go in we can we can talk about sitting high for timings or stuff like that micah i'm so i'm totally good with one five way at the same time as the ice age bomb removal what i'm not a fan of is using the bomb to effectively coerce people to choose the same choice as us the whole idea with decentralized governance and

fork based governance is that if you don't like a change you just don't fork you go you go your own way and that's okay like etc was okay people had a difference of opinion it was very strong they have their own chain now and that's a healthy thing i'm not a fan of basically saying hey you know us core devs like this thing if you users don't like it you know now you know we're going to bundle it with this thing is going to break you sort of thing i'd much rather make sure that we keep those two things separated like fork based governance is all about freedom of choice and i don't like leveraging our position to uh of this difficulty bomb to kind of make it very hard to make a different choice than us to disagree with the court deaths

so would every difficulty bomb uh delayed need to be its own single fork micah and your proposal or your opinion no like from a from an organizational standpoint i think that you know if 1559 happens you're ready when the fork goes out you know from coordination wise it's easier to do one fork in july than to have two forks in july but that's a huge pain in the ass i just don't like just from a kind of policy standpoint trying to use difficulty bomb as a forcing function to get people to agree with the change that we think is best for them like if they want to agree it's a good change for them then they should join us willingly and voluntarily not because they have to okay noted uh peter i would just like to say that the point

of the difficulty bomb is to force people i mean that was its original goal we can debate whether it's it's good or bad but uh i mean let's not kid anyone that's the goal of it got it okay um so we will um i think we're all rough or actually let's actually there's a few other people hold on uh dragon and thomas or thomas is your hand still up for a comment or did you just get raised accidentally yes please i'll go ahead um so i think the difficulty bomb has this great property of ensuring that in the cases when something like group of miners wants to execute a fork that they also make a promise to the fork users that they will be capable of

executing the force to remove the bomb because it ensures that any forks are not just simple split announced to everyone that it's all fine and never know how to work on the client but any fork will actually have to ensure the community being able to distribute the clients and so on so it is a good tool of coercion but also protection for anyone who will be dragged to a potential force chain if somebody wants to fork without a difficulty bulk they just can use any client just make adjustments to the client itself it's not a big hurdle to just for copy i thought they think uh difficulty

ball in general is good timeline okay even for somebody that didn't even start on that public um to move on um from this um unless there's um let's let's i guess i'll put it this way 1559 we're seeing mostly yes um except for for miners difficulty bomb we're seeing mostly yes there's a little bit of uh trepidation from a few people about combining them because of some of the user technical barrier adoption barrier arguments user choice arguments but does anyone oppose to 1559 at any point going in in the future or going into london all right as anyone opposed to the

difficulty bomb happening i don't think anyone is because it kind of has to or else the chain slows down this is not to say they should go together yet so because now the third question is is anyone strongly like a client dev specifically who'd be implementing this strongly enough opposed to not putting them together that we should have a further discussion on this before making a determination of where the difficulty bomb goes because it sounds like no one wants to separate the forks even micah and it's worth saying that the timing of them doesn't matter necessarily the order would potentially matter if you decoupled them if you had 1559 before the difficulty bomb then effectively if you don't want 5059 you have to defuse the difficulty bomb

uh essentially on your own um once you fork and don't do the 1559 chain whereas if you do it after it changes kind of the dependency there so um it's not just decoupling order got it okay uh thomas did you have a comment no sorry peter so my comment in general is that if we believe that 1559 is the correct path towards uh correct path forward for the entire network then i don't really see the whole point of um of this whole so essentially by decoupling

uh the two things the only thing you achieve is that you give people who just figure that they don't want to don't want 1559 you give them a super simple tool to just say that hey let's fork ethereum because we don't like 1559 and in my opinion there's no i'm not aware of any technical reason or any reason at all why 1559 why somebody would oppose it however you can always dream up a group of people who will be very very vocal and will try to fork ethereum and forking ethereum is a super lucrative thing even if it only survives

for a week you can make immense amount of money on it trading and speculating and whatever so i don't think so if there's no technical reason for for giving people the opportunity to easily fork off and i don't think we should make it easy of course everybody as as also dergan also mentioned everybody can modify the clients it's it's not particularly hard to modify the clients but if you if you actually want to bring up a new ethereum classic classic or ethereum 2 classic or whatever then you should be prepared to to actually do the work and not just piggyback on on the existing clients okay um something i don't i don't know if we

got an answer that the client so if we have the next three months to do development for 50 59 or all the clients feel comfortable with that amount of window to do the work required are there any clients who do not feel comfortable in doing that amount of work required speak up uh peter your hands still raised i don't know if it was about this or not no apologies okay i think everyone feels comfortable with uh the timeline then um it sounds like so let's do this i think we're in agreement rough consensus uh at least about 1559 going in the difficulty bomb going in in order to make sure that this chain doesn't slow down and that they would

both be going in for london is there anyone with very strong opinions against that plan to have them both included for london officially okay great the next uh oh sorry yeah two small technical comments um so one if that's the case we should probably set up i guess it'll be yolo v4 maybe we need a new name whatever um as soon as we have uh you know the client's implementations ready um so that's that's one thing to keep in mind the second technical comment is there's another eep that's like i guess call it a sister eep to 1559 which just adds an

up code to return the base fee it's something that smart contract developers have asked for we just removed it from 1559 specifically because uh just separation of concerns um i'm not sure exactly what the the eep number is abdel is the author um but i guess you know does anyone oppose also having a base fee up code along with 1559 um and it's fine we can maybe decide that later and it's fine i have one comment on that one so i don't oppose or support it either way uh the only comment i wanted to make is that what we should think over is not to give people an opportunity to

again play with the gases and so we don't want a new generation gas token so if there's a legitimate reason why you know checking the gas fee or base fee would be useful i mean we can consider it but i think we should really really strongly consider it from a perspective of not enabling some weird games again so i think we can maybe have a proper description discussion about that eep you know in the next caller the one after it's a tiny technical change if you have done 1559 but i'm fine with us not agreeing to include it now yeah i i i remember writing up a list of like reasons why it would be a good

thing but i'm happy to like rewrite it and put it in whatever thread you point to is best great that let's let's definitely because this isn't on the next part of the agenda maybe bring this up for next time for inclusion uh for london if it's going to be a possibility and by then metallic can point us his resources in the right direction and we can have more chat in the all-court of discussion and discord about it does that sound good tim talk about the just one thing i wanted to say is that probably it would be nice to get a lexi also in on that discussion because i remember that a while back he was really really

um vocal about removing all kinds of gas inspections and he had his reasonings on why those would help so it's just if he has a whole list of reasons why he thinks people should not have access to the gas maybe it would be also nice to get his input on it that's a good idea thomas well so it's possible to inspect base fee even without the base fee code but uh quite a expensive operation gas code wise and we've been doing it in one of the projects and basically just simplifies it a lot and also i think both alexis and mine compliance about gas inspection were more about the

amount of gas because it opens a lot of problems but the base fee itself is more like a gas price up so it just gives information about the economical environment of the transaction it doesn't really affect the evm execution in any way because base fee is only charged before any vm code is executed the same as gas prices it's not really related to the execution flow okay yeah sure that's why that's why i was saying that i'm not opposed to the op code i'm just saying we should ask the people who might be opposed that they can speak up maybe they won't be opposed either yeah i agree let's not do 23 15 again and remove it yeah

good call okay um all right so we are in agreement for note taker 1559 in london 32 38 in london uh next discussion we will be talking about um the space fee thingy uh and if that would be in london uh because that does kind of go along with some of the fee market change stuff um next up we only have three minutes left but i know um william morris who's the author i think he's the author of the eips for 3300 or 33 22. i'd he'll tell them to switch ones we've talked about um 3298 disabling gas refunds from vitalik before and a different call so with the last few minutes i'd like just a quick summary from william

of the two phase out and um the efficient gas storage if they wrote that one in order to discuss um what those are so that we can start commenting in the issues and the agenda and just to be clear if anyone has a comment on it that they don't want to put in the core dev chat or that is maybe longer form you can go to the issue and the agenda and the way we have the agenda set up now um the issue section is for long form discussion on agenda topics that go multiple meetings so all that being said william go ahead and uh just in the last just quickly two minutes um just kind of go over what you proposed so the strongest motivation for removing refunds seems to be that there's a limited uh capacity and that's on average we need to be well

below that in particular we should already be well below one fourth capacity so that nodes can sync within a year um my 1000x number is based on a turbo gear fork running binance smart chain finite smart chain's already running 220x uh gas per second on a and still sinks quickly so i'm skeptical of peter's 10x number um and specifically the warning that it might stop um perhaps there are performance improvements there i definitely support increasing the gas limit uh or and then 1559 the gas target so quickly gas tokens track the gas price um liquid refunds such as gas tokens have two prices the break-even price and the break-even sale price

bought cement and sell in the same transaction which forms a gas by wall so if you're using less gas than them uh you can use their pricing for a patient safe low on the other hand uh the breakeven burn price reflects the price at which it becomes cost effective to buy and burn gas tokens potential bandwidth is almost doubled at this inflection point so it serves as a great standard gas price oracle during sustained congestion the fast gas price can remain above this level for days but they eventually converge similarly when someone dumps their gas tokens the buy wall cancels and moves to a lower price so i was able to precisely call the bottom following the 3298 posting the benefits of the refunds is that they provide block elasticity by moving space

from less valuable blocks to more valuable blocks a lot of the opposition is that this comes with state bloat because of the current uh weight that we get refunds uh specifically by s-store and self-destruct um 33-22 as proposed would create a more efficient refund that would out-compete uh what's the current bloat um and uh so i believe that it might be uh strongly uh superior enough uh from a market basis to out-compete the existing uh and the most significant concerns we'd still be able to stabilize gas price that way

and the block elasticity would still be limited by the refund count um that's uh those are my opening statements okay perfect um we don't have time for any rebuttals on that sadly but if anyone does have a rebuttal on that could you please post it in the agenda topic you can click on eip 3300 phase out refunds that's number 258 issue number 258 and also talk about it in the core dev chat william you're in the ethernet discord for questions right yes i am okay great so william can be found there um for any rebuttals on that um uh and then let's see uh oh and then yeah we're out of time so uh

thank you everybody sorry everybody who came on to discuss their potential london eip and it didn't get in on this call uh we had some uh unexpected berlin stuff to go over but thank you all for showing up uh even if it was earlier time uh thank you all so much uh for uh having me do these the last few years and uh let's all get excited for tim taking this over he's gonna do a great job and uh thank you all so much we'll have another meeting in two weeks on the 19th of march 1400 utc bye everyone thanks hudson thank you so much [Music]

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

[Applause] [Music] you