Post London EIP-1559 Assessment (Breakout #12)

okay so thanks everyone for joining this post london infrastructure call um yeah so i guess the goal here is mostly just to discuss kind of you know what different people have seen uh since london has gone live um how you know we can adjust i know that like there's been a lot of conversations uh happening around like you know how do we handle the new the new free mechanism and uh yeah how how do we make sure that uh you know we're providing like a good user experience to people um so um uh i guess yeah uh the first hand the agenda was like an overview of the upgrade i mean to just do this quickly at least on the consensus level side everything worked kind of as expected so you know we don't expect to do any changes to kind of the core protocol shortly regarding the fee market um we didn't see anything kind of go wrong or go different than what we would have expected uh from the test nets and from the the just the simulations that we've done in the past um yeah i i guess um i'm curious to hear just like from others on this call what they've seen and uh it can be useful if you know if you share something to just kind of share what what product or at the very least what type of product you're working on i think you know wallets have had a lot of uh interesting experiences but yeah just curious to hear kind of for everybody what what they've seen and and if there's any issues that they think are important that we should we should bring up uh i guess i'll go first um my name is austin bunsen i'm the co-founder of quicknote we provide blockchain infrastructure to companies we're running open ethereum and this is probably very very unrelated to the london hard fork but maybe just in case i'm going to mention it we are noticing that um we're seeing a lot of dropped piers after upgrading to the version of open ethereum that supports london again probably unrelated but just throwing it out there in case it is pertinent okay thanks that's good to know i'm not sure what's this so i know open ethereum was being deprecated after basically after london um i assume like they still have people looking at the the repo uh help um yeah so uh is there is there a specific issue actually that you've opened or anything yet or that you've seen on the repo no yeah we've been tweaking with configs and trying to figure it out okay um yeah if if you do not figure it out i think yeah if you can share just the issue like in the all core devs chat once you have that that's really helpful um i know a lot of the basically a lot of the open ethereum team has migrated to aragon so the devs are still kind of working in the ecosystem and that's probably something they should look at if uh if it needs to be fixed thank you um if no one has like anything burning uh i saw barnabay uh you were on the agenda as having some data to present about the upgrade so far is that right yes i've got a couple of slides sure yeah you want to go ahead and share that sure screen can you see yes yep all right cool uh yeah disclaimer it's been only a week so it's really early impressions and i did not get as much time also as i wanted to to dig into much more data but uh yeah i hope these impressions kind of maybe help frame uh some of the discussions after so as a kind of look back to the previous conversation we've had on the podcast i said i would be looking at three things the gas used kind of the dynamics to see when are we in full blocks and maybe first price auctions kind of come back on the table and the second thing is base fee what does the let's say trace of the basically look like is is it smooth is it more like oscillatory and then the last part is the oracles and are they doing the job well enough like are they tuned properly so i'll try to say a couple of things on each point on the gas used i focused here on the longest trick that i found as of yesterday i i don't know if another nft drop happened in the meantime but the longest streak of foolish blocks i found was around 35 blocks so it took the base fee from yeah low 30s to something like over 1 500 gray and i'm plotting below here the priority fees of one five five nine transactions that were included uh during that ramp up namely i'm plotting the inter quantity range so like the 25th percentile and the 75th percentile of priority fees i guess if we expected to see like these first price auctions on the priority fee we would expect some kind of ramp up that would be a bit smoother than it is like here the priority fees really get super high very quickly and my impression is that uh what happened is legacy transactions are still very much dominating on the network and at this point they were at the time and so these transactions are sent with a high gas price because we cast them into these 1559 formats with like full priority fees um their priority fees are high and so in turn the one five five nine transactions the kind of copy via the oracle and they also send high priority fees i see that mika has the hand raised should i yeah do you want to go ahead i'm just wondering so you have a couple of dips on that top graph there are those artifacts or was there actually block space available yeah at some point there were like a less than full block so i i kind of took this trick to be yeah if you if you don't take like i can't really take 100 because there's always a little bit of space so i took it as like uh the moving average was above something like 95 so there was indeed like maybe one block where the gas use was a bit lower than others yes okay so it wasn't like a an empty block or something that could have been an artifact of just how mining works like it was partially full meaning the miner was including transactions and everything correct yeah definitely not empty because this this is like the proper uh size so something like 21 million gas i guess okay yeah i've published this dashboard on the doing analytics so if you want to take a closer look i can send the links after right yeah so maybe we do have fps but at the moment i guess it's a bit early to to conclude that okay this is what the system will look like when you have a series of full blocks i think a lot of what we'll see might be artifacts of having more legacy transactions in the system about base fees so people have noticed that it seems to oscillate quite a bit like it's not really smooth it goes up down up down sometimes you have a full block then followed by another empty block is that normal so we know that there's definitely like a let's say a region of the system where things can happen that make basically look like this my take on this at the moment and this is more of a reason intuition than actual data analysis is that legacy transactions that are sent by users they would set the gas price to something that's maybe higher than base fee but which remains kind of close to base fee because the oracles they use they gave they give them kind of okay this is the ambient uh current gas price and so this is what you should set your parameter to so you send a transaction which is close to base v which means that includable transactions they actually tend to clump around the current basically small upward deviations of base fee then price out a lot of transactions and if you have then basically decreasing a little you have suddenly like a lot of transactions which are again includable so you could observe like these sorts of hiccups due to the fact that these legacy transactions they they are not they don't have like a lot of margin uh to get into the system or not as much margin as the one five five nine transactions have uh with the max fee another point is comparing legacy and 1559 transactions so this was a simulation that we've done maybe a year ago trying to simulate a mix system where you have both legacy users and one five five nine users exactly the same let's say dynamics but what we observed is actually it's not really that legacy users overpay especially when they send their transaction with a gas price which is kind of close to the base fee but it's more that they are easily non-includable and in that case so these red purple and brown line they all represent legacy users while the green i think green and yellow line will the line the flat line here is one five five nine users so what happens is anytime basically kind of rises suddenly legacy users they get priced out and they have to wait quite a bit so so i see i see kind of two scenarios either they are included quickly either basically stable with legacy users or we are priced out and they need to wait until the base fee comes back down so my take on this is that they seem to be paying more with their time than with their money and actually um thanks block native i've seen this graph parameter gave me a heads up that this exists it was posted in the gef discord it does seem like uh so these blue spikes is kind of a pending time to inclusion for legacy transactions and it does seem to be considerably longer than most of the one five five nine transactions so i think these dynamics are quite interesting especially still as we have quite a bit of legacy transaction in the system all right so last point the oracles this is more of an anecdotal observation but i was able to send transaction with one way priority fee and we got in really really quickly even though metamask was at the time recommending me to use like minimally four to five grey and this is how to put down metamask i think it was quite smooth experience um but as tim noticed also in the notes for this call i'm guessing that the priority fee oracle might be biased a bit upward and most likely this is due again to the legacy transactions who when they got in they might be even if i said they pay more with their time and with their money they're still more range for them to to overpay on the priority fee and so perhaps this is biasing the the fee history oracle a little i think if we want to be sure of that we could kind of take a look at the inclusion delay as a function of a priority fee that was sent um yeah that would give us maybe a clearer picture of what's good happening but it'd be interesting to know how low can we go with the priority fee and what are the kinds of guarantees that we need on this fee to be to be included this yeah go ahead nika do we know what formula metamask is using to determine that four to five base fee or four to five priority thing ella now oh my my understanding was that we were using the history oracle but perhaps they are on the call yeah i think i i don't know for sure but i think the four to five is some sort of minimum depending on the the setting so i think you know if i remember correctly it was the last call where i think we had discussed sort of like starting minimums um and four to five was in the range i think like two three and four or something so if uh it pulls from the fee history but if it's if it's like one way or something we might be hitting a minimum but i'm not positive that's just my guess i don't think it's a minimum i i used it earlier today and it was recommended to me like 4.73296 or something like it didn't seem like a hardcoded number unless someone had fun with primes and it's possible we may have updated at this point i'm not sure when this data was pulled from yeah so there might be a minimum but i still believe there is some kind of dynamics here where the priority fee sophie story is looking at the quantize the quantize might be quite high because a lot of people are a little overpaying with their priority fee so that that could also be yeah both a combination of having a hardcoded minimum plus the oracle itself yeah and if you had a lot of legacy transactions right like these might push you know you you could have a case where say only five percent of the block is 1559 transactions those transactions can get in with a one great priority fee but then if you're looking at say the first you know decile there's not even 10 of the block that's 1559 transactions so you're pulling the priority fee from a legacy transaction and that might explain why it's it's uh it's lower i thought the fee history endpoint was given you a percentile of the lowest priority fee included in the last uh n blocks is that not correct in that case i'm wrong i'm i'm not sure i mean i'm not super confident on a statement so if someone knows better please speak up and yeah i'm not sure last one but it seems yeah it'll be interesting to dig into this right so this was for a priority fee so the second parameter that is kind of relying on oracle a bit more crudely at the moment is the max p so the early guideline that we we set was to say okay look at the current base fee multiply it by two add whatever you were going to propose as priority and this should be good enough and if we have more data we will make it better um and this is some data courtesy of parama thank you for the data um which which seems to be saying that so okay what is happening here the what he's been looking at is uh how long does the transaction stay viable given that you are multiplying you're setting the max v as a multiple of the current base mean and 2x definitely remains viable for 30 seconds because there's no way the base fee can go that high 99 plus of the time it remains viable for a couple of minutes even but it seems the numbers are fairly close uh even for lower multipliers so 1.7 1.5 even 1.3 so in a sense what this seems to say is maybe the market isn't so unstable that we need to have 2x maybe we can use less aggressive max fees than 2x default of 1.

5 seems fairly reasonable this is of course maybe more of a static analysis of if everybody changes their max v to something else the dynamics could be different but i i do think this is early evidence that yeah 2x might be a little high go ahead um what was it sorry i might have missed it what was the time frame this data was gathered over was it since launch till now yes i think he posted that two days ago so pretty much most of the blocks until that time yeah and is that does that include that big event you mentioned earlier where we had a bunch of blocks in a row i think so yes i would check but uh okay i believe it does yeah even if that spike is not included well these spikes are not so long right so you could still have a spike for it could represent point zero one percent of your sample and and you would still be there right so yeah uh all right that's about it um yeah one thing i wanted to highlight is that i thought was really really interesting and super cool it was the many doom dashboards there was definitely a lot of community engagement around looking at the data i actually learned a lot from conversations on if r d a lot of inputs from wallets implementers infrastructure providers and very super nice hopefully this continues i think we're all like really keen to to dig more into this so yeah thank you thanks for sharing yeah this was great um i guess uh the other just kind of thing uh i wanted to make sure we mentioned on the call is uh we talked about the fee history api i know there was some issue where like uh the return type for the oldest block before was uh in decimal rather than hex and that caused some problems so geth released version 1.10.7 yesterday where the return type of the oldest block in v history is now a hex string um so i think yeah a few people had mentioned that this was causing issues and that should be fixed if you if you use the latest release by geth um and i guess that's pretty much you know what we have planned for the agenda like i'm happy to leave the rest of the call for just people's concerns or comments or anything you know y'all want to discuss um if i jump in here the only thing that i've noticed is that very low priority fees are getting included so for example 0.3 guai uh grey um and i'm just wondering if anybody had any thoughts around why that is happening or how that might change because previously we'd spoke about the minimum being for example one or two or as jake said before possibly three four uh grey so yeah and any ideas around why that is happening that's really interesting how how frequently have you seen like point three like not zero right like zero would happen like if you send a transaction directly to a minor but like yeah i haven't seen a ton of uh between zero and one yeah so yeah people from uh outside have been testing i don't know if roman yeah i'm here yeah yes so i sent like i don't know probably 10 15 transactions with 0.2 0.

3 grey and also sometimes i set max priority fee higher and but transactions would be still included with the like 0.3 0.4 deep well because base fee would be uh kind of higher than i expected but those does actually still would be included yeah and do you have like a rough sense for how long they would sit in the in the transaction pool well i i had so sometimes it took like hours but uh um i had like multiple times when it was like four or ten minutes that's really cool like i mean i guess the reason you know we mentioned one or two as an initial base fee is because that's the price that like offsets the uncle risk for miners um and it's kind of like the economically fair price if you want um whereas where if they include transactions on average for one way and then they get on cold you know every so often then they should end out end up net ahead um so i'd be like i wouldn't want to like see like defaults go below one way just because um i think then we end up in a spot where like if if we're sending transactions which are on average not profitable for miners to include um that that might not be great but i yeah i guess you know some miners might be willing to pick up those transactions you know if there's nothing else in the transaction pool and um yeah i i guess what we're seeing is kind of like the equivalent of like before if the gas price was 20 and you sent like a transaction with one way or something and like some minor just decided to pick it up um yeah so basically the best way for me to reproduce this was to set the like max fifa gas as uh like base fee which is like 10th percentile for past 100 blocks 10th percentile of base fee plus uh the value which is returned by max max heaper gas method and in this case usually transactions would be included like in 10 minutes or so and the tip would be reduced to some value below one grade yeah so if anyone is interested in that are you saying are you saying the the effective uh premium was below one or the uh premium you've set on the transaction was below one what they usually higher than a runway okay so that suggests there might actually be a bug in gas then since and i would not be surprised if one of them screwed it up my guess is is they're not um they're sorting transactions by the premium on the transaction not the effective premium and they're not correctly excluding when that doesn't get met i would be curious if someone can get through a transaction separately so so this should be looked into see if it's a bug and geth if not it's probably some miner running a custom fork or they screwed something up um either way i would be curious if someone can get through a transaction with less than one as the uh configured premium on the transaction and that would indicate a different situation oh yeah i can try something right now it happened also i i used like 0.2 0.3 is set as max fee per gas uh and it worked yeah max premium for gas multiplier okay yeah so find those transactions if you need another video so in the case of when you set that so i think there's probably two situations here one either a bug and geth or a bug in miners um with regards to internal transaction sorting and causing them to not correctly do the rational thing um the other one for when the priority fee on the transaction is actually set to lower than one we saw this long time ago back before there was congestion in ethereum when you could just throw a transaction out and it would get included eventually because there's always space um there were some miners that mined and transactions that were below like what was profitable for them like despite everyone knowing that it was unprofitable we we always assumed they were just like altruistic miners who just you know didn't really care about the money just wanted to make ethereum great and include everybody who wanted to get included and so you could like do like a 0.

5 or 0.1 even transaction and just wait several hours until this one random altruistic minor would show up and include your transaction um it might be something similar or it could just be one of the miners configured something wrong or they're testing things yeah it's interesting yeah there's a good comment in the chat like different miners have also different profitability threshold um and uh yeah i mean maybe i don't think i don't think any miner that we know of has uh uncle risk that's lower than significantly lower than one like point eight i think metallic ran the numbers well back and point eight was like for the for the good miners the ones were really well connected and had very low uncle rates like point eight was their fresh yeah um yeah i'll definitely share this with the get team and make sure that they look into it uh thanks yeah thanks for sharing the two transactions there yeah um was there oh yeah go ahead i was gonna bring up something else and just thinking out loud here uh based on some conversations with uh users of each scan like uh it feels like there's like two different uh groups of users when it comes to gas prices like there are the people who want to get their transaction through uh in a short or reasonable amount of time for them and that's the ones who want to have like the current or previous kind of grass oracle experience and then kind of the comments that i've seen in the agenda and even for myself like there is a another kind of user who would be okay with spending like one or two priority max fee and then with a max fee of like a few a few way higher than the current base fee and it gives them like a say a 90 plus percent probability of getting their transaction through within the next couple minutes and uh yeah i don't know if others have a similar kind of um uh perception that there's like like two different uh groups and it kind of like whatever guest oracle that you want to show you can't have to choose which group you're showing for i'd say i've heard people also mention like a third group which i think is is maybe the group that's having the toughest time is people who want to send a transaction with the low fee who don't mind it waiting like for hours in the transaction pool um so it's like you want the just like the person who wants to be in the next block the person who wants to be in the next five blocks and the person who wants to be in the next like 24 hours um yeah yeah i'm curious if like while teams or others yeah so the the core problem here is that when you try to each every user has different time preference and so some users have a high time preference some users have low time preference and when you try to factor that in you end up with a far more complicated problem and the ux becomes insane very rapidly basically it turns it from a like being able to ask user a question yes or no versus asking a user to look at a 3d chart and say where are you on this three-dimensional graph like in this three-dimensional curve where are you you know in terms of both time preference and financial preference and you know these are multiple variables in this problem and so the the reason i have always lobbied for the defaults for for wallets to be um what i have which is you know low priority fee high max fee is because it simplifies the problem to just a boolean question so just a yes or no for users which is very easy and it just kind of assumes that everybody has a time preference of i want in right now or not at all um and the only reason not because we think that is the dominant user but because that is the easiest user to solve a problem for and it gives a a very comfortable user experience even when they fail so like even it gracefully degrades to okay i'll just come back later which you know for you can express that to use by saying hey by the way you know transaction fees change throughout the day you might want to try again it's something easy to communicate to users where it's very difficult to communicate to users hey here's a three-dimensional curve of all the possible things you need to consider if you want to include your transaction and so yeah so you're definitely right there are definitely users across the spectrum that have you know different time preferences different price preferences and the and i definitely encourage wallets to try to think of how you can cater to those different users i just want to exercise caution of building like super complicated uis that users see first like as long as the first ui they see is the easy one i think it can work out pretty well and then for more advanced users you know they can use things like we've seen these you know east gas station and i don't remember what the other one was i think my block native has one as well they have all sorts of different pieces of information you can see and then you can also look at like base fee over time and so you can say okay i've noticed the base fee usually drops on sunday at 4 p.m the base fee is usually at its lowest so i'm going to wait till sunday at 4 pm and see what the base fee is and then try it then but you know if it's a if there's a big token sale going on or an ft sale going on at that time then i'm going to wait until 5 pm like this things get really complex really fast so just a warning that if you go down this path they're trying to build a ui for that it gets really complicated incredibly quickly any comments on that [Music] i did not mean to kill the conversation yeah maybe i'm sorry it's hi it's dom vincento here uh i'm a democrat mistakes for the alchemist community we are utilizing a technology that's called flashbots for those who don't know about it it's directly sending to miners the transactions and we are having a hard time building the ux around the base fee due to the fact that the flashbacks the when you send a transaction the transaction will be sent and signed sorry it will be signed by the user uh immediately including the the max augustine um but then this transaction is sent to flash votes and retried until it's included and this is what we do this is the habit that we propose the issue that we are having is that to on the ui on the ui and as a ux we need to estimate the transaction fee to from the screen to the user and this estimation needs to include the basic due to the fact that we are submitting at every single block let's say that this transaction is not included in block one or block two or block press three but maybe block press 20 that means that we need to increase uh on display the on display potential estimated base sheet that the user may be paying so we basically need to show the max fee that they may detain to remain honest about it and to remain transparent but this is this is a big problem that we have because this uh on display only shows a really a potential uh really high fee when the user is really not going to pay that max fee this is going to be a very rare case where the increase is going to be uh at every block for the next 20 blocks for example i think yeah i think melamask was i saw a thread by dan from metamask yesterday kind of covering this i think they tried to use like the average you know like how many blocks on average does it take for your transaction to be included i i don't know jake if you have any thoughts on that yeah it's yeah i can't i i can't speak to exactly what the estimated is but it's it's taking our best guess and then highlighting the estimated number and then we also showed the max feed too as like an fyi so it is i mean it's one of the things we struggled with the most in the ui is trying to to show that right because you don't want to show a super high fee that you're not actually going to pay most likely then you also don't want them to be surprised by a high fee if you never expose the max fees so yeah we do our best to guess you know where or estimate what we think the user will pay and then highlight that number and then show the max fee as kind of a secondary number yeah i guess what the issue that we are having is that um we are uh we are not i mean whenever you use uni swap for example you when you when you click on the swap button you will be redirected to the metamask window opening and showing clearly what gas and feed you're going to pay so users clearly and naturally understand that this is extra fees and network fees since we are sending that to freshboots we can't have that metamask window opening and we are throwing everything in one go in one place and and where we are being heard today is that users they will compare our prices and our field uh with uni swap for example and on uni swap they will not that will not include any any base field or anything that will be shown after in the next display so so that's why we are being hurt at the moment and this is really something that we're trying to solve by displaying better expanding better but also by finding the right way to uh to show a base fee that's not scary that's not driving our users away i see so this is the problem of um the person who is submitting the transaction is not the same person who is paying for the transaction and currently the transaction types that we support do not support um secondary payers like that we used to so it used to be that you could have a different person paying for the transaction versus who signed the transaction particularly with flashbots because you could you know submit a bundle where one person pays one person doesn't we have talked about this before on having new transaction type that would as a couple options one is we can make it so the miners can choose to cover the base fee and something we talked about and it almost got included but we withdrew it because we wanted to keep the initial 1559 simpler um i don't think there are any strong arguments against that one so if people have real use cases like it sounds like you do for making it so miners can pay the base fee then what that effectively means is that from the flashback's perspective you would submit a bundle where the user's transaction had a base fee of zero or sorry had a max base fee of whatever but that would be covered by the miner i think that use case work and the other option is a new transaction type where you have two signatures basically one signature of the person who wants to do something on ethereum and another signature for the person who's going to be paying for gas and that also you know there's no strong arguments against it like theoretically it just needs a champion to kind of push it through the process and work out all the details um both of these things are on the table so i think your situation we can do better in the future um it's just this initial launch didn't have either of those yeah i agree that will help definitely um both of those proposals um i don't think it will solve uh if if you want the users to pay for the feed at the end of the day i don't think that would be solved by those but definitely that will give us room for for for extending that kind of options and start um thinking of another way to make profit and pay for the user base fee and not carry them away like he does today anyone else had anything they wanted to share or bring up if not i guess one question i i had for all the folks on here is um i understand that like 1559 was the first time in a long time we've had such a uh a broadly impacting change to ethereum that that rippled across uh across a a whole lot of different uh areas um we do have another one of those changes coming in the next i don't know six to nine months depending on how things go uh with the merge um i'm curious if people here have anything you know that they they would like to see or they think could help them as we're working on the merge to make the transition smoother and to offer kind of a you know the the best experience uh to uh their users um yeah like things i i don't know either things that we didn't do in london that like you would have wished or things that you thought were actually quite good and and that we should definitely do again um yeah that would be really useful as we're starting to work on this personally i think these calls are great and trying to bring people from different levels of the stack helps a lot in terms of what to improve i would say try to stagger more to give a little bit more time for each layer to implement uh whatever the they have to implement so the players on top have enough time to adapt for instance having get ship fee history or all or require changes just a few weeks before the the merge made it really really difficult to to get to it yeah and uh focusing a lot on making sure that test nets are really representative of what's coming up on mainnet for instance something that beat us um after the merge was that um we have tested everything thoroughly on test nets but the base fee on test net was ridiculously low since blocks were not full usually and so when we actually got a higher base field maintenance some things started fading due to poorly set up gases yeah yeah that's useful um what like so you mentioned you know like having more time for like you know different layers of the stack to adapt and whatnot what do you think is like you know the right amount of time from when you know we have kind of a release of json rpc to that that people can actually use you know the the features to like going live on mainnet um yeah is it like you know one month two months three months uh hopefully not six months i i would say it depends on the complexity of what we're looking at for something like 15 59 i would say yeah one two months probably two months sounds reasonable of course i'm going to push for as much time as i have as i can have as possible and that means putting more pressure on cardiffs and i play and no developers so i know that the this there is a tension between like the the time frames for for each part of the stack yeah but yeah it's helpful to know that the rough kind of estimate that that yeah of time that you need and thanks yeah this is really really valuable anyone else uh yeah micah go ahead uh what's your question uh so i just curious we have a particular group of people here like wallet developers and whatnot i'm curious what you all think you need to do for the merge i suspect that like it differs greatly from what you actually need to do and i think now sooner rather than later is a good time to uh start clearing that up but i'm curious like what do people think is necessary from all the developers related to the merge or not all developers any third-party integrators uh well on the design side i haven't even thought about it so i don't know if that helps i mean you're more correct than a lot of people have spoken to in theory the the merge should have relatively little impact on integrations um but i want to start those conversations now to make sure we're not forgetting something is everybody in the same boat basically completely haven't thought about it you just you know it's a thing that's sometime in the future yeah this is um jen from rainbow year yeah i guess when i think about the merge at least from a wallet perspective that um kind of relying on the the tools underneath me to to maybe have to shift a little bit but we're kind of relying on not too much kind of changing from a ux perspective so uh but yeah also thinking of it as like oh sometime in the future and once it gets more real then um we'll have these calls again with like the different at the different layers of who needs to change what that's a great point like what maybe what's the point where it starts to feel real for you all right like and i understand it's kind of farther in the future than when the clients start looking at it because you know right now it's not even implemented in places like gas and whatnot but yeah what what are like the i don't know the signs that'll make it feel real for you um is that that's helpful oh hey this is bruno from rainbow uh yeah uh i just want to say that uh i think it's like a rad well kind of like uh um you know implementation like you know first client level then having a test net then wallets can start playing with it and then the apps and other people right like in that order yeah without without having test nets starting to think about stuff like not starting to think but like actually doing any work it's you know it's just like theory right yeah when you say test that so one one challenge that we've had in the past is like it's easy to spin up new test nets um you know like like a merged test net for example um but because a lot of people actually rely on gordy robston and rinkeby it's it's a bit harder to like fork them until we're pretty uh you know pretty far in the process um how useful is it for like you all when we have test like new test nets is it something that's like easy for you to integrate and like you know you can kind of start prototyping or is it something that's basically useless because if it's not gordie rinkeby or or uh or robston um then you just can't really do much because of how your infrastructure is set up for us it's not it doesn't make a difference i think okay um like you know it depends like aside from like being a testament or a new testament or not it like it depends on like how many ranking changes in like code like json that's that that's why it actually breaks or like complicates things and not the the test net itself you know yeah that's helpful um cool um that's pretty much all i had anything else anybody wanted to bring up um this is a michigan from anchorage digital i am i know i kind of missed the boat on this but i just wanted to voice support on um i think it was dawn from uh flashbots that was mentioning uh you know the difficulty of predicting the fees uh that we're displaying for our customers and perhaps including the new kind of uh transaction types or whatever the ideas are that we're kind of coming up with for kind of solving the issue of you know a a long time for where base fee may be changing drastically between when transaction is initiated to submitted so um just wanted to kind of reiterate support for that got it um i had just a few i mean i haven't i have to think about it a little bit more but um uh barnaby thank you thank you for your for your notes and presentation um and i think i'd like to digest kind of what your findings were and especially that kind of the the last slide that you had with the you know uh this 2x is equal to you know or it covers 100 of time or 99 whatever percent of the time um i'd like to uh maybe it'll be easier if we follow up afterwards uh with some people just to see if we could break down down even further um because i know that your your numbers were for all all time um or and so i'd like to kind of distinguish between certain peaks and and norms and uh like when things are flat versus when things are spiking um and then micah you were talking about it's funny because like from a wallet perspective um yeah we were kind of trapped because we were trying to take into consideration um the user's intent which is distinguishing between what a user wants now or never versus whenever versus like i really want to get this in it's got to be asap and i want to keep trying until it gets in you know like that that urgent but also extended timeline versus uh just now or never and of course now or never is much easier we do have plans in our ui to kind of be like hey things are going crazy right now uh it might be better just to try again later sort of sort of thing when things are spiking um but we would we were kind of hoping that um i don't know if ether scan or some other apis are here but uh we're kind of hoping that this could be more of like a math problem that is solved by someone who could just give us the numbers that we want for these different scenarios versus you know like so that the user doesn't have to do the math but the api can do the math and we can just give them an appropriate suggestion based off of the intent that we read off of the user um i i assume that's probably very uh hopeful it's so it is possible to do the math like i mentioned it's really like a three dimensional curve and if you know the inputs for that curve you can do the math and tell the user okay this is what you should do um the the hard part is getting those inputs from the user um in a like digital form so so a user who just kind of vaguely says you know i kind of in a hurry that's not super helpful for for the math side like turning i'm kind of in a hurry into like this is the digitization of my time preference um that's the real hard part so if you guys can figure out or someone can figure out how to distill a user's time preference and price preference relative to each other into like quantifiable numbers then we can definitely you know put together a formula that will tell them okay this is what you should do based on you know all of history and you know what we know about the ecosystem all these things um i'm not sure if that's reasonable or realistic at all because i think like even when i ask myself like what is my time preference i can't put that into a number like i don't know what my time preference number is i just know that you know i kind of want to go in today maybe or like you know i'm gonna i'm gonna go to bed soon and i want to be sure it's in before i fall asleep so in the next couple of hours like they're very vague numbers for me i don't know if other people have more solid things um do you think it would be so so i can understand like trying to extrapolate users intent into actual inputs to a mathematical function i understand that but i i'm wondering if we can uh kind of chop it up into like maybe three or four different categories or boxes um in some way i mean yeah i'd have to think about a bit more but that would be if that math function is there and then maybe we can give a little bit more thought of like how do we translate uh user intent or how do we even um get a signal about user intel i think we have a few ideas about how to get the signal for users intent um then yeah maybe we can follow up on that you might be able to kind of craft some like straw man users where you just kind of describe a particular person and then you give that like fake person some actual numbers to plug into these formulas and then you say you know are you this person or are you this person are you this person um that might be possible um it's still going to be vague like people won't map exactly to actual real humans but that might get us closer so instead of just mapping to the now or never person as our only straw man we now have you know three or four straw man and you can map to users can then pick one from like a nice little picture book yeah um uh yeah i think i think that would be helpful just and i guess from our perspective we would um i am glad that barnaby had that that slide about how 2x seems generally on average too high because intuitively we also think that we should tighten the the multiple that's placed on the base fee and if anything kind of like play around with a priority fee instead because um yeah because we are kind of like uh like even if you're urgent then you kind of if you're urgent now or never you also want like a a tighter uh multiple because you don't want to be potentially waiting you know waiting around forever uh but if you don't care that much then it's kind of unfair to show you a huge range of prices that you could you could uh you could use so it's better just to like wait around and and maybe you might get dropped if it's really busy but it's it's better to give you like a tightened bound like we don't want to have a huge range that we show to a user where on average it's like you know a very small subset of that range that you're actually going to be spending um that's what we'd like to avoid um so yeah i guess i'm just asking for like magical uh estimations that that'll work all right i nominate barnaby to do magic okay great yeah i i don't know if we have enough time but i'm not um and and barnabas slides you heard there was one example of kind of a normal scenario where there was some variability in the base fee but i think if the if you were to create a moving average you would see oscillations in in the base fee across that um and then there was the other scenario with uh um with multiple consecutive full blocks um and the the issue on the design side is right okay which of these two scenarios are we currently in so how do we reasonably estimate um whether somebody will be included in the next few blocks based on which curve the the the everything is currently on um and it's almost impossible to tell like you don't know what is going to happen you don't know if the trend is going to continue upwards and it will take a long time for that period of time to pass with the multiple consecutive full parks or whether it's just kind of the normal state where things oscillate up and down um and with that on the design side it's really really difficult to make a call and say okay actually we're in this situation and it's going to take x amount of time for you to be included um and it's also quite difficult to flag okay we're on a we're on an upward trend here and we don't know when this is going to end it doesn't install confidence and it's quite difficult to communicate and if somebody figures out how to communicate these potential scenarios then great perfect but i'm not sure whether it's whether just having um like a way to determine which of these two trends you're on is going to be helpful to lots of people it might be helpful to some definitely but um i think yeah there's lots of communications that need to be done here above um actually determining those those trends so the core problem here is anyone who can answer the question of which trend are we on can make far more money by going into finance than we can offer to pay them to help us because essentially it's the exact same problem as predicting the like future price of a stock or you know a commodity it's it's it's it's an attempt to predict future demand for an asset which comes down to like you know keeping an eye on all the things that are happening in ethereum keep an eye on the news sentiment analysis like when we get these bursts they're not burst because of something that's predictable they're always bursts of like something that happened like an event occurred in the world that resulted in all of a sudden everybody wants to use ethereum now that being said some of these events air quotes around that are seasonal and so there really is you know at a certain time of day every day the fees generally are lower than other times a day we do see strong seasonality in gas prices and so those ones we can predict and we can show to users potentially and they're actually pretty easy to graph like you just look at the especially now they have the base feed that become really easy to graph so you look at the base fee over time and then you know plot by day plot by time of day plot by day and time and we should see some very strong seasonality but um the ones like we saw earlier which was like an nft sale or something those ones are just effectively random for anyone who's not you know an nft buyer and you know it's nfts today it was icos before that it was cryptokitties before that it was you know some some event occurs in the world elon musk tweets something and it triggers it and so i just want to make sure everybody's aware that it's very unlikely we'll ever fully solve that problem the best we can do is capture the seasonal stuff and try to express uh present that and let people know hey we're on the you know morning uptrend like every morning it starts to go up so we're gonna estimate a little higher or we're on the evening downtrend so we're gonna estimate a little lower like we can maybe do that but i think that's probably about the best we're gonna get realistically and one thing i've noticed is that it was especially difficult i mean it was really like eap1569 went live and we discovered the effects of some of the effects were discovered after the go live uh is there already and i'm not i would not be aware of that yet or is it possible to have a test net which will have all transactions replayed maybe with a delay of 24 hours or something that will allow us to see the impact of such upgrades the two challenges good yeah the two challenges with that is one um basically the tech to replay transactions is is is hard uh that's you know solvable but uh yeah we don't have a team or that that can uh that can help with that the second part is uh the money basically so like because transactions on main that are worth something um we get like a different patterns and different incentives to send than like on test nets um so it's it's hard to get like a yeah a perfect replay basically um and to expand on that a little bit um the one of the issues replay test nets is that they very quickly fall out of sync because if you're replaying under a different rule set some transactions will fail that previous that on the main net succeeded and so um i guess i guess in this case you're sorry when we talked about this before we're talking about test nets for future changes are you talking about tests for future changes or do you want just a a test net that just replace history so you can do testing like back testing basically what i'm thinking is for example for this go live uh if a week before erp eip 1559 was was deploying on the test net that every day was getting the main net transactions with the delay um we will have seen some of those issues that we're having now a bit earlier with our new ui new ux and and and in fact it has i understand it's difficult right understand it's not something easy to do but i was thinking you don't really need to uh reproduce uh some of those uh data like you don't need to reproduce just the from or the addresses or anything i think that what matters here is is the the amounts uh the tokens in play um and and then the that all the transactions that i mean we got the same flow of transactions some number of transactions in the system so we can really see the impact uh that those would have uh on the gas and the user drop into accuracy yeah so the core devs have talked about this in the past and i think we generally got agreement this would be generally useful for the courthouse as well just because it's nice like you said it's nice to see real world stuff the issue that we run into is that when the rules are different between the two chains they very quickly fall to sync with each other and so transactions like you start with one transaction that fails on the test net but doesn't fail and mainnet and then that leads to the world state being slightly different and then now another transaction fails because the world state is different and then another one and this kind of balloons out pretty rapidly we don't know how rapidly that happens it probably depends on specific so the rule changes um but so it means we can't just like spin one up and leave it up forever because eventually the world state will differ so much that we just simply doesn't make any sense to replay anymore because everything's failing that being said we can do we talk about doing things like you know having a daily or weekly reset or something so it's just so we constantly do have real real world transactions being replayed on a test network um using new rule set but we just reset it periodically to make sure the world states say stay in sync and that is an option the like i said the the core devs generally were favorable to this idea um it's just a matter of core devs are overworked and we have to choose and at least for london we decided not to do this but we did talk about you know maybe for the next um next big feature fork or something we will want to do this like like i said the general interest is just a matter of prioritization yeah thank you um and yeah i you had your hand up a while back and we never got to you so oh yeah it was to the other thing uh basically it's not only to say it's not only personas basically where you need to make preferences it's also the transaction type um for example i'm the persona that usually doesn't care about the timing but then when it comes to uni swap transactions that has a timeout um then it's a problem then you want it fast and i once made um a post on magicians about that um that we should make a way to signal that so either via match specs so that contract authors um specify that on nutspec or we add it to the rpc so that we as wallets that's also good for the user experience because then we have less cognitive load on the user right so if they don't need to decide it's better um but it's also an important signal because then also it's happening for a lot of users they don't really know about the timeout or the expiry of the transaction and so basically the the transactions uh can also signal that they want in very fast it's not only personal yeah i would love to see that agreed any we're already a bit over time but um we're still here so any final questions or comments um if i wanted to follow up with bonner bay or or micah should i just do that on the um the discord yeah so we have a 1559 dev channel which yeah probably makes sense to use yeah and then relatedly does it make sense to have another one of these calls probably not like two weeks but like i don't know does it help people in like a month or like when people have had more time to to like dig into this um yeah we don't have to schedule it now but yeah the people generally want another one of these calls about 1559 and if so when would be like the right timing there's at least one yes i would i would like at least yeah one more one more call after you do a little bit more uh back and forth first so probably a month makes sense cool yeah okay so let's yeah let's aim for a a month from now roughly all all um yeah it's probably easiest to have it be literally four weeks from now when it's like not all core devs or something um yeah so i'll make sure to uh to set that up um to your last answer tim aren't we combining the one five five nine channels into just bouncing off the market yeah there might be like yeah so there might we might rename the channels on discord to have it be just fee market so if you can't find a channel which 1559 fee market is basically the same thing it might make sense i guess just given this and that we're having another call in a month i'm i'm finally just holding to change that um yeah i don't think it has to happen right now but yeah if there is no more 15 channel just search for free market and if you're not sure just ask anywhere in the discord and somebody will will um will share the link uh yeah let me just share the link to the discord in the chat here there we go cool anything else i recommend anyone who joins that mute the channels you're not interested in there's a lot of yes yes this is all of the core devs channels across all of the research so yeah definitely or muting aggressively cool well yeah thanks a lot everybody for coming on and uh yeah i'll share the information for the next call um when it's when it's all set up i'll see you thank you