EIP-1559 Gas API Call (Breakout #10)

uh yes yeah uh okay so we are recording uh thanks everybody for coming uh this is a call to talk about the gas api uh and how 1559 affects it um if we have time we can cover any other questions concerns that that folks here have um so trent already shared the agenda in the in the in the chat here um basically uh the main i think topic or yeah the main topic of discussion today is you know what do we do to return the priority fee in the json rpc api there was already some discussion about that on the issue and um before that though uh i think trenty put in the agenda the presentation by gas api providers so i don't know if there's folks here who've actually you know prototyped or looked at what uh you know like a gas price oracle can look like post 1559 but if anybody wants to uh share that uh it's usually pretty helpful to just start off with looking at something otherwise we can go right into the api yeah i see uh there's some etherscan people here or if anybody else wants to just jump in go ahead whoever was just speaking feel free to just speak yeah uh hi i'm from the get team and well i can i can i can talk about what we have as a guest price record now if someone is not familiar with that already or it does that there's already everyone know that i think it would be pretty bad like it was at least valuable for me yesterday and the day before to understand it better so yeah i think walking through what you have now and how it's changing under fifteen pieces and i know that like you and peter posted some some comments as well but yeah just to make sure we're all on the same page yeah so okay i won't go into like very fine details but it's pretty simple actually so uh what we had for a very long time like for regular transactions was that basically we took the past uh i don't know how many blocks well actually it depended on whether you were running a food or a light node because if you were a full node the gas price record took the last 20 blocks so it's quite a lot but if you were running a light client there may be two and maybe now the latter will be better but uh and what it did is uh it took uh the few smallest uh guest priced transactions and basically uh found the not the median but slightly below that so if we put them in descending order there may be i think 60th percentile or something like that and just return that as as a suggestion and and yeah so what uh we currently we are currently planning at least the latest like kind of team consensus is that we are going to keep this mechanism and use it for i mean we feed the effective miner reverse into it so so that's what it will actually use and and this will be a suggestion for the tip for the the private max priority fee and for the fee cap for the for the max fee per gas we suggest this tip plus twice the current base fee and uh yeah uh it's still a good question how many blocks we should take and uh and it might depend on certain situations so i also had this proposal that i just posted like this morning that maybe we could just um so it might depend on whether there's a congestion right now or not so we could we could like iterate through the recent blocks and and like offer different uh uh priority fees depending on how urgent it is for you and maybe this could be also like a nice uh signal for to for the users to see if there's a congestion or not i can dig up the link and but i it's it's in the in the 1959 free market uh left channel so yeah and but basically we are going to uh so this is what we want to do we want to just uh use this uh this take take take the minimum or close to minimum tips of of recent blocks and offer something below the median india so that's what we want yeah thanks for sharing um so and yeah again on the on the issue i think the main concern about the current get implementation is if um if there's a spike in usage uh those will likely be short-lived and yeah the 20 block is almost remembering like too much like looking at too much history whereas under 1559 um you know things will probably happen much quicker like if there's a spike it's likely that it's going to be something on the order of less than 10 blocks and um and if you're looking back at 20 you might have users overpay slightly i'm not so sure about that actually if there's a spike the spike is short-lived so if you if you take the recent block so if you like accommodate yourself to the spike then you will pay a lot and get in earlier and if you take longer the longer history then you will find a tip that has worked like in the past usually and then what will happen is that you will wait out like the spike and and get in somewhere at the descending edge of the spike so i'm i'm not sure interested yeah yeah yeah that's right so it depends on what you want how urgent you want to get in your transaction yeah yeah so basically this if i'm understanding correctly the api would work kind of pretty well obviously if there's no spike at all like if if the blocks are pretty constant it would also work pretty well if there has been a spike in the last 20 blocks but it's kind of over and it would it would probably fail and you know there is a spike happening right now and you know um yeah then that that means you send your transaction and it just kind of has to wait until the spike is cleared to be to be included again is that roughly right um well yeah if we use like a constant setting then i mean content setting for how many blocks we look back then yes that's right and yeah thanks for linking my proposal so i think i think that kind of addresses this but uh yeah so this is just like putting up ideas right now but okay so that's what we have now yeah got it uh micah your hand is up so i just want to reiterate my broken recordness um most people here probably already know what i'm gonna say but i'm going to say it again for the new audience i'm generally against any sort of priority fee estimation that's not just what do we believe the miner's min value is the reason for this is because it's kind of self-reinforcing getting people into these auction and bidding wars and in most cases it's probably unnecessary and in the cases that are remaining it often can just hurt the user as much as it helps them and so i think it's much better that most of our oracles are writing unless we're writing oracles specifically for like very advanced users like you know bot authors and stuff like that which i don't think any of us are i really think that for the premium we should just be saying hey we know that miners will accept a premium of one or two or three or whatever and that's unlikely to be changing and so this is what you need to set the premium to and that's it like i do not think we should be incentivizing or incentivizing encouraging and helping people get into these gas auctions because they're just they're going to get themselves hurt like things are going to go wrong like it's just for the end user it doesn't i don't think it really improves anything in a significant way and it's a lot of work and a lot of complexity and then we have to expose this in uis and it's just just a huge headache that i really don't think is going to help us down the road yeah i kind of agree but what so uh so this is so this is why i'm saying that sometimes it makes sense to look like more into the past and okay this is like the minimum that has ever worked and suggest that but i mean so you you are talking about using a constant basically and ether price is changing so basically uh i don't know minor preferences the technology a lot of things can change so these if these minor settings do change how will users notice that if we don't look for the facts like how like like the actually included transactions uh yeah so i think the we we do need to have it be dynamic um but that dynamicism should be over like really long time scales like we don't i don't yeah i want to be cautious here because it is possible that there is a little bit of incentive for miners to actually have dynamic base fee or sorry dynamic premium or priority pricing based on current mev rewards this is really complex really hard to do but it is possible and theoretically rational as i want to be cautious with my words here but at the same time i also think that it's probably unlikely we're going to see miners do this anytime soon because it's a lot of work and the games are pretty minor compared to other engineering tasks they could be doing and so i think that we can look kind of longitudinally and say you know the clients that are out there like guess that miners we think miners are using have just like a command line option for set your minimum priority fee and we believe most miners are just setting a minimum to something and we have seen you know over the last ten thousand blocks ninety-five percent of the miners have been below two and so or have mined a block with a transaction below two so set your base fuel or say your priority fee to two and i wanna be careful to not get into this not trying to be too dynamic not trying to adjust hyper fast to what we think miners might be changing because most of the time when that changes it's just due to a very short-term congestion spike and does not last and so i do think it should be dynamic we shouldn't just yeah i i agree with that can i go next yes yeah go ahead right so i do think also the value probably needs to be dynamic but the issue with looking at let's say past records of what people have been bidding is that we might be too slow to actually catch that the spikes are happening in which case while this pack spike is happening you're still recommending the minimum tip to users and at the end when the spike is over you your indicator will still be kind of trailing these high values and it might not be that useful but we do have an objective source uh that we get for free uh from one five five nine itself like we don't need to look at what users are doing we can simply look at how full the blocks are or maybe like the two or three uh recent blocks and if we see that two or three blocks in the in in sequence or even the previous block was full then we know that we are in one of these uh spike uh regimes and and we don't need to wait to see users increasing their tips because they might not do that first by themselves they might rely on wallets which would do that for them and and second even if we wait for this with the parameters that are set looking back 20 blocks and looking at the percentile it's not clear that you would catch immediately that the spike is happening and you can really do get it quickly enough by looking at the at the gas usage in the block itself so i i would this is kind of what i was advocating for and i understand that it might be very different from the current paradigm and then there's a bit more implementation complexity but but this is where i stand on the api so do you so do you suggest that we should react quickly to the spikes with the recommendations in the end well i think if you're going to react at all so mika recommends not reacting at all and and that's definitely a valuable position but i do think that it might be available for users to have at least some kind of indication that something is going on so if you do want this indication i i think relying on the gas used by the previous block of the previous two or three blocks would be more accurate than relying on more subjective uh price points such as what the users are currently doing yeah well yeah so this is why i propose that we should like return a series of suggestions depending on how urgent it is and yeah so the users could decide whether they want to like uh find the fight fight for for for priority or not and uh yeah it's also good to see whether there's actually had something happening right now but yeah uh always suggesting like to to to to jump on the spikes i i don't think that's a good idea offering it as an option that that might be good right i think returning series of prices like options it might be okay but but i would still use the the gas used as as a as a metric to to check that something is happening rather than user prices because then you will have like this kind of self-reinforcing behavior that i think mika is worried about and so am i so yeah uh micah yeah so just to reinforce the barnaby says if we are going to do uh reactive gas pricing to congestion we should definitely use the fullness of previous blocks to identify congestion similarly when we're trying to determine what like the 95th percentile minimum is if we decide to go with that we should use that same block fullness to filter out um minimums like we're trying to figure out okay what what do we think 95 percent of miners have set their min to we should first filter out any blocks that were full or sorry any blocks yeah so any boxer full filter those out and don't count them at all um to get those numbers so that way we are seeing just the minimums we're not seeing the congestion times um separately the thing to keep in mind i think with this debate of should we be reactive or not is that if everyone is reactive it turns into a pathological scenario where kind of everyone ends up paying more like the the reactiveness is useful as an as an advantage over competition and so if you have one user competing against another user the one that reacts wins if you are building an ecosystem all your users presumably are you know approximately equal like you want to serve them all in which case if you build in tooling for everybody competing using the same strategy you just end up paying miners unnecessarily and so if we do introduce these strategies kind of at a very core layer like in geth for example we need to make sure that they're introduced in a way that most people don't use them like i know it sounds weird to introduce a feature that we don't want people to use but if we introduce them in a way that everybody uses them then they become not useful anymore like they no longer serve a purpose we very much need to introduce this and one way to achieve that is by having like this concept of transaction priority like kind of fast medium slow or whatever where the fast is saying yes i want to be reactive and as slow as saying no i don't want to react one caveat with that though is that i'm worried that compared to the base fee you know if the base fee is 100 and the fast medium slow is like two one two and three like everybody will always choose fast and now we're back in that same situation where everybody is choosing fast at which point it is no longer helping anybody because everybody's following the same strategy like in order for this to work we need people to be following different strategies if everybody follows the same strategy the strategy stops working this is very common in game theory and so just keep that in mind that we need ways to make sure people are not following the same strategy so one question i want to ask is a bit tangential to the discussion is that we're kind of trying to solve the whole gas price suggestion uh problem before we actually see how the network behaves and uh so my personal two cents would be that uh so the current model that is that get it get implemented is essentially just continuing the old algorithm and i completely agree that this might be completely unsuitable for certain tasks or certain scenarios but it kind of worked until now so wouldn't it be kind of prudent to wait until mainnet actually forks over and see how the base fluctuates and how tips fluctuate before we try to solve this problem so i'm kind of uh the only thing i'm afraid of is that we're coming up with a solution to the wrong problem because we don't know what the problem gets until the fork yeah yeah but the problem might depend on what we offer as a default option so yeah it's the i kind of agree with you but yeah we should also keep in mind that what we will see in practice that depends on what we offer as a default option now yeah yeah of course but essentially if we continue our current algorithm then at least we know how wrong it is whereas for example mica had a really nice example i think the base fee is a hundred and the tips are one two and three then it doesn't really matter and this is exactly the problem we don't know how the tip will fluctuate in comparison with the basic so that's why i'm saying it's not super easy to to solve the problem at least for me it's not super clear what the exact problem is or will be i stuck greg you had a comment and i think you put your hand down yeah i mean for me it was just kind of just coming back on mikko but he kind of answered it the the big one for me um is that you know i personally i've like personally believe like i would rather people pulling the nodes to figure out a gas price than a third-party api um and in that case like we're always gonna have to be competitive to some degree so if you know you kind of have to go back down to like there has to be some level of competitiveness there um obviously the issue being naturally that like we're gonna run to the same same problem we have now everybody just competing for astronomically high prices is a problem um but in the case where like you know we have products that we use um if we don't we try using the node and we actually had to switch off of uh geth and open a theorem just like we couldn't rely on the node for the gas price anymore and now we're using a third party which is not what i want to be doing right so like i think we have to do some sort of competitiveness and like like you said you just have to be careful but i kind of do agree with peter in the sense that you know is there something simplistic we can do and just see how it ends up playing out in the real world so i think there i think there is a simple thing we can do that has a good chance of working for launch and then we can re-evaluate once you have more data and that is to encourage um the client devs to have a hard-coded defaults for the priority min priority fee that miners use and a hard-coded default for the party fee that gets returned if you ask for a gas price recommendation and make sure those two are the same thing both of them can be overridden by command line parameters or whatever but the idea here is is that by default if all the miners just run stock guess and all the users run stock guests then everything will just work like the min priority fee that miners are accepting is exactly the same as the priority fees that users are using and everything gets through with an exception for during congestion at which point we get good data on how congestion happens and what goes on there and then like a week or two later we can start making alternative recommendations and then the next patch of geth can maybe include something more smart but if we can get all the clients that kind of just agree that hey where's our miners we'll do this by default is the min and our users will get this is the min then i think we have something that can work out of the gate and my guess is is that most miners are probably going to run stock out of the gate and similarly watch and see before they crank up their numbers and so we can set that to one we said that's two let me say it to five you know we believe that you know one or two is probably the right number well you said it's five just because around launch that will probably be inconsequential compared to the base fee anyways and so you know people will mind five and it means that it's less likely that miners are going to manually adjust that again that requires all the clients kind of a green we're kind of agreeing hey this is our launch number just to feel things out but i think it's really simple and it gets us to a point where we have more data so a counter argument to that would be that currently the gas prices fluctuate i mean i have no idea what it is currently lasts a couple of days ago it was around 30 a week before that it was around 100. so you have a quite large fluctuation with me which means that the node has to fluctuate along with the gas price otherwise your the transaction you make will never get included oh i see because you're saying the issue here is for specifically for the the eth underscore gas price needs to work for legacy transactions not um no i'm i'm talking about internal both that one if i if you want to submit a transaction by get then your assumption is that the transaction will go through reasonably fast now if if cat will always tell you that the tip is to peek away and the base keys whatever then probably when others are paying 100 feet away for the tip i mean good luck with your two gigahertz yeah and i think so this is yeah the failure mode of heart basically hard coding the base fee works only when there's not a spike right so what you're the trade-off you're saying there is like you won't you're guaranteed to like not overpay when there's not a spike but if there is a spike you'll be way underpriced and then you need some other way to to estimate what the right base right the right uh priority fee is um yeah exactly and the caveat there is that we expect spikes to be both rare and short-lived and so for users that are just using the default they will probably still get through like as long as you're setting like base feed times two or whatever like this common people talk about um you'll probably get through in almost all cases like it just might take you until at the end of the spike and the spikes like you know seven blocks or whatever and not just the spikes yeah there's there's two cases where you won't get in it's uh one if there's a spike and two if there's a high mev transaction and this is why selling a constant is a bit harder uh barnabay has uh made some some some graphs about this but uh basically if you know if a block has a really high mvv transaction uh the opportunity cost of being uncold is is quite high so it's it's kind of unlikely to include anything with this kind of hard-coded tip um so i think when when i last looked last week you know if you get if you hard code a tip of two then it's i think it gets you something like 75 of the blocks with mev it still makes sense to include those transactions uh if you if you have a tip of and the top 25 probably just won't include transactions with low tip um so that's the other case where you're just kind of selling it out i think right now um last time i checked there's about 35 40 of blocks that have mev so that means you know statistically like if you're really unlucky you set your transaction the block has a ton of mvv in it um but then you know the block after probably doesn't have a ton and and you get into that block um but yeah it is a case where like um and i don't think the current gas price oracle can really pick it up like it'll probably pick up um you know what's the sort of average longer an average and and you know looking at it right now it would be like two way would compensate for the uncle risk accounting for like something like the 75th percentile of mev um but you're yeah you're not going to be included in those blocks where there's like a 10 eth front-running opportunity yeah with the again the cap my caveat here is that we we should do this as a launch thing with plans to change it in the future um and the reason i think this is fine is because i think you just broke we're going to all of a sudden have we missed we missed the reason you think this is fine can you hear me now or am i still bad you're good okay so the reason i think this is fine is because on launch day i find it very unlikely that all the miners are going to all of a sudden have super advanced pricing gas min pricing strategies already coded into a patch for geth or whatever minor they're running um even without having any data on one five i just like us like remember miners are going through this exact same process as we are where they have no data they have no idea how things are gonna work out in the wild they don't have the guest code to work on yet so they can't even start their patch until after we get our release candidates out and so like if we just plan on having this like this is our kind of launch thing to get to gain more data and we you know in a couple weeks we'll change it or in a month we'll change it i think that's safe like i don't think we have to worry too much about like a large percentage of miners having hyper advanced gas pricing strategies on launch day um so i i i want to bring up a point which is like on launch day on the day of the fork most people most clients who are sending transactions are probably going to continue sending legacy transactions um until like the market is stabilized or they'll gradually roll that out to something and those folks are gonna you know many of them still rely on the e gas price api and assuming that still exists and you know at least is backwards compatible and continues to return um the same implementation for legacy transactions that means that folks are essentially going to be like the majority of the market is going to be sending legacy transactions with max fee set to max fee and max priority fees set to the same thing which i believe means that the majority like unless we are committed to like breaking eve gas price and getting rid of that api all together we are the fact that like clients you know guest is going to be de facto making pricing recommendations anyways is that correct yes that is correct almost so it doesn't really matter what you have to eat gas price or not guest price uh 10 point because legacy transactions still only have one gas price fields which get interpreted as both the different i mean as both these so as long as you're sending a legacy transaction doesn't matter how you estimate the gas price it's still going to burn block so i think i see the difference here um i think peter is talking about people who send their transactions unsigned to geth and then guest fills them in and signs them and submits them i think yuga and other people are talking about people who ask geth for the gas price and then they fill out their own transaction in a script or an external service sign it and then give that to guest to submit to the chain i was talking about that the second thing so if you just ask a guest to sign the transaction we will never sign the legacy transaction so get will always default to 1559 transactions uh i'm so referring to the guest price on you when you sign when you sign it outside of get so to say you just you just ask for the guest price and create a legacy transaction yourself in that case i mean the both the tip and the fee will be the same i think that wasn't that the initial problem that everybody will be using the old legacy transactions so maybe i don't understand what what do you will the return value of each underscore gas price change with the fork just a single value right like a single number and that single number will be a combination of base fee times two or whatever plus some parity free recommendation prior to you it will be the priority plus one basically okay so it'll be party feet so essentially that would be retaining the current behavior people who want to sign a non-legacy transaction would probably want to use a new endpoint that gets a base fee separately and priority fee separately yes for that we didn't so there was i think that client made the uh the pr to the something specky whatever about the new rpc endpoint so did introduce that so we do have the i don't know what it's called whatever is in vip it's called that endpoint to actually return just the tip and then uh okay we have a separate endpoint so if you want to submit uh 1559 transactions we do have a separate endpoint to specifically give you a tip and we do not have an end point to give you a fee cap because it's so if you don't specify you will just default to the tip plus to the base keys if you want more control you can specify it it's very reliable so the hard thing to do is estimate the tip so that's that's why we need to support an api for that okay gotcha that clears things up for me thank you all right yuga i'm sorry for interrupting i was wrong no no no worries at all i mean i guess the only point i'm making is basically it's clear that um clients are like each clients are going to make recommendations there's no way around that right because there are many many people who rely on these apis on the east gas price api specifically so we are you know the community's de facto making a recommendation about how to price 1559 transactions because you know legacy transactions can be interpreted uh as 1559 transactions so like that ship has essentially sailed i think so the only question is what is the type of recommendation we make well here but that again you made a nice point there that the problem here is that we don't just buy this switch forward to 1559 rather we will have a mix and match for what's more initially most of the transactions will keep being legacy transactions so people have an expectation of how legacy transactions work how they are priced how they compete with them so i don't think we can really break that expectation and then if you have a network with 90 taxi transactions then you need to create your 1559 transactions in a way that they can actually compete with the legacy transactions because if the legacy transactions are paying 10x the tip then it doesn't matter how nice algorithm you come up with for the 1559 transaction they won't get included because they were just always under price compared to the legacy transactions so this was kind of my where i was coming at is that i don't think it's advisable to break the current workflow for legacy transactions because we have projects wallets and everything that kind of rely on it with all its quirks and ugliness and some optionality so i don't think it's advisable to break that and if we don't want to break that then our hands are kind of limited into how we can implement estimations for 1559 but this is a problem i don't have a solution so i guess one thing uh i'd be curious to hear kind of people's thoughts on this greg you kind of mentioned earlier you know you see it as like a bad thing to query like a third-party service to get more precise gas price estimates um at the same time it kind of feels like a separation of concern issues like where you know guess gets like main functionality is not to be like a gas rights oracle right it's to be a node and to submit some you know reasonable estimate for the gas price um and it does feel like you know 1559 has like a much broader design space for like gas price oracle so i i'm curious like what what people feel you know like if geth has like this good enough kind of backwards compatible solution that's like not optimal in all cases you know does it make sense to have folks like eat gas station gas now and what not be the ones who kind of you know come up with like fancier apis that do look at the block history that that do help with this use case like i guess i know more granular if if you want like use cases um i don't know if people have thoughts on that rick i see your hand is up hi hi uh yeah i mean for me personally i feel like geth is the best place to put an oracle because everything already kind of needs it and i mean itself needs it but it's like a point i can kind of trust if a person's trusting in fear they're going to continue trusting in fear it's weird that you know in order to do anything i trust infira and now some like a get gas price something something especially when all the data is sitting in memory in geth it has to for other purposes anyways um and so that's kind of my hope is that uh i mean at some point i saw somebody else recommend it as well as even like a histogram or something of gas braces but it seems like there should be some way to like bubble up information in a call that they can be used by a more clever oracle um even if if geth doesn't want to be the final call if they can bubble up enough information that's sitting there literally in memory it doesn't have to hit the disc or anything in my mind uh so that's kind of my take on that like in ethers when you connect to something you connect to something if you call get gas price it's not going to start then trusting some some other service um for the gas price that's my two cents got it uh santiago see your hand is absorbed yeah i agree with rick in that it would be great if geth could solve 95 of the cases and we're mentioning that we still haven't figured out exactly how to solve the difficult cases like the bot writers or the traders or people who need to get in during a spike i think that would be the place where we would rely on gas now any gas station or more complex casper gas price oracles but for the average user i would love if get can provide the whole solution cool peter is here hand it up again yeah so an interesting question from from get's perspective is um essentially currently provides one api endpoint now um given that 1559 will arrive let's say we will have two api inputs one collected transactions and one for 1559 transactions now our assumption up until this point is that get is kind of work operates in this headless mode where an external app just does that to somebody's transaction and then gat needs to figure it out now from this perspective i don't think we can make it much smarter now i think it will show suggestion to maybe have an additional api endpoint maybe automatically additional part that may be able to provide some more information but the problem is that yes maybe we could be smarter and look at various metrics and try to give some options to the user but for such an api essentially you need something in front of guest that can actually show this to the user or make heads or tales of the recommendations or the variations and then the user or something gets too big but i still think that if you just have a dumb program like a mining pool payout that just wants to pay irrelevant of how much it costs then you'll be still in the dumb api which kind of just works and doesn't give any choice but i'm going to be fine with having an additional api endpoint that tries to be a bit smarter and tries to offer up some suggestions yeah i i the way i imagined my suggestion yes so this is this is why i think it's a good thing if the like uh more flexible thing is like a general generalization of the default thing and we should definitely leave the default uh default api and i also want it to work more or less the way it did work before because yeah it's better to not break things that already exist yeah sir can we get a confirmation to what uh bernabeu asked on the chat on what exactly this gas price api would be returning is it going to be base fee plus the get estimation of max priority fee so currently okay so currently the gas price workflow within gas just looks at the past blocks and tried to see what was the minimum minimum i think for each block what was the minimum three tips actually paid to the miner and then based on that it will currently the crisis takes the 60th percentile so it essentially tries to uh take not if not the smallest tips within the blocks but something very close the smallest tips yeah but i think the best question was that uh what will the old guess at gus price api recommend and i think sorry sorry so essentially i was saying that internally get calculates a recommendation for the tip and then for the old east gas price we just add the current base fee for that to that tip and essentially that way the basically gets burned and the the tip that the miner gets will be more or less what the miners were getting in the previous blocks so the miners should be happy with that so basically the answer to benefits question is yes it's correct what yes thank you can i ask you for a quick follow-up on that uh what is going to be great behavior if if it sees a transaction on the mempool with a base fee that's below the current block is it going to keep it on the member is it going to drop it currently the implementation actually was encountered by jordan is that okay you you can talk about it yeah just real quickly yeah so i don't want to again go into details but uh yes we do keep if if there's uh so so we do do keep transactions in the manpod that are currently not includable if they have a high fee cap because then they will surely become includable really soon so so what we do is that uh for most of the pool we have this we recalculate the actual binary reward based on the current base fee the latest base fee and we prioritize transactions based on that but uh there's like a little space reserved for those transactions that would like fare very badly in this comparison but still have a high fi cap or max fee and therefore they are worth keeping so that because they will be includable in the next i don't know five blocks probably so yeah perfect thank you essentially about uh previously so currently transaction pool maintains 4000 transactions and with this update at 1559 we added another 1000 transactions whose purpose is to be those transactions which cannot currently be executed because the base fee overflows or underflows or whatever but uh but otherwise they kind of look good but as a disclaimer it is a new mechanism so we're hopeful it doesn't blow up in our faces and the reason i was asking is because there is the intuition that legacy users who are sending the old format transaction will always be grossly overpaying because they have their max fee equal to the max priority etc but actually if you if your api returns the base fee plus an estimation of the max priority fee and if the max priority fee of this legacy user is really large over time base fish should kind of try and compensate for that and basically we will sort of match the the price levels that these legacy users are sending initially which means that once that happens the actual priority fee that these legacy users are sending will should should be pretty small and should be once again close to the minimum that miners uh would accept and so legacy users are actually a bit um hampered by this because they are recommended prices which are close to basically which means that any small fluctuation of ones of the base fee means they are priced out it's not like the current mechanism where okay there's room they can still go in like the base fee is really binding so i don't think we need to to be too worried about these legacy users and i don't think we need to have necessarily this image that they will be really overpaying all the time i'd like to ask a follow-up question to uh peter's comment about memphis structure there um currently the mempool is divided into two parts of the uh cubed and the pending um did i understand correctly that there is now going to be a new component to the mempool that contains these uh high max fee but not um but the base fee is insufficient for the current block yeah so this is a different division so cued and pending that's uh like per account thing and it's about the ordering of of like sequential transactions but uh so there's there's like a big heap for all the or we had one big heap for all the the remote transactions uh and uh and yeah so that was so that's that that that priority heap was for for like eviction of underpriced very low price transactions and this is what has changed and this is now that uh works that yes if if if it falls out from one queue that is based on current miner reward then it still has a chance to stay in the second queue that's based most that is just based on vcap on max fee so yeah and this is a new queue and is this additional queue this new queue does that consume additional queue i'm sorry um sort of slots like we have yes 4 000 now for the pencil we did not want to break the existing situation so we raised the mempool's size slightly so now we have a 4 000 sorted by current miner reward and an extra 1000 sorted by fee cap which is i think affordable and uh and it's also guaranteed that it will not work any worse than before at least if the code is not broken or something yeah great thank you for the clarification so one slight verification that i wanted to make or precision is that uh so currently um this uh this cue split isn't really a split isn't really introducing any new cues rather what it does is it just changes the eviction algorithm so previously when the queue was full i mean depending you have 4000 transactions queued up for execution and another one arrives then that one actually needed to push something out and then if there was something cheaper then it pushed that something cheaper out and with the new algorithm we have a combination that if let's say i have 5 000 transactions because that's the new limit then if the new transaction pushes something out tip-wise from the 4000 then it gets included and if it if it cannot push something out tip-wise and it can try to push something out from the worst 1000 maximal cap wise so it's just playing around with the eviction rules but otherwise structurally the transaction remains exactly the same any more questions on the gas price article there was one other thing um on the agenda so i just want to make we have 10 minutes um so it feels like a natural transition but uh yeah i i do have one other comment go ahead i've seen a lot of people comment that they want to avoid centralized oracles which i am 100 on board with i think the thing to keep in mind is that we need to drop our understanding of the old system and think about the new one in the old system in order to build an oracle you need to basically monitor the pending pool have a access to large amounts of data and you know the flow of transactions it was really complicated these new oracle oracles should be mostly implementable as just a javascript library like it'll be like three functions long and you can just copy and paste it into any piece of code we can have you know gists that have them there'll be githubs that have them et cetera you don't need this high frequency data access the one exception of that is you do need to know what the base fee is and so i do think the clients should return the base fee for the next block and you do need to know what that minor estimate is that that one is like a data problem and so i do think there's value in in the clients returning data about that once we return those two pieces of data though everything else should be calculatable with a small javascript library like you don't need more data than that like you used to and so i don't think we need to worry about uh centralization of oracle's like we see with gas now and inferior or whatever because the oracle is simplified so much that it fits in a library as long as we have the data we need from the clients and so i would much rather see these endpoints in the clients return that data that we need and this is what rickman was talking about where we need there is some data we do need from the clients and we need endpoints to get that like a histogram for example of minor priority fees um but once we have that data like we can have every wallet can use their own library they have their own little oracle they can tweak it and tune it we can have standard ones that we share and whatnot and there won't be centralization like we don't need to worry about centralization as long as the data is available even if geth doesn't provide any gas price estimator yeah i kind of uh agree that that is a nice approach just explosive data one thing i wanted to still highlight is that uh the basically is exposed already because it's part of the block headers so i mean you can always retrieve the basically of the current block uh i mean if you just retrieve the header you have to basically and you can see whether the block is full or not so you can if you must calculate the basically for the next block you could but i don't think anyone wants to estimate that close to the limit i think some will like it'd be nice if we could have just like the end point that just because in order to calculate the base suite for the next block it is kind of complicated and you do need the full transaction list or you at least need the gas used for the block um if you have the gas used for the block then end the base fee from the previous block it's already there well it had it already yeah oh okay so yeah so yeah that can also be live in the library so yeah just the all you need is the last block then and the histogram of historic stuff i think yeah i i tend to agree that like over time i i think because the estimation was like so complicated and now it becomes simpler like over time it probably makes sense you know like wallets can probably write some of it themselves um but i i guess i do appreciate that like this is like a transition and you want things to kind of be smooth so yeah i i feel like that's probably something like we'll kind of gradually see happen and um and maybe one thing i can follow up on is like how do we actually provide like this kind of just base implementation in javascript that like you know helps you do a good estimation and shows people that like yeah it's not rocket science and we can do it quite quite easily um just because we only have five minutes left though um and uh this is kind of related to the same topic a few folks asked about having a json rpc endpoint for the next blocks base fee um i just wanted to check i guess both from the people here and i know the get team like how valuable and easy that is because it is like it is easy to calculate in a way but it's also like you know you do need to like actually look at the spec from 1559 so it feels like it's maybe something that the the client could could do pretty easily and that like third-party libraries will have to fiddle a lot to get working um yeah so here's what our people's thoughts about like i don't know kind of like base fee for like the next block just retrieve the pending block off already so you and it'll basically just look at the yeah gas use and calculate the basic for the next block so well so in order for us to construct a pending block we need the base fee for any block oh yeah you can just retrieve the bending block and boom you have the basic okay does that work for people here so you get the block with the pending tag and get the basic pergas from there that's the answer okay yeah so that would already expose it i mean if that's not enough we can consider exposing another api but kind of i know isn't that enough i i would be happy to work with rickmoo to just make sure that ethers.js has a calculated base fee from the pending block the latest blocks basically um i think it's simple enough that you know just once javascript has it you can just copy that into whatever your language of choice is it shouldn't be too hard it's already exists in python yeah i mean currently what i've been doing in my current application of eip1559 is i actually just grab uh i get block negative one and take the black the the the base view of that um my one concern with is this get pending block is that new or is that something that exactly like 1559 because part of ethers is right now detecting whether or not the network supports um eip 1559 by checking the previous block if there is a base fee on it so pending has been around for a while caveat there not all clients return the same thing for pending so for ethers i recommend being careful of using that endpoint just because it's not consistent across clients right i mean i can't imagine what the other fields would be so anyways yes yeah neither could the clients they all imagine something different right so standing block has been part of ethereum since forever so actually since forever but get blocked by hash or get blocked by block tag pending my number number uh you you are retrieving block minus one so that's i mean that's an ethers thing if you pass in a negative number ethers it gets the current it uses the the most recent block number subtracts it for you yeah so if you get at least in gambit you got minus two that's the pending block but uh i don't know if you can actually pass it so uh if you just um okay let me just check which end point you eat block by number pass pending the word the string pending as the one parameter and you'll get it thank you i'll try that out it's the same thing as if you would pass the late the word latest in for that just in the same spot i think you might need a boolean as well for whether you want the receipts or the transactions so the only downside i see to to getting the next base fee using the pending block is that you get a lot of unnecessary data but it works from our use case so i'm okay with that well um so if you i mean define not to understand it i mean sure the base key is probably five bytes and the header is 500 so yeah i mean from that perspective yes you do waste a lot of data the question is is that too much or isn't it it's a valid question so i i'm not saying we should not add a gap basically i'm just saying that we can do it currently too so might be worthwhile to see how people use it and then add the endpoint that's actually needed um we have two minutes left any other quick concern that people had they wanted to bring up i just had a quick quick comment or if i'm not sure what the what the plan is after this but um i was struggling to follow along in some parts and so if someone could give me a summary of uh like the it sounded like they're gonna be certain phases there is still a little bit of debate of exactly what the guest client will be providing and it sounds like also that the gas station apis will also be uh providing some fancy extra fancy features potentially or not as a wallet we would still rather prefer to be able to get information easily and digestibly with like rich content from an api if that's possible from geth but without like we don't want to have to constantly be pulling uh on on each of our clients for the last x number of blocks uh so it'd be great you know if both were provided from an api standpoint as well as from the clients directly um but yeah if you could summarize what the phase like the different phases are for uh rolling out that would be great sure so right now or uh oh no like it doesn't have to be right now it could just be like in a summary after the meeting just to make sure that yeah yeah we gotta understand what's happening yeah and i think you know it's still kind of influx but i'll try to to get that yeah and i'll share it on on the discord um yep so one thing that before we close this video um i think michael mentioned that it would be beneficial for gas or ethereum clients in general to expose certain past historical i don't know histograms of who's been paying how much for which miner if we can so i think providing a gas oracle that works on these is kind of hard i mean forget because it's an api that we cannot just change afterwards because if somebody relies on it we're shooting them a network however if it's an api that just provides data that others can build upon that i mean that can remain stable so if we just provide that api that returns a histogram of uh priority fees paid i mean at worst nobody is going to use it but we don't need to change the api it cannot be wrong so i think that might be actually a really good good idea to expose this information then anyone can build a gas circle on top if they want something custom and if something turns out to be nice and something tells us to be stable then we can also shift that within gap and the reason i'm saying is that if we can figure out a reasonable data retrieval to expose from gas then i think it would be nice to add it but that one kind of needs an idea stacked out because ideally you want to have the same data from so micah if you have a suggestion on what data you would like to see i think george also had some instagram idea approach maybe you can manage your ideas and yeah this just to keep it quick and tie things up i think my recommendation is that like i said guest returns just some data that data would be and some of this is already returned so i'm just going to try to be all inclusive here um the base fee of the latest block the base fee of the pending block the fullness of the latest block the fullness i guess that yeah so the defaults of the latest block base field latest block base fee of the pending block and then a histogram of the minimum the lowest gas price accepted by over the last n blocks with full blocks filtered out i think that that full box filtered out i think is critical for getting the use most useful data here and i think with that anyone can build a oracle like with that data you should be able to build most of the types of oracles i've seen people propose um with just like a handful of lines of code in any language a quick idea along with the histogram of um gas prices maybe also histogram of full blocks if that even makes sense or or so i have like so there's someone to know how blocks are i think it's definitely useful and interesting data and i can imagine someone wanting to write an oracle that takes that into consideration like oh you've noticed that you know there's a lot of volatility and block fullness lately and so we're going to change our strategy and so yeah so let's add in a stretch goal would be a histogram of block fullness over and blocks and histogram may be the wrong word i don't know a better word to use for that purpose right now but yeah but we get the yeah the idea for the concept yeah so i think it would be super nice if we could just write up a small brain dump of what we would like to see and then then we can see what would be how we could expose the whole thing because i guess gathering all that data and exposing it is not particularly complicated so it's just more like figuring out what the actual data we want to expose i mean what format um tim if you give me a place to put stuff i can start it off and then let people modify from there yeah okay sure i'll do that uh i'll send you something i'll post opposite the 1559 fee market channel and discord um if folks want to uh comment there uh yeah that would be really valuable so um yeah i'll i'll put together like a hackmd or something that anyone can edit um yeah um great yeah this was pretty helpful um and i suspect you know we'll probably have another one of these calls in like a few weeks uh and once we actually have 1559 on a test net it might also make things a bit more concrete um in the meantime if you do want to just like play in a very experimental way which i think it's fine we do have a devnet called calaveras that's up um so that that's running there's a spec for it uh in the the github specs repo let me just link it here in the chat if anybody wants to check it out um there's you know very basic like rpc support and whatnot but uh it allows you to send the transactions and and if you have your own tooling to kind of play with them um yeah uh that that could be useful just like you know just to mention it if you download also has the flag for joining this color as tesla so you can with a with an unstable build of get you can join it and you can play with the whole thing actually had a quick question as well is there like by call had somebody else running up an rpc no we could just connect to and it also didn't explore will that will that be added to the new card calaveras the explorer is there already i don't know about the rpc node okay yeah the explorer is linked in the spec um and there's an each stats in the faucet as well uh okay last quick question what's the parameter to think death oh perfect yeah yeah and they answered in the chat yeah cool okay well yeah thanks everybody uh and yeah talk to you all or at least part of you in the next in the coming weeks thanks everybody for joining we'll send out an email with the link to the recording and notes if there are or a summary document all right bye thank you thank you