All Core Devs - Execution #119

All Core Devs - Execution · 6 Aug 2021 · 29:40

A short Ethereum core developers call on London updates, with a note that other transaction types need testing, and the post London EIP-1559 assessment breakout.

Speakers

Topics

From All Core Devs - Execution, hosted by Ethereum Foundation.

Transcript

foreign [Music] [Music] foreign [Music]

foreign [Music] foreign [Music] [Music]

[Applause] [Music] foreign [Music] foreign

[Music]

Tim Beiko: hi everyone welcome to awkward devs number 119. um we don't have a ton on the agenda today basically going over the London Fork um yeah which happened yesterday in case anybody missed it uh it seems to have generally gone well there were no consensus issues most notes seemed upgraded uh there was some small issue where uh some of the miners were still targeted 50 million gas limit um because that was kind of the default but then by reaching out to them I think it's been mostly fixed we're now roughly

at 30 million gas blocks um I think there's one or two small mining pools still targeting the old ones but they're not significant enough percent of the hash right to drag everybody down um yeah that's basically what I saw in my end I don't know if anyone else has anything they wanted to share about just the fork or what they've seen happen

Danny Ryan: do we know if um most of the functionality has been tested on mainnet like did people try to send an EF uh yeah that's a good point I've haven't seen it so I I posted on Twitter yesterday the only thing I've seen is somebody trying self-destruct

um so testing parts of 3529 but I I haven't seen somebody tested base fee op code I haven't seen uh the zero xef and I haven't seen kind of the other conditionals for uh the gas refunds although I expect those would trigger I think in in a lot of like dexes but I'm not 100 sure about that actually

it's

Trent Van Epps: sort of a half test but exit put together a dashboard checking if there are any contracts starting with Xerox EF and there are zero so far um but yeah somebody should definitely actually test it

Tim Beiko: for for the zero xcf one though would it actually what would happen would it be

just that your transaction reverts right

Martin Holst Swende: yes

Tim Beiko: okay

so in that case yeah you would still see I mean neither transaction or internal income was great garlic

Tim Beiko: and yeah Trent posted the link above uh which which is counting them um but yes if anyone on the caller listening wants to kind of test those basically 35 29 there's a couple kind of edge cases uh Beyond just the basic self-destruct uh if somebody could send a hash of a transaction that tried to deploy a Xerox EF contract and then uh just calling the base fee op code also I

I don't think anyone's done that yet um yeah foreign that people wanted to share or that they noticed

or what's the the real node count uh count like did it greatly reduced like normal

Tim Beiko: um let's look when I looked yesterday before the the upgrade um and uh it was something like yeah we were at 80 yesterday right

before or right after I forget the upgrade that uh that had upgraded now ether nodes shows 96 that has upgraded um and there's ethernet's tracks 1400 that have updated um and you basically so on ether nodes you see a drop but the drop is is from when we released kind of the uh or white March I think this is from run we actually released Berlin there was this massive drop because we hadn't had a fork in like two years um and now they're showing uh we're still at like 5 700 nodes on the network

so I'm not sure I'm not sure what explains kind of the discrepancy in their two pages like their total notes counts shows 5.7 thousand and then their London page shows 1.4 000 with 96 of them being updated um so on the total view it doesn't seem like it's dropped and then on the London view it seems like 90 over 95 have updated

and another like random um data point regarding up this is the if you look at four from the normal monitor um the Legacy Death Note on there has not seen any blocks it got stuck on 99 so it

none their appears there'll be no minor which seal the block on the old chain at least which reached that Legacy guest mode it says

Tim Beiko: bad blocks one is that just because it got the fork block and then

rejected it and didn't apologize yes okay

Micah Zoltu: did I understand correctly not a single

minor forked um well yeah I mean it's only one note there so

Danny Ryan: uh it could be a single GPU that hasn't found their block yet

are you

Micah Zoltu: sure but is this the first Fork that actually went perfectly smooth don't we usually always have some minor

that stays behind yeah like every fork in history yeah so the one that everybody thought I was gonna be the most contentious

ended up being bad it almost takes a while though before the first uh post for non-canon Block is sealed but it's been it's been a while now so yeah I'd

Micah Zoltu: be curious if someone sees one please share an awkward dose otherwise this is a pretty big milestone if you manage to get everyone to work correctly

yeah but

Martin Holst Swende: the thing is also if there are fewer If the percentage is smaller it's going to be much harder for that single Miner to propagate his block because everyone will just reject it

so yeah let's go down for the latest node to

actually pick it up so

Micah Zoltu: I think the moral of the story is is we just need to make sure that every four concludes a highly contentious change that way it goes smoothly

wow

has anybody done analysis on the uh kind of intermittent zero transaction blocks to to see if there were really no transactions that were uh suitable at that base fee or if it's really just you know zero transaction blocks that are being produced

Micah Zoltu: so I haven't done it through analysis but just glancing at etherscan I think uh there at least some of them are zero

like I'm looking at one that the preceding two blocks were below the threshold so the base tree is going down leading up this block and the block immediately after this had was very full suggesting there was lots of stuff pending and there's the time between blocks is really short so we didn't have like a super short block or anything it looks like our super long block I mean again just anecdotal but yeah

Tim Beiko: and I think vitalik I saw you you posted on on Twitter basically the distribution of guests of gas usage we should expect do you want to just give it a couple

yeah

Vitalik Buterin: um yeah like basically um all that was was

um just uh made scans through 500 uh recent uh blocks and uh like uh just made a chart of like what the gas used that divided by the guess what that is of each one and like uh that's just up a lot of the distribution by percentages and if anyone wants to look it's my most recent Suite um and the thing that I compared it to was basically a simulation I made about uh like one and a half months ago where the simulation was pretty simple and basically just let's do um it assumes that transactions happen at a very uniform rate uh like basically a coin flip of like once every couple hundred milliseconds and then blocks happen with uh some Pro some

probability per tick as well and the uh one of the block comes and basically grabs like either all the transactions that are in the pool or if there's too many it grabs them actually the pool goes down by that amount and if you pull and so the right is like it's a part of that simulated distribution and it the two look very similar to each other which is a good side like it just uh means that well first of all it uh it also shows that there's not that much empty blocking actually going on but also it's just a nice sign that I guess nothing very unexpected is happening uh just remember this is different from Robson and Robson the distribution was looked much more different and uh and

irregular but enough mainnet is looking quite healthy

Tim Beiko: nice thanks for thanks for sharing um anyone else have thoughts or anything related to London they wanted to bring you up

Pooja Ranjan: just one small announcement from BBM get her decide uh one of our contributor has created an nft for uh London upgrade uh so we'll be soon making a distribution of that some of the distribution has already been done from the public wallets but uh we are in process of collecting more and thank you everyone

Tim Beiko: thanks um and yeah one one more thing I'll add is um we have a call for infrastructure providers wallets and whatnot next week uh given that a lot of them wanted to wait and see kind of uh 1559 being deployed on mainnet to get some data before they actually launch their products um so next Friday at the same time as all core devs so 1400 UTC uh we'll have a call uh yeah with wallets and other infrastructure providers to discuss um yeah and and we could kind of analyze you know how the tools who have rolled out uh London support are doing

um and and kind of what's missing for for everybody else to add it uh because yeah it's worth noting the the percentage of 1559 native transactions we're seeing on the network is still quite low uh I think my crypto has support by default and melamask has it in kind of a Dev or Beta release um so hopefully yeah in the next couple weeks more and more products Will Will just enable these by default and we'll get kind of a higher uptick in in adoption um yeah so that was pretty much kind of the only thing uh we had on the agenda I

recognize everybody's been very busy these past couple weeks trying to get London out and uh we we've done it successfully so that's that's really good um was there anything else anybody wanted to discuss or bring up okay well then I'm happy to keep it short and give kind of an hour back to everybody um I think maybe just uh oh the sorry what do you mean

Puja uh like about what is coming up next time and if it is it's not like very

urgent uh the last meeting we were discussing on the upgrade next upgrade name and if people are interested and we have time then we can continue um sure I think yeah does anyone have have anything they wanted to share regarding like just naming in the the next couple upgrades um is

Vitalik Buterin: uh are we talking about the merger are we talking about the next non-murage upgrade

it

Danny Ryan: was a debate last week as to what you call a fork the next Fork regardless and if there were any contingencies and you know right if it's only Ice Age is it

named after Glacier

that kind of stuff [Music] um yeah

Tim Beiko: my read on those conversations is it seems um it seems people really want to call if it's just like a Ice Age Fork people like the two name the two word names kind of like mirror Glacier and I think exit had a recommendation for another Glacier we could use um so it seemed like that was kind of the most popular option I think people were split on whether the merge should be called the merge or like have an actual you know more ethereum sounding name um and I think uh there was a conversation about like how do you call upgrades after the merge

which is definitely not something we need to figure out now um and whether it'll be both kind of consensus and execution layer coupled or not um but assuming that they are coupled uh we could just keep using kind of the the consensus nomenclature around I think it's star names if if I'm getting this right star or Galaxy names

Danny Ryan: um yeah yeah it could be uh Altair London you know if if it touches both layers it can have two names I don't know I don't I don't actually want to throw my hat in the ring

because I don't want to debate this one today yeah so there is an async

Tim Beiko: there is an async uh discussion thread there if people want the comment

um and yeah I think the question around like whether the you know you name the the the the the December Fork uh like a two name or one name thing kind of depends on what it is and we're still not ready to make that call so um yeah we really don't need a decision now but uh Micah you have your hand up

uh yeah I just was wanting to get a temperature check assuming that we would like to make just a single parameter change to 1559 so like like after we do some research we had some data are any of the client teams opposed to including that with the um

Glacier push but the Ice Age push back let's assume that there's like just a you know a one character change you know like you have changed the divide by eight two divide by ten because we find that's better after we get data is that acceptable and reasonable like I'm not going to interrupt people too much

Artem Vorotnikov: well Aragon is still looking towards a real feature of work for what it's worth

Martin Holst Swende: uh for me I would prefer to not do a future Fork but it's up to the change if it's

very tiny change sure that I mean yeah it might be

discussed never mind it's

Łukasz Rozmej: okay with something very very small but and that's about it

yeah and

Tim Beiko: I guess Michael like what you're saying you say we found that like yeah the base fee is moving too fast and it would be quicker it would be better to adapt it to like yeah update slower or quicker then this is just a constant that we're changing but it's not something like actually changing how 1559 works right

Micah Zoltu: yeah exactly this would be we've long known that we weren't like the divide by eight and a couple other the parameters we use we're just kind of guesses and we wouldn't know if they actually work until things are in production and so by

November things will be in production long enough we might have some better data and so we might be able to change some of those constants as well I'm definitely not lobbying here for a big change just like if there's something small like just clicking a constant or something we've got a couple I think that are eligible

yeah

Micah Zoltu: I just want to qualify why I say that we don't want to do a feature work right now uh and that is first because we want to focus on the merge and get that right

and get it done and of the um focusing on other issues just for listener so Nicole yeah and and I think yeah

Tim Beiko: just to reiterate from the last call it seemed like everyone was kind of on board to

getting to a spot where we actually have merged test Nets up and running and and then kind of making a call based on how much time that's taken and how much work we anticipate is left uh with the merge um one thing that I think Thomas you know had brought up this idea in the past of leaving the merge test Nets up for like much longer than we leave regular test Nets that might actually give us some time for a small feature Fork um and I regardless of whether or not there is a feature Fork um I think this is some feedback we've gotten from a lot of people regarding London where they would have liked to see kind of a longer uh more time between when it's on the test Nets and when we're basically when

we stop making consensus changes and we're confident in forking the test Nets um then have more time where we can actually iterate the apis before we actually have the main net Fork um so as you know people are on this color where there's still like some tweaks that are being done to some Json RPC calls um and I think for the merge uh I've at least I've gotten the feedback that like um people would would like for for those to kind of happen before it's deployed on mainnet just because whenever something's deployed on my net it tends to be kind of cemented behavior um yeah um and Ansgar has a question about

whether the Virgin Q4 is a realistic possibility

I mean

Ansgar Dietrichs: the reason I was asking is really just that I think just for clarity and kind of planning certainty it's I think it's best to to be as open as possible with these things and to me it is failed for a long time that Q4 seemed to just slip more and more into like very unlikely territory so just just in case at some point we feel like that right

now it's really clear that we won't be able to make it I feel like it would be best to communicate that as early as possible but maybe it's still like in the cards so

yeah so so if there are no updates on this that's fine I'll ask again in two weeks

Tim Beiko: I suspect it'll be a much easier question to answer once we've actually started putting test Nets together and devnets um yeah I don't know if any client dev has better estimated than that but it seems hard to know yeah when it will be ready given we don't even have it implemented in or we I know there's some that's been

implemented in clients with realism but we don't have kind of the latest spec implemented in clients and um and network set up between kind of the consensus and uh and execution teams um yeah I don't know if anyone has a better answer than this I guess not um and I guess yeah one last thing just related to London um I'm gonna try and reach out to the different client teams over the next two

weeks to chat about you know what we can do like what they think went well what they think we could have done better and and try to kind of document that so as we're planning the merge um we ideally have a smoother process than we did with London um I think we did do a lot of things quite well in London but like uh there's definitely like I've heard a lot of people you know complain about various various aspects of it and and things that we could have improved so um I'm gonna try and document that in the next couple weeks and and be able to share it so that hopefully we um yeah we can learn from from everything that happened in London and have the merge go uh even smoother um

yeah and I guess yeah kind of related it probably makes sense for clients to start looking at uh the merge stuff over the next couple weeks so we can start uh on the next call and this the the subsequent ones um kind of discussing the actual technical bits uh around the merge I know mikhail's been there on a previous call to give a high level overview of the EIP and there's still kind of a couple open questions uh that that were tracking you know what not so I think kind of going forward we can probably start going through those and and uh and yeah working on on getting it implemented in clients and uh and running on devnets Danny

you were saying something

I'm just excited cool

Tim Beiko: anything else anybody wanted to discuss

Trent Van Epps: oh yes I guess it's related to the call next week but do we know when yeah we'll have the 1.7.7 release um I don't know how crucial that is for apis but it's I think it's related to fee history unless I'm mistaken

Martin Holst Swende: no we don't sorry yeah I've been I've been away uh the last couple of days um and I'm coordinate with Peter about

that

Trent Van Epps: okay yeah that's fine just wanted to check uh and then I guess I'll just keep going I don't know if you already mentioned it Tim but um next week we'll be having at the same time uh a fourth of the ecosystem coordination calls uh this time it's obviously post London so it's a 1559 assessment for anybody who wants to join that um we'll again be having a lot of the ecosystem providers while it's um API providers uh on the call just to assess how they're implementing stuff now that we have a few weeks or one one and a half weeks it may not uh data to look at and I think Barnaby is also going to present

on some of uh some of his thoughts so far so that'll be next week at 1400 UTC Friday

yep

Tim Beiko: anything else okay well thanks everybody um again great job on London very happy that it went out smoothly um and yes I will see you all in two weeks

thank you all right thank you I'll [Music]

foreign [Music] [Music] foreign [Music]

foreign [Music] [Music] [Applause]

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