All Core Devs - Execution #108

Transcript

[Music] [Music] [Applause] oh sorry i think i got something wrong with the live stream and i was still playing the awkwardest uh the awkwardness uh little intro video so let's do this again welcome to awkwardness108 people are still rolling in uh i'm tim i'm your host

and we have a packed agenda today uh so we can get right into it um first thing on the agenda is uh we have the burden update i go live on robston and gordy um i know that rye had uh or basu had an update to give about the ropstem uh fork uh i don't think anything notable happened on the gordy one um so yeah maybe we can start with uh basically giving you an update on roxton yeah sounds good um so we stopped importing um on robson at some point uh we should have actually fought but my bad i had misconfigured our minor so we weren't actually mining we are now

um but yeah we stopped importing on robston um and it was because we hadn't fully removed um all of the references to bls12 um and so i kind of had two things to discuss based on this one is just a general thing about test net consensus issues um what are people thoughts people's thoughts on uh postmortems for test net consensus issues is this kind of below the threshold um or is an expectation for clients to be um you know doing a write-up on this for mainnet it's obvious if you know there's something like that then we'll write a post-mortem um but yeah what are the communities expectations around test net post modems

and the other question i had is um when should we have tests for non-inclusion of something uh clearly with uh 21 sorry um 23 15. um it was last minute enough that we thought it was important to have a test for non-inclusion um and with bls 12 we didn't have any tests for non-inclusion and i think you can correct me if i'm wrong thomas if you're on the call but i think nephamine also had to pull it out kind of last minute so this this could be a potential issue in the future so yeah those are the two things that i want to talk about yeah i remember that we deployed bls 12

and only removed it removed it together with 23.15 and and yeah we didn't notice with any tests that were there at that time i think it's tricky because the set of things that are not in a fork is infinite and so we need to find a line to draw i think we just need one test that will say that whatever goes to the addresses that are after the latest pre-compile address uh for the like next one so if the last recompose 15 if we test pre-compose 16 if it actually uses if it uses no gas at all then so that works that works but that's just

for pre-compiled i was i was hoping for maybe a more general rule like okay if we had referenced reference tests for this and then it gets pulled out we should have reference tests against it um and that kind of helps solve micah's issue of like okay well obviously this set is infinite of the things we don't have there so where do we do the line and like what do we test i think the simplest thing is when you have tests that do test for the presence of it run the same test one fork back we should all fail the same way how often do we expect to pull back eyepiece actually this uh this actually happened on mainnet

or um yeah in a minute or one of the tests where parity had implemented that uh zero signature transaction thingy and managed to enable it on on maintenance and how to do a new release so there is some historical questions about this happening [Music] as well but i don't know if we can make any definite lines when aware

i think all op codes have the tests for non-inclusion as it's just the pre-compost that do not have it and anything outside like networking transaction formats as martin suggested so this is a bit harder to detect but any op codes being switched on or off we can detect it and i think we have tests for it already like there is a there is a bad op code test within the blockchain test that verifies for every single fork if the op codes that shouldn't be there are not there and if they return the invalid opcode so 2315 is included automatically within that test because it says that's not quite true because if you take foreign

stuff right so you i mean even if you have it implemented if you just do a jump sub it will fail looking just like it would have looked if you hadn't included it so yeah you know you can don't get full coverage on both sides of this you need to kind of actually know what this you want to check for that is not included in order to do it properly so maybe we should just create a note that in whatever process we where we create for when we're doing removing that this should be something that's addressed like what yeah reverse test should happen we should just make sure we have

the conversation about it every time yeah i think that seems that seems reasonable um but thomas asked the question i just want to answer uh no it wouldn't return there is no consensus on like what the error is i mean it either works or it goes out of gas but there's no like consensus observable but this was that type of error or this type of error yes but the the opcode there is always at least one test for the opcode not failing for any change that includes the op code so it will automatically fail for for any fork where we do not switch on that functionality

and the thought on the post-mortem why i would say it should probably it should be up to the client implementing teams if they need one and like they should just just figure out if it's something that would be valuable to other teams or their own team and that just kind of depends on the situation and what the bug was i mean with post-mortems it's also partially like the reason partially the reason you do them is an expectation from others that they will be there so what i'm trying to suss out is like the expectation around the test net like are we seeing it is like oh okay well you know test net consensus issues happen that's partially what it's

this rollout is designed for um so you don't need to do that or is the argument like well no there are users on it so do the postmortem so basically what i'm asking is like from people from other client teams what would you do if you had a test net consensus issue would you do a post-mortem or not yes probably would i think the silence means everybody else doesn't want to admit that they would

not so i i guess you know it'll be like a nice to have you know like we maybe should not force people to do it but i think it is valuable for the community to see it and obviously for other client teams and just for like historical you know keeping track of what happened um yeah and it's probably some it's probably more important sometimes than others too so that's just like depending on what the error ends up being yeah it depends on what kind of issue and depending on what kind it will depend then you are going to basically release postpartum

uh generally speaking postponed is something like explanation what's happened and i think every everybody would benefit from that okay i'm happy with it depends you feel like it was a useful question to ask cool um anything else on the rubstone fork i think that was the only thing that came up and and oh go ahead definitely definitely a useful question right because all these things like suss out some of the stuff that hasn't been formalized so

don't don't take eight silences like it wasn't a good thing because it was definitely good to just get out excited open it to your side open it there are for obstacle uh we found one bug related to the rust version and our docker images was built with odrust and we recompiled that doc images and now we are fine that was one hiccup on the opening website regarding robson cool anything else from any of the other

teams okay and for gordy it seemed to go smoothly but anything come up there okay no our validator is fine robsten girly both fine so we didn't see any problems yeah also noted notably all validators were upgraded in just in time so uh with the piece of fix deployed before the gurley forks there were no issues so not none that i've seen and have we triggered at least like

minimal versions of all the features on one or the other tesla i don't think we did well we must have triggered at least something on roxton for bass you to break right robson was a fat finger that was somebody trying to do unislap withdrawal in robstead and they got the call wrong so that was lucky there for the most part um i i have seen i have seen that there have been access to calls invoking access lists on roxton so that feature has been exercised both empty access lists and normal access lists i haven't looked for any of the other specific calls related to

the features i think in the past of that testing method were apart from the standard test that we run outside of chain that we can also always after the fork execute those features as transactions as test transactions on every single net but obviously it requires some work from us yeah i guess what is the hard part is it automating i guess you need kind of the same accounts across all the networks that you can automate sending all these transactions from

are you asking why can't we just rerun the same test suite yeah exactly yeah sorry what's that so the standard test suite of the blockchain tests usually goes by setting up some state and then and then verifying that state you cannot just send it to the network exactly yeah so there would have to be quite a lot of pre-work to actually set up the state in in the way we wanted for the test just thinking about the set of tests when instead of uh requesting some specific behavior we just prepare a set of transactions that use the thing but don't uh but the test set itself

doesn't say what should happen and just what should happen is that all the clients together should behave the same and we can detect if there is any break which means that we have a set of transactions that we generate that verify every single potential thing that we can think of um so something i did for robson is i just took some of the old transactions and resent them with an access list i think those are the transactions that deno saw so i think around uh 10 000 or 100 000 transactions or something that were just like all transactions from robson but yeah in the future we could uh have some

uh more meaningful transactions that actually like touch the the code the code that we want to test yeah anyway as i see it we have test nuts where like yolo we can send whatever and we have uh infinite bonds and we can [Music] do whatever kind of test cases synthetic test cases we want and the goal of having the robstone and rinkeby is to see the like actual main near mainnet usage [Music] in the more complex scenarios with everything that user does

we don't do so i don't know if it's worth deploying the synthetic tests on robs and if we already tested that on some earlier testing got it and in that case i guess the value is like having almost like as much time as possible on the test net so that people just use it and and we see what they what they do basically right i mean the yolo ones they don't have to live very long yeah prior to robsten do we have any proof of work test networks like any of the yellow test networks work nope or is or is robson the only place

that we test anything proof of work until maynet yes yep that would be the only argument i could think of for doing something special on like something above and beyond don robsten otherwise i agree with what martin said yeah we don't make any changes that are related to proof of work or click so it's not like it's important in this particular case unless we change difficulty behavior like we will do in london uh but we should have absolute confidence to generate any synthetic tests on robsten now so it's not like there is risk we should all feel totally fine to generate any random transactions

yeah definitely cool and i guess there's there does the ranking be fork happening next week on the 24th is there anything we want to do kind of after the rinkeby fork before the main network we'll have like two three weeks um yeah is there anything we want to do there or just kind of look at regular usage advertising with community to test show them what they can use how the access lists work encourage them to experiment with access lists that would be great testing okay prepare people to understand what tooling they can use and how they need to change their tools

that's a really good point yeah um yeah yeah that may be a hard sale since i don't think it might be hard to sell because i don't think anyone actually cares about access lists i mean they exist basically to given out to the set of contracts that may break and we don't even know if any of those are like real things that people care about or those like we know like it's what three percent of the things that martin tested broke but those might just be defunct contracts and no one touches so the design of access list provides uh gas savings for everyone who uses it based on what i read in the design which means that practically everyone can benefit from access lists and it's a bit of um i thought it

didn't i thought it didn't decrease gas costs like specifically so the way so the way that the ipa 29 29 and 29 30 work is that there's a gas cost of 2100 or 2600 if you access something dynamically but if you pre-declared it in accessories it goes down to 1900 or 2400 and i think the longer term case for moving more people onto using access list is that access was allow us to do database access in parallel instead of doing them in series which could potentially increase yield was that am i incorrect that the for

most users the gas costs will not actually change if they use an access list or not yeah then every cold um read will cost 200 gas less so right now it's very small but it does exist okay that was my second yeah to making it clear to community actually if they start using access least llc gus savings okay yeah i'll follow up on that um and look up at what tools and whatnot they can use and how we can we can announce it um yeah next week um is there anything else on burden that people wanted to bring up

otherwise we can move on to the other parts okay um so i guess yeah just to give some background on kind of the rest of the agenda which was pretty massive um last call we accepted 1559 and the difficulty bomb pushed back into london there's a couple eeps that are directly related to 1559 um so the gas refund stuff where there's different eeps the base job code michael who's joining on the call has a proposal from the mining community to change the brock reward if if we were to see issues with the hash rate on the network and then finally there's a proposal to bring back the hard-coded

block gas limit which was originally part of 1559 but got removed um so all of these are kind of very closely related to london and uh i think it makes sense to try and get to a decision on them uh sooner rather than later um and then there were another set of discussions around what should the scope of london be given that it's happening quite soon because of the difficulty bomb and and similarly what should the scope of shanghai be um there were some conversations on that um i'm not sure how much we can get through on this call but i think at the very least if we can kind of resolve the london stuff that'll be good because we can uh we can start actually implementing that and and testing it

um yeah so just a general context and then at the end of the agenda there was a lot of different eeps uh that weren't related to london or to the stuff already in london um but i think it makes sense to kind of go through the stuff that's that's directly related to see how big london already is before we make decisions about anything else um and then the first one in those so we started this on the last call we only had two minutes to discuss it so we didn't get into a lot of depth with all the different alternatives with regards to removing the refunds from uh estore and self-destruct uh so italic had an original eep eip 23 20 3298 and then um i forget william

had two counter proposals and then vitalik put up yet another proposal this week eip 3403 um so i guess it makes sense either vitalik or william if you want to give just like a quick overview of uh what your eeps are and and what what the goal is here um i'm happy to start so emp 3298 was a very simple uh bare bones uh removal of all refunds so including the self-destruct refunds and also including the refunds for estore clearing there were some concerns mentioned in

response to eip3298 so one of those concerns was that it would make a lot of use cases that go zero to nonzero to zero and kind of needlessly much more expensive so one of those is mutex locks as to where contracts kind of flip a bit in storage before they make a call so that they when execution happens inside of the inner call it can't re-enter the original contract and the second is erc20 a proven spend within a single transaction where the storage slot that represents the approved amount starts off zero then switches to something non-zero and then switches right back to zero and my

proposal for um both of that tries to at least address those concerns is to do a more restricted removal of refunds where refunds stay in the one case where the original storage slot is zero the current value is non-zero and the new value is also zero right so now the the reason the reasoning behind this more restricted approach is that it still um satisfies two of the key goals of eip3298 so the one key goal is that it allows us it preserves the kind of the or it also creates the invariance that

the amount of gas execute for execution has to actually be bounded by the block gas limit basically because every 15 000 gas refund is kind of mapped to a 15 000 gas extra that was spent uh just to fill the swat and so basically the only gas that refunds can cancel is gas used within the same transaction that was used not for storage or not for execution but for storage filling so from a kind of dos and uh execution time various mitigation perspective it still achieves the goals and also it manages to make gas tokens non-viable because it's only

uh like refunds uh i would have can only refund gas that was spent to fill the exact same storage slot so you can't use uh storage slots as a battery anymore um so yeah that's the ip3403 would it be correct to say that you are currently lobbying for 3403 and not three two nine eight i definitely favor three four or three over three two nine eight um at the moment i i think like in the viewer in the much longer term we should probably do further clean up but i feel like for what i did like three four or three is just the

minimal thing that achieves the goal yeah william i see yeah you have your hand up and you are the author of the two kind of utter eep so yeah if you want to take a few minutes to give some background on that yes uh i'm currently supporting 3322 which is the explicit gas storage eip this has been proposed in the past both 33 22 and 3403 fix uh gas token viability at least as gas tokens currently are the crux seems to be whether or not block elasticity from refunds is good or harmful 1559 can make 2x while refunds also already make 2x uh but 1559 elasticity

is strictly less than refund elasticity because it is bound by increases the base fee while the liquid refunds well the liquid refund supply bounds the uh gas token elasticity um if we replaced refund elasticity with only base fee elasticity we would see more congestion during peaks because uh having both is better um we'll need a lot more than 2x capacity during those peaks anyway as discussed at the end of the last call the network should be operating well below 4x capacity to ensure nodes can sync dos on the other hand is a problem of badly mispriced stop codes dos is usually the reason that forex is considered bad but the the last uh or the first uh up code repricing from 150

followed a dos event in 2016 but the op codes changed by a lot more than 2x call was changed by 17 and a half percent balanced by 20x ext code 35x and uh self-destruct went from zero to non-zero um refund elasticity has never caused such a problem uh and never will not even on forex the urgency of refund changes seems to be uh originate around perceived gas token storage bloat but the supply of gas tokens has actually declined more than 50 percent in the last three months empty blockchains are having a much bigger problem with this than ethereum despite only existing for about a month there's already 40 times more qi on binance smart chain than on ethereum i think removing refunds will blow the

state a lot more in the long run despite 4203's 4203's handling of one case uh there'd be no incentive to zero out token balances and allowances in most cases uh due to the 20 000 cost of store set when wallets and protocols billed for an evm without refunds the state will grow much faster than ever before but i believe the bloat is addressed by 33-22 by providing a more efficient alternative we can be expected uh we can expect to supplant the current inefficiency and waste uh um with explicit storage thank you technical question uh i don't really get it is there supposed to be an um a gas refund counter in the state of

an account uh 3322 proposes uh to put a gas uh encounter in the account though one alternative might be a pre a built-in uh um pre-compile that is an erc20 that would store this do you expect that it will lead to lower volatility of the gas price because like people will now have easier mechanism to explicitly store the gas into the account yes okay i mean 33

22 is uh i mean maybe you think it's small but it's in fact extremely large because it touches the consensus encoding of an account in the try i even if i supported it which i don't i think it would be totally out of scope for for london i concur uh can it be merged with a proposal from axic to limit the account bonds so that we have now the proposal for 24 sites principle space sounds like this the proposal for mexico about limiting the account nons is

a no because the account nons will never go above 64 even 64 anyway on manhattan yeah so but there is something like so well it's it's still 32 bytes uh in the in the storage i think it's like as far as a isn't it rlp encoded yep i think it's rlp encoded so we strip off those zero bytes already yes more or less um just yeah before we get in the weeds i see thomas and piper have their hands up uh do either of you want to go yeah so and generally i don't i don't think it's something bad about this uh

33 or 2 proposed driving gusto can i always consider those solutions to be actually quite interesting and good response to the market volatility around gas prices um and definitely think that it's not a good idea to just push it uh straight away with london because of its complexity uh i would love us to look a bit more at this but also like to ask for a bit uh more up-to-date and detailed analysis of the actual numbers because some of those numbers were set here with a lot of confidence but i seem to be referring to the very old events maybe not that relevant so be great to refresh that and prepare a better

clear motivation for uh for this upcode also in a way those markets were created in response to how protocol behaved and now we suggest of changing the protocol to support this market so it's the other way round approach so we have to understand that this motivation is still relevant and eip1559 does introduce this like a short-term capacity burst solution so so they would serve similar thing we have to analyze it further piper um yes so william one of the things that you said in there seemed to hinge on the idea that by

removing uh refunds we will be removing incentives to clear state and thus causing state bloat to be a bigger problem and i want to push back on this concept because i don't think that refunds and state clear clearing incentives have actually i'm not i don't have numbers to back this up but i do not think that those incentives have actually resulted in any significant reduction in state bloat or or or improvement in people clearing state and right now the direction that we're looking at for protocol development is basically to say uh not clearing the state isn't a problem because we're

looking at expiring cold state so i think that under that model keeping refunds doesn't actually make sense because we're not looking at a mechanism that's effective at reducing state blood anyways so i just wanted to push back on that specific point um yeah that's it i concur a response then i can care about this just to briefly mention one more point there i am i do think it is like i i think it seems seems like all people agree that this is just too also like too too early in the process to be

considered for london but like i think for a long time it is interesting just to think about like the gas limits having like of course the stool purpose of kind of like limiting the processing time for books but then also limiting the state growth and of course ideally those should be like like both at the same kind of like uh limiting size but as long as they aren't i think something like this proposal that would shift kind of like uh throughput towards the times of higher demand would make sense and when where the limited factor is the um purely the state growth right because then the state growth on average still is the same whereas if the limiting factor is the blockbusting times then of course like it was like this just doesn't make

sense um at all so just wanted to mention that so yeah um just one more kind of comment on long-term um economics in the context of at least the current proposed state expiry road maps one kind of important technical nuance of these approaches is that it it will actually likely not be possible to have a concept of setting a storage slot back to uh being empty like basically the the the reason being that in the context of these uh storage uh our state expiry revamps a storage slot being empty is just assumed by the mechanism to mean that that storage slot had not been accessed yet and so you should go check it

earlier state trees to see if um what the most recent value was and so what's going to have to happen is that wheel needs to have a like basically emptiness and zero be represented by different values and when that happens like i think removing refunds completely will be okay uh because needs zero to one to zero use cases like basically as soon as something has gone away from being zero once that storage slot is turned on and then everything after that is just uh and just uh just modifying an existing storage slot but like basically just because of that there would be no like not only would it be super it would be superfluous to add extra incentives to clear storage but it would

actually be useless okay so as to uh the point about uh storage uh currently not being incentivized enough or perhaps uh it not being effective uh i would counter that it's effective at encouraging uh inter-transaction uh zero to one one to zero behavior and design at the top level when protocols design this and interfaces they're more likely to encourage for example users to approve exactly the amount that they're going to uh need rather than infinite and the difference is that you will always have this uh approval in this case but it could be a

balance uh or uh any other kind of storage uh just because uh there's no reason to remove it if you're accessing it between different transactions if since the uh the incentive is there you're more likely to build it that way and the instead of it is important for that reason if as vitulik and another mentioned in the future there's actually no benefit to removing storage and they'll just be removed anyway then i can see a world in which we wouldn't want refunds because it would be complex and we already have some other complexity addressing the issue but that's in a future that is not london thank you uh yeah artem

i think you've been waiting for a while to speak uh yes uh i think uh we of these four proposals the original one 3298 is the simplest and the most straightforward therefore we should just go with it thanks uh then grab alex anything you want to add um i wanted to add to the economic argument like of smoothing like long-term gas long-term i think like um actually ip159 will already do a better job at that because it allows gas futures and options markets um and i think we should rely on that rather than trying to

transfer get stored gas into the future thanks and alex oh i see you put your hand down so i guess there's there's a few comments in the chat and what you know people have oh sorry alex here yeah yeah i i wanted to get a clarification with alex that if later on with uh with the state rent mechanism like stand purification uh empty slot and explicit zero will be encoded differently uh like is it expected that having like more empty slot and not having to take care or history of zero slots will

give some benefits to users or any estimate in this direction not sure i understand the question well like the point of that entire mechanism is to have state expire automatically if it doesn't get touched in some period of time like a year and so like it's about that if i have a lot of state uh cells which are zero that right i ideally wouldn't want to care about them right kind of yes exactly right yes if it wasn't worked on then it's fine but uh i think maybe it's having an empty

slot and zero slot being the same may be beneficial you know the reason why they have to be a difference just has to deal with these kind of really subtle nuances where like if if in the past uh the most recent value of some storage slot was five um but then you change it to zero then like th the fact that it was changed to zero has to be stored because if the fact that it was changed to zero was not stored then the system would kind of walk back to the most recent value until it would think the storage value is still uh again well yeah yeah proving emptiness is the same as proving uh non-existence in this case yeah sure

right just yeah to take a a step back here like it seems i guess as i understand it you know uh william you're kind of advocating for your 33 32 proposal over the the other one you had um vitalik for the 3403 even though it's a bit more complex than the original 3298 one um i guess maybe just like on the on the client side does anybody feel like 33 22 could be realistically done for london and yeah let's start there because that seemed to be the general feeling that no yeah i would say no yeah

and um yeah regarding the complexity of 3403 i implemented it yesterday and i posted on the whole product called on or call it chat a table summarizing the the changes for some particular scenarios um and of course just 32.98 is a bit more trivial but 3403 is still trivial to implement and that's does 3403 prevent us from doing 33 22 in the future if we wanted to it does not yeah 3403 i think is forward compatible with everything oh and mika you have your hand up the

does any clients opinion change at all for 33.22 if it was moved to a precompile instead of an opcode for the storage or sorry instead of the account so where the data is stored is that that's the critical piece or is it other bits so uh if you want to make a drastic well uh a pretty large change in what kind of date that we store for an account i can think of more valuable things to use that mechanism for than to have these guys playing games personally oh that's right do we currently no pre-compiles actually have storage is

that correct they're all pure they're all peoria okay so even if we moved it pre-compiled it would still potentially introduce complexity they would definitely introduce that somewhere it will bubble up in the in a try or somewhere yeah it's pretty large change so the i guess you know that uh you know geth clearly feels it's it's a pretty large change thomas has echoed the same thing and we could potentially do it for shanghai um does anyone kind of disagree with that to like potentially considering it for a future fork but not having it in london

yeah i don't think we should even consider 33 22 at all honestly i i honestly i think this is the prime example of like an illustration of what we discussed that before eeps can be considered there should be a ready-made implementation for the major clients okay fair enough i guess does anybody disagree with that not necessarily like the specific threshold like i think that's a separate conversation but just like about 30 33 22.

i agree okay um and open ethereum any thoughts yeah we agree okay i'll introduce new opportunity and introducing new state in the state three seems like a big change so then uh we're kind of down to 20 32 98 and 34.03 um i'm curious like martin you said 3403 was not too complicated to implement does anyone else have thoughts i guess on the client side between the two now it seems simple i think the

the only benefit of not going with 3403 is that the other one removes the refund entirely so for any potential new implementations it would make evm simpler but we can do that later if we decide to so 3403 is better i can agree with that vitalik mika you both have your hands up any comments on that one yeah i know i was i just wanted to give the long-term strategic comments that if we ever wants to do changes to the account struct structure then a good time to do that might be

when we do these uh state expiry and statelessness changes um and uh we switch to vertical trees because with the switch to vocal trees we have the opportunity to move to a more a kind of pure key value and a single layer system which would uh make it make it be very easy to just kind of add on whatever new slots you want because they're pretty much already like there's already got it um so is there a consensus to bring 3403 into london then and i guess we on the previous call we had consensus to bring something about refunds in

london to help deal with the increased block size of 1559 it seems like people prefer 3403 uh does anyone disagree with bringing 3403 into london i'm a big fan of 3403 though i'm not a fan of bringing it in for that particular reason that particular like i am very unconvinced that we need it for london i think it's an awesome thing to include and i would love to have it i don't think we need it for london with the introduction of one five five nine i think one five five nine going to london without this would be totally fine i agree with micah martin did you say that you implemented

this one and that it was relatively straightforward uh yes i posted on the guest sorry on the all corner channel they they commit or get very small i'd also like to mention so there are two things one is that i'm not sure if the actual we we might want to modify the the refund size in 3403 um to make the zero one zero case identical to the one to one case which is currently a bit cheaper um what was the other thing i want to mention is that currently we have a problem with the the gas talking problem is that

any mining pool a lot of miners fill their blocks with mining chai tokens um and filling the state um we can fix that if we remove or make refunds not carrying a cross-transaction on the cross blocks and i think it was peter who is not on the call today but he mentioned that if we're gonna do 1559 we should slash need to also do something about the refunds because 5059 uh has these yeah you you can temporarily have a lot more gas and block processing being performed during the block

and with refunds and refund burning the effect will be even further magnified which would be a security concern so i think that's the kind of tie between 1559 and refunds yeah does peter or you have data on that like i've heard that argument made many times but like every time we try to push on it it's kind of it's very fuzzy i'd like to get much harder data personally i don't know what i mean you can have double the double the block size and you can also burn refunds yeah sorry yeah the argument being that

we are not currently constrained by block processing time like that is not a real issue unless the average processing time goes up and 1.59 doesn't change the average processing time and even gas tokens don't actually change the average processing time because they end up getting burned later in theory or we're sorry let me rephrase that last part gas tokens change state growth but the average state growth doesn't change because they're later burned um and processing time there's basically the same as any other gas you spend and so i'm not convinced that we need to care about individual blocks being up to 4x is big because i don't think that's a real problem we have right now uh so there could i don't know how i can explain that

uh well um but it's a client if you don't do it on this call i would just like it comes up repeatedly so i'd like to see something more solid at some point right and it's kind of hard to show but in the code in the gut client or i guess whatever client there is a difference if the if you are executing 400 transactions or if you are executing 200 transactions uh there is journaling there i mean that yeah yeah i'm sorry i can't really okay um we can take this offline but just it's something that keeps coming up and i would really like to see it handled or more addressed more

thoroughly so so i guess based on on that uh thomas you have a comment about uh saying that you would want to keep london clean which is 1559 and the difficulty bomb and that maybe 3403 should be scheduled for shanghai um i don't know what do people feel is the next step here like should we just try and have perhaps a breakout room or just an async conversation about the different approaches and and decide if we want something in to london and and i suspect at this point it's basically do we want 3403 into london right

um right and i guess the sub question of like what what the what number the refunds should be set to yeah and because the martin should be i'm okay so i guess maybe we can yeah uh and and because the implementation is also quite small as as you said martin i think it's at the end of the world if we decided on the next call to include 3403 into london but uh what we can do is just have the maybe conversation async about um what the impact is on clients of of these blocks that are that are i guess four times as big

um and and you know whether 3403 helps there and and the kind of additional complexity it adds to london um does that make sense or do people feel i guess i don't feel like we have kind of enough consensus to make a decision now but the people feel differently from that i'd i think it'd be nice if we said we want to do 3403 and then and not the other ones but whether it's london or shanghai it's an open question and like narrow the scope of the discussion considerably although i i would say just from a risk aversion point of view i think it's better at least to think about the earpiece as like a like as

addressing a security concern and so unless like we are completely certain that 4x block times are fine i think the default should be that it's in london unless within the next couple of weeks we are like absolutely convinced that it's not necessary at which point it might still be a nice feature but then it's a feature discussion i think for now it should remain a security concern discussion yeah and i'd agree with that dude this fits into the evm graveyard category as well as just the direction that we want to go in general with the evm right it's uh it's like both evm graveyard and security um so i guess maybe just on the security supportive of it since it's simple and

on the security side like obviously martin you raised kind of some concerns i'm curious like what do other clients feel um is this also something you see as a security concern i feel is very it's very close to what hansgar is saying and that we generally should it would be a great success if we could define it without london is it predefined as this two yeah is the difficulty bomb and tip1459 and then maybe i would just change from what answer suggested to default by default f3403 i would suggest by default not have it but actually promise that we start working

on it to analyze if it's needed for security but that it comes in high and only and only if it's really needed and push it forward a bit so but one other thing is that like this is going a bit further on into the agenda um but i think some of us wants to propose that shanghai should be only the merge yeah and that is definitely another can of worms so i guess okay let's maybe uh keep like thinking through 3403 um whether i guess it's default in or default alt doesn't make a big difference over the next two weeks

um because i suspect all the client teams anyway uh need to implement a bunch of other stuff for for uh for london like we're not at the point where we can set up a yellow network um so yeah i i think it makes sense that like you're like kind of saying in the chat make a decision about that on the next call um and just yeah to move forward because we have a lot of kind of other eeps to go over um yeah any final comments on that or is everyone fine to move forward we could just move 3403 to conserve foreign inclusion and then that i think would be the way to formalize that let's let's get the eap actually into an

eip it's currently just an idea it's not even a draft yet okay so let's get it move it to cfi so we don't run into so get the eip finished like someone needs to finish writing it and then once it actually is an eip then get it into review then get into cfi so we don't end up with problems like we've had in the past with you know things that are still just like ideas on a piece of napkin and we're like oh it's considered conclusion okay yeah and we can definitely do that over the next two weeks and then uh discuss it on the next call um yeah it should only take like a day okay so next one i think this one should be a bit quicker uh base fee up code eip3198

uh basically to add an upcode to query the base fee um there were some concerns that were brought in on the last call regarding it um vitalik posted a comment in the issue to to kind of address those um basically that the the op code doesn't provide gas observability uh in the same way as as you know looking at how much gas uh uh internal execution costs it just shows you how much what was the minimum gas price of of uh of uh of a block um yeah i don't know this uh thomas i see your hand is up so any comments

yeah i think uh it's i would be both the person that would use it extensively in some projects and also the person that knows that it's not critical to be introduced straight away i'm unlike it's a simple op code very basic very needed it doesn't introduce the gas observability about the gas progress it's a different type it's similar to the gas price up code which is the transaction environment or transaction context observability we have lots of those and they never caused any trouble really and yeah i'm like as few things as possible in london just to make sure that london is simple and this one should come straight after and it's very simple up code but even

this would just be one more thing to think of i think this again overlaps with the discussion that is scheduled as the next big item on the agenda the kind of the scope scoping for london and shanghai because if it turns out that shanghai might be merge only and it might only arrive let's say late this year or early next year then any new feature fork after london might be mid to late 2022 and so under such a scenario i think something as simple as the base fee of code might be nice to have before like the 20 24 months horizon yeah okay so let's let's maybe come back

to this one in the same way as 3403 um the next one uh so this one will probably be a bit longer again um so michael carter aka bitsby trippin is on the call uh so basically there's been a lot of conversations with miners about the impact of 1559 um and michael has been working on different kind of models with regards to minor revenue and how 1559 would impact that um and 33 68 was his proposal that should potentially go alongside 1559 depending on on the network conditions i believe um so maybe it makes sense michael for you to just take a few minutes to walk us through like

you know the proposal and and i guess specifically the the kind of scenarios you've considered and the one where you think this proposals would make the most sense yeah thanks uh i wanted to thank you guys for the opportunity to talk briefly about it and before i jumped in i wanted to take about 10 seconds to uh you know apologize to the ethereum developers in the community over the last few weeks of the tension that was created around some of the language that was used when we talked to a show of force around eip1559 as a minor and educator becoming a participant even well before ethereum in 2011 i've been very passionate around the proof of work

concepts and a mining advocate in the scene i think that passion in this rare occasion uh caused a less than ideal message when it came to the the risk of the fee burn if particular conditions occurred when talking about the specific eip the first iteration as i would call it is just trying to address an existential risk that i believe is you know an unlikely scenario but if we had a participants fall of price along with the yield burn we would have a potential issue when it come to the size of pi of the growth of you know because of the success of ethereum and the crypto ecosystem in general has

brought up this a huge amount of participants um about two and a half times what the current um previous all-time high was when it comes to yield make no mistake i know what that this eip looks like it looks like a money printer goes burr and but i think at least from a conversation standpoint we can look and look at a pragmatic approach when ensuring that all circumstances to up into that merge that we have security is paramount um having a solution you know to address a large hash drop not just because of market conditions there's also a scenario that has you know maybe a hybrid type of issue where you

have another uh proof-of-work coin come in and start you know peeling some of that dominance away with the understanding that uh you know ethan is moving to a place of proof of stake that's that's a known known state right i guess bottom line the upfront in you know inflation risk with the tell-off that brings the same emission over two years uh given the you know the flip of moving the merge closer probably isn't as tenable now because it it wouldn't have that same emission rate now over a two year period i've also you know not only is this optional but there's also maybe a discussion that we can have um

it will take this obviously offline but you know implementing something like mess like the multiple uh exponential subjective scoring or something else that allows and protects against any kind of reorg or double spin which is the primary concern here so uh if a mission is just against the monetary policy which makes complete sense um the the formation of this eip was to ensure that the emission rating would be the same amount of emission over a period of time but in a shortened schedule i understand that that doesn't make sense um you know just i'll open up to you know the the floor to see you know some other tenable solutions that i have no problem at all helping to champion

um in this regard thomas yeah you had your hand up yeah so i think that just the idea of starting the conversation around the block reward and how it binds to the ethereum price fluctuation enterprise fluctuation uh it's relevant i mean it's important however i i don't think that just by changing it to to free or far just defining any change now makes sense without understanding how you want to have it in the long term ideal solution would be binding the move of if price

with the security payout in a block reward sense i think the the mev solutions that enter the market now they the price of ether provide a lot a lot of uh payout to the security providers to miners and this doesn't seem necessary but the conversation around it is necessary and it's important to talk about it and to think how are we prepared to act very quickly if the price happens to drop 10 times for example how do we quickly ensure that this excessive mining power that appears during the times of the high gas price is not used to just do the quick gain by attack on the

network mika am i correct in understanding michael that uh this proposal is um you want to have it ready in case there's a problem but if everything stays exactly as it is you do not believe it is necessary today like we're to do london tomorrow you don't think it's necessary but you think that we should be prepared if the environment changes by july is that accurate absolutely yeah and in the modeling that was done rudimentary as as it was it took effectively 10 different scenarios

three of which started to create an instance where you could have a precipitous drop and so in the unlikeliness of it happening having it to go in mandatory i think is uh premature i don't think that it it makes app any sense at all to be honest with you but the it is about having the fact that ethash in general is not protected against this type of situation and the scripts and the know-how on how to implement um has been proven in the system and it's so it's really just a stop guard and to have something because of this process of going through and how quick could it could you know the community react um if this was to occur like over a week

period uh you know what's the flash to bang and having something in the back pocket that could be implemented um you know i think is is pivotal especially as we start to get up to that to the merge uh james um the in the context of having it ready if something was to happen i'd say like reducing the year decay to like a year the time decay and then also noting that the value might need to be different depending on the on the actual event that happens but it's a good option it's good to think these things through

now and have a have the option when we need it ready yeah i i tend to agree with that like uh michael we've talked a bunch over the past week and i think my my view on it as someone who's worked on 1559 over the past year is obviously there's you know a ton of things that could go wrong the network could get attacked and stuff like that and and i'm personally you know not in favor of pre-committing to a specific solution i think if something goes wrong uh then you know different problems have different types of solutions like the case for miners obviously uh there's not enough hash rate on the network a simple solution there is increasing the block reward but if something else goes wrong then there's a different solution to that problem um so i think it

it makes sense to generally keep in our back pocket um yeah uh i don't know alex thomas you also have comments or danny i see you coming on on and off mute uh i would like to clarify for understanding of the claim that uh the mining power like which has increased during the bull runs uh and high gas prices uh can be later on used to attack the network in case if the ethereum price goes down and gas prices go down um now when like

uh at least i'm not aware of any highly popular uh coins with it uh and with most of the mining power now coming from asics what would be a logical reason for you to take your asic which like maybe doesn't work you're not used right now and use it to decrease the value of something which you could have earned with this asic but you don't do right now so it will be like it can only be used by someone from outside of the network and then it's kind of uh

looks like the same probability can happen in any case yeah i think that's what we should be having this conversation i still believe that we are very very safe at this stage and also we have a much much simpler tool than this eep that is proposed it's just changing the reward without any long-term decay or anything it's something that we can introduce very quickly i believe the difficulty of such a change is even lower than changing the difficulty bomb numbers um it's one line change very easy testable can be agreed on very quickly and

introduced to the network probably within two or three weeks with all the agreements i might be slightly too slow for the economic reaction but at the same time we don't expect this uh changes to be to be that drastic so i think we have tools we should have conversation but we have tools it's not like we are totally unprepared we have some tools now and they are simpler and faster to be introduced than the one here which makes assumption about the long-term behavior like it makes assumption that it's it's important to increase that now and it should be decaying to the previous number and that decay i don't think it's justified by anything else and trying to um make the cip to look a bit less um like less

less permanent and then so be accepted more likely cool and danny first of all i don't think that uh it's probably good for a blockchain protocol in the long run to be manually manipulating um kind of monetary policy over and over again i think that's probably really easy to be captured i think there is a little bit of a precedent here because of the blocker reductions and because we are moving to proof of stake which is fundamentally modifying that um policy but i i think in the long term i don't think it's a healthy kind of path to go down but that that said um for this particular

and these types of proposals like kind of a reactionary uh proposal to increase block rewards in the event of an attack or even a price drop i i think that it's very it's probably naive to assume that doing that type of manual work um on the protocol would not have an impact or potentially have an impact on price i don't think you can isolate it and say okay ether is worth 100 bucks right now we can increase uh the block reward by by 10x and think that that isn't going to have any sort of uh potential impact on price um i i think that obviously price value and and uh the relationship between those things the

relationship thing uh we do and things that other people know you need to do is not known uh but i don't think that uh i think that you could have a negative impact there um and so i don't you could even backfire um by increasing block rewards and potentially having you know creating fun and that kind of stuff so it might it might actually backfire with recycle security just something to think about um i i would say though don't make a habit out of meddling with uh monetary policy and get to proof of stake and kind of have a disability thanks and uh yeah michael i see your hand is up again so yeah i mean i'll first start with danny

i i actually agree with you danny i think that the to any kind of adjustment and reward and the incentive i think has a weird um effect on how it can affect price not in such a linear way that it could be driven by news or anything like that and would have potentially the risk of effect on that uh when when getting this uh proposal put together having that that emission schedule to be the same amount of the mission was to try to address uh you know if there was a precipitous drop that it could you know elevate enough that kept the uh this i wouldn't call it the status quo but about where the network has been over the last 12 months

when you look at not just peak times but just the average block reward where it's been it's been around a little over three and you can run that back since may and so that's where the three came from and then the the telling off of that as we got to emerge was to ensure that you know if it took a two it gave a two year window uh if that needed to move it was uh you know it could do that i think understanding not just the reaction from the community but just in general when we mess with monetary policy there may be other um better approaches when it comes to addressing the security issue and just take you know some of the

uh the lessons learned from some of the other networks um where they've had to really deal with this uh like with regards to they've had impacts um so that you know if this is too untenable you know from a protection standpoint having maybe a corresponding eip that's in the thread uh such as mess or deep gravity well or something that allows a um a protection as it were to a reorg may be more tenable to it and it addresses the issue um but yeah we can take that one offline uh so i guess just in the interest of time to kind of summarize you know i think everybody agrees if there's a problem you know we should consider

addressing it obviously there's kind of disagreement about what the best way is and what the the second order effects are of of doing such a thing um it seems to me like nobody's advocating to put uh 3368 into london as is um so i just wanted to state that clearly because i know a lot of people are watching and kind of tried to interpret the decisions out of this um so does anyone disagree with this that you know uh we can obviously address any problem with 1559 once it comes up uh issuance is you know one potential solution uh which might have unintended consequences um and that for now we can

keep london as is with regards to 1559 and i will take silence as agreement um the last thing uh hopefully we can do this in just a few minutes and keep kind of 10 minutes for the whole shanghai merge discussion um but the last kind of 1559 related concern for london um is the idea around hard coding the block gas limit so the original spec of 1559 hard-coded the block gas limit uh at the time it was 8 million and up to a 2x of 16 million over the last year as we worked on 1559 we removed that part

uh of the spec so to leave the block limit under 1559 controlled by miners as it is today um the main reason for that was just separation of concerns um 1559 was already a big change and and and this seemed like a kind of uh uh somewhat unrelated change to bring in in in the same eep um then over the past few weeks there's been some conversations about uh some potential concerns where under 1559 uh if miners get a tip uh to compensate for their uncle risk and their their node operations then their incentives to grow the block size uh increase because you know if all the miners nodes are more expensive to run then the tips will just go up and

they'll be compensated but uh most other participants of the network uh will not be um so there was an e put together again this week uh as micah would say kind of a back of the envelope idea uh which basically brings back the idea of hard-coding the block gas limit uh alongside 1559 uh mostly to avoid the scenario where like miners are uh overly incentivized to uh to grow the the the block size um and uh i think phil from horizon labs was the author of it uh but light client uh wanted to discuss it on on the call quickly um so

do you want to give a quick overview and then we can take comments uh i think you know the title really basically says it all it's just setting the block gas limit to a hard-coded value it should be backwards compatible we're not going to remove it from the block header it's just going to remove the ability and the consensus logic for the the gas limit to go up and down i think the fraction is 1024. so that's about 0.1 per block so just removes that and it requires every block to have the gas limit set to 12.5 million uh thomas i think you had your hand up first i think we historically never seen any

um any bad action from miners on this parameter and on the other way we've seen actually a very helpful cooperation on this number during the shanghai attacks i believe i may be wrong here but the the custom it was brought down just to make the network much safer in the short term also this introduces um a fine balance between the awkward defs and miners so just any other conversation with this single parameter being untouched is much more balanced because it says miners can react to the very adversary conditions when they detect those

and uh we have to stay aware of it and we have to understand it that there is this one parameter then they may change to protect against some network events as i would i would be actually strongly opposing this change and would prefer to leave it in the hand of miners um i mean i was uh actually about to say exactly the same thing i think miners have historically done an excellent job of governing the gas limit and also i think the portion of the tips that does that would not go down with a higher gas limit is is fairly small so i like just economically that incentive doesn't seem

to me to be too huge may i remind you that miners also run nodes and if miners are able to process larger blocks then they we should let them the network should scale at the first possible opportunity because like the centralization and everything is good but 100 bucks gas fees are not and they are much worse for the network michael i think you had your hand up next and then danny that was left up from the previous

conversation no worries daddy yeah i'd just say miner is a different type of economic actor on the network obviously they can afford to have much more robust machines miners could even have very very sophisticated machines and so this parameter isn't only tuned for that type of conversation i don't think we should forget that um i will say though the threat of removing it um is something that we can kind of keep in our back pocket um and maybe removing it doesn't really need to happen today um unless it were abused and one comment on that uh i assume this also could be removed by a

soft fork right like because in the case where miners abuse it uh obviously they won't upgrade to a new hard fork which uh which removes it but we could have all the other nodes on the network refuse blocks beyond a certain size um and and that could be done basically without miners uh support right like so if there was a case where we needed to deploy this as kind of a response um contrary to like a bunch of other changes we don't necessarily need miners to adopt it um yeah uh james artem um i think i just had my raised uh my hand up

okay cool that it's true that miners have been great and they're yeah so far and i don't and i agree with vitalik's point and um i do like in general that that over time shoring up the incentives and promises for the network makes sense and that the people who most understand the nuances of state growth and those things should really be the ones that are deciding this until that's no longer a problem and so i would i would say we should go with some kind of block

limit but maybe it doesn't need to be for london and just a general idea um actually those same people who understand the best they also drown in the awkwardest bureaucracy and given that all our like uh the nearest hot forks are um are reserved for like e 1559 or the merge we will never get the chance to increase the the hard cap so i guess just this was originally brought up as kind of a security concern related to 1559 does anyone feel

strongly that this should come in in 1559 uh in london alongside 1559 to kind of address a security issue and i think if no one feels strongly about that um maybe it makes sense to just have the next five minutes for the for the merge conversation okay so not included alongside 1559 for now in london um so we just have six minutes left um i i don't think we can resolve this but i think uh there's been a lot of conversations uh about

shanghai and the merge um so to kind of summarize quickly um we've wanted to keep london kind of uh uh lean in terms of an upgrade uh for a few reasons the first is that 1559 is already a pretty huge change and the second is that it is going to have to be done quickly in parallel to the berlin work which is the first first time we've done this so every extra bit of complexity we add in london is kind of a has a fairly high cost um so i think it was uh last right after the last call um thomas proposed that we should just start having uh planning for shanghai um kind of soon so that if we have good

ideas we can kind of move them to shanghai uh right now and and and kind of free up 15 uh london for 1559 and have shanghai happen shortly after um in parallel to that over the past week or two uh there's been a lot of conversations about the state of the ethwon to e2 merge um and the vitalik has put up a proposal where um you know we could have a greatly simplified merge that would still require a fairly large amount of work on the eth1 side um so another approach is to have london be the last kind of feature fork and then to have uh the

awkward ev's attention kind of exclusively focused on the merged after london um so i'll stop here i see a bunch of people already have their hands up um thomas i think you were first and then danny yeah so my proposition was to since we see some simple eips that would be very uh proper for london but we want to make sure that london has no delay at all so i'm suggesting london for july and then a bit faster forex than we usually would do so suggesting shanghai for october with anything that naturally comes uh to accompany london changes so 3403 refund remove pace fee uh and whatever else would be suggested

and then suggest cancun to follow very quickly in january for the emerge and yeah i see danny and mikael you both have your hands upside down you want to get some context on the merge yeah and both of us can speak a bit to it so um i mean the promise of e2 the promise of what the the beacon chain is doing is the three-fold um to make the protocol more secure sustainable and scalable um there's kind of the prioritization uh just moving the existing theorem network from proof of work to stake uh satisfies the first two of those uh making it more sustainable protocol from a carbon footprint standpoint as well as a more

secure protocol um due to some of the properties of stake whereas if we did sharding first the you bring scalability to the beacon chain but you don't really bring scalability native to ethereum proper at that point and so from a prioritization standpoint i think there's much buy-in to do merge first so i don't think that's necessarily what we're debating here i would also argue that bringing kind of the promise of proof of stake and the the sustainability and security um is likely i think we could say a much higher priority than anything we could get into shanghai um and that would be my prime argument for um

kind of once london is shipped or once london releases or shipped uh kind of doubling tripling down on engineering efforts uh and and digging in i know um you know some people say there's no way you could do it this year some people say i think you know there's enough in that chain set in that minimal version that we could actually ship this year and you know in terms of prioritization obviously we could ship a small shanghai fork um and work in parallel to that but i think anything that we do and attempt to prioritize that isn't the merge would likely lead to some amount of delay in that um and so i would definitely argue for

all hands on deck and and get it done i think it's kind of um one of the core mandates of theorem at this point to to get that merge done yeah so then he said pretty much what i was going to say but i can add that with the simplification that we have now um with um it the merge can be much easier uh thing to reason about and uh we have like the and the scope is pretty much understood as well and um yeah since the uh proof of stake has been um announced like from the very beginning and since we have this clear

path to the merge makes a lot of sense to focus on that and also one thing i would like to add here is that um with the bringing the execution to the beacon chain rather than to the short chain uh the merge becomes independent from sharding which it used to be before when we discussed like phrase one and phrase 1.5 so um since we like have all this um the table um i think it makes a lot of sense to pursue emerge after london so there's a ton of heads i'll go ahead and mikka yeah sorry um yeah i just wanted to to to basically um

agree what's been been said primarily though also to point out that basically from the merge research side um i think at least my understanding is that it looks like one of the limiting factors of like time to merge really is um client like eth1 client attention basically and so at least it looks like right now that that then whatever focus we can shift to the unlike the merge earlier that gets us to the merge so just so much earlier and so i i don't think like any kind of commitment to shanghai as the merge would preclude that if like a month or two from now we realize that merge can't happen before either march or april of next year anyway then we could always kind of like revisit

this decision but i think at least there's there seems to be very universal kind of community buy-in to really prioritize um uh the merge and i don't think any potential features for shanghai are like important enough to even justify delaying the merge for just let's say a month or so so i i personally strongly kind of like agree with kind of committing to shanghai as the merch but also which variable if you wanted to say on the london side um on what that means for london i think there's at least a case to be made for like some of these nice to have earpiece that are small for example the base feed to then be included in london um i i i think there's like a strong case there because again the next feature fork might be quite a far way out i think it's more

complicated for other earpieces for example i mean i'm one of the code champions of like a one of the bigger earpiece that is potentially considered for london i think there's definitely a case that there's just no time because of the tight schedule for london um but i would maybe at least propose that we were to kind of like just go ahead with any potential earpiece for london as long as we think we might be on track timeline wise and then once we see that it's just like basically we are too kind of like we were running out of time it we can always kind of like go with like a more core version of london but yeah that's all i wanted to say and since we're at time i was gonna ask a question we're gonna yeah i was gonna ask questions about the

phrase of the statement instead to avoid inciting discussion um the question was is do we actually have a spec for eth1 or application clients to go implement or is it still just in the heads of these two core devs if it's not then i feel like we really shouldn't be talking about the merge until we have something that each one clients can actually look at and implement so i think the challenge here is that we have more and more and we need to have eth one client involvement sorry somebody else was speaking yeah yeah yeah i was just going to say that currently we don't like uh have uh this pack as a document uh rather that we only have the proof concept um but yeah we are working on this back

actually now so uh and likely see this the spec or i mean for the application layer like in the next quarter so would be just what would be interested to hear like what about what if the current proposal says uh like is is not yet specified because it actually does seem to be uh to me to be pretty specific but maybe we can move the conversation offline um i do want to announce in um we will be doing a bi-weekly uh like semi-public call won't be

won't be shared i mean it won't be a stream or anything um to discuss the merge um from an engineering perspective and kind of dig in and that would be on the thursday prior to the all core devs call so two weeks from yesterday and we are looking for like say an engineer from most teams to sprint on merged test nets from mid-april to mid-may that would be along with the like east global scaling hackathon so if you have an engineer on your team who's interested in getting involved that's something that we're going to be discussing in the coming weeks okay so i guess just to kind of

summarize and wrap up um so i think for today you know uh for london we haven't included anything beyond 1559 and the difficulty bomb pushback uh and then the big conversation we need to uh think through is um yeah what do we do with regards to shaggai for the merge and for uh or and that affects what we do for london and and and all the other kind of features um and and that could be obviously the main topic of the next awkward devs um like client has a comment about breakout sessions i'm not sure to me it feels like the we don't need like one breakout session

as much as like just this general conversation about the merge versus shanghai and that the different eeps should probably uh the different eats that you know were proposed for london or shanghai should probably keep you know doing their work and and trying to to get it ready um but that ideally at the at the next call we can kind of make a decision about you know what the scope is for shanghai um yeah sorry that was kind of a ramble but basically next call trying to figure out what do we do about the merge in shanghai uh and consequently what goes into london um and over the next two weeks just try

to keep having those conversations which i guess will kind of culminate with the the merge call two weeks from now uh that'll be the day before awkward abs does that make sense for everybody any final comments thoughts sounds good cool well thank you very much welcome congrats tim for our very first well-managed call we made it yeah agreed agreed thanks everybody steam thanks for watching thanks thanks bye thanks bye hey guys [Music]

[Music] thanks hey guys [Music] so [Music] [Music]

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

[Music] so [Music] [Music]

[Music] [Music] [Music]

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

so [Music] you