Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Tim Roughgarden: EIP-1559 – Tackling the Gas Fee Problem on Ethereum

Episode Date: May 7, 2021

Ethereum Improvement Proposal (EIP)-1559 is a proposal to make several tightly coupled additions to Ethereum’s transaction fee mechanism. Central to the design is a base fee, which plays the role of a reserve price and is meant to match supply and demand. Every transaction included in a block must pay that block’s base fee (per unit of gas), and this payment is burnt rather than transferred to the block’s miner. The base fee is adjusted after every block, with larger-than-target blocks increasing it and smaller-than-target blocks decreasing it.Tim Roughgarden is a Professor of Computer Science and member of the Data Science Institute at Columbia University. Tim did an extensive game theoretical review of EIP-1559 and joined us to chat about what the proposal is trying to do and why, and how it is doing it.Topics covered in this episode:What Tim's research focuses on and how he became involved with blockchainWhat made him interested in the fees problemThe current fee system on Ethereum - the first-price auction and base feeEIP-1559 - the problem it solves and how it does itIncreasing and decreasing of block sizesThe threat of miners colluding to drive down base feesDeep dive into how the proposal worksWhat are some alternatives to EIP-1559Episode links:Tim RoughgardenEIP-1559 on GitHubAn Economic Analysis of EIP-1559Tim on TwitterSponsors:Solana: Solana is the high performance blockchain supporting over 50k transactions per second to power the next generation of decentralized applications. - https://solana.com/epicenterExodus: Exodus the easy-to-use crypto wallet available on all platforms and supporting over 100 different assets. - https://exodus.com/epicenterParaSwap: ParaSwap’s state-of-the-art algorithm beats the market price across all major DEXs and brings you the most optimized swaps with the best prices, and lowest slippage - http://paraswap.io/epicenterThis episode is hosted by Friederike Ernst & Sunny Aggarwal. Show notes and listening options: epicenter.tv/390

This is Epicenter, Episode 390 with guest Tim Roughgarden. We're here with Tim Roughgarden today. Tim Rothgarten is a professor of computer science at Columbia University, and he has written a pretty exhaustive paper on EIP 1559, which we'll talk about with him today. But before we go to the interview, we'd like to tell you all about our sponsors this week. Our first sponsor for the week is Solana. Solana is a next generation blockchain with lightning fast blocks and fees less than a cent per transaction. Scalability is perhaps the biggest challenge preventing crypto from becoming the backbone of the world's financial system.

And today, Solana, the best solution we have. So go to Solana.com slash Epicenter to learn more. We would also like to thank Exodus. Exodus is an easy-to-use wallet, which supports hundreds of assets and has innate apps for all platforms, including iOS and Android. And as a fully non-custodial wallet, they're firm believers in the not your keys, not your coins mantra. Go to exodus.com and give it a try. We would also like to thank Paraswap. Paraswop just came out with a huge update that's even faster and more liquid. It's cheaper than Uniswap and comes with a new gas token

that can cut your gas fees by up to 50%. Plus, for all our listeners, Paraswap offers 50% gas refunds for the first swap of at least one ether. Make your trade and go to Paraswop.io slash epicenter to claim your refund. So, hi, Tim. It's super good to have you here. Hi, great to be here. We've actually had this scheduled for a long time, and EIP 1559 has been in the wax for quite a while. So, Tim, you're very much not our usual guest. You're a computer science professor at Columbia. Tell us what your research focuses on.

Sure. So once again, thanks very much for having me. A pleasure to be able to speak to your audience about EIP 1559. So I have two main areas of expertise, you know, which sometimes overlap and sometimes don't. So one of them is just in algorithms. So many people sort of know me from my courses and research and books on, on algorithms, as is taught in a typical computer science curriculum. And then the other one, which is the part which really relates to blockchains is, you know, my whole career, you know, 20 plus years, I've been very focused on interactions between computer science and economics. And in particular, I'm really passionate about sort of applications in computer science that require game theoretic or economic reasoning. So my training is totally

in computer science. I'm just sort of a total auto-didac on the game theory and economics side, but it's something I've been doing for a couple decades now. And I don't think I have to tell anyone in your audience that, you know, blockchains are sort of, anyone with that interest, it's just an incredibly exciting opportunity. Were you involved with like things, before like your work on 1559 or was 1559 until your first foray into researching blockchain from like a very academic standpoint? Yeah, it's a good question.

So it's kind of, it's been like a slow build, I would say. So I started dabbling in it maybe about five years ago. So, you know, right now I'm at Columbia, but before I was at Columbia, I was at Stanford in the computer science department for about 15 years or so. And literally I shared a wall with Dan Bonnet. and, you know, we had, you know, we were all part of the same sort of theory group. So we wrote a paper together back in 2016, which appeared in financial crypto, which was about

sort of incentives in mining pools, you know, in Bitcoin mining pools. And so that was fun. And I definitely started teaching more about really Bitcoin specifically in some of my undergraduate courses, because, again, it's such a great illustration of sort of, you know, the role that game theory can play in computer science applications. And, you know, I sort of was following, I'd say, you know, 2016, 2017, I sort of was following along from sort of a hobbyist sort of perspective. You know, number one, because I had some other kind of big projects I wanted to finish, you know, books I wanted to write and papers I wanted to write. But number two is I was hedging my bets a little bit.

So, you know, the question was, you know, would there be, like what was clear is that, you know, doing top rate research on blockchain protocols would be sort of a multi-year endeavor. there was just so much to learn. And I have sort of very high standards. So I really wanted to do it right. And so given the cost that it was clearly going to be needed to do good work in the area, I wanted to make sure that there was going to be enough intellectual depth that it would be, you know, that's something I could work on for sort of, you know, several years and it would find it really fascinating. And then I'd say maybe, you know, end of 2018, being in 2019, I became basically fully convinced at that.

I just was totally sold. I was like, you know what, this is going to be at least five. five years of great work, probably more. You know, totally worth it to sort of, you know, just sort of dive in. So I'd say the last sort of, you know, year maybe I've been focusing more and more of my energies on blockchain research. And so what brought you to this fees problem? Why was that the, obviously there's a lot of academics in the space, but I think, you know,

people tend to focus on like, you know, developing new consensus protocols and things like that. But this usually isn't actually that much going on on like thinking about fees. So why was that the problem that attracted you? Right. So a couple of things. So I think it's a great point that, you know, I mean, there's a lot of really nice academic research around sort of blockchain. Certainly one of the most vibrant ones has been, you know, consensus protocols, you know,

formal properties and sort of new designs, which makes total sense because, you know, I mean, you know, consensus protocols and distributed computing, that's been sort of a, core part of computer science for a long time, right? There's really a rich history there. A couple of Turing awards have gone to researchers, basically for consensus protocols. And so there's a massive community where sort of this is, you know, this is sort of what they did anyways. And then along come blockchains and it's, you know, and it's just, it's a paradise, right? Because there's, you know, you know, Satoshi comes up with a new consensus protocol, tried to analyze it, or even just this sort of shift of focus from the

traditional permission setting or the permissionless setting. There's all these new questions you can ask. So it makes total sense that that happened very quickly because it plugged in so neatly. There's a community that really did not have to learn much new stuff to start doing really interesting research on the consensus side. And, you know, I feel like there's a pretty similar opportunity on what I would characterize broadly as the market design side. You know, so transaction fee mechanisms, that's one example of sort of creating a market. In this case, it would be the market for, say, you know, EVM computation, you know, or just space on the blockchain. But especially, you know, once you start, you know, once you start thinking about sort of application level stuff, you know, it's obvious there's just tons of, there's just enormous need for sort of people who are all in on sort of crypto, but also really know a fair amount about market design.

And, but I agree with you that's that, you know, there's the migration of academics to sort of work really seriously on market design and blockchain has been slower than on the consensus protocol side. That said, I think you're going to see it speeding up in the next year or two. Obviously, there are incredibly smart people in the Ethereum ecosystem, but it's all very unfurmo and very meme-driven. I don't come from the computer science background, but I also have an academic background in physics, and to me that was a major culture shock, despite the fact that physicists are not known for being particularly,

particularly tack up or attached to traditional business ideas. How was that for you, Tim? Honestly, it was really exciting. So, because it was one of the things that actually I took notice of very early on. In maybe 2016 or so, I just saw, you know, tons of super smart people, you know, turning away from, you know, what could have been a ride into the sunset at Google or whatever other kind of cushy tech job they had, dropping everything and going into crypto, right? And that's been happening for many years.

And that's, you know, that's usually a very strong signal that something interesting is happening. So I totally agree with the comment that there's just like super high IQs for people who work in crypto. I also agree, you know, it's true. It's many, many people don't necessarily have like a PhD per se. But, you know, I view that as kind of, you know, neither here nor there. And I got to tell you, you know, being sort of an academic, you know, sort of, you know, an ivory tower or whatever, you know, In 2017, I started getting cold calls from people building things saying, like, we really, really need a computer scientist who knows about mechanism design. And, like, you said, I mean, it's just not that common. You get sort of a call from, like, you know, the outside world saying, like, we have

incredible demand for your very specific, you know, expertise. So, and that's another thing. I started getting those calls. I was like, this is not going to happen every day. Right. So it also became just clear as more sort of a moment in time for someone with my kind of skill set. Like I said, this can be huge opportunities here for people interested in that. So computer science economics back and forth.

Another thing I'll say is, I mean, it was interesting is, you know, I mentioned briefly that I have sort of online courses and algorithms. You know, and those have, you know, really like over a million people have taken them. They've kind of run for eight or nine years. And so through those courses, I've interacted with tons of, let's say, you know, non-traditional students. Right. So people who are not college students, people who may be majored in history, but now are trying to convert. to being a programmer and they just, you know, and algorithms is this hard subject that they need to know.

They don't have to know how to do proofs by induction, but they kind of need to know, you know, how to pass their technical interviews. So that was like many years actually of communication with, with, you know, you sort of, as a professor, like teaching undergraduate students is kind of a funny thing, right? It's hard to keep yourself honest because they're a totally captive audience, right?

You've got all these 19-year-olds, you know, they want to get A's, you know, they don't really, you know, they don't really know what their outside offers. are at that point. So you can kind of get away with a lot if you're just teaching undergrads. And so somehow, you know, when you're talking to people that, you know, maybe have families, you know, and are really busy, but, you know, still really want to learn. I mean, somehow, I mean, I feel like I evolved tremendously as an educator sort of through that process. And there's parts of sort of, you know, doing kind of formal work in crypto that sort of reminds me of that.

So the first thing is, I mean, I really do feel like, you know, even if people don't have formal academic backgrounds, I feel like there's a lot of just, you know, relevant academic work is held in very high esteem, right? So I don't feel like, oh, I never get this since like, oh, you know, you're a, you're a fancy professor, right? You know, we don't want to hear what you think or something. I've never gotten that vibe at all. It's more kind of like, you know, just excited. Like, if I actually start working on problems that, you know, people care about, I just get very positive feedback about it. People just seem very excited. And moreover, like, you know, it's because they're so smart, it's very easy to, I mean, it is, you know, I'm not going to maybe like,

right proofs, you know, I'm not going to have a tweet storm, which is like a full proof or something. But as far as, you know, what's really important, you know, the really important takeaway messages has really been very little trouble, I'd say, communicating that to the people who are really interested. So I found it to be, obviously, I still interact with academics and my PhD students and all that kind of stuff. But, you know, this adds like a totally new dimension to, you know, me communicating about technical material. And as a result, it just, I mean, it leads to sort of personal growth. It's like yet one more community that I feel connected to and that I gain experience with sort of how to best, how to best explain different technical concepts. Let's get to our sponsor,

Solana. Now, this is a special ad for me to read because I've been a deep supporter of this project since meeting the Solana team back in 2018. I invest personally in the project and my company course one is super deeply involved in the Solana ecosystem, including running the biggest validator. So what's so cool about Solana? Well, we all know that scalability is the single most important issue facing the blockchain industry today. And the Solana blockchain is an amazing solution for it. The network supports thousands of transactions per second with 400 milliseconds block times and

over 500 validators. The special thing about Solana is also that it's not a sharded blockchain. It's a single blockchain hyper optimized for performance. So that makes it really easy to maintain. composability between all of the apps on Solana so that they work together seamlessly now and forever. The Solano ecosystem is growing at a rapid pace and it's a great place to build your project or just get involved with the community. So go to Solana.com slash Epicenter to learn more. Let's talk about fees on Ethereum, which we're here to talk about. So maybe before we dive into

1559, let's talk about the status quo and kind of explain how the fee system currently works. So as an economic computer scientist, you describe fees on Ethereum currently as a first price auction. Can you explain to us what that is? Sure. And maybe I should be used to just very briefly to go back one step, you know, kind of just let's all remember why is there a transaction fee mechanism at all. Like why even bother having that component, you know, in Ethereum? And the reason is because, you know, with Ethereum, you really have the problem that you want, which is that, you know, demand exceeds supply. Okay, so by supply here, I mean, you know, the amount of, you know, Ethereum virtual machine computation, which is available. And so, you know, there's, you know, on average, one block

every 13 seconds or so. In one block, you know, there's a fixed amount of gas. I think it just got raised to 15 million gas. Gas here being kind of a proxy for the amount of computational and storage costs. And so that means it's a finite resource, right? There is 15 million gas every 13 seconds or so on Ethereum and nothing more. So that's the supply. And then the demand is just people who would, you know, like to see their transaction get sort of executed on the Ethereum blockchain. You know, and at a price of zero, the demand for space on the Ethereum blockchain would be way, way, way more than just 15 million gas worth of transactions per 13 seconds. So that's the first thing is you can't include everybody. You have to include some people and exclude some others.

And then the question is, who do you want to include? Who do you want to exclude? And one very sort of natural approach would be like, well, let's try to include the transactions for whom, you know, inclusion is the most valuable. So the transactions that generate the most value for the person sending the transaction. And that's exactly what transaction fees accomplish. Right. So, you know, if you have a very valuable transaction, you want to get across the Ethereum blockchain, you can signal that it's a very valuable transaction to you by offering to pay, you know, non-tribually large transaction fee. So when you have transaction fees, you know, you know, transaction fees, it naturally screens. It separates the population of transactions into the valuable ones,

those willing to pay a non-trivial fee, and the sort of not so valuable ones, the ones that aren't willing to pay that. So that's why you need transaction fees. And one thing that's a very important point, actually, which is that, you know, probably at some point we'll start talking about sort of transaction fee revenue and, you know, where does it go and how do we feel about it? You know, and I just want to point out that really, you know, that transaction fee revenue is generated primarily as a side effect of other things that you really want. So what you really want is you want the blockchain to be efficiently utilized. It meaning the blocks are full, and they're full with the most valuable transactions

that are out there. And the only way you can accomplish that, the only way to actually sort of separate the wheat from the chaff is to charge prices, which then generates revenue. So it's really just sort of a necessary evil, if you like, of trying to have an efficient allocation of the Ethereum blockchain. Okay. So that's sort of why you need a transaction fee mechanism. And, you know, Ethereum's current transaction fee mechanism is basically copied from what Nakamoto used in Bitcoin.

And it's really, I mean, it's a very natural, I mean, it's kind of the perfect thing to do in a first cut blockchain. I mean, it is, I think, the natural starting point. And it's called a first price auction or alternatively a pay as bid auction. And so the way it works is just when you submit a transaction to the Ethereum network, you or, you know, your wallet on your behalf, submits with that transaction a bid. So an offer to pay a certain transaction fee, which is denoted in gway per unit of gas. Then it's really up to miners, right?

So miners are sort of monitoring the mempool. They see all these different transactions. These transaction has a bid attached to it, a gas price is willing to pay. Miners can pack the block however they want. It's natural to expect, and miners generally do roughly this. It's natural to expect miners to pack the block full

with the transactions that are offering to pay the highest gas prices. So that's the first price auction. As a creator of a transaction, you are yourself responsible for coming up with this offer. You have to decide how much you're willing to pay. And then if you're included in a block, that is, in fact, what you will pay. And in fact, you will pay that directly to the minor of that block. So that's the status quo. So as a user, what's my best course of action?

How do I determine what gas price I would like to pay? Yes, that's under the status quo you mean. Yeah. Yeah. So it's a tough question, to be honest. So, you know, I think, you know, I think probably the broadest, probably a lot of the audience, you know, won't necessarily, you know, when they interact with the Ethereum and blockchain, they don't necessarily actually pick the transaction fee, right? They'll more have that be set automatically by your wallet. So I'm sure many of your, much of your audience has experience with, say, the Metamask wallet,

where it basically suggests, you know, what gas price you should offer. And then even if you've ever clicked on, I forget if it's called advanced or whatever, but, you know, you can sort of expand it and it gives you three options. It says, oh, if you're willing to wait a long time, here's this lower gas price that we recommend. And then here's an average one. And then if you really want it included immediately, here's a higher gas price that we recommend. So if you think about it, it must be that the, developers who designed Metamask had to sort of tackle that exact same problem that you're

now asking. Like what, you know, what actually should you bid? So they presumably have some algorithm that gives its best guess and then and then sort of offers it to you. And something which, you know, was known way before block. I mean, first price auctions obviously have been around way before blockchains. And, you know, in the old applications and the new applications, it's just, it turns out to be a very difficult problem. I mean, and, you know, and it's just, it turns out to be a very difficult problem. I mean, in a perfect world, you could, you know, telepathically know exactly what everybody else was bidding and then bid just high enough so that you would get included in the block. So that's what you wish you could do. So if you knew what everybody else was bidding,

then it wouldn't be a hard problem. You just bid the minimum amount necessary for inclusion. The challenge, of course, is that you do not know what sort of the, you know, newest arriving transactions you're going to have for their bids. You have to sort of guess that. And that, of course, is going to depend on, you know, demand, and demand is fluctuating often quite rapidly in Ethereum. So, and you'll see this. I mean, I'm sure much of many, members of your audience will have had the experience where you use metamask's recommended, you know, gas price, and then all of a sudden, you know, your transaction hangs for like 45 minutes. And that's because, you know, it was using sort of the past to try to predict the future,

and you were unlucky enough to submit your transaction exactly in a period where the gas price is sort of shot through the roof. And so you're using this kind of. of gas prices. It would have been fine five minutes ago, but it's not fine. It's not fine now. So that's the challenge. You wish you knew what other people were bidding so you could just barely outbid them. That requires guessing what people are going to be bidding in the next block. And, you know, all you can do is make an educated guess and you're going to be wrong some portion of the time. Have you looked at how much users spend too much? So basically, if you look at how much gas users actually spend, and what would have sufficed?

to get them included. By how much do they overspend in, you know, in percentage terms, do you know? That's a good question. I've only seen kind of anecdotal discussion of that. And I have to say, it's a little hard to know. I mean, so, you know, you can go to Ether scan and check out various blocks. There's no question you see a widespread in the gas prices that people pay. Now, there's various reasons for that, and it can be hard to know what's going on.

You will see transactions that have a gas price of zero. of. And that may be because the miners submitted, you know, created that transaction itself, but included its own transaction and didn't bother with a transaction fee. It could be there is some other kind of off-chain agreement, off-chain way that the minor was getting paid. And then you will see transactions with extremely high gas prices. But often, you know, that's because they're transaction, you know, basically they're vying to not just get included in the block, but to be, for example, first in the block. If someone's executing a front-running attack or something like that.

So you look at, you know, you look at Evis scan, you see the sort of distribution of gas prices and can say, okay, well, so, I mean, you can do a heuristic, like, let's filter the zeros. Let's filter the ones where it seems like it's the minor or some off-chain arrangement of the minor. Let's filter any stuff which is crazy high. And then let's look at what remains. And let's agree that, you know, that's our guess of who the normal users are in this block. And even there, you definitely see, you see big spreads. They are not tightly concentrated.

Is it a factor of two or four between the men and the max? I don't remember. But any block that you see, there's surprisingly little concentration in the gas prices that even sort of the middle part of the distribution are using. It's a good question. I mean, like, I love your question. I'd love to see someone make a serious empirical attempt to get a number on that percentage. Let's get to our sponsor, Exodus.

Exodus is a fantastic cryptocurrency wallet that strikes a right balance between ease of use, security and great features. You can get Exodus on the iPhone, desktop app, web app, Android, whatever platform you use. It's a non-custodial wallet and that is so critical. Because what's the point of crypto if you don't control your own assets? With Exodus, you always do. They're old school and they've been around since 2015. Over 1.2 million users rely on Exodus so you know that they've stood the test of time. They have support for OECD. over 100 different crypto assets. And from within Exodus, you can easily change one different asset to the other.

They also allow you to buy crypto with Fiat. And they even have a great offer where you can buy up to $500 worth of crypto through their iOS app and pay just $1 in fee. So go to exodus.com slash Epicenter and check out their wallet. We want to thank Exodus for their amazing support of Epicenter. One piece also is that like, you know, the gas price is used, there's almost like two auctions going on in parallel. There's one which is just to be included in a block and that my transaction will be executed. And then the other is about the ordering within a block, right, where it's like, you know, some people are playing a game. You know, oftentimes, you know, if I don't really care, I just care about my transaction happening.

But there's other people who are playing a game where they're like, oh, I want to be the first in this block for XYZ. reason. Has there been any, like, attempts to, like, sort of, you know, separate out these two, like study these two markets independently of each other? Yeah, that's a great question. I agree. That's also my mental model for the blocks. It's almost like there's this kind of, right? So there's like 15 million gas for the transactions. And some portion of that, which is not zero, but also not 15 million, is engaging in so-called priority gas auctions, you know, basically trying to really over, not overpay, but pay a lot. lot to signal that they don't just want to be included, but they want some particular position.

And there definitely are, there have been attempts to measure, for example, you know, you know, what fraction of the overall fees come from the group of very high paying position dependent transactions versus just kind of normal transactions. And I don't, you know, again, you have to make lots of assumptions to come up with a number. But, you know, the bottom line is it's, it's, you know, well bounded away from both zero and 100%. So there's a significant fraction of fees coming from, you know, these priority gas auctions. There's a significant fraction of fees, or at least a significant fraction of the gas in the block, let's say, is not paying fees, you know, are just paying for inclusion or not playing for positions. Honestly, I think, you know, sometimes they get questions like, you know, what are good open questions, you know, sort of for mechanism design.

in the blockchain space. And I think this is actually a great one, which is suppose you want, you know, and just, you know, just take it from like a clean slate approach. Like just say from scratch, right? So I'm not sure originally the creators of, you know, Bitcoin or Ethereum necessarily envisioned these priority gas auctions. Maybe they did. I'm not sure.

But in any case, now we know that they're going to happen in a general smart contracts platform. And you get asked the question, knowing that, would we go back and actually somehow design a different transaction fee mechanism where the intuition would be, you know, you know, let's because right now it's sort of very restrictive all the only vocabulary you have to communicate your preferences to aetherium's transaction fee mechanism is the one number the one bid okay obviously off chain you know you can try to communicate with a minor and say more stuff but you could imagine that in the on-chain transaction fee mechanism you allow transactions to have a richer vocabulary

right so just like a very sort of trivial thing would be like maybe you have an optional second bid which is specifically for the first slot of the block for example And so that whole space is really completely unexplored, at least from an academic perspective. So that's something I'd love to see, to see research on. So that's the status quo. Let's talk about EIP 1559. What's the proposal? Where are we headed?

And what does the proposal entail? So we should probably take this in pieces because it's honestly, so EIP 1559, it really proposes multiple tightly coupled changes to Ethereum's current transaction fee mechanism to first price auctions. And so, you know, one question would be, what is it trying to accomplish? Another question is, like, how does it work? So how does it accomplish that? So let me start with the first question.

My understanding is that the origins of EIP 1559 is to solve exactly the problem we were just discussing that it's hard to figure out how to bid in. in first price auctions. So even the very smart people, sort of working at Metamask, have only, you know, they haven't fully solved the problem. And so, you know, really you'd like to have, you know, you know, bidding for space on Ethereum being as easy as just like buying something on Amazon, right? So when you go to Amazon, you pull up a product page, like for a book, maybe the book

costs 40 bucks. What's the cognitive burden on you? It's really just a binary decision. Is this book worth $40 to me or not? And either way, it's okay, right? You get to make up your mind either way, and you're not going to regret your decision. Either it's worth $4 or it's not, in which case you buy it or you don't. And you'd love it for sort of, you know, obviously not everyone's going to get their transactions

into the Ethereum blockchain, but you would love it to be as transparent as possible. So you would love it if you sort of transaction shows up, you know, and Ethereum promises you, look, next block, you know, if you're willing to pay a gas price of 90 way, you're going to get in. If you're not, you're not going to get in. And it's totally up to you. Just pick either way, but you'll get in if you, if you've been. bid 90, right? Which is not true now, right? You bid with MetaMass tells you to bid and you may or may not

get in. You don't know. Depends on sort of fluctuations in demand and who knows what else. So that, my understanding is the origin story of EIP 1559. You would like to change the mechanism and change the bidding mechanics. So it's just obvious in some sense what gas price you should include with your transaction. That's what I think of as the original motivation. Now, interestingly, to accomplish this goal, you have to, as I said, make several tightly couple changes. And there are actually some side benefits of the other changes that you make in the service of that goal. In fact, at this point, I think some of those side benefits have really even maybe eclipsed in sort of the community's mind, the importance of the original goal of easy fee estimation. And the main one I'll foreshadow just right now is a lot of people are excited about EIP 1559 because they think that it in

the tokenomics of the Ethereum network, specifically through, you know, as we talk through how it works, we'll see that some portion of the fees are actually burned, meaning they go to nobody, so they don't actually go to the miner of the black that includes those transactions. The fees are literally just removed from the circulating supply of Ethereum. So who likes that? Well, anyone who's a holder of Ethereum likes that, because that's sort of like the protocol doing a buyback, right? So like in the spirit of a stock buyback.

So by decreasing the supply, you know, in principle, at least, that increases the value of all of the remaining supply. So Ethereum holders see this as, you know, potentially very impactful on sort of, you know, the price of Ethereum and also just generally connecting the value of the Ethereum network to the value that's flowing through the Ethereum network. All right. So that's the what is it trying to do. So now that now we can move on to how does it do it. Okay, so I would say there's kind of three main ideas. Okay, so three parts to it. So part number one is there's going to be what an Ethereum is called a base fee in each block. Okay, in auction theory, you would call it a reserve price.

Okay. So the base fee is like a price floor. It's the minimum gas price, which anyone's going to be able to get away with, to be included into this block. Okay, so like maybe it's 90-gway, and then according to 1559, if you bid less than 90, you were literally ineligible to be included in this block. You're just sort of filtered in effect from consideration. That's the base fee.

So this is meant to be that posted price you see on Amazon. So that's the goal. A couple questions now is, all right, so some transactions will pay the base fee, some won't. One question is just how is this base fee computed? Okay, so we'll get to that in a second. I guess the top order bit with how the base fee is computed, what's totally crucial is that the base fee is a deterministic function of the history of the blockchain. So all of the predecessor blocks on the longest chain, okay, that this block is extending.

And in particular, the base fee of a block is completely independent about all of the contents of that block. The minor of that block cannot influence the block's base fee. The transactions included in that block do not affect that block's base fee. So that's the higher bit that's super important. It's a history-dependent, present-independent base fee or reserve price. We can talk more about specifically how it's computed if we want in a little bit. Okay, and so then there's a question of, you know, what happens to the revenues generated by that base fee, and these are exactly the revenues that get burned. Okay, so any transaction that agrees to pay the base fee, say, have 90 way per unit of gas. All of that ether will just disappear. Okay,

will be burned. Now, you know, why do we do that? Do we do that because we like fee burning? So actually, even if you don't care about fee burning, it turns out the game theory really demands that these fees are burned. Or at least, the game theory demands that these fees do not go back to the minor of that block. Okay, perhaps they could be redirected elsewhere, but they cannot go to the minor of that block. Why not? Okay. So the issue is, is that if you just tried to like have this base fee disallow transactions that were not willing to pay 90, but then everybody was paying 90 or more was included and all of that got transferred to the minor. The problem is through an off-chain agreement, the minor and the creators of these transactions could totally evade

the base fee. So like say I'm a transaction and I only want to pay 60. I don't want to pay 90. I could just have an agreement with the minor off-chain that says, look, you know, I'll pay 90 on-chain so that I'm eligible for inclusion, but then you need to refund me 30 off-chain so that my net payment is 60. So as a result, through this sort of off-chain evasion, you do not succeed in preventing the low-value transactions from getting onto the chain. So that's really where the fee burning arises as sort of an inevitability given the design decision to have this base fee. You know, most people book flights on travel aggregators to get more options and the best prices for the travel plans. So when you're making defy swaps, use pair swap.

It beats market prices across all major dexes. And thanks to the network of professional market makers, you'll get zero slippage on your trades. They just pushed a huge update that's even faster and more liquid thanks to a brand new algorithm. It's cheaper than Uniswap and it comes with a new gas token that cuts your gas fees by up the 50%. It's no wonder, Metamask, Argent, and monolith all rely on the Paraswap API. So give Paraswop a try at Paraswop.io slash Epicenter. This URL allows you to claim a 50% refund on gas fees for your first swap of at least one eth.

This offer is available until May 1st, 2021, and refunds will be made every Friday starting April 9. We'd like to thank Paraswap for their support of Epicenter. Is there another reason as well, which is that like, you know, we don't want an incentive for miners to drive up the base fee as well. If the fees go back to the minor of that block, it's free for a minor to spam transactions in order to drive up the base fee. And by burning the fees, it puts a cost on a minor to actually try to drive up the base fee. Is that one of the main considerations as well, or is that just sort of a side thing? Yeah, good question. I view that as a side benefit. And we can have a longer discussion later about, you know, how could miners collude and

manipulate this protocol. You know, but the short answer is, is, you know, that kind of manipulation, you know, manipulating the base fee, some miners colluding to sort of set the base fee where they want it to be. That in effect is something you could already do now, okay, before 1559, right? If Ethereum miners wanted to, they could say, hey, guys, agreement, okay? Never again. Will anybody accept a transaction, you know, with a gas price less than 60 way? Okay, never. And they all sort of swear to swear that they'll do it. And that has, you know, that's roughly the same as sort of manipulating the base fee so that it's 60, basically. So you're right that it does further disincentivize that particular manipulation, but I don't know that I'd be so worried about that

manipulation even without the fee burn. So I really view the first, the first reason is to fix the game theory around the base fee. Okay, so that's part one. That's, so, so key idea number one, base fee. It's a deterministic function of everything that's happened in the past. It's independent of anything that has to do with this block itself. All right. Now, the second part, the second key idea is to help answer the question like, okay, well, where does this base fee come from, right? It doesn't just like fall from the sky. We have to compute it. How do we compute it? How do we use history to say how to choose it? And it's, you know, the high level idea is very natural. It's basically just kind of local search in effect. So if it appears that the current base fee is too low, you adjust it

upward and vice versa. If it appears the base fee is too high, you adjust it downward. So what does it mean that it appears that the base fee is too high or too low? Well, suppose, you know, the current base fee was like 150 gway and there wasn't even 15 million gas worth of transactions willing to pay 150 way. So the miner says, look, it looks around in the mempool. It's like, whoa, there's all these transactions that are ineligible. Here are the transactions that are eligible for inclusion because their gas price is 150 or more. But it's only like 10 million gas worth of transactions.

But that's all I got to work with. So I guess I'll just publish this block, which is only two thirds full. Well, that would be a signal, right, that the base fee is too high. Right. You're actually not filling up your block. And so that's bad. We want the blocks to be full. We want to use all of the available real estate.

So that's what I mean by sort of an on-chain signal that the base fee is too high. The block is under full. But now, let's think about the symmetric situation, right? So imagine actually, you know, the block that you see on-chain is full. It's 15 million gas per the transactions. How do you differentiate between the situation in which you got the base fee exactly right so that there was exactly 15 million gas where the transactions

willing to pay it versus the scenario where it's way too low. And in addition to the 15 million gas of transactions you happen to see on chain, there was another 25 million gas transactions that were not included on chain that would have wanted to have been included on chain

at the current base fee. In the first of those scenarios, you don't want to change the base fee at all. It's exactly right, exactly the right amount of people are willing to pay it. In the second of those scenarios, the base fee is too low. low. Demand is super high and you want to raise the base fee. So this is what inevitably leads us to sort of

the second key idea in the design, which is variable size blocks. So this is another really quite significant change from how things work right now. So the way Ethereum works right now is there's a cap on how big blocks can be. And I think it was just raised to 15 million gas per block. And any block with more than that is simply invalid. It doesn't count. So in understanding, Under EIP 1559, the Ethereum protocol is going to be granted additional flexibility on how to allocate, how to allocate its blocks. It is still going to have to conform to an average block size of 15 million gas. And that's just because that's kind of what people are comfortable, the network handling. And in particular, like, if block sizes get too big, then you have forces towards centralization, right?

Because you need sort of more and more resources to run a node if the blocks get super big. So people are only comfortable with an average block size of whatever, say 15 million gas. However, under EIP 1559, Ethereum will be allowed to temporarily violate the target of 15 million gas up to a cap of 2X the target. So up to a cap of 30 million gas. So we're going to be seeing blocks with variable sizes, possibly as big as 30 million, possibly as small as zero. but the protocol will make it so that the average block size is going to be tuned to 15 million gas per block. All right. So how does this solve the problem we had earlier, right? The problem we had earlier was how do we know whether the base fee is just right or whether it's too low? Well, now we just look at how big the previous block was. So remember, a miner has the capability of going up to 30 million gas if it wants, assuming there are enough eligible transactions.

to pack it with. Again, eligible means that the transaction is a gas price at least as large as the current base fee. And so intuitively, I mean, we expect a minor to pack a block as full as possible with eligible transactions. We'll see in a second that they do get some revenue from the transactions, even despite the fee burn. So we're thinking of miners. They're basically going to look at the MEP pool. They're going to say, which transactions am I allowed to include, and they're just going to include them all. Or, you know, if that's more than $30 million, if that's more than the max, they'll have to make some decisions, but if it's under the max, right, the miner does not care about this target of 15, okay? The minor is just like, look, I've got 30 million to work with the protocol allows it.

If I can pack that with sort of, you know, fee paying transactions, I'm going to do it. So if you see a block, which is really big, if you see a block which is more than the 15 million target, possibly as big as 30, but anywhere more than 15, then you know your base fee is too low, and it's time to adjust the base fee upward. because remember you're shooting for a steady state of 15 million gas per block. So whenever you see more than that, the base fee is too low, you need to raise it. And then like in the previous example, if you ever see a block that's below the target of 15 million, you know, the base fee is too high and you adjust it upward.

And it's kind of a, it's, you know, and then, you know, in the, you know, there's a specific formula by which that adjustment is made. I don't think those details are super important for a conversation today. But that's sort of the really key point. Okay. Blocks, there's a target size for block. blocks are allowed to violate it by up to 2x. Why is that allowed? Well, now it gives you an on-chain signal of both directions,

both of whether the base fee is too high, like before, but also whether the base fee is too low. And then for the next block, you sort of gradually adjust it accordingly to try to get the block size back to the target of $15 million. So just like before, basically the base fee can vary between zero and in effect infinite, right? Right.

Okay, and basically it will be the same for every transaction included in that block, but it won't be like a post-sprice thing because on Amazon, when I buy a book for $40, I know that I'll get it. Whereas if I actually just pay the base fee, it's still possible that there will be, that demand has just gone up and basically there will be many more transactions and mine won't get included, right? So the bad case is when the base fee is crazy low compared to the demand. Like imagine the base fee was zero. Then there's going to be like you're not going to be guaranteed inclusion because anybody would be happy to get in at zero. How can you guarantee that it's you? So that's a bad case.

But the point is as long as the base fee isn't excessively low, meaning as long as it's sort of like roughly correct in the sense that remember the target is 15 million gas, But really, as long as the base fee is high enough that at most 30 million gas is eligible, then actually there's room for everybody. So you're not actually competing. So as long as you're willing to pay the base fee and as long as the total number of, the total gas of transactions willing to pay the base fee is 30 million or less, you're golden. There's room for you.

There's room for everybody. There's room for every eligible transaction. And that's exactly the power of the base fee, right? It automatically removes from contention. a whole bunch of transactions, the one's not willing to pay the base fee. And if the only remaining contestants all fit in the block, then there's no hard decisions to be made by the minor, just include them all. So what, but what are the incentives for the minor to actually include me?

Because, I mean, they could actually potentially benefit a lot from censoring me, right? And basically, under the current system, that's pretty expensive because they would forego my transaction fee, whereas if they don't get any money from me, why would they include me at all? Great. So this is a perfect lead-in to talk about the third and final key idea in the 1559 proposal. So again, just to review, the key idea number one at base fee, which is independent of the current block, it's history dependent. Key idea number two, variable-sized blocks so that you have an on-chain signal of whether the base fee is too high or too low so that you can adjust it for the next block.

And now, good. So, I mean, you've mentioned exact, so the last two questions mentioned are exactly the questions you should be asking, which necessitate the third idea. So first of all, why won't miners just publish empty blocks, say? Collect the block reward because that's all there is for them to collect anyways. And then secondly, what do you actually, okay, but what, like, what if you do have a situation where the demand just spiked like crazy and the current base fee is too low and more than 30 million worth of transactions are willing to pay it?

I mean, you certainly need to specify how the protocol works in that hopefully edge case scenario. So it's the same answer to both of them. So the third idea is to have what's known in 1559 is tips. And tips are really basically just a first price auction laid on top of the base fee. So each transaction will specify how much above and beyond the base fee it's willing to pay for inclusion. And like in the status quo first price auctions, that part, the excess above the base fee, known as the tip, that actually will be transferred to the minor of that block. So really, you know, a user is going to be paying some amounts,

and part of that amount will go to the base fee, and part of that amount called the tip will go to the mine. So how does this solve our problems? Well, so first of all, now, you know, you can make sure miners have a non-trivial incentive to include your transaction by setting the tip, right? So this sort of, again, two regimes. Is the regime where there's competition for the current block

and the regime where there's not. So if there's not competition for the current block, meaning the base fee isn't too crazy low, it's at least high enough that there's at most 30 million gas that's willing to pay the base fee. So in that regime, which is the happy regime

and hopefully the common regime, then the tip you need to pay should be minimal. It's just the minimal amount to make it worth the miners while to include your transaction rather than leaving that part of the block empty. So the analogy I sort of like to use

It's kind of like, you know, imagine inside of the New York City, so you can imagine I go out on the street and I want to put some money on the sidewalk, you know, that guarantees that someone picks it up in the next 60 seconds. Like if I put down a penny, it might not happen. But honestly, even if I just put down a $1 bill, that's going to get picked up in the next 60 seconds, right, even though it's not really that much money. Right. So that's, you know, in the regime where the base fee is at least approximately right, that's how. I think of the process. So you're just putting a dollar on the sidewalk. The miners like, well, it's not much money, but I may as well pick it up, right?

Why not? And so, you know, we'll see sort of what the norms around what the tips should be when there's no competition, you know, but sort of right now I would expect it to be like really small in the one or two way range. So kind of like gas prices from years ago. And then, okay. And so then in the other regime, we're actually, you know, you are in this edge case. The demand is suddenly spiked.

the base fee hasn't caught up yet, it's way too low. Then, you know, at least 1559 devolves gracefully into the current status quo transaction fee mechanism. It basically devolved, like, so again, if the base fee was literally zero, it would literally then be a first price auction. Okay, so the hope is that 99% of the time, there's no need for any users to engage in the auction. Either they're willing to pay the base fee or they're not.

And if they're willing to pay the base fee, they leave a small tip of one or two way and they're good. One percent of the time, okay, you're going to be back in the usual first price auction kind of scenario. But still, if you're a user who doesn't want to touch a first price auction with a 10-foot pole, ideally you should just be able to wait a small number of blocks, you know, five blocks or whatever, the base fee will have caught up to the new peak in demand. And now all of a sudden, once the base fee is where it should be, again, if you're willing to pay that high base fee, you won't be competing with other transactions. You just pay the base fee and you'll get into the block.

This is a bit of a tangent, but is there a marginal cost to a minor for including a transaction? Yeah, so I would say, it's a good question. I would say at least a little bit, at least epsilon for some small epsilon. And indeed, like, if you submit a transaction with zero, you know, with zero fee, and this was true, I mean, even back when there was room for everybody, you know, typically you wouldn't necessarily be included, at least not for a long time. if you set the fee to be zero. One reason, I mean, there's a couple of things. But so one opportunity cost comes from uncle risk. So for those of you know, this sort of Ethereum consensus protocol in some detail, right?

So it's a longest chain protocol, so you have forks. So if you mine a block that doesn't wind up on the main chain, it's sort of a bummer because, you know, you solve this hard proof of work. You're expecting to get this block reward. But oops, you're not in the longest chain. And unlike Bitcoin, Ethereum at least gives you a consolation prize. Okay, so if you get uncleed, so if you have a block, but someone else found a block sort of roughly the same time as you and the other miners extended their block rather than yours, you still get some fraction of the block reward.

And I think it can be as high as even three quarters or seven-eighths or something like that. So you can get still a very significant reward if you get uncle. But still you lose something, right? You are going to lose, you know, an eighth of an eighth or a quarter of an eighth, which is not nothing. So that's the first thing. And then secondly, the bigger the block you publish, the longer the propagation

delay of transmitting it to the other to other miners. And so the bigger the chance that someone else will beat you out and you'll wind up getting unpled. So there is some sort of, you know, it's small, but there's sort of a still non-zero risk. Every transaction means a little bit higher probability that you're going to wind up getting unkled and sort of lose some of that block reward. So if nothing else, that puts a lower bound greater than zero on what miners should be paid for transaction inclusion.

Have you looked at how cyclical the demand for block space is? So basically, I mean, basically if you look at commuters, I mean, typically there are rush hours and then traffic will be slower, prices on trains will be higher and so on. I remember when I was a kid, you had to call relatives in far off cities at certain after 8 p.m. or something because then telephone lines were cheaper. And you know, like that kind of thing. Have you looked at how big that effect is for Ethereum, which is in effect a global thing? Yeah, that's a great question.

In fact, I'm literally working with someone on exactly this question. So, you know, my collaborator sort of scraped a bunch of, it's a guy named G. Lo. And so he scraped a bunch of data from the Ethereum blockchain. And we're trying to kind of come up with a reasonable model of demand. And again, there's a lot of things that are difficult about the problem that we sort of already, you know, touched on, right? So when it's censored data, you sort of don't see the willingness to pay of people who are excluded. You know, you've got these weird off-chain agreements that give you some very low gas prices. You've got these PGAs, which gives you some very high gas prices.

So it's somehow a little bit hard to cut through the noise. But that's exactly what we're doing. So we're trying to come up with a reasonable traffic simulator or transaction simulator, ground. in historical Ethereum data, right? Both for us to play with and also for other people to play with. And so literally right in the thick of that project. So, but as far as I have not seen a, again, you can definitely find anecdotal discussions. And, you know, like I recall, right, so there's like, there's interesting blog post that, you know, Vatalik wrote several years ago where he was analyzing the elasticity around, around sort of, you know, block space.

So in other words, like as you increase the block size, how rapidly would you expect to. the sort of market clearing price to go down. So that involves some sort of heuristic uses of historical heatherian data. There's a couple other examples like that. But I really think there should be a sort of serious empirical study. This is super interesting. So the elasticity would have been the next question I would have asked. So basically, how elastic do you think the demand is?

If you look at different types of transactions, if I just say, I have a super high value transaction, I have a million dollars that I want to get to. sunny, then obviously it'll be difficult to price me out. But say, I'm an up trader, then you can put a very precise dollar value that this transaction will be worth to me on the transaction. Have you looked at this or is this also in the works? So we have. It's quite noisy. So I don't, you know, I'm speaking here about, you know, nothing's published, nothing's close to being published. I mean, it's very sort of early days. So I don't want, I don't want anything I say. here to be taken too literally or it's sort of to be quoted as truth because this is just kind of

our very preliminary sort of explorations. So we have been looking at that. It's very noisy. And we've been, but we find, you know, we found actually elasticity a little bit higher than what the Talek did several years ago, which we think is, you know, our conjecture is that just because, you know, gas prices are higher. And so, you know, if gas prices are super low, you know, you don't necessarily care much if they double, right? Whereas the current gas prices, people really do care if they double. But that's again, there's a lot more work to do before we feel confident in those conclusions. You know, even though our target block gas limit is 15 million, we have to make sure the network is capable of running 30 million gas blocks

for a reasonably extended period of time. And in a way, doesn't that imply that the network's true, like, potential capacity is 30 million gas per block. But then we end up in an equilibrium state where we only end up like, you know, when the system is in equilibrium, we, we're basically are only spending 15 million gas. And doesn't this just like, isn't this like pricing out half the people? Because we're just artificially like reduce the supply of block space to like half. And it's like, well, you know, maybe if we, yeah, you know, here's this min fee, base fee, that we're all getting in and we're filling this up at $15 million and this is a nice equilibrium.

But there's all these like other people who'd be willing to pay maybe like $10 less. And there is technically capacity that the network could handle them, but we're just not letting them in now. Yeah, that's a good question. So, you know, the motivation behind the design, I mean, the thinking is that, so I'm going to take a step back and just ask, you know, what criteria should we use to decide on what, let's take the current version where there's just a single block size. and you could say, you know, what are the criteria by which we should set the current block size?

And clearly bigger is better in some respects, right? You sort of accommodate more transactions. You're going to have lower prices. So there's definitely reasons you'd want bigger block sizes. So what's pushing in the other direction, right? So it's basically, I guess, two things. One is just kind of technical capabilities, like just, you know, say of the peer-to-peer network that's being used, right? There's a certain amount of – because, you know, there is this block rate of 13.

seconds, right? So, I mean, nodes have to be able to keep up. They need to be processing, you know, faster than every 13 seconds, and including, you know, the communication that's required. And then also people, you know, in the Ethereum community, you're very concerned about forces towards centralization. And so there's a concern that, you know, if you really could only handle the, you know, if a block size was so big that you needed sort of a really serious machine to keep up with the block rate, that that would be insufficiently open. Again, that's something different communities could disagree on, you know, and I think we even sort of see different decisions being made by different blockchains in that regard.

But in Ethereum, you know, there's really, I think it's part of the culture that, you know, you really, you know, anybody should be able to run a node, basically, with sort of pretty minimal investment. Anyway, so those are the things that are pushing back on the block size from above. And if you actually, if you think about those forces, you kind of realize that's really kind governed more by the, you know, the average rate of data creation as opposed to the peak rate, right? I mean, so it's definitely true. So if you had a machine that couldn't handle a 30-minute, a 30 million block in 13 seconds, if it needed like 20 seconds for that, it would fall behind,

right? But then again, it would sort of catch up, right? Because again, any 30 million block is going to be compensated for by some less than 15 million blocks later. So again, I mean, the base fee adjustment is going to ensure that, you know, if you look at a window of, I don't know, you know, say like 10 minutes or something, the amount of, you know, the amount of data that was generated that some of the block sizes over a 10 minute period is going to be almost exactly the same as 15 million times the number of blocks. I mean, that's true if you're like just sinking the network, right? But if you're trying to run a mining node or something, that's clearly not okay, right?

because then you'd not be, you, like, if you're like mining or like you're, you know, you're doing something, any super mission critical, you want to be at the tip of the chain

as much as possible. Yeah, I agree, but it wouldn't be the end of the world. And as you say, I mean, maybe think less of miners and more about just people running nodes, right?

I think that's more, you know, the sort of openness aspect, I think that's probably, yeah, it's probably both. But, you know, I think in particular,

you know, you want, you know, if someone wants to be altruistic and just kind of help out of theory in by running a node, you obviously want the barriers of doing that to be as low as possible. I mean, people argue about what should, you know, what should the block size be? So the old arguments are about the maximum block size.

The new argument is going to be about the target block size. You can also argue about the 2x multiplier for that matter. But I'd say the way to think about EIP 1559 is just set the target block size as high as you can get away with, right? Meaning subject to kind of the bandwidth of the network that you're using and subject to, you know, the, the centralization risk you're willing to tolerate. And then whatever that is, EIP 1559 just layers on this sort of extra flexibility where you can borrow block space from the near future to bring it into the present if there's an urgent need for it.

So that's how I think of it. So go ahead and max out the target block size as high as you can get away with. And then further exploit the fact that if you think about it really what's constraining the choice of the target block size is really all stuff about. sort of average throughput, not maximum throughput. And then use that as the variable as the on-chain signal for where the demand is high or low. Where do we land on this 2X number from? So from my understanding, it seems that the reason we need a max limit above the target limit

is because without that, there's no ability to detect when demand is higher. Why can't we say, like, okay, let's aim for like 90% full blocks. By full, I mean, as opposed to the max block size. And every time the block fill is greater than 90%, that's when we start to increase the fee. Why does it have to be 2x? Yeah, I wouldn't say it has to be. Or I guess why was that chosen? Yeah.

So I discussed this in the report. I'm trying to remember what I said. So it's a 50-age page report. So sometimes I don't. Parts of it has slipped from memory a little bit. Because you could also definitely say, why not go above two, right? So the benefit of going above two would be you have even more flexibility in sort of temporarily increasing block size to absorb short-term demand spikes. I mean, personally, I tend to see the max block limit as the more important limit from like a protocol like perspective in the sense that like, you know, we can't, we fundamentally can't let the get block limit get to like $100 million.

otherwise that even mining nodes won't be able to keep up. And so I feel like, you know, that is kind of what has to be, in my opinion, has to be like hardcoded, like, okay, this is our no-go limit. Like we fundamentally can't put this higher. And then the target limit, we can choose like, okay, what percentage of that max limit do we want the target to be? Yeah. Let me refer, I'm going to refer the audience to section 866 of my report. I mean, I could just read it here, but that feels kind of boring. I mean, I will say, so as you say, there needs to be some cap, right? Just just to avoid just, you know, obviously if you had, you know, infinite size block, it would, you know, everything would, everything would halt. But I don't know that in talking to, you know, people in the community and people who sort of, you know, develop clients and such, right? So, so, I mean, both are important, right? So both, what is the target block size and what is, what is them? And in fact, I mean, I know some of the teams did.

stress testing, where they really took a test net, you know, copied over all of the state from main net, you know, and then simulated sort of two X blocks for some period of time. I mean, so definitely people were concerned about this, but the tests, you know, the tests, I think all went well. I mean, one other thing, I mean, one sort of side point, I mean, anecdotal evidence that sort of, you know, bursts should be okay is that, you know, I talk about the block rate being once every 13 seconds, but it's really a poisson process for the nature of sort of the the proof of work mining. So you will actually sometimes have one block very soon after another one. And you will sometimes have, say, a few minutes where you produce twice as many blocks as you

would have expected. Like that's going to happen once a week or something like that. And it doesn't really seem to be a big deal. So that was another thing that gave people comfort that at least kind of 2x one could handle. I could imagine going more. I mean, again, I do think, you know, I think sort of things like cost of running a node, et cetera, I think those are good for setting the target block size. And then, you know, especially ratio is bigger than two. You know, I could imagine, I mean, I think that's worth keeping in mind. That might be a nice aspiration point. Because that, again, you know, if the ratio is bigger than two, that means it's even more rare that you're going to be in this situation where you have just a base fee that's way too low, right?

It's even more of the time you're going to have room for everybody. And no one's going to have to worry about the first price auction. Right? So that's what's nice about ratios bigger than two, is sort of the extra flexibility you have to accommodate a sudden demand spike. I guess I was more interested in the opposite. I wanted it to be like

maybe only like 1.25X because that way it's like at equilibrium, we're still running at the majority like 80% of our max limit. But wouldn't that assume that the variability in demand is very low?

Well, that variability would just have to be pushed across multiple blocks. I mean, that's the same thing that happens now. I mean, I guess one thing is like when we see spikes in demand on Ethereum, I think it's more than a 2x spiking demand, right? Usually the spikes in demands are in the magnitude, you know, in the me bits auction. Like at the end, like this demand on block space just went up like 10x or something. So, you know, no matter what, I think during demand spikes, we're usually going to, have to spread that demand over multiple blocks anyways. Yes, just sort of looking back at my report now, so one thing that comes up, it's kind of a

subtle point, but with, if you use less than 2x, if you use like 1.5 or something like that, it does interact, you know, it's not, you know, I definitely don't think it's the end of the world, but it interacts a little bit badly with the game theory around cartels of miners, trying to manipulate the base fee in the sense that, you know, what, you know, There's certain attacks which, you know, would require 51% collusion to pull off with the 2x ratio, but would require only 34% of the hash rate with a ratio of 1.5. I mean, you have to make a decision. I mean, I mean, one thing that's nice about the 2X is just sort of convenient is the update rule is then very symmetric, right?

So basically, the specific update rule is after a double full block, after a 30 million block, you increase the base fee by 12.5% after an empty block. after an empty block, you decrease the base fee by 12.5%. If you don't, you know, if you have asymmetric deviations around the target, right? So with 2x, you can be either 15 above the target, you can be 15 below the target. So you can just have this completely symmetric kind of adjustment function. So if you can only go, if you can go like down to zero, but you can only go up to say 22.5, you can only go 50% over, then you have to make a decision.

It's kind of like, okay, am I going to increase? I should have said, like in the current proposal, you linearly interpolate between the two, right? So if you have like a 25 million block, you would just sort of linearly interpolate between sort of the zero and 12.5%. So it would be sort of pro rata up to the, up to the block size. And so if you made it asymmetric, you'd have to decide, okay, if I see a 1.5 full block, which is as full as they can get in this scenario, do I, you know, again, sort of increase the base fee by 12.5% or do I just increase it by 6.25%, and if you can only increase it by 6.25%, maybe that's now all of a sudden too slow. On the other hand, if you do increase it by 12.5%, now all of a sudden, the cartel of miners

that control more than a third of the hash rate, they can now manipulate the base fee downward by publishing empty blocks. So as long as they can make one out of three blocks empty, that's going to be enough downward pressure to get the base fee to drift downward. Whereas if you have, in the symmetric case with a 2x ratio, you'd actually need to be, the cartel would need to get really, you know, 50% of the blocks. to keep the base fee from sort of rising up due to the non-colluding miners. I don't know that that's, you know, I don't think this is deal breaker stuff.

And so I agree with you. I mean, there's not this, I find the partitioning of it, like you have the target and then you have the multiplier. I actually find that partitioning of things very helpful because I do think so much of the decision making is just around kind of the average block size. But I definitely agree the multi, you know, the multiplier you could imagine iterating with. as in a post-1559 world. You can imagine that being a parameter that gets revisited every hard fork, for example. There's one aspect that gets talked about too little, I think.

And I'm wondering whether you feel this is like a side issue as well. So basically, a couple of years ago, I remember there was this upheaval in the ETH community when people realized that in principle, you could actually abstract Ethereum away. So basically, in principle, you could pay a miner any way you choose to to get them to include you in the block, right? So basically, in principle, you can PayPal them the fees.

You could kind of set up an agreement that they have to include X number of transactions from you per day. You can pay them indirectly via MEV, which we actually see happening a lot right now. So we see a lot of zero gas transactions being, included. So this with 1559 completely changes, right? So basically in principle, the miner could make up for any shortcoming in base fee for the user. So I could maybe still transmit a zero fee transaction, but someone has to pay an ETH because that ETH is going to be burned, right? How much of that was intentional and how much was, you know, this narrative of making the fee market more

predictable and, you know, the usability for the user better? Yeah. I mean, in some sense, this is really you just asked Vitalik this question directly, but my guess from sort of, he was writing about these ideas as early as 2014. So from like reading his early writings on it and also just some discussions with him, my sense, my guess is that the origin story is like I said, where really the goal was easy fee estimation,

fee burning came out as a side product, the game theory kind of dictated fee burning. And then that took on a life of its own. I mean, one thing that's interesting, It's a little bit of a side. But I mean, so for people who are fans of the fee burning aspect, right, a very natural question would be like, why not just like, let's just like throw out all this base fee stuff? Like, you know, people will, metamask is fine. Like, let people deal with it.

But let's, let's burn half the fees set. Keep everything as it is right now. But let's like burn half the fees and let the minor keep the other half. But the problem is that totally doesn't work, actually. Right? Because now basically, again, the, you know, so, and it's. again because of off-chain agreements. So the minor and the users can basically, you know, all the money that's supposed to go to the protocol, they can succeed off-chain and sort of

keep it for themselves. So, you know, how would that work? Basically, all the users would just submit zero bids on-chain. They'd submit whatever bids they want to the minor off-chain, and then the payments would all occur off-chain. And so there would be no burn. So what's kind of amazing is like, you know, I mean, I do think these are the two biggest things about it, you know, easier fee estimation and fee burning. Those are the two real big things to talk about. And so what's kind of amazing is how really you can't have one without the other. It's like choose both or choose neither.

They're really inextricably linked. And different members of the community, you know, some care more about the UX, the user experience issues. Others care more about the tokenomics and that's fine. But really, you know, I think that's, I mean, this is part of, I think, why it's a scary change for a lot of people because it's really sort of, you know, it's really kind of changing the economic model of Ethereum, which kind of, you know, in a major way. But I think this is one of the reasons that despite, you know, the fear that people naturally have

about making a change of this magnitude, there were really two totally orthogonal reasons for people to get really passionate about it. And so I think that's really broadened the base of support. But completely agree, I mean, now I has gotten to the point, you know, and it may just be because we're in a bull market or whatever, but, I mean, I do feel like I hear more about the fee burning slash tokenomics aspect last month or two, then I hear people talking about the UX user experience improvements. And I mean the fees have become much more dependable ever since MEVGath has the majority stake of other clients, right? So basically we haven't seen

the crazy spikes that we've had in the past year or so. Things have been calmer. Yeah. It'd be interesting to know how, I mean, the block size also went up. That probably helps some. But yeah, presumably, you know, flashbots, et cetera, is a major part of it. So let's talk about collusion, one of the favorite topics here. So in principle, the miners could collude to drive down the base fees, right? Right to zero. And have the majority of the value go to the inclusion fees or the tip fees instead, right? So basically, if minors never mine a block over 12.5 million, you know, gas, the base fee would just continuously drop all the way down to zero. And for that, you'd only need like 50% of the miners, right? Right. So collusion. So this is a, it's tricky to speak very formally about

this, but I can tell you the approach I took in the report. So basically, what I argue in the report is that the sort of forces working against miners trying to collude in these kinds of ways, the forces working against minors are as strong post EIP 1559 as they are now. It's not to say it's impossible, but I think the fact that miners collude in only very limited ways now suggests that they will continue to collude in only very limited ways afterwards. So let me just talk a little bit about sort of the status quo. I think this is important to understand, I think. So point number one, so first of all, you might say like, well, can miners even collude at all, right? Maybe it's just sort of hopelessly decentralized and it's just not feasible.

But you look at kind of like how the block size changes get made. And it appears that at least kind of the major players in the Ethereum mining community are able to coordinate to some degree, right, by sort of figuring out when the block sizes should increase. And so that's interesting, right? So it seems like when they want to, they can roughly coordinate to have something, to make persistent change to how things work. And so the question then is, you know, why don't they use that ability to coordinate,

which they apparently have, to do other things? And who knows? But, you know, my speculation is that, okay, you know, they're managing the block size. And, you know, they're managing the block size in a way that's quite plausibly really helpful for the Ethereum community, right? Like, they've never changed the block size in a way where it was obvious it was just in their interest and against the interest of sort of other parts, other Ethereum stakeholders. Now, when miners increase the block size, they can be doing it for a few different reasons,

right? One reason would be just because they want to make more fees. This, again, is going to depend on the elasticity that we discussed. But you could imagine that maybe if, you know, it's pretty inelastic, right? Then when you increase the block size, you're just going to be making more transaction revenues. So that'd be a self-interest reason why miners might want to increase the block size. On the other hand, if you thought it was more elastic, they could say, no, trying to do everyone a favor. We're willing to work a little harder, and all of you will get lower gas prices, right? So it's in the benefit of the community. I'm not sure how you would assess, you know, which of these is sort of dominant. But the point is, is it's a type of collusion,

which is very palatable, right, because it seems to be for the health, long-term health of the Ethereum network. The long-term health of the Ethereum network with E2 looming at the Verizon, for the mine, basically the miners will be excluded anyway. So basically their losses, kind of have founded, right? Is this a good time to put them with them their backs to the wall? Yeah, no, that's a fair point. And when I wrote this report, it was before kind of people started talking about moving up the merge, right? So at the time I was writing this report, it seemed like there would be a more non-trivial window where you'd have both proof of work and the IP 1559. Now it's looking like that window might be shorter. Yeah, I mean, and this is sort of

the conclusions I come to in the report. I mean, I basically say, you know, the difficulty of of persistent collusion by minors is the same. However, they may be newly motivated to actually overcome the barriers that are there. So you could imagine that, I mean, you can imagine a kind of, you know, almost like a sort of, you know, kamikaze exit, right, where they sort of say, you know, like you said, it's like we have very little to lose. We have three months to get whatever we can get. Right. So you could imagine them trying to just like have a fork, which doesn't have EIP 1559 and trying to get people to sort of use that. Again, I think that won't be easy because, you know, as soon as you have, say, like a stable coin, you know, saying like, oh, it's no, it's only the assets on, you know, the 1559 fork that are actually kind of are backed by our assets, right? As soon as some major stable coin picks a fork, you know, I just don't see any, I don't see how you could have a significant alternative fork that almost, you know, that has serious use. So I don't know. I mean, it'll definitely be interesting to see how it plays out. Yeah, I mean, that's all I can

say is I don't think there's no like new attack vector I would say really around collusion that 1559 introduces however you know it may make attack vectors which were previously reviewed regarded as not worth it they may newly be regarded as worth it because it's sort of just as you say I mean that you're only sort of compounding your interest over a very short short window at that point so that'll be interesting to see It'll be interesting to see. I mean, one thing I think is clear is that, you know, I feel like the Ethereum community is pretty mobilized to, you know, minimize whatever the chaos is going to be. I mean, I think, you know, there's a lot of awareness that this could happen.

I think my sense is, you know, leaders in the community have contingency plans. So in some sense, I'm not, like, deeply worried that there's going to be, you know, that there'll be a month where it's unclear which fork you should be using. I just, I don't, that I think is an implausible scenario. Are there not collusion attacks, though, that can be done? So I guess part of what you're suggesting is that there's a certain social norms and taboos in place to prevent collusion. But I feel like, you know, what we've seen from like the communications from many of the minors in the last couple of months is that they don't see that acting against 1559 as a taboo to them. And they are like ready to put in the work to like try to prevent it. And so aren't there like ways that even within the 1559 like paradigm, miners can like collude to basically undo the effects of 1559, at least the ones that they care about, which is the fee burning?

Right. So that's so good. So I mean, I guess I was talking more about sort of extra protocol collusion, which I kind of view is sort of the more serious, you know, that's more the doomsday scenario, I would say. Right. So for in protocol collusion, right. Thanks for bringing me back to that. I mean, so here's an important point, which is that right now, right, there's a form of collusion that minors could do that they're not. In some sense, it's conceptually not hard for them to do, which is, again, when you'd want to do this would depend on sort of what the demand looks like.

But there would be periods of time where you would be in miners' interest to artificially decrease the block size. So instead of using $15 million, use $10 million so that they can squeeze higher. prices out of the transactions that are willing to pay for just being in the smaller block. Revenue is price times quantity. As you decrease quantity, the price goes up. And so there will be situations where Q goes down, P goes up and the product, the revenue actually goes up. So that's, you know, so that is something miners could do right now.

Again, this is the example where they get together. They say, no one is ever going to accept a transaction with gas price less than 60 way. They could totally do that. And they would probably make more transaction fee revenue if they did that, at least in a smart way, in a way that was informed intelligently by design. And they don't, at least as far as I know, they don't. And I don't, you know, I don't really want to speculate why they don't. I mean, you could imagine things. You can imagine it's just too hard to pull off logistically.

You can imagine that they're worried that people would notice and there'd be retaliation from the Ethereum community. You can imagine that, you know, they just don't want to, you know, they don't want to hurt. they don't want to hurt Ethereum because that's what their business relies on. To me, that's all kind of, right, the points on the ground are they don't try to artificially impose a sort of limited supply to boost revenues, right? So for whatever reasons they don't do that. And given that they don't do that, I mean, there are these shenanigans you can do to manipulate the base fee after 1559, but none of them are any easier to pull off than the one I just talked

about that you could do now. about sort of imposing a smaller block size. There are just kind of variations of that same idea, right? So, okay, so now you're now maybe you're keeping the block size down, not so much to sort of boost the immediate revenue, P times Q, but more to like get the burn to go down. But it's really the same thing, right? You're basically asking minors to make a short-term sacrifice, right?

And the short-term as a minor, you have to give up tip revenue or fee revenue that you'd otherwise get by packing a block full. So you're being asked to sacrifice your own fee revenue, for the good of the collective of minors. And that's, you know, so that's what the game theory looks like. It's basically, you know, in game theory, you would call this sort of a multiplayer prisoner's dilemma game. And, you know, this question is, you know, and so if you have a repeated prisoner's dilemma

game, one thing that's interesting to think about is whether, you know, the participants can sustain cooperation over time. And, you know, sort of anecdotally, it appears that minors, you know, have not been able to or not been willing to sustain that kind of cooperation over time. for the sort of obvious sort of economic manipulations you could do now. So I don't really see a reason why they would start doing that after 1559, except, again, it's possible that they would just change the equation. Like if they just felt under attack, they're like, well, it's going to be a real pain.

It's going to be very harmful to Ethereum to do this stuff. But all of a sudden, we don't care anymore. So now we're going to do it. I do think that is a possibility. One is like the social norms have changed. But the other is I think also that like, you know, artificially decreasing the block limit today in Ethereum, it has just negative effect on the network.

But I feel there's like collusion attacks in 1559 that don't actually have a tangible impact on the network. So the one that I'm thinking about specifically, and tell me if this attack even makes sense, because I just thought of it on this, like, you know, a minute ago while you were speaking about it, was, you know, what if miners go ahead and like, you know, we spend one day just like trying to bring the,

the gas, the base fee as low as possible, right? And then all we do then is miners, we agree to alternate blocks between being 30 million gas and zero gas. And like, so every other block is empty and every other block is maximally filled. And now we ended up still keeping our average 15 million target rate. And we, you know, but we kept the base fee low. We're preventing the base fee from going higher. And this didn't impact the network because we, you know, in the expected way that 1559 is supposed to work at equilibrium, we're still making 15 million, on average 15 million gas blocks. In this version, we're also making 15 million gas blocks, but now the majority of revenues are going to miners instead of being burned. And I feel miners might not see this as a negative

because it's like, it doesn't seem to be having a negative impact on the network. And so they might not be so dissuaded from doing it. Yeah, I mean, you're going to get different opinions between minors and holders on this point, right? I mean, I think at this point, like, the tables are sort of turned and, you know, maybe at one point minors sort of felt, or some miners felt that, you know, the transaction fees were rightfully theirs. And I think now with 1559 sort of, you know, actually really happening in just a matter of months, and everybody's so excited about it. And who knows if that has something to do with the price spike or not recently, but, you know, there's no doubt a lot of Ethereum holders now, I think, feel actually like those,

the base fee revenues is rightfully theirs. So I don't really see, it's hard for me to envision any attack along those lines that would not be, you know, that would be even neutrally viewed by the majority of the Ethereum community. There was also talk of not burning the fee, but actually redistributing the fees to other miners. So, I mean, from a game theoretic perspective, it's important that the fee not go to the miner that mines the block and IE has the dictatorial say on which transactions go in it and in which order. But in principle, the transaction fee could go to minors of different blocks preceding or succeeding or a random pool or whatever. This was abandoned at some point. Why was this?

Yeah, that's a good question. I wondered at that myself. And there's been a little bit of, like, so this is something I highlighted in my report. I call it the sort of pay it forward or sort of L-Smood mechanism. I specifically was proposing paying the base fee revenues forward to miners of future blocks. When you said it's exactly correct, all the game theory tells you to do is give it anywhere other than to the minor or the block. It could be a foundation, it could be past minors, future miners, whatever.

I, you know, look specifically at the case of paying it to future mines. It's a good question. I mean, you know, there's no question from an implementation perspective. Burning's the simplest. And I can't imagine that initially that was the proposal. I don't know. I could imagine initially that was the proposal for that reason, right? Just because, like, let's start with this and, like, let's acknowledge these other more complicated things we could do if we wanted.

Presumably, somewhere along the line, people got so sold on the sort of, new tokenomics that the fee burning version would would introduce that, you know, I think probably, like I said, I mean, there's just a lot of community enthusiasm about the tokenomics change that the fee burning brings in. So at this point, you know, I can see why it's not getting a lot of discussion, I guess, at this point. And part of it is there's just, another thing is you can interpolate between these two mechanisms, right? So this is, again, something that could be revisited, it, if necessary, you know, in future hard forks. You know, you could say like, oh, actually, you know, let's go ahead and pay, you know,

25% of the base fee revenues forward and burn 75%. Again, as long as none of it goes to the current minor, you're fine. Right. So, I mean, what's actually kind of amazing about this, you know, people talk in sort of vague terms about, like, you know, Ethereum holders and miners and if it's stakeholders and tradeoffs between them. But, like, actually, in this family of designs, there's actually this extremely explicit knob, which you can turn to decide exactly how much you want to favor the holders and how much

you want to favor the minors, right, which is just what fraction of the base three revenues get burned, that favors the holders, and what fraction gets paid forward, that favors the miners. And really, you know, I just view it as sort of the, you know, it's up to the community to decide, you know, what is the right value for that parameter. I think it's something that, you know, is worth revisiting periodically in the future, even assuming that the burned version is what gets incorporated right now. What are some alternatives to EIP 1559? You know, 1559 is probably one of the most popular, like, algorithmic fee policy systems.

But, you know, I know there's other ones as well. I know the agoric team had, has one called the escalator algorithm that I think was turned into another EIP. And then I know the goon from, you know, the avalanche team, he has a paper, which I think you mentioned actually, you referenced in your paper as well. have you looked into some of these alternative algorithmicry systems and how do they compare to like 1559 and what are some of the tradeoffs between them? Yeah, I've looked into, I have looked into the two that you mentioned. There's certainly other ones that I have not really thought about. But to your question, so the escalator algorithm, so just to explain what this is, you know, imagine you submit a transaction and it hangs and then you do sort of replace by free or use metamask to sort of speed it. up or whatever. And then imagine you keep doing that until finally it gets included. So you can

imagine an actual person doing that, right? And so the escalator algorithm is really just sort of taking that strategy and implementing it programmatically in protocol. So the idea there is, so it can be implemented with 1559 or not, or just by itself. So let me describe how you do it by itself. Right. So currently, all you specify is a gas price, a single gas price. And then if you want to modified, you have to kind of resubmit the transaction, et cetera, et cetera. So the escalator algorithm, you would submit more parameters, and the suite of parameters would specify a whole schedule for how your transaction would bid in the coming blocks. So you would say something like, I want to get in somewhere in these 20 blocks. You know, I'm willing to pay as much as 50 for

the first block, and I'm willing to pay up to 100 kind of eventually. And then it just, and then, you know, hard-coded and escalator is it sort of linearly interpolates, between the beginning point and the endpoint. And yeah, so, I mean, that's definitely, I mean, that's a reasonable idea. It's always a little, I mean, so there's a general question which is, if you're going to have a system which needs bidding sophistication, like first price auctions, how much of that sophistication should be in protocol versus out of protocol?

And basically, the escalator algorithm is moving some of what had been complexity by users and then sort of, again, making it programmatic. And one always tricky thing about doing that is it's hard to know that, I mean, like from the user perspective, right? I mean, it's not clear that this makes it easy for you to reason, any easier to reason about what gas price or schedule of gas prices you should submit. Right? Because like in a first price auction now, okay, I have to reason about what other people are bidding.

Right. But then with Escalator, I have to reason actually about, maybe I want to reason about not just what other people are bidding. but how rapidly their bids are going to be increasing in the near future, right? Which somehow makes my, that's even greater cognitive burden on me. So I can sort of go either way, I'd say. And then the way you would layer it on top of 1559 is you would use escalator just for the tips. So the base fee would still be exactly as it is now, but you could say, oh, rather than having

users submit a tip, they'd actually submit a tip schedule. Now, if 1559 does what it's supposed to do, tips will almost always be irrelevant. And so the escalator shouldn't really be necessary, I wouldn't think, with 1559, if it works as it needed. So, you know, I think it's a, I think in general it's a reasonable idea, you know, ask the protocol to do some of the strategizing on behalf of the users. But if you care about the easy fee estimation, I mean, one should notice it doesn't help, or it certainly doesn't help as much as 1559 does. Because without 1559, you're still fundamentally in a first price auction, right? The fact that you've given me sort of, you know, a bigger vocabulary to articulate a bidding strategy, fine, but it's still a first price offer. Now, the other one, so Bagun, along with David Easley and I think Maureen, Orhara and Basu, I think, is the first author.

Yeah, so they had an interesting proposal also, which includes a sort of variance of the pay it forward idea. So there's a bunch of aspects to their proposal. But the part that's relevant for me now is that they were proposing that basically the fees for a given block would be split between the block of that minor and future minors. So there was some parameter K, then basically if you mine a block, you're going to get a one over K fraction of your fees. And then you get a one over K-fraction of each of the previous K-minus-1 blocks. And a K-minus one over a K-fraction of your blocks fees will be paid forward to the next K-minus-minors. And the issue there, which they don't discuss, and I do think is a significant issue, is again, this off-chain agreements, off sort of attack vector. Right.

So, because remember, in this proposal, like, right, so in other words, like, if I'm a minor, right, why would I want to give up a K-1-1-K fraction of my revenues? Like, I'm happy to collect whatever I got from the past, right? I'll put that in my pocket no matter what. But let's just focus on who showed up in my block right now. I'm going to ask them to submit bids of zero on-chain and submit their real bids off-chain and just pay me to. directly. And then I'm going to sort of deprive the next K-1 minors of this transaction fee revenue that they deserve. So there's definitely a bunch of ideas in there that I like, but I do think that's a fairly serious flaw. And maybe it can be fixed, but I haven't seen a proposed fix,

at least at this point. Yeah, it seems this off-chain agreement really is a, you know, pokes a hole in a lot of designs that, like, each would really be thought about. And I have to say, it's one of the things, I mean, you know, coming, like I've studied a lot of traditional auction design and mechanism design. It's one of the reasons, like, you cannot just look up in an auction theory book and sort of say, oh, you know, it will not prescribe solutions, you know, in a blockchain setting because of all its idiosyncrasies, right? Traditionally, you think of sort of the person, you know, there's some trusted third party

running the mechanism, right? Or you think of the seller and sort of buyers is kind of competing, not like colluding with each other to mess up the mechanism, right? So it's just a totally different set of constraints, which is scientifically is super interesting because it's just like these very basic problems have not been have not been solved before. So one thing I was thinking about when you mentioned the escalator algorithm, something like a UX thing I was thinking about earlier was, can I just say, so let's say, you know, the currently the base fee is at 50 way.

And I want to go ahead and submit a thing at 50 way. But then, you know, in the very next block it happens that is like, you know, oh, shoot, the base fee just went up to 55 way or something. But maybe that's okay for me. Is it possible for me to just say, you know what, I'll accept any base fee that's in the next 10 blocks. Because, you know, the protocol kind of guarantees me the base fee is not going to spike to like a thousand way in the next couple blocks. And so can I just say, hey, I don't want to put in a numerical value. I just want to say I want to pay whatever the protocol min fee, base fee is.

Yeah, good question. I probably, and I'm glad you asked you because there's something I should have explained more clearly about how 1559 works actually. So I talked about how you know, you pay a base fee and then you pay a tip. Base fees burn. The tip goes to the minor. But I didn't actually talk about what the user submits with their transaction, right? So it's actually a little more complicated than now. Now you just submit the gas price.

But under 1559, you submit two parameters. There's the tip, which we discussed, that's the payment to the minor. But then you also submit what's called the fee cap, which is really just like the maximum amount you're willing to pay. And that really is, I mean, and so what's nice about, so in your scenario, you would just set a fee cap extremely large. And then you wouldn't worry about it, right? And so what's cool is, and this is now starting to feel a little bit like a second price auction or a proposed price mechanism, which what's nice is like, you know, even if you're willing to pay a lot, and you can go ahead and tell the protocol, you're willing to pay a lot. But again, sort of programmatically in the mechanism, you will only pay what you need to pay, namely the base fee plus the tip.

If you said the tip really big, you're going to pay a lot no matter what. The tip you will always be paying. But a big fee cap will only hurt you when the base fee is really big. Kind of like slippage bounds on Uniswop or something like that. Yeah, roughly. Yeah. It was super fascinating. So if people want to find out more about you and your research, we will link to the mammoth paper on EIP 1559 that you did. It's actually a super nice read. It's very succinctly put. So I can definitely recommend it. But if people want to learn more about your research. Where should they follow you?

All right. So there's a lot of information on my webpage, Timruffgarden.org. There's also, I am on Twitter. I'm not like a super frequent Twitter user, but certainly, you know, whenever I come out with a new crypto paper, I do post there about it.

You know, DMs are open. I'm old, so I use email a lot still. Those are probably the best ways. Cool. Fantastic. It's been a real pleasure and honor to have you on. Thanks so much for having you. having me. Thank you for joining us on this week's episode. We release new episodes every week. You can

find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guest or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.