Dynamic Transaction Fee Mechanism Design by Max Resnick (@MaxResnick1)

Transcript

thanks for having me uh those of you who follow me on Twitter may know that I'm not the biggest fan of 1559 and uh this talk will tell you why along with some other very important things about transaction fee mechanism design so just to start us off mainstream transaction fee mechan ISM design by which I mean the body of work that came out around the time that 1559 was being discussed the Tim Ruff Garden paper being kind of the seminal work there has a big problem because it ignores some complexity that exists in the real world and abstracts it away in the

model so in particular it assumes that users are not willing to wait to get on Shain so they come in and they say I want to get on Shane in the next block and in the model they just go away if they don't get in but in the real world uh users actually are willing to wait so classical models the users care about inclusion in the next block but in the real world we observe that they care about inclusion over some time period actually this idea of good things come to those who wait as a popular idea in ads around like the 2000s era so there's a Guinness ad and a a catchup ad

that use this idea but the same idea is true in transaction fees those of you who are developers who post contracts may know that you're willing to wait some time to get your contract deployed because you're going to get a lower fee so some transactions are time sensitive for example you might want a DEX trade that's certainly time sensitive right you you need to trade before the prices change uh if you're trying to buy something at a coffee shop with crypto you probably don't want to wait 30 minutes for that to settle if you're playing uh I don't know poker or chess or something on chain you probably don't want to wait too long for that so these are transactions that are time sensitive but

there's also a lot of transactions that are not time-sensitive like simple transfers posting uh on an L2 posting L2 data uh contract deployment like I mentioned so we have multiple types of like a lot of the uses of the blockchain are here on this slide not on the first slide at least today so the goal for this paper is let's look at transaction fee mechanism design with the added complexity of the fact that users are willing to trade off fast inclusion and low fees so we have two main results which I'll walk you through one of them which

I think is really important and under considerer is that proof of stake networks actually have better ux they actually have less congestion which means lower fees with the same demand and throughput in expected block time which is really a surprising result um but it's basically because of the regularity of the block arrival process and the second which is also a surprising result is that in the Dynamic setting where users face an explicit tradeoff between fast inclusion and low fees $1,559 does not converge to the same price as say the Bitcoin fee mechanism that we had before

1559 and this is something that if you look at the literature around the time of 1559 approval and if you look at like say Barnaby's tweets or even if you talk to a lot of people they say well doesn't it converge to the same price actually Anar who's the next speaker we had a conversation at some point and we were arguing about this which is does 1559 converge to the same price as the standard fee market and actually we're both right because in the not Dynamic case you can prove that it does converge to the right price and there's a recent paper about that uh called uh 1559 is like almost optimal I think is the title of the paper and it shows that in the not Dynamic case it

does converge to the right price but actually in the dynamic case we show in this paper that it doesn't converge to the right price and it actually raises more Revenue than the first price fee Market that Bitcoin has so here is a quick timeline of the important events as most people see it so we have the mainnet launch between the time of mainnet launch and London hard Fork we had the same uh fee Market that Bitcoin uses now which was basically you put in a priority fee and you pay your priority fee and the block builder takes all the all the transactions and builds the best block with the available priority fees and they get all the priority fees for themselves right and then in 2021 we

have the London hard Fork which introduced 1559 and that moved us to the current Dynamic reserve price mechanism that we have now but there's a third important event which is the merge which moved us from the static block arrival or sorry moved us from this like memory list block arrival process that came from proof of work into the current one that we have which is like a 12C heartbeat and I think that's like also very important for uh transaction fee mechanism design and user experience on ethereum so what do I mean by exponential arrival process specifically when talking about blocks basically if

you look at this chart up here it's the convergence of this arrival process so if we say there's probability one that will arrive in the whole interval and then there's probably like one half that will arrive in the first half of the interval probably one half will arrive in the second half uh and we keep doing that and and go all the way down to nals Infinity that is an exponential arrival process and mathematically that is a very good model of what block arrivals looked like before the merge so this is the week before the merge and the week after the merge of course after the merge we moved to fix slots and almost every time that the weight was 12

seconds a few times slots were missed and then it was 24 seconds and I guess you probably can't see it but there's maybe one or two observations where two slots in a row were missed right but almost all the blocks arrived on the dot 12 seconds and before we had this exponential looking thing so the key thing here is that exponential is a memoryless arrival process so the expected waight time time for the next block arrival doesn't depend on how long you've been waiting so if I went to Bitcoin today and I go and submit a transaction the expected wait time for the for the next block to come is 10 minutes no matter whether there hasn't been a block for 20 minutes or not it's still 10 minutes whereas if I go to

ethereum and I go 6 seconds into the slot and I submit a transaction the expected wait time is 6 seconds if I go 5 seconds in the expected weit time is 7 Seconds so that is a big difference between a proof of stake blockchain and a proof of work blockchain so just to give you an idea proof of stake is like waiting for the subway in New York City like occasionally it won't come but most of the time it comes and it comes on time and it it comes every 5 minutes or so and proof of work is like waiting for an Uber in Dubai so no matter how long you've been waiting the expected weight time is always like the same um so here's our our main results for this

which are that if you have a blockchain with the terministic block arrival it has lower congestion and lower fees and what I'm showing here is actually the bids which correspond to the fees that users pay and the orange lines are for the deterministic setting like proof of stake the blue line is for the exponential setting like proof of work the memory list setting and you can see that the orange lines are much lower than the blue lines and actually the difference between these two plots is how many transactions there are in a block and we're able to solve analytically for one transaction in a block and for two transactions in a block once you go higher than that the

analytics break down due to some uh non-deterministic like you you have a quadratic formula you have a cubic formula you have a quartic formula and you don't have a quintic formula and that's like a very famous theorem in math but that's the reason that you can't go too much higher than k equals 2 for analytic results and if you're interested in those results you can check out the paper okay this is the next set of results that I'm moving to now and I'm going to try to do the simplest possible explanation of 1559 um here's a representation of an ethereum block at 15 million gas that's our gas Target right now 30 million gas is the

gas limit so we can theoretically go up to 30 million gas but we're targeting 15 million gas on average the way we achieve the target is that if the block is more than half full we're going to increase the price for the next block and if it's less than half full we're going to decrease the price and in particular you can see the formula I put it because there's a diverse audience here we have some the mathematical expression and the code expression um basically to give you an idea if the block is 100% full then the price will be multiplied by 1 + 1/8 if it's 0% full it's empty it will be multiplied by 7/8 if it's you know

1.5 full it will be multiplied by 1 + 1/16th Etc so that's basically the the update Rule and as you can imagine uh it looks kind of like this you have a slightly less than full block the price goes down you have a a more than full block the price goes up and so on as you can see so that sounds great we're going to increase the price when there's too much demand and we're going to lower it when there's not enough and we're going to find the equilibrium right well I guess we kind of did that but it looks like there's something else going on here which is our update rule can be too fast and that's why we see these oscillations so this plot is

actually just a th000 blocks so uh three and a half hours and you can see how spiky it is I think there's 32 spikes here I counted and that seems a little weird to have 32 spikes in 3 and a half hours like this I think it's it's hard to imagine that this is accurately reflecting like some underlying changes in demand and it's more likely that the model is Fooled by Randomness in the arrival process of transactions and that's you know an interesting thing that's going to be what leads to the result that these don't converge to the right prices so one 1 18 which is the update parameter is too fast and basically the

way that the cord have set parameters is they just choose some like random n and then they do like 2 to the n and then that's the parameter um I mean it's I'm being a little factious but actually there is like a fascination with two to the n and this parameter was chosen at the beginning and like has not really been looked at that too much and I think it's too high right now and basically time sensitive transactions are going to have to pay higher fees during spikes because if if you're in a spike and you're time sensitive like you're it's too bad you just have to pay the the fee like if you're just like at block 180 here you just have to pay the high fee because

you're time sensitive right um and if you're not time sensitive then you're going to wait for the price to go down but if you're a time sensitive guy you can't pose as a Time insensitive guy because you're going to have to wait and you're time sensitive so what does that look like in the results this is going to take a second to explain but if we have a model where there's two types of transactions there's High Time sensitivity types and low time sensitivity types the load which is the Rival rate of high sensitivity types is on the x-axis here and similarly for the low sensitivity Types on the y- AIS on the

right here is the priority fee mechanism so that's similar to bitcoin or what we had before, 1559 on the left that's what we have with 1559 and we have some simulations here you can see that for the same load the average number of transactions in the queue as we get to stronger and stronger load it blows up in the 1559 case so in the top right which is where we're uh almost at full load you can see it's six on the left which is the 1559 case and 6 on the right which is the priority fee case and what that means is it's similar to like in an airline can charge more for business class by making

economy less comfortable so if they reduce the leg room in economy then they can charge more for a business class because they've like penalized you more for not upgrading to business class and that's similar to to what this looks like so that's like the United business model and the Emirates business model is we're going to make business class nicer um but this is like 1559 is more the United business model where they just like Crush you in this in the economy seat and then make you pay for business class so you get more room so just to summarize in the dynamic model not the static model where users are willing to wait for lower fees time sensitive transactions end up paying more under1

1559 and time insensitive transactions have to wait longer and these are necessary for each other otherwise the time sensitive transactions would have would be able to pose as time insensitive transactions uh and that means that 1559 actually has higher Revenue than the standard uh priority fee model which is not something if you remember at the time 1559 came out Fe fees were really high and people were really mad about it and actually a lot of people said that 1559 would lower fees which obviously was not true but if you said 1559 is going to raise fees at the time I don't think would have been very politically palatable so it's interesting that we find this out now that it actually does

raise fees uh because the the update parameter is too high so if you're interested in what can we do about this in the spec which you can read about on our website mechanism. org we talk about a special mechanism called uh Dynamic vcg which is a way to do an alternative to 1559 and we also talk about how to update the update parameter uh for 1559 to be slower so that we don't run into this issue thanks for coming and thanks to the organizers for having me awesome yeah check out his PDF