Ethereum Cat Herders Breakout Room, 30 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: EIP-1559 Coordination Call (Breakout #11)

Description

EIP-1559 Coordination Call (Breakout #11)

July 30th, 2021

Agenda: https://github.com/ethereum/pm/issues/363

A

All right we're going to get started here. I know we have limited time, so I want to make the most of it. I welcome everybody to this. Fourth 1559 coordination call. uh Fourth, and probably the last ahead of the london fork, which is next week, I'm sure you're, all aware of it. um It's going to land around, I think 12 utc on thursday august 5th, depending on the block time, so I'm sure we're all very excited. I know I am um so I believe it put the agenda in the chat.

A

You can check that out if you want, but this is a very open session. um I think a few of the we have a few wallet teams here. I don't know what it makes sense to start with. um If anybody has any pressing discussion points they want to bring up before we get into some demos, I'm open to hearing that richard you're unmuted. So I said one quick comment: I'm gonna take that as you want to talk go ahead, I mean.

B

It's just a very quick thing. I think it's useful if everyone changes their name in this chat to the project, they're working on sure. If you want to you, don't have to just a suggestion.

A

Oh, I see uh tim is joined tim, I don't know if you want to lead off with any general comments or links to anything. I can share the rpc doc that you put together.

C

Yeah I mean if anyone has has like questions or things I want to bring up. First, we can do those, but otherwise yeah we can. uh We can kind of share some updates. I guess from from our end and start that way,.

A

Yeah go ahead: whatever you've got everything.

C

Oh uh okay, so there's a question uh from santiago. We can start there. uh So what are there's any gas price oracles the gas station get now? Yes now working on 1559, um I don't know if any of them, oh yeah, we have someone from eat gas station on the call two people yeah.

D

Yeah so yeah, I'm andre here, yeah working for a target station, uh so yeah. Indeed yeah we are looking into this uh yeah we've been working on this this month. uh We probably won't make it exactly to the same uh yeah to the to the next week, but yeah pretty much like maybe the week after or something so yeah. The idea is to give some tipping minor tipping estimation for the coming blocks to get included so pretty much what we got so far, but yeah with the tipping change.

C

I'm curious, if you can share this publicly but like how are you approaching like adding like how are you approaching estimating the tips and if you can't share it, uh because that's like your secret sauce, that's fine, but yeah.

D

Yeah, I think it's pretty much what's being shared on what this uh uh page. I can't remember this uh yeah. It's basically like uh pretty close to the pros uh pers approach.

D

We we we, we have uh like checking the last 100 200 blocks uh and then trying to find like the uh the quantile out of it uh for the tipping uh field and yeah, uh given certain quantile, we we will share like forgiven like uh standard or fast or uh yeah, ultra fast line for the next block for our transaction to get included in the block these details. We we still need, like two yeah to tweak some stuff and yeah those details.

D

The implementation detail we most likely share some of it so yeah as we get the thing like more clear and more like uh in shape, then yeah. We have more resources to share.

C

Yeah, I think one thing I think it was barnaby who brought this up before, but like that, potentially looking at, like a shorter block horizon, makes more sense after 1559 because of how quickly the base fee moves. So I'm not sure if that's something you're able to back test, but um I think that would be really interesting like to see you know. Do you get better estimations?

C

If you look at like 10 versus 50 versus 100 versus even like something like five, because um because the base you can basically double, I think in like six blocks um and and and that means like if, if we're in a spot, where it's doubling really quickly or going up pretty quickly, the tips will be going up quite fast, obviously, and you'd want to adapt quickly to that, whereas, like if you know, if that demand spike is over, the tips will probably go back down quickly um and again.

C

You'd want to with that quicker, so yeah it yeah. I mean it'll, be interesting to see the actual like live data for that, but I think as you're, maybe working on like a v2 or an upgrade to it. Like comparing different history ranges and trying to see what's like the best estimator could be really interesting.

D

Completely yeah completely yeah, thanks for sharing.

C

um Chris, I see you have your head down.

E

Yeah, um I'm with blocknative, and uh we we're we've updated our gas platform to support 1559. It's also triggering on the 1559 fork block, so that'll that'll go live when when 1559 goes live and it basically adds to our api.

E

You know a max a fee cap recommendation as well as a tip recommendation. It also reports on the base fee, just if you want to get it through that source. Instead of asking the block and initially it's a little bit heuristic based, um but then very quickly, it's going to switch to our full models. We just need to get actual data on those models and the the behavior that we saw for 1559 on the test nets really didn't give us anything that we could build a model off of so it just wasn't used enough.

E

But that's the plan for block natives gas platform support.

E

F

E

G

F

Anything on boxton for that available already.

E

um Our guest platform only runs on uh on mainnet. We don't. We don't really provide an api for the for the test nets for that, but we do what we haven't done yet is show what the api changes are for that so hopefully, over the weekend, we'll have that we're just doing some testing now and I want to make sure the api is reasonably solid. The payload changes are reasonably solid before we publish that, but hopefully by monday, that'll be available for anyone to see the api not to actually get the.

E

C

Cool anyone else have uh comments or just thoughts on oracles. They wanted to share before we move on.

A

H

Oh, go ahead. Go ahead! Yes, sorry! So I also have some experimental, but yeah that's been shared. The link has been I see now I see and the link has been shared. So I have so uh there's this uh fee history, api that- uh and I I I wrote some um some some javascript uh oracle using this, this history, api, that's also supposed to be like capable, so it's also theoretically capable of making suggestions for like more urgent or or less urgent and more economical uh fee options and everything but uh yeah.

H

So I believe we really need the main beta to to test these things and yeah, but um at once minute launches uh I'd, be uh very happy to like see some comments or issues opened on that repository. If anyone uh wants to try this this, this fee oracle.

C

Thanks yeah thanks for sharing um and yeah, it feels like a lot of this stuff. The data on mainnet will be kind of a much better indicator just because all the test nets don't have sustained like more than 50 uh full blocks usage.

E

Yeah cool anything else on the oracles.

A

I was just going to surface if anybody from gas now or tai, chi or spark pool is here, uh and you wanted to ask any questions um now would be a good time.

A

uh No, no pressure, if you don't have anything but.

I

Yeah, we do not have anything we just. uh We have finished all the code uh uh revising and the review, so we are just waiting for lunch and currently no uh from our site.

I

A

All right, yeah, let me double check the agenda um again. This is open so like. If, if you guys just have a question, you want to bring something up just go ahead: we don't really have to rely on the agenda strictly. um Are there any wallets here? Who would be bold enough to share any screens or demos of what they have so far? I know we have metamask and status here. I don't mean to put you on the spot, but it would be really really amazing if we could see anything from you guys.

J

uh I'll go first on our end, uh our kind of fee estimation stuff is expected to be ready on monday. uh So that's not ready right now um and uh yeah as soon as that is ready. I will share a share a link to um the branch, along with any build instructions for anybody who wants that uh information, so they can jump in and play around with it.

J

The kind of interface side of things is done, it's just not plugging into anything, and so that's no different to what we shared a few weeks ago uh inside the figma files. So all of that stuff is pretty much exactly the same.

K

Gotcha thanks uh kevin from metamask. Here uh we are live on private beta uh on our mobile apps, uh which is ios and android with our desktop extension uh version. We should be live next week, sometime uh on private beta as well, and when the london hard fork happens, we'll we'll go to uh prague soon.

A

After I was reminded, we have rainbow and my crypto here so, if either of you would like to share some thoughts or a quick update, that would be.

A

L

Hey this is jen from rainbow. uh We decided to hold off and wait until we get more data to be able to figure out what sort of decisions we want to make for our users. Just because our goal is kind of to limit the range that we're going to be exposing to users, because there will be kind of like a vast range going up, and so we've kind of mapped out a few different scenarios and situations and are still debating um kind of what our ui.

L

We want to show essentially kind of uh yeah kind of trying to limit the multiple on the base fee um and being smarter about the the tip instead, um so that we don't have like this long tail or this huge range um of like. Oh, your, your gas price could be some large amount that might be uh way bigger than what it ends up being in practice.

A

Okay, yeah- and I think um tim has mentioned this before it's not unreasonable- to wait and see how it plays out a little bit before deciding how to present things um or making changes in your ui. So that's good! um Sorry, I keep I I I keep. I can only see a few names on this screen. Some apologies. If I keep missing wallets who are in attendance, but if there's anybody else who wants to say something just just go ahead.

F

I would just say briefly: argent we're doing the same thing um as uh rainbow so we're holding off for now. um I think we need to be a bit confident what kind of data sources we can use for the oracles um and it sounds like most of them- are kind of fine tuning things and we'll be probably for a couple of days, at least afterwards. Anyway, um where you get to get it in uh with the ux that we already have.

F

We believe it suits the same model, um but it's probably gonna be I'd, say you know at least a week or so afterwards, a week or so from here or from the uh after yeah. I think until we can start looking at it properly and we've got gas oracles with good estimation models, there's not much. We can do um so. I think we'll come back to it, probably about a week after um london's gone, live and then start digging into it and seeing what technical changes we can make.

A

Great so it sounds like it also might be helpful to have another call in two weeks just to share everybody's learnings, but we'll plan that, after the fork.

A

uh Leaky, do you want to talk at all about? I see there's some discussion going on about decimal to hex. um Does anybody want to bring that up verbally? Just so everybody's aware of it yeah.

M

There's a change basically in the fiesta, it's just for the history, so not for submitting um and it's a bit a sad situation because for the clients it's a bit hard because you don't really know what to use. So, if you use the wrong one, you get an error, and so you need to check the client version and, depending on your model, that's a bit strange. I hope we can accept both.

M

So the current release um 1106 still uses decimal and the master currently, which then will be released to 1107 users hexadecimal, that's better, actually, better, using hexadecimal, it's more streamlined, because hexadecimal is used for blocks in other places, but the problem is the transition. Basically, because as a wallet, what do you actually then use? You know what I mean: uh sorry, which.

H

Values are being changed, so actually one of them is the input value and the other is so so. The block count, input value and the oldest block return value are both changed from decimal to hex now so yeah, and this is tricky because uh one on one side, the javascript code could accept the return value both in both formats but but then also, the client has to accept the input parameter.

H

The block count, input parameter in both formats, which is possible, but it's also not how it's specified now so yeah, I'm not sure but uh yeah, maybe maybe that's that's the best way to go.

M

I think the main problem is basically the input values um because, like I can I can as a client, I can basically check um the value I get. um No, I mean the output values. I can check basically what value I get and then decide on that. But the problem is if I need to send a request and not really know what to send that's a bit of a sad situation so.

A

G

N

M

Both just in the transition period, basically um for for a while, we can also switch that off at some point. um That would be nice because otherwise it's quite problematic.

H

Yeah but right now so right now the the currently released version that only accept decimal. So then, the the proposed script should also like use a decimal value. So maybe that sounds like we might just get stuck with that, but uh yeah. Also if open ethereum and b2 already use hacks and when I think wrote that just now, then it's one big good either.

H

So that's the problem that uh right now we have a release version of get that only accepts decimal, and then we have other clients that that accept hacks or I don't know- maybe do they accept both.

O

No, they don't at least open ethereum. When I tested it, it was breaking.

H

um So they only accept hexadecimal. Is that right, yeah uh-huh? So it's not so easy yeah. So then it's badly the race, unfortunately yeah, and it was probably my mistake and I'm sorry about it, but yeah. So I I then, then I don't think we should release this javascript code in uh in a way that it uh uses a decimal value in the call, because I mean for the free history, input value the block count, because uh that only that will only work in guess then and won't work in the other clients.

H

B

Are you referring to the json ap, the so the json rpc api? Are you saying that the inputs to geth, or you mean the results.

H

The input now now, I'm I'm talking about the input, so so so the so the api. I'm I'm thinking about how about like, from the north side, some from the get a implementation site. So by input I mean the fee history, apis input, value, the block count and, and that's now yeah. So the currently released version of get accepts. The decimal value there and the other clients accept the hex value and the master branch of get only or is already updated to hex. So maybe.

B

I think most clients accept a quantity which is just a non-zero prefix.

O

Hex right they know the the standard is everything to be hex and, and then uh yeah yeah, as the quantity values are right. It's like yeah, the quantity is a hex value yeah. So so to me, the issue with an ethereum is that uh really, if, if seven is not released, I might have to as kef is the most popular client.

O

I might have to uh recreate a new market university with netherion that will support the the six and then release again when seven is out, um because I kind of do the uh this guessing stuff like in javascript, because it's all tight. um So ideally, if seven was out before that will be.

O

P

Is there a plan to release 10-7 before the hard fork, or would this be after the hard.

A

Work, I believe after, but somebody more somebody closer to the guest team can maybe respond.

H

Actually, I don't know yet.

A

Okay, I will reach out to the rest of the team and find that out.

H

Yeah but uh yeah I I will try to find it out too, but yeah. I just don't know it right now, but uh yeah. It would.

M

H

It would be from this for this issue. It would be nice if we could, if we could do do a fix release, at least because yeah I don't think so. I don't think that, uh like uh yeah, so so accepting both uh both formats in get that just won't solve this situation, because the situation is already there and if we can do a release, then we can just change it to hex and the, and then it will be hex everywhere and that's like the best outcome, but uh yeah.

H

I think the only way to fix this is to like do do do a at least a hotfix release for this issue and yeah. I will try to talk to peter and the guys, and maybe maybe we can do it.

H

Or maybe they have this plan too yeah? I don't know.

O

I have been testing on on on 10 7 and to me works perfectly, and hence I've released ethereum thinking. That was gonna happen, but yeah. So if you just let us know or just in the in in the score chart, you know so that I can plan ahead and I can.

O

I really think that being compatible with gas is, you know at least will touch more more clients than the other way.

G

uh Question for rigma related to this um is it possible that the uh get feed data um metal from ethers uh does not accept any parameters right now,.

B

So right now I don't use feed data at all for ethers. I'm still using micah's suggested hard-coded one-way got it got it, um but what I plan to do in the future is that there's a fee data structure, um and so that's also rolling up like so in v6. There will be, there will no longer be a provider.get gas price that'll be rolled into fee data as well.

B

So if you look at the result of fee data, you get inside that the gas price, if it exists, the max fee uh per gas and the max priority fee per gas if those exist. So in the future.

B

At some point, once like the the dust is settled, and we know exactly what what um v history is going to return, there'll be something else in there for that, but I'm also planning to make that object, an actual object that has, for example, a method so that you could, for example, have get priority fee uh per gas like get priority fee as a method that you can then pass in, and that's still up in the air, whether it's going to be a number that represents a number of seconds you're targeting or whether it represents you know uh fast, slow, medium, cheap, something like that, um but yeah for now, then that exists.

B

That's just kind of like future plans. For now it's going to there will there will be a a max priority fee per gas, which is kind of like the best estimate we have, which is currently hard coded to one way, but soon it'll start pulling fee data and making some sort of educated guess. Based on that. If that makes sense, yeah perfect sounds good. Thank you for clarifying.

A

Anything else on this topic.

B

Actually that does bring up. One quick question is that cert, currently sufficient, is the previous advice of hard way. Still, I would say two is so one so.

C

The the background here um and I can share barnabas posts uh for people who want to read it um uncle mev is in my most red things. um One going covers the opportunity cost of your block being uncold. um If you just look at like transaction fees, um but the the challenge is that since uh 1559 was developed, mvv is now a big thing, uh so the opportunity cost of being on called is not only you lose the transaction fee revenue and the block.

C

You know the block reward uh like the delta between like an uncle reward and the block reward, but you possibly lose kind of your. Your mev bundle. That's included in your block right. So what you want is you want the tip to basically offset that potential loss as well, um and that gets much trickier trickier for two reasons.

C

One is mev: rewards are very variable right, they're not evenly distributed, um and two is you don't actually want to like compensate for a hundred percent of possible mev right like when there's a 100 mev bundle, it's probably fine for a user to wait a block to not like you know over tip that. um So last time I checked like a two way default gives you basically uh compensates for roughly 50 of like historical med blocks. So that means that and and mev blocks are only 60 of blocks right now.

C

So that means that, um if you, if you compensate for for half of those, it's like there's 40 percent of blocks with lme v and then you're good in 38 of blocks so like roughly 70 percent of the time to go, should be enough, and I think three way was enough to compensate something like 80 or 90 of mev opportunities right now, um and that probably means something like you know: 90 plus percent of blocks, so um two to three probably makes sense, depending on like how aggressive you want to be um compared to you know the the prevailing mev numbers um and the thing I shared from barter bay has like kind of the formula that you you can use to plug in that um I don't think.

C

Does it link the flashbots dashboard? uh It does not. um So the other thing that yeah that I've used is there's like this dashboard. If you just want to like eyeball it, there's this dashboard.flashbots.net website um and that'll actually show you historical mev.

C

um So that's what I kind of use- and I I just like very roughly eyeballed it, um and you know, at the end of the day, you're kind of debating between like one to three ways. So it's not like it has to be a perfect estimation, but yeah unless, unless mbv changes a lot, I think those numbers make sense I'll.

B

Probably follow frederick's example, then or frederick. I don't know how to pronounce the name. Sorry uh example of using three for now and then we can dial back later.

C

Yeah, I think yeah one is likely to be too low because it won't take mev into account at all. um And two is you know, uh I know if you, if you had like the concept of like a slow transaction, two is probably like a good uh good value. Three yeah.

L

I had a question. I had a question for fred, frederick. Sorry, if I'm also mispronouncing your name from my crypto, so you mentioned in the chat that you default to three way for the priority fee up to a given base fee, and then you start using the fee history. I was wondering like how do you determine when that switch happens? Like is the bait the up to a given base fee? Is that hard-coded or is it based on some like trajectory or or.

N

Yeah, you didn't butcher my name. That was all good. uh Basically, we we've set some hopefully same defaults, uh so basically hard-coding it, but we are. We will be monitoring it and like changing them on the fly. If, um if it turns out that we are like completely wrong, um but we've we've just tried to to come up with something that that would hopefully make sense.

L

Okay, cool. Thank you.

N

All right, uh if anyone wants to read it, I put it in the chat I can post. It again are like definitely work in progress, but our current fee estimation.

N

A

All right, I know tim had requested that we add um the discussion about requiring uh sorry. I lost the agenda again requiring gas price uh and the expected deprecation. Let me link to the discussion tim if you want to touch on that.

C

Sure so, um right now guest and I think all other clients um currently return a gas price value for 1559 transactions in json rpc. So to be clear at the protocol level, 1559 transactions do not have a guess price field, but because a lot of tooling depends on it, um so guest originally kept it in the json rpc and I think other clients have have added it so far um and basically uh what it does is before a transaction is mined.

C

We can't actually know its effective gas price on the network because it depends on the base fee so before a transaction in its mind uh that gas price field in the transaction will return the max prior, the max fee, um so the maximum the transaction could ever pay um and then, after the transaction in mind, it'll return the effective, uh the effective gas price, which is uh basically the base fee, plus the priority fee that was paid um so the the goal in adding that was, you know to kind of act as a sort of backstop and to minimize uh breakage in the ecosystem, um but it's obviously not ideal for a few reasons, like one, this field doesn't actually exist in the transaction.

C

Two, it's a bit sketchy that the field changes based on the the status of the transaction, um so on all core devs. Last week we were talking about you know. What do we actually do about this? When do we possibly deprecate it? And what not, um and one idea that we have was that we would deprecated the first release after the next hard fork.

C

So not london, um but we're gonna need to have another hard fork in december, even if just to push back the difficulty bomb so that that hard fork would still contain the gas price field for fifteen to nine transactions. Then the first release after that you kind of deprecate it. So that means, if you wanna stay on the old kind of release you can. uh You can do so basically up to the too hard fortune now. um So I was curious. I guess, to get all of your thoughts and rick has his.

B

Hand up right, so I definitely want it in place much longer than that. The second that's removed, every version of ethers prior to 5.4 will fail if you like, for a lot of things, if you just try getting a transaction, just get transaction will fail if there's not a gas price there, because the block, like the the response, is validated to make sure all the fields exist and are correct things, and that was a required field back then, so I definitely want it longer than just the next hard fork.

B

So I mean, if you put a dummy value like if you put negative one in there, I actually it'll work. It'll be fine, it's just it has to be there okay, so it would work.

C

If, okay, if it returned like, would.

B

It work if it returned like null or it has to be like an integer value. It has to be yeah, I'm pretty sure yeah. It checks um that was one of the changes in v. 5.4 was that it used to be big number. Now it's a allow null big number. Okay,.

C

And what what do you think would be like a reasonable deprecation schedule to like remove it completely.

B

I mean in my mind, if you're changing like the json rpc, I mean this is also probably discussion have in the I think, you're part of the other um jason rpc steering api calls yeah yeah, I mean that's almost something I would expect. This is one of the reasons.

B

I guess why we also need a version field or something inside, um uh because you can imagine if you went to like you know, uh json like um right now you go to your url, slash whatever and you just post something if it was your url slash v2. If there was some sort of versioning on the api, because right the problem is right now, you're, there's there's no way to detect backwards that the backwards compatibility is going to be impacted.

B

So I mean in my mind, until there was some sort of versioning it should still be present. Okay, like removing fields, is backwards breaking, whereas adding fields is kind of safe. This is one of the first times I can think of where there's been an issue. I can't remember for the the state route uh stat when we added status, we did some state route, but I think state route still exists right yep, so I mean that's the important thing because it still exists and is like a thing so I mean I guess in my mind.

B

I don't really want to see this go away until there's some sort of version field, because that way you can, if you start receiving json or pc requests that are not versioned. If you're not uh appending a slash, v1 v2 on the end, you know this thing is broken at least return them something gas price related yeah. But again I was looking the other day.

B

There's still, I think about 50 of users that are still on, like you know, antiquated versions of ethers, and so it will break a bunch of, and it's also very spotty, like you'll see like version 4.4.47 has a ton of downloads, but 4.4.48 doesn't or 4.0.48 doesn't so there's. Obviously, a lot of these are probably deep, nested dependencies, in other things,.

C

Got it yeah yeah? um What uh yeah.

O

Oh go ahead, I'll just say: oh yeah,.

C

Yeah, I was gonna say if say we introduced something like version json rpc around the merge right like we said you know like the json r, because there won't be a ton of json rpc changes around the merge, but there there will be and like the the block format will probably not change but like some fields are kind of being set to zero forever and whatnot like it feels like. Logically, you know we.

C

There is kind of this big step change in terms of functionality. There um do you think that would be kind of a reasonable time and you know probably say like q1 next year. If we have a new versioning system.

B

Well, that's what.

C

B

Yeah like well, I think, yeah, one of the advantages of having a versioning system is so, for example, if currently, your url is one two: seven: zero zero one colon eight five, four five: um if that's the url, then the geth node should just still continue returning a bunch of legacy values in these things.

B

You know slash v1, then you have the opportunity to to exactly like you can drop state route. You just don't you don't even need to include it.

B

You can just throw the window, um you can then drop gas price and then at some point you know if at least then, what I'm requesting without the slash v1, you can feed me back an error, saying unsupported geth, no longer supports version, 0 or legacy version apis at least then there's a an error that the user is going to see the users that you know when they're, when their application blows up, because some deep dependency is using an old version of ethers and it can no longer get the the gas price.

B

At least they see a human readable thing, seeing like the back end. You're connecting to is uh flaky yeah upgrade got.

C

It and in the meantime, if we wanted to kind of self-deprecate it right like, if you start returning -1, then it means nobody can actually rely on that field. But you potentially don't break things.

B

Right I mean for me, minus one is fine, I can imagine a lot of snares or minus one is going.

C

B

Cost people money because now they're they might be- they might be taking that and adjusting the fee for something and now they're subtracting, subtracting, so they're, actually adding.

C

B

Value so maybe zero is a better. Zero might be the least worst option, um so yeah yep.

C

Yeah, I can see minus one or even the worst case is like if it creates some sort of underflow and right.

N

C

You're, adding like all your balance as a max priority fee or something.

G

Exactly exactly.

C

That would not be good yeah, um yeah, okay yeah! This is really useful. So I'll share that back uh on on the jsonrbc uh thread. um Does anyone else have comments on.

C

That yeah, let's hope nobody divides by zero. um I mean at least at that point. It should fail right and not send your entire balance.

B

Divide by zero either gives you n a n or or if I actually don't know it might, give you negative if for a negative number, but um yeah divided by zero, is going to be bad.

C

um Cool- uh and I guess yeah talking about jason rbc, I think trent you mentioned this just at the beginning, but like yeah, we we put together a a quick document that specifies all of the changes uh coming in uh in london related to json rpc. So if you just want to have one place to look, this is pretty final um going forward.

C

Now that we have a separate repo for json, rpc and whatnot, we'll probably be able to use branches and what not to to track those changes, but we just didn't have those in place for london. So um there is this. This hack, nd dock, which uh which kind of just yeah, explains like for every type of field. You know what's changing uh for 1569 transactions and and mentions obviously fee history being the new api, that's been added.

C

um Aside from that, there's another thing about the road map: I'm not sure what the question was.

C

um I think you added that yeah, I'm not sure.

A

Let me see it was, I think it was about um planning for shanghai or what's next, just getting thoughts on that.

C

Yeah, um I'm not sure this is like the most valuable thing, so I feel like if people have other anything else they want to discuss. We should probably get through that first.

C

C

um If not, there is something else, that's even more valuable, so um the ethereum.org website wants to try to highlight which wallets support 1559, which ones don't um so they're kind of looking for a list of wallets that plan on supporting it around around launch. um If that's the case, if you can just leave a quick comment on the issue and say you know where wallet x and we will support it um yeah.

C

That would be pretty good, because then users can come and know kind of at a glance if their wallet supports 1559 um yeah. So if people just want to leave a quick issue there, I could comment on the issue there.

C

C

Yeah for the roadmap stuff, I mean the threat is linked in the issue and I think it's probably not for spending time on this synchronously, but oh uh mike, uh frederick, uh just on the literally the issue. I just linked uh above your your zoom comment. uh So the ethereum.org issue, um if you, if you could just say you know, we support it from my crypto, um that's good enough and if we can get like a couple of those um yeah it'll be at least a good start, and then it's much easier.

C

If there's like you know four or five already there we, you know you can just tell people to like submit a pr to add their their wallet in the future. But just so we can start with a a handful of wallets.

C

C

Yeah and I guess yeah for the road mapping stuff just some context like we were discussing this on our core devs. Basically, uh how should we go about naming upgrades um how whether there's value in trying to stick to a very strict schedule or trying to like, uh I guess, yeah.

C

This is probably the best question to ask here um when we're planning the upgrades um from an infrastructure or just like tooling perspective is the biggest pain point actually adding support to the upgrade which in this case, feels like it is, but I'd be curious, just like more generally, if you look back at like berlin or istanbul or whatnot or is the biggest pain point kind of the timing of the upgrade, because some people think we should kind of have upgrades happen at these times, and you know like one upgrade in june, one upgrade in in december, whatever no matter.

C

What, um and this way we can provide kind of more predictability in terms of like the the tooling that's dependent on ethereum and whatnot and there's the other point of view. That's basically, if you're doing an upgrade most of the work is actually adding support for the eip. So we should just you know: ship say london whenever 1559 is ready and make sure we give plenty of time to adapt um so yeah.

C

I'm curious, if, like the predictability of the time, is more important for anyone here than um the kind of focusing on the biggest or most complex thing in the upgrade and and potentially delaying the upgrade over that um yeah.

C

And uh yeah: this is the east magician's thread. If people have thoughts, they want to share on on this later.

A

It's definitely a big discussion, so no pressure, if uh you wanna yeah, provide your thoughts. Async yeah.

K

C

Cool, um I think, that's all we had on the agendas that.

A

Yeah, I think we covered everything, uh including a couple other things which weren't in the agenda, which is great. um Does anybody else have other discussion points um or lingering questions that they wanted to bring up.

Q

Hi, uh I'm sid from coinbase. I work on coinbase wallet. uh We have a couple of colleagues here as well. uh Thanks for organizing this call super helpful, uh I you know we're listening in. We noticed that we are also amongst the wallets that are still working out our plans.

Q

We want a, I think, it's a combination of, if working through what we think the best ux might be, but also having a bit of reluctance in in the sense that when the fork happens, we want to see what the actual data and the gas price or oracles are staying and so we're holding off, maybe for a couple of weeks post launch- and it sounds like there's a few other wallets in that boat as well.

Q

uh We wanted your feedback on a little bit of downside, planning and risk planning. What uh do you do? You feel that there are any uh red flags here around something could go wrong and cause massive disruption to our clients, uh to order our users or anything that we should watch out for from the do-nothing path for the first week or two, where all of our users are either getting stuck transactions non-stop or they're, massively overpaying.

Q

C

So I mean there's two different things right. One is just like the hard fork itself and just like, like any hard fork, you know if I wear coinbase, I would like freeze deposits. You know an hour before and, like you know, monitor the situation and- and you know, wait and see what uh you know that everything is running smoothly and and then turn deposits back on. And obviously, if you see a consensus issue like the thing with consensus, issues is like sometimes it'll take hours or days or what not uh to to happen.

C

So I'm sure you all have processes for like freezing everything if, if, if you detect one um so at a high level like yeah, I just say like monitor the hard fork closely. If you see anything, weird you're, better off freezing things and and waiting for uh like for more information.

Q

um Yeah, I think yeah just just to clarify you know we have obviously the main exchange and then we have coinbase wallet the non-custodial wallet. Oh.

C

Q

Only about the non-custodial wallet app.

C

Okay, okay, okay, um yeah, so I think then, with regards you know like if you keep using legacy transactions, the experience would all be worse than it is today. Right like the and and all of the gas price oracles, I think, will still keep reporting gas price estimates based on like the historical data and blocks and whatnot. So you will like you, will still be able to like submit legacy transactions.

C

What happens is like you know when we say, like your users, will end up overpaying they're overpaying today, right like they just they will not get the benefit of 59, um but they shouldn't overpay by more than they already are um yeah just because you can still kind of estimate based on the data that was included in historical blocks and you're, basically back to like a first price auction, um and the only difference is like when you have a 1559 transaction and you set your max fee.

C

Whatever you, the difference between the base fee, your tip and the max feed goes back to your user, whereas if you're just using legacy transaction that all goes to the miner. um So you know I yeah. It's not the end of the world. If you want to wait a couple weeks, um it also doesn't there's some comments in the chats about like if everybody waits then like, we don't get good data.

C

That's not necessarily true, because what you do get data on is uh the blocky utilization ratio and how frequent stuff, like spikes, are and whatnot. So you you yeah, like we were talking at the very beginning of this call like how far should you look back in terms of blocks to estimate you know the the base fee? uh Sorry, the the priority fee and whatnot like you'll, get all of that data. um Even if nobody was using 1559.

C

You would kind of see that, like you know, we get spikes and we see that the the we see that the the basically goes up. You know on average, every like hour or every day, and these spikes tend to last an average of like three blocks or five blocks, um and that's all pretty useful and you'll still be able to look at blocks. You know some people.

C

There is an economic incentive to use 1559, so some people will use it and you can still look at blocks and look like you know: what's the what's, the like lowest quartile, of uh a priority fees that miners accept and if you just want to like you know, use that as a reference that that'll be possible um yeah. So I think yeah. I I think you know it's not the end of the world.

C

If you wait um it, it definitely doesn't like block the rest of the ecosystem um and the status you're, basically kind of stuck at the status quo um yeah. Unless I'm I'm missing something. But that's that's pretty much. How I understand it that that's really helpful. Thank you. So much yeah.

C

Yeah and barnabas, you have a comment in the chat I don't know do you want to uh share some thoughts as well.

R

I mean yeah briefly like if you don't want users to overpay and you want to keep using today's infrastructure, but you still think 1559 is pretty nice.

R

You could just just set the max feed parameter to whatever you were going to set the gas price of the user and then tune down the priority fee to two or three.

R

So what you're doing, if you're, not using one five, five nine is your legacy transaction is just converted like the gas price is taken for the max fee and for the priority fee, so you're not getting the benefit, so you could just yeah whatever gas price you are going to set just set that as max fee and use a very small priority fee, something like two or three and most likely I mean you will never pay more than the max fee, which is the gas price anyways and most likely you would pay less as one.

C

Any other questions.

K

I have a question about timing. I just want to confirm, I think, uh mentioned earlier, that uh the hard fork will happen on 12 utc on the fifth. Is that correct.

C

Yeah, so it's it's always tricky to estimate those the closer we get to it, the better. The estimates get just because of the proof of work drift right, uh but right now it's scheduled, for, um uh I think, less than 12 utc more like 10 utc, 10 pm, utc um yeah. It's actually been. It's actually moved a bit in the past day. So, um oh, it's! It's moved that much. It moved by two hours.

A

Yeah in the future.

C

Okay, I thought you said.

A

If they said pm, I was like whoa, that's quite.

C

Oh sorry, oh yeah! No, sorry, sorry, yeah yeah! um Oh actually, wait! No! That's still! 12. um no you're right! It's still scheduled for 12 utc um schedule, yeah scheduled, um but yeah definitely check this like within 24 hours of the fourth. Usually you have a pretty good, like estimate down to the hour.

K

Got it uh this is helpful. Thank you.

C

Yeah and there's two uh ethernodes also has a countdown um so like and and they I think they kind of vary in which data they look at um because they tend to be off by like one or two hours each so like. If you want to. If you want a good window, you can basically set. You know both the ethernet and the ether scan one, and you have like a high probability that it's between those.

A

Two, I'm just seeing a comment from matt about the test net stuff. So we did spam the test nuts, but um so like definitely, the mechanism to change the base fee was was tested, but it wasn't consistent, which is what we'll see on mainnet, which is like consistent usage and then spikes. On top of that.

A

And not not run by a a spam bot. um Organic demand is always going to be a little different.

A

Sorry, I think that's everything and we're right at time. We filled up the hour with delightful discussion. Thank you, everybody for coming. um I really appreciate it and I think we turned up some some points which uh I don't think we had seen before. So this has been really helpful. um This will be uploaded where the other videos are. I think, that's the ethereum foundation youtube channel and we will also have notes for it as well for you to share with your colleagues who weren't able to attend um so yeah.

A

The the last thing I think tim mentioned a while ago is, if you are a wallet that is supporting or when you do just leave a comment on the ethereum.org repo mentioning that you support this just so, users are aware of their options and then um the other thing was oh, it sounds like it would be helpful to have a call in a few weeks after london, when we can have some data, um maybe have a presentation from barnabas.

A

I'm sure he's got all sorts of great ideas about how to present this stuff and um we'll have a much better idea of how this is actually working out in the wild and get everybody to share their uh their progress.

A

And then there's the other things of the discussion on fee history. And I think that was maybe maybe that was the only thing.

C

Tim was there anything else, uh yeah, there's that well, the json, rpc gas price stuff so I'll make sure to update that thread. uh Based on your comment, rick.

A

Cool yeah, thank you so much everybody for coming um and if I emailed you that means I have you on a list and if you want to add any of your other colleagues, just let me know and uh we'll make sure to invite them in the future cool cheers. Everybody see ya.

K

C