Bankless - EIP1559 Expert Panel | Tim Beiko, Hasu, Micah Zoltu, Barnabe Monnot, Matt (LightClients)

Episode Date: August 4, 2021

The time has come. With the London Fork just around the corner, the much anticipated EIP-1559 will be implemented. This fundamentally changes the relationship among miners, users, and gas. This panel, moderated by Ethereum core developer Tim Beiko, is set to discuss the macro and micro shifts to the ecosystem. We've talked about this a lot on Bankless, so it's time to hear from experts around the community about this massive turning point. ------ 📣 PoolTogether | DeFi's No-Loss Lottery Protocol https://bankless.cc/PoolTogether  ------ 🚀 SUBSCRIBE TO NEWSLETTER: https://newsletter.banklesshq.com/  🎙️ SUBSCRIBE TO PODCAST: http://podcast.banklesshq.com/  ------ BANKLESS SPONSOR TOOLS: 💰 GEMINI | FIAT & CRYPTO EXCHANGE https://bankless.cc/go-gemini  🔀 BALANCER | EXCHANGE & POOL ASSETS https://bankless.cc/balancer  👻 AAVE | LEND & BORROW ASSETS https://bankless.cc/aave  🦄 UNISWAP | DECENTRALIZED FUNDING http://bankless.cc/uniswap  ------ Topics Covered: 0:00 Intro 8:00 Understanding EIP 1559 ETH Research post: https://ethresear.ch/t/first-and-second-price-auctions-and-improved-transaction-fee-markets/2410 20:34 Changing Metrics 26:21 Improving User Experience Micah’s article: https://medium.com/coinmonks/a-tale-of-two-pricing-schemes-dc9c8717906 33:45 Advice for Smart Contract Devs JSON RPC Changes: https://hackmd.io/@timbeiko/1559-json-rpc 42:30 Miners, Burning Fees, and MEV 53:52 Clarifying MEV and Gas Prices 57:00 EIP 1559 on Geth 1:04:44 Hasu's Turning Point on ETH 1:11:11 David & Ryan ask Community Questions 1:15:51 Fifteen Fifty-Nine 1:19:40 Old Transactions in a New Paradigm 1:22:00 Stuck & Pending Transactions 1:24:16 Changing Monetary Policy 1:36:01 Manipulating Block Size 1:39:58 Discussing Timelines 1:47:25 Closing & Disclaimers ------ Resources: Tim Beiko on Twitter: https://twitter.com/TimBeiko?s=20  Barnabe Monnot on Twitter: https://twitter.com/barnabemonnot?s=20  Hasu on Twitter: https://twitter.com/hasufl?s=20  Lightclients on Twitter: https://twitter.com/lightclients?s=20  Micah Zoltu on Twitter: https://twitter.com/MicahZoltu?s=20  ----- Not financial or tax advice. This channel is strictly educational and is not investment advice or a solicitation to buy or sell any assets or to make any financial decisions. This video is not tax advice. Talk to your accountant. Do your own research. Disclosure. From time-to-time I may add links in this newsletter to products I use. I may receive commission if you make a purchase through one of these links. Additionally, the Bankless writers hold crypto assets. See our investment disclosures here: https://newsletter.banklesshq.com/p/bankless-disclosures 

Bankless Nation, welcome to another State of the Nation episode. This is a special episode we have lined up for you because it is EIP 1559 week. That's right. The week has finally come. The deployment of EIP 1559. David, we have so much packed in to this week. But let's talk about the first event, which we are hosting right now, live streaming this on YouTube. You can catch on the podcast as usual later.

What is the panel that we have lined up today? Yeah, we have Tim Bako, who is one of the guys that really stepped up to get EIP-1559 over the finish line and then stepped into the all-core devs coordinator position with all of Ethereum. And so Tim came to us and said, I really want to ask some experts, some expert level EIP-1559 questions. And so that is what is going on today. Tim pulled in who he thinks has just the best understanding as to what EIP 1559 is from the expert perspective. So he is asking the questions that Ryan, I don't think you and I would have been able to even think up. And so this is, we're not smart enough, man. We're not smart enough. We're not, we're not smart enough to handle the, uh, the IP 1559 introduction with, with Hsu that we had a few

months ago. And by the way, guys, if you're looking for a primer on 1559, we want to refer you to that episode. Take a look at the bankless archives. We'll include it in the show notes as well. But this is a deeper dive because this panelist has the EIP 1559 rock stars. You mentioned Tim Baker. Who are the other panelists, David? Yeah, we have a bunch of core client developers. We got Barnaby Monaut. We have Light Clients, aka Matt.

We have Hazu, who is, I would like to say that Hasu came over to the Ethereum world because of EIP-1559. Maybe that'll be a question in the show. And then we, of course, also have Micah Zoltool, who is a major contributor to Ethereum. Guys, you can ask questions on YouTube. Tim is going to be asking questions from his own roster of questions. But after the conversation, David and I are going to pop back on, hopefully, ask some of our own questions and address some of the questions in YouTube. So ask those questions, we will be documenting those as we go.

Guys, this is just event one, though, because the actual deployment of EIP 1559 happens. We're going to say, what block number is that? Block number 12,965,000, I believe. if I got that correct, David. So what time is that going to be? We don't know. It's on the Ethereum clock schedule. So it depends on block speed,

but it looks like it might be around 5 a.m. Pacific time on Thursday. That would be 8 a.m. Eastern on Thursday, August 5th. So you know David and I are going to be up. And what are we going to be doing? Yeah, we're going to be live streaming with the boys over from Heath Hub. And we're also pulling in some classic Ethereum community members. We got Hudson joining the call. I just got a message from Danny Ryan saying he'll be there.

Trent Van Epps is going to be there. Tim, I believe Tim is also going to be there. So it's going to just be a community call of people all watching the block of EIP-1559 getting mined. And so that stream will actually be starting, I think, roughly around 4.30 a.m. Because we think that the hard fork is happening roughly around 5. So we want to be there a little bit early to make sure that everyone gets a chance to watch it happen live. So David's going to be up early. Not as early as our E2 staking live stream, but still pretty early.

I'm glad I'm on the East Coast for this one. Last event for you later that day on Thursday, we have an EIP 1559 Bulls panel. We're talking about all of bullish things that EIP 1559 could mean for ETH the asset. We have Squish Chaos, DC investor, James Wang. We are live streaming that at 2 p.m. the afternoon of August 5th. So lots to catch up on. The best way to just catch up on everything is to subscribe to the YouTube channel, bankless YouTube, and then click notifications on.

one last thing, and then we are going to get to the sponsors. And then the panelists, that is, pool together. They're doing some really cool things right now, David. And this is like celebration of scalability summer with pulled together. So if you don't know, pull together, they are a no loss lottery. So that means you deposit your ETH. It could be your USDA, your stable coins in. You don't lose any of it.

You only have the possibility of gaining. They actually use some of the DFI protocols to generate interest and then pay those out as prizes on a weekly basis. So every week there's a lot of draw. Super cool protocol, super cool way to save. You can see right now, if you deposit into USC, there's a weekly prize of 50K that you could earn. If you click into that, they also have some loopbox prizes too in every single one of these. These could be, you know, other coins as well. So super exciting. The thing I'm most excited about, David, is no gas fees because it is also layer two summer,

scalability summer, and gas fees are much reduced with some of these right now side chain type deployments in Polygon and others. And I think roll-ups will be coming soon. So a lot happening there. David, anything to add? You know, that's pretty comprehensive, Ryan. Guys, just get in the pool. The link is in the show notes, bankless.cc, slash pool together, relocate your savings account. to pool together. All right, we are going to get to the sponsors right before this panel. These are the sponsors that made this episode possible.

Balancer is a powerful platform for flexible automated market makers. Typical AMMs just have two tokens inside of one liquidity pool, which can lead to fractured liquidity across the many pairs in Defi. With Balancer, you can access the full power of multiple tokens inside of one single AMM, which unlocks an entirely new playing field of possibility. This makes Balancer an awesome building block for so, many different use cases. Balancer pools can make asset indices, but instead of paying fees to portfolio managers, Balancer lets you collect the fees from traders who use your portfolio for liquidity.

Additionally, Balancer smart pools can be programmed to have properties that change according to predetermined rules, such as changing the swap fee based on market conditions, or even liquidity bootstrapping pools, which can help you launch and distribute your token with day one liquidity. At Bankless, we use a liquidity bootstrapping pool to sell our BAPT T-shirts, too much success. Balancer V2 brings powerful new features that makes your money work even harder for you. In V2, idle tokens are capable of generating yield in Defi without sacrificing liquidity in the pool using Balancers' asset managers. Balancers' vault architecture lets you trade between balancer pools at a fraction of the cost versus trading on other platforms. Balancer's mission is to become the primary source of liquidity in Defi by providing the most flexible and powerful platform for asset management and decentralized exchange.

Dive into the balancer pools at app.balancer.fI. Gemini is the world's most trusted cryptocurrency exchange. I've been a customer of Gemini since I first got into crypto in 2017, and it's been my main exchange of choice to make my crypto buys and sells. Gemini is available in all 50 states and in over 50 countries worldwide, and on Gemini there are markets for over 30 various different crypto assets, including many of the hot defy tokens, and it's one of the few exchanges that has liquid-difference.

die markets. Gemini just launched their Earn program where you can earn up to 7.4% interest on 26 various crypto assets. If you're tired of paying fees in Defi or you don't want to worry about defy exploits, but you still want to earn interest on your crypto assets, Gemini Earn is the product for you. Another product I'm stoked to get my hands on is the Gemini crypto back credit card, which gives you 3% cash back on all of your purchases, but paid to you in your preferred crypto asset. When I get my Gemini credit card, I'm going to be to make sure that I get my cash back in ETH. So whenever I buy something, I get a little bit of ETH bonus back to me at the same time. You can open up a free account in under three minutes at

Gemini.com slash go bankless. And if you trade more than $100 within the first 30 days after sign up, you'll be gifted a free $15.5 Bitcoin bonus. Check them out at gemini.com slash go bankless. Well, good morning or evening, everybody. Welcome to this 1559 paddle that I'll be running for the next hour or so. Yeah, so we have a lot of people here with a pretty extensive experience with EIP 1559. As you all introduce yourselves, one kind of first question I'd like to ask you is, what was the moment that you kind of got 1559? And what I mean by this is that it's a pretty complicated change. It tends to take people like a lot of pass through it to feel like they fully understand it. So yeah, as you just give a quick description of yourself, just walk through

kind of what what made you get 1559. Matt, you want to go first? Sure. Hey, everybody. I'm Matt. I go by light clients on the internet. I work for a small team called Quilt. We do a lot of core protocol R&D and I was one of the main contributors to 15 for 1559 and go Ethereum. I don't think there was one specific point whenever 1559 specifically clicked for me. I think there were kind of a couple points. And I originally read Vitalik's paper a few months after he wrote it, the pricing resources paper. And I kind of at a high level understood, you know, 1559 is going to act like this dampener to dampen the spikes and gas prices during periods of high demand. And that was something that sort of resonated fairly quickly through discussions. And I kind of tucked that away for basically two years

until I really started getting evolved again in the end of 2020. And so that was kind of one aspect. I would say the other aspect of that was the Tim Rough Garden paper. I really liked Tim Rough Gardens earlier papers on axiomatic approaches to block rewards. And so when he wrote about 1559, I was like, this is a really good, a really good paper describing all these things. But there was another part of 1515 to my 1559 that didn't click for me until a lot later. and that was how it affects the security of the protocol. And I was lamenting to some people.

Like, I didn't like, I'm not really the biggest fan, actually, of this ultrasound money meme, especially for core developers, I think that it's not really my place to, you know, propagate these memes. And so I was lamenting to some people about this. And they made this good point that we're moving to a world of proof of stake. And proof of stake, we have this economic requirement of ether to kind of have value to provide security to the network. And we have that to a degree in proof of work, but it's becomes, there's a lot less transactional cost of mining and owning miners and stuff. And so at that point, I kind of, you know, back down a little bit from this ultrasound money meme. The community can can have that meme if they want. I think it's done, it's been a valuable resource and pushing 1559 forward.

Not my place to perpetrate it, but I think that the value of ether being something that's staple is really good for security of the network. Thanks for sharing. That was, yeah, quick to history. Barna Bay, you want to go next? Sure. Hi, everyone. I'm very happy to be here. So my name is Barnaby Mono.

I'm a researcher at the Robust Incentives Group, which is a research group funded by the Ethereum Foundation. We mostly do things that look like Game Theory, a bit of economics, modelization, simulations. And actually, my experience with 1559, started, like everyone else, when I was just trying to understand it. And the way I understand things is I just try to simulate them and see kind of how they play out.

And this is really kind of when it clicked for me. And I think the major insight that I got and that I feel, okay, this is when I actually understand. 1559 is understanding why the dynamics of what we call the priority fee or sometimes the tip are completely different from the dynamics of the gas price as they are today, which is something that many people, I think, still have a bit of confusion around. like why aren't we just shifting to a model where, okay, there's a tax, the base fee, and kind of people still need to compete on that tip to the miners. And once you get this insight, I think you really unlock everything that makes 1559,

like a step change in the way that the protocol is doing the gas market. And so, yeah, I hope we can talk a bit more about this, but I'll leave the other guests. Thanks for sharing you. Micah, you want to go next? Yeah, sure. So I can actually show you guys my, where I learned how EIP159 worked. Let me share my screen here real quick. So back in July 2018, Vitalik wrote this article on E3 Search Forum.

It talks about basically what ended up being EIP159. I can see here, this is, you know, 12 a.m. or whatever on July 3rd. And then, like, I don't know, six hours later, Micah shows up, and I'll paraphrase, so you guys don't have to all read this. It basically says, come on, Vitalik, why are you being an idiot? This won't work. There's no way this will work. This is not any different that we have right now. We can do better.

Then Vitalik shows up, and again, I'll paraphrase a little bit, and he basically says, oh, my God, who is this guy? I've never heard of him before. He clearly doesn't know what he's talking about, and he tries to explain some stuff to me, but you can tell from his tone that he obviously doesn't think I'm going to get it. I'm beyond help. Then, you know, a few hours later, again, this is July 4th. So we're going back and forth pretty quick here. I basically just, again, tell him that he's wrong, obviously, and this cannot work. And then he again tells me, no, you're wrong.

And we just basically go back and forth, back and forth. And then Micah mysteriously disappears for like three months. And then I eventually come back to this thread. Actually, maybe it was like a year later or something, or another thread, years later. and I came back, guns blazing, and I was like, oh my God, everybody needs to get on board with the EIP-1559. This is the best idea ever. Hopefully no one remembers what I said in the first place. So, yeah, so if you're curious about my learning experience, go ahead and look at this link on the EF research forum,

and you can see how Micah, the person who is now probably the biggest proponent of EIP 1559, originally was the biggest naysayer and just spoke aggressively against everybody who thought this is a good idea. Wow. Do you remember what made you change your mind between kind of those two? It was just, I mean, Vitalik ended up being right. I was wrong. And so he patiently explained things to me and I just didn't get it. And a lot of the things I didn't get were the exact same things that people who I explain EIP-15592 don't get. And so I can appreciate where they're coming from. It's like, I was there. I was that guy who was like, no, this won't work. This is not. you know, the mechanics are wrong. But once you actually dig in, really let it sink into your brain, the mechanics actually do work. Like it does make sense. But it's not obvious at first. And the specifics are kind of nuanced and maybe we'll get into that later in this call. But yes, it's the same reasons everybody else thinks it won't work. Well, that's really a turning of the tights. Cool.

Hasu, I want to go next? Sure. Yeah, I'm Hasu. Hi, hi, everyone. I'm a research collaborator at Paradigm. I'm also a co-host of the Uncommon Core podcast and still general editor at Deribate Insights, which I helped bootstrap. My first touchpoint with ERP1559, I would say, was in early 2020, when I did a month-long deep dive with Georges, who also collaborated with later on on many articles on ERP 15559. and we did what was basically a deep dive on all possible block space market designs that

are employed in the crypto space. So across all projects pretty much. We looked both at existing proposals and at, or basically existing implementations as well as stuff that has been proposed and try to understand why it has been like what are the goals of the proposal and for historic stuff. Why has it been discarded? And a lot of stuff that has been discarded has been broken. So it was very, very interesting to see all of the different stuff that you can propose

and then like work through on your own, why is this a broken proposal? Why does this not work? And this is where we stumbled across EAP-1559, which was barely starting to get any traction in Ethereum, I would say. And yeah, I was, I would say mostly thinking about Bitcoin at the time and not very much about Ethereum. And so my first instinct looking at this was, well, this is an over-engineered mess. So it has so many goals, right, described in the original post and so many aspects of it.

So there's the fee burn, there's like the elastic block size. Then the protocol quotes a fixed price, but they still have this tip option on top. And it was so many things. And it tried to be so many things at the same time, at least what it seemed like from reading the goals. But then I tried to point out why it's actually broken. And I had a lot of experience, a lot of training at this, because for months we had been dissecting all kinds of block space protocols. And I couldn't.

And within like a few days, I realized, yeah, this is actually, like all of these moving parts are actually necessary. And it just affects so many things inside Ethereum. That's why you can say it has so many goals. But these are like really oftentimes like downstream effects. Right, like the fact, for example, that we burn Eve is, you could say, like, so the people who use if has money, they like that it creates a disinflationary pressure on the price of Eve. But then, like people who care a lot about security, like that it cements EVE. That's the fee-paying asset in the block space market, even if the user pays in any other currency,

like even if you get extracted away on the user side, which I think we are all for in the long term. but the miner still has to keep an inventory of Eiff and still has to burn EVE. So it has like all of these very nice properties. Yeah. So yeah, that was basically my experience with EIP-1559. And so this culminated in our post like analysis of EIP1559 for Derribute Insights. Again with Georgia's. Yeah, and this, I think this for many people was the starting point hearing about this proposal,

because we used to get a lot of reads at the time. And I think this was really like for us when you had like this crowd of people who were really interested in following it and asking for more and more and more content on it. And yeah, I've been in so many Twitter discussions and so on because so many people have the same questions, right, that I had before it clicked for me. And I think it was really good training, like just engaging with people on Twitter and on podcast and explaining it to them like a hundred times engaging with the different questions. So yeah, here we are.

Yeah, it's pretty impressive how almost everybody here, or I think basically everybody here started off as a skeptic and slowly got converted to like in 15-159. Bartoway, you mentioned in your answer, you know, like the new mechanism is obviously going to be better for gas usage and whatnot. And you've also mentioned to me in the past that once it goes lives, you want to actually track that and try to quantify the impact. So can you kind of give us a bit of detail of like, what are you expecting to see? What metrics are you expecting to change when we launch 1559?

What would you consider a success? What are some things that would kind of scare you if you saw them once 1559 went live? Yeah, that's a great question. And I think my motivation here is really driven by the fact. that I spent all this time doing simulations, trying to think through, okay, how do things work when they actually launch? You can't really get these answers from, let's say, so we have all these test nets, which are awesome to test that the code is working, clients understand each other,

but they don't really tell you so much about the economic properties of the mechanism or really what happens when there's actual money on the table. So we know cannot go maybe too wrong because it is live in some version on some other networks. But the things that I will be very much looking at and that I think are super interesting to keep track of. The first one is kind of looking at, if you're thinking of the chain, you have these metrics block by block,

looking at the gas used. So you have in 1559 doubly sized blocks, which allow to have like kind of this damper when you have demand shocks, trying to understand, well, are the blogs getting too full? So one question we often get is, how often does 1-559 revert to a kind of auction on the tip? And Hsu and Georgios kind of made this meme of 95% of the time,

like things go right, 5% of the time. Maybe there's too much people at the same time and we need to have this auction. And in that case, the mechanism still works, but maybe there's more instability on the, the user side. And so one question is, well, is it really 95%? Can we quantify how often 1-559 is pushed in this kind of regime? The second thing that I'll be looking at, and it's certainly kind of dual to the gas use is actually the series of base fee themselves. So we wrote a

paper with some of my co-authors. We've seen that most of the time, base fee, so the base fee update rule is kind of a multiplicative rule that depends on the gas that was used in the previous block. These update rules are really, it's actually a fairly simple one and let's say even naive, but it's good that it's naive in some sense because it makes it somewhat robust to whatever the protocol can throw at it. But we know that there are regions where that update rule can be maybe too slow to pick up the actual, like if the demand is changing really fast, you want the base fee to catch up with this as fast as possible. And in other regimes, it can be also too fast. And when it's too fast, it just kind of flip-flops around value without necessarily

getting to that equilibrium. And that can lead to instability in the sense that you can see blocks which are empty because base fee kind of jumped up and everybody is priced out. And then it goes down, everybody wants to go in and you can have this. So we know that in theory, that's something that can happen. In practice, maybe, I mean, I'll be very curious to see if we actually see that happen. And one reason that we might see it happen, which is maybe the third thing that I'd be looking at, is also kind of how users send their transaction via their wallets, and their wallets are using oracles to kind of determine the parameters.

For 1559, you have two parameters, the max fee and the priority fee. And depending on how these parameters are set, It's possible that you can find different patterns in the way that the transactions are first dealt with at the transaction pool level. So how they kind of get ordered by the clients. But even when they reach on chain, yeah, what do you observe? Do you observe these oscillations? Do you observe that maybe the oracles can be tuned given the data that we have on it? Like we often say, okay, you should take this kind of random constant as a,

as an Oracle default, we will change it when we know a bit more about the mechanism when we have the data. And so I think it would be very important to kind of back test how the Oracle's have done, especially at launch where we have this mixed regime. Some wallets will be still sending legacy transactions, so like the old format and new wallets,

or same wallet, but new versions, we'll be sending more 15598 transactions. So kind of picking apart, yeah, how wallets are. are doing, can we back-test it, can we understand how to make them more optimal, perhaps. These are definitely the things I'll be looking at. Cool, thanks. And so to summarize at a high level, three things.

How often do we actually get this reversion to first price auction? So basically 100% full blocks. How does the base fee evolve? Do we oscillate smoothly or do we just kind of go from full increase to full decrease? and how well do Oracle adapt to set basically the priority fee for transactions, right? Yes, excellent scenario. Yes. Nice.

And Micah, I think you wrote what was, at least for me, the best explanation of like why 1559 actually improves UX for end users. And I know you spent a lot of time in several Discord servers kind of dealing with users who say have their transactions pending and stuck. today. So can you take a few minutes to actually walk it through from like a kind of a new user to Ethereum coming in like why is 1559 going to provide a better experience for them to get their transaction included than the current system? Sure. Let me go find an article I wrote so I can read it real quick. I remember what I said apparently it was a great argument. If I remember correctly, so basically right now what we see, So for those who don't know, I run a little side business where I offer support services,

outsource support services to Ethereum applications on Discord. And so I have a lot of insight into what problems users run into because my team is constantly helping these users deal with those problems. One of the most common problems we see from users is stock transactions or pending transactions, same thing, different names. And so a user does a thing on Ethereum, like they go to Uniswap or they go to whatever app they're using. They go to use it. They plug it into the app, it pops up Metamask, and they say, okay, and they basically use the defaults.

And they think that their transaction, they just says a little pending spinner shows up, and they're like, okay, my transaction should be included soon. The problem is, is writing an Oracle is very hard. So figuring out what the right gas price is is a very hard problem today. And so that app, so Metamask, is doing its best to try to choose a gas price that results in two things at the same time. One, the user isn't overcharged. So they don't want to set a gas price that's really high and then the user ends up paying more than they needed to. And two, a gas price that is not too low that the user's transaction doesn't get included. When gas prices are stable, so when the demand for Blockspace and Ethereum is very stable over time,

meaning like the exact same number of people want to be included as are submitting, you know, spread out over, let's say, 15 minutes, then this problem is pretty easy. You just say, okay, what was the, you know, look at the previous blocks. Okay, they're all around, you know, 20 or whatever. So 20 is what we'll set. This problem becomes much, much harder when the demand for Ethereum is increasing for any reason. So it increases because there's an ICO or a new NFT sale or just because people in the U.S. are waking up or because it's a weekend or a weekday. Or, you know, it's the second Thursday of the month and it's payday in, you know, Azerbaijan or whatever, you know, whatever it is that causes gas demand of Ethereum to increase is very complicated. Like, this is the whole world of people doing things. And for some reason, they have all decided to do things on Ethereum right now. And so what happens is the user shows up, fills in everything, hits submit, and a gas price is set by Metamask using an Oracle that usually works pretty well.

But this time, it didn't because it estimated a gas price based on. history and demand is increasing and so the gas price just keeps going up and up and up and up. But the problem gets worse. So the user has a stuck transaction. You'd think, okay, well, they can just increase their gas price. The problem is the user doesn't know this. The user just knows their transaction is stuck. So they, what do they do? Like, okay, I'll refresh the page. So they refresh the page. But now the page doesn't remember that their head-upending transactions. So then it just prompts them again, hey, what do you want to do on the internet? And they say, oh, I want to swap some coins. So they go and fill in the form again, they swap some coins and hit the button. And it still doesn't work. So they

try it on their browser and they repeat the process. And now by the time the user comes to us for support or comes to somebody for support, they've got like six transactions out there. If we're lucky, someone helps them that can walk them through the process now of canceling all those transactions because the user only one to do one swap, but they've got six swaps pending. And so someone will walk them through the process of canceling those transactions, which is not super hard, but it's, you know, it's kind of technical. And the users don't really understand what's going. on so just kind of blindly following people on the internet who are giving them advice and we all know that's a terrible idea and so like that's that's the happy path where people are following advice of random strangers on the internet to fix their problem

the unhappy path is they don't go seeking help soon enough and what ends up happening is all six of those transactions go through and instead of buying you know five eth worth of doge coin they now have bought 400 eth worth of doge coin and they do not want 400th worth of doge coin because it turns out out that drop tanks the Dogecoin price or whatever it was they were doing. Like the thing they're doing is not the thing they wanted to do. And so now you have a very unhappy user who now is seeking help and like, how do I undo this? Okay. So the first thing they try, of course, is, okay, let me, I'll swap back. And so they swap, go to swap back. But, you know, for whatever reason, there's huge demand and they get in the same situation. So they, you know, swap back 20 times.

And now they're, you know, shorting Doge or something. I don't know. Like the point here is the users get into these really weird situations when things don't behave as they expect. And 1559, the hope is that we can kind of solve for the most part, solve this whole class of problems by just making it so that one root problem. So that one root problem in this scenario was writing an Oracle for the gas price is hard. Predicting what the future price of gas is is a really hard problem because you both don't want to go too high and you don't want to go too low. And so you can't just like overbid because then it costs the user too much money. You can't just underbid because then you end up stuck. And so that's a really hard problem.

And so 1559 will hopefully make it. So when the user goes to Metamask, Metamask can follow a very simple algorithm that will 95% of time, or hopefully even more, 99% of the time for lucky, we'll get it right and will not result in users in that situation. And when it gets it wrong, we want it to fail gracefully. So in the ideal situation, that 95, 99% that we're hoping for,

what's going to happen is the user will be included in the next block and they'll pay exactly the minimum they need to pay, and that was it. In the kind of worst case, hopefully, worst case scenario, the user will have to wait a little bit, but they'll still get a good price. Like, they still won't end up overpaying. And in the worst case scenario, you still, I will acknowledge you can still end up in this kind of pathological pending transaction situation.

But the hope is that becomes a much, much more rare thing. It doesn't happen to like, you know, 100 users a day. It's happening to, you know, one person every couple of months gets stuck in this situation. And that's a significantly better situation, just from usability and making it so users, experience with Ethereum is simpler. And all this, just because we can solve that Oracle problem easier because we now have the data and we now have this second price auction thing. So you don't need to try to do complicated auction stuff. Thanks. Yeah, that was a very colorful overview of this situation. And I think it's one of the things that gets missed a lot. Like when we

talk about 1559, people say like it'll improve the U.X. But yeah, that's often like a very abstract thing. So yeah, this helps kind of put it in perspective. Moving out to Matt, you've worked on like not only 1559, but on a ton of other kind of pretty important EIPs. Like your team worked on account abstraction last year, which eventually morphed into 3074. You've implemented 1559. And you're one of the people who has background both kind of with the smart contract level and the core protocol level, which is, which is rare. usually people are on one part of the stack or the other. So how should smart contract devs build it on Ethereum kind of think about 1559

and what, you know, should they change anything about it? How should they basically, yeah, change your practices or approach 1559 as it gets deployed? Yeah, I think that's one of the cool things about 1559 is like Mikeo was saying, there's all these UX improvements. But for the most part, smart contract developers get to just take advantage of all of these things for free. Like, there's been a lot of work by core developers and researchers up front to try and make sure the 15 and 59 is a change that's safe that it's actually works the way it's intended

to. And a lot of other, the burden has been shouldered by these wallet teams, like developing how they're going to choose these priority fees and interoperating with new RPCN points. And so now the smart contract developers kind of get this free ride. They just get to take advantage. They get to continue building there. their smart contract to take advantage of a lot of this work that people have been doing over the last few years. There are a few nuanced cases where 1559 really does come into play.

And one of the interesting ones is that the gas price op code will begin to behave slightly differently. It's not really something most people are actually going to notice. But now for 1559 transactions, the gas price op code will return the effective gas price to the transaction. So that takes into account the base fee. It's the actual amount that's being deducted from the account paying. And if for the most part of people who use the gas price off code, this probably isn't going to be a problem. There is like a very specific class of people, though,

that use the gas price op code in pathological ways or expect that they could potentially have a gas price of zero. And that's something that won't be possible with 1559 anymore. So you've kind of removed a few paths of execution that could have existed in the world. So now if you ever had anything that was checking, if gas price equals zero, then do this. That's not going to be possible anymore. And so if you were a smart contract developer who decided that was a great idea,

then that's something you should consider. There is a class of people. I don't know if they actually have gas price equals zero, but flashbots does generally require that these bundles are being included with a gas price of zero. This kind of helps them from if their transaction as uncle, they don't have to pay the gas cost to go into the transaction. And so if you are someone who's planning to use flashbots,

for something, whether that's for MEP or for account abstraction or user onboarding, these are things that you should take it to account. And I'm not certain what FlashBots has chosen to do about this, but now you have to understand that you won't be able to have zero gas price transactions anymore. So that's kind of how 5059 changes what exists in the EVM today. But 1559 does add this new base fee functionality. And an op code was added not in 5059, but in a different EIP 3198. and this base Vop code is going to provide really exciting new functionality to the protocol.

A smart contract developer should consider looking into and maybe using. And there's a couple of places where this base Vop code could be really valuable. The first one is if you want to pay for some bounty to be executed on chain. I know there's a couple of protocols that do things like this where maybe someone will say, I want to have this limit of order executed at this price. And a relayer will decide to submit it on chain whenever that, bounty would pay out. But there's kind of this difficult problem with, like, how do you decide what a fair price to pay for them executing that on chain is? Because if you, you know, if you want to have a

bounty that pays out like years down the line, it's really impossible for you to know, like, is 10 gway going to be a good price for that bounty to pay out to the user? Or is like, are we going to be like, you know, 200 gway? And you can't really use the gas price off code because then the person who submits the bounty could really just grief the user. They could submit a 500 gway. transaction and there's no way for the execution of the smart contracts right now to get a fair idea of what the gas market looks like. But base fee is basically a mechanism for having insights during execution of what is the current demand for gas in the protocol. And so this creates like this really nice mechanism where you can pay for penalties more fairly. And having this base fee

The op code is also going to allow new financial permanence around the gas markets to emerge. I think we'll see people develop like future mechanisms based on the gas market. People want to speculate whether gas prices are going to go up and go down. And we kind of had this with gas tokens because you can mend a lot of gas tokens whenever gas was really cheap. And then there was demand for it. You could sell them whenever the gas prices were high or you could call them in. But there was a very significant transactional costs of using gas tokens. And it wasn't really something that was a net good for the protocol in general.

And now this base fee op code is going to be something that we can use to much more efficiently develop gas market primitives. So I think that's something that interesting that smart contract developers should look into and consider. The last one is really for these like layer two scaling solutions. There are a lot of fraud proof based solutions, rollups, even state channels have some sort of like replay mechanisms to play out states. And right now you kind of have this world where we just choose a static amount of time to give for people to submit their fraud proofs on chain. And I know like optimism says like one or two weeks is this is the challenge period that you have to submit a fraud proof. And that's to avoid, you know, minor censoring for a

long period of time. What we might be able to do with base fees, we might also be able to look at the actual load of the chain and determine how many people are trying to execute things on chain and potentially expand those fraud-proof periods during periods of high demand. And so that might allow these challenge periods to become more efficient so they can kind of become elastic with how much demand is in the market for block space. Thanks. Yeah, that was pretty comprehensive. And one thing you'll add is you mentioned, you know, using the base fee off code to build gas derivatives. It's also worth noting that London has another EIP 3529, which will make the current gas top tokens unworkable because of how it

changes gas refunds. So yeah, if you are kind of a heavy user of gas tokens, that's not going to be possible after London. And so, yeah, looking into ways to build these gas derivatives off the base the app code is probably worthwhile. I should probably also mention that if you're more of a full-stack developer for Ethereum. There's actually a fair number of changes that came to the RPC with London. And so this isn't something that if you're a pure smart contract developer, you may interact with. But if you are someone who maintains a back-end system for a defy application, you should consider looking at, I think Tim, you and Trent put together this comprehensive guide of the things that are changing with London. We could probably link that in the show notes.

but there are a handful of changes. And I'll mention like one, the, if you're calling these RPC endpoints that receive transaction objects, there is a gas price element of these transaction objects. And normally that's just the gas price of the transaction. But with 1559, we now have these two different elements that kind of relate to the fee mark and we don't have a gas price. But for backwards compatibility reasons, we're continuing to support gas price. And so that value will be equal to the max fee per gas before the transaction is mined.

And then after its bind, it will be equal to the effect of gas price to the transaction. And that's something that you should be aware of if you're a developer interacting with these things. So yeah, take a look at this document that Tim and Trent put together. Yeah, good point. Yeah, a lot of applications are not just smart contracts and they'll actually have to interact with the node itself. And changing gears completely. There's been a lot of talk about minor revolt around 1559 and the fact that the base fee burns of ETH, which obviously lowers their income.

And I think Haseu, you put together, alongside with Georgia, else, I believe, kind of one of the best explainers of why it's in miners' best interest to support 1559. So could you kind of quickly summarize that argument for us and, yeah, how you think kind of the game theory plays out here? Yeah, I mean, so you already touched on it, right? So why would miners even be interested in blocking E.P.1559 or somehow like revolving? against it, it's that the EIP will burn some of the fees that are generated in the block space market, right? And at this point, I would ask you like how, into how much detail you want me to

go because it would cover like stuff like MEV and how that plays into how much is being burned since I understand these might be like later questions. Oh, go for it. Yeah, yeah. Okay. Yeah. Okay. So basically the first analysis that we did was first to find out how much is actually being burned because we thought that before that point, there was this very, well, sort of naive understanding that like all the transaction fees that exist today in Ethereum would end up being burned. And so like all other fee revenue that miners make would go down and they would be only

left with the block subsidy. But fortunately, at the same time was when FlashBots started to get a lot of traction, sort of the private relay for miners. And they were very transparent with their data. And they started classifying a lot of sources of MEV, minor extractable value, and made public how many of the transactions in Ethereum today are sort of transactions that fight for MEV, stuff like liquidations and front running users and so on and arbitrage most of what. And so we took that data set from flashbots and tried to map it over the total minor revenue in order to understand. how much of what miners make today is actually from MED and how much is from regular transfers. And the reason we did that is that, to understand how much is being burnt, you can think of

sort of the block, the list of transactions, there's not actually one market, but actually several markets. So the market to be included, like anywhere in the block, is actually a very different market from the one about being included at a very specific point. in the block, for example, like at index zero, like being the very first in the block. So you can be the first to do an arbitrage between Uniswop and Sushi Swap, for example. So there was a very important insight that these are two different markets. And in the priority market, basically, EAP, that 1.5 doesn't change anything. This is a market that will always happen.

So between those who want to submit their transactions, get their mind in a specific slot and the miners who control the ordering. And this is money that couldn't possibly be burned. Because if the protocol set some value for that, then the market would just move off-chain for that. Yeah. And so we realized that all of the MEV that is extracted in Ethereum today will be untouched by ERP1559 and wouldn't be burned. And we tried to simulate that. We found that maybe 30% of the fees that are generated today are actually fees that are from regular transactors who don't care about where their position in the block is. And probably 70% or more is actually nowadays just from MEV extracting transactions.

So this was an important insight for us because it showed that it would be much less impactful on miners. And I think this also helped sort of to diffuse the opposition from miners. a bit because if you, I mean, you could argue that it's in the best interest for miners to like adopt any change that sort of the users want. And it is to a degree, but you can still create disruption in the mining market and create like perverse incentives there if you end up reducing the revenue that you pay to miners by too much over too short of a period of time. And so it was it was quite good that, you know, the reduction of revenue turned out to be much smaller.

And also that the uptake, the uptake from the market of this update was so positive that arguably contributed to, like, how we see an ether is the asset was perceived in, like, the public, basically, right? So because for miners, it matters not just how much revenue they make the nominated in Eve. So they don't just care about the Yves denominated fees, but of course they also care about so the other side of the equation, how much can they sell that E4 in dollars? So both of those were, I think, very important. So I think you have this one side, which we just discussed, that the reduction of fees is actually not that large. And second, that minors are structurally long EVE.

They have a lot of future revenue at stake. And so generally they are incentivized to go along with what users want and what they think, with users and developers and all of the parties building on Ethereum, what they think is best for the ecosystem, because that is what maximizes both the value of EF and so the economic activity that ends up generating all of this MEV and all of this transaction activity. Thanks, yeah. I guess, yeah, this is one thing.

I'm curious to hear other people's thoughts on this because estimates very, very wildly. You mentioned, you know, the current fee market is, you can think of the gas price as combining two things, the right to be included in a block at all, and then you're positioning in the block. And revenue in a post-1559 world from just the right to be included in a block is what's associated with the base fee. That's what gets burnt. And then revenue from positioning or right of inclusion when there's too much demand is what goes into the priority fee. fee. And you estimate there's basically like a 70% of this that would end up in the priority fee and therefore not be burnt and then 30% would represent the base fee. I'm curious if anyone else

here has thoughts on that breakdown. Do you all agree this is kind of what we should expect? Or yeah, anyone have strong opinions on this? I would add maybe one thing because this is this does not at all like refute what Barnabas said earlier that you have different regimes, right? Where the demand is very very high to get into a block and that's why you end up with the tip auction. So this is something that happens in every block, even if the block is just 10% full, you are still going to have competition to be in the top spot in that block that has otherwise zero base fee. Yeah. And zero tip. Yeah, I guess a way to think about it, it's always like if you had two blocks and one of

them had just room for one transaction and then, you know, the rest of the transactions is almost like a separate block. Yes. Yes. This is exactly the right framework. Thinking of it, not as one, block, but actually has several blocks stacked on top of each other. Yeah, yeah. And there's always going to be obviously kind of one transaction's worth of demand for that sort of premium block, and then the demand for the rest of the block space varies based on just general demand for Ethereum. Yeah, I'm curious that the people generally agree with that split. The people have kind of differing opinions. So I don't know the exact number breakdowns. The thing to keep in mind for everybody is that the

the MEV or minor extractable value is highly variable. And so we will see some blocks that have relatively little, like it's not very interesting. And you'll see a block that's got like 100s in it. And so in that 100th block, as Hasu kind of described, like the person who paid 100th to get to the front of the line, they really, really, really want to be in the front of the line. Like they're willing to pay 100th to be at the front of the line.

They are going to pay 100th to somebody. to get to the front of the line. Like, either that's a minor through gas price, or it's a minor directly, or it's some off-chain payment channel, or it's, you know, a cash dropped at it underneath a mailbox. Like, they will figure out a way, when you've got a hundred ether, you're throwing around, you'll figure out a way to get the money into the hands of the person who gets to decide who goes first.

And so, so yeah, so from that standpoint, I totally agree with everything has to have said. Like, you can't avoid that. You can't make that go away. You can drive into the dark, which just makes it harder to see and harder to record, but it will always be there. And so, but that means regarding 70% versus 30%, it's hard to say. Like, there's many people who have done research on this and come up with different numbers. I think a lot of it comes down to, like what time frame you look at. If you look at some, like back

when things were going crazy, what was it, like six months ago or whatever, nine months, I don't know how long ago it was. Like, that's very different than, you know, a boring week in the middle of summer, you know. And so just keep that in mind with any sort of stats like this, that it really depends heavily on what time frame you look at. Like, if you look at like a one, a five-year time frame, it's very different than a one-year time frame, which is very different if you look at 2018 versus 2017.

Like, there's so many variables here. It's really hard to come down with, I think, a concrete number. But in general, I think Hatsu is generally correct. There is still a lot of value going to minors and will continue to go to miners, as long as they are the ones choosing block order. Barnaby, Matt, any thoughts? I mean, I don't have much to add.

I think it's quite clear, but I do have in mind this idea. Yeah, basically looks like today's gas price or like average median gas price, let's say. Priority fee is mostly going to be nominal, like the minimum you need to send to be included by the miner, except maybe when you have kind of like these tip auctions, and then you have this MEV process,

which I think so maybe one thing is the 70-30 figure kind of hides the fact that as Micah pointed out, MEV is extremely variable. So you have much more variance perhaps in revenue for miners. And this is perhaps something that's worth just pointing out. Yeah. And I guess talking about MEV, I think Haseau, your analysis was maybe one of the first ones related to 1559 that actually took MEV into account. But if you look at a lot of previous analyses, including, for example, Tim Rothgarden's paper, or even some previous papers that were written on how kind of high transaction fee blockchains are less stable and more prone to short reorgs than high block reward relative to the transaction fee chains. None of this kind of took NVV into account and they were all kind of written in a pre-MV world.

So I'm curious, you know, are there other spots? where, you know, aside from the actual just minor reward, you think MVV can have an impact with 1559? Oh, was that at me? I thought. Anyone, yeah, yeah. I don't really have anything to say at the moment. So if anyone else has any thoughts? Maybe just to, yeah, point out that by design, 1559 really addresses more the problem

of pricing inclusion in a block. And it's almost completely agnostic to the problem of position. So inherently there's not so much interaction between the two. Like the base fee is kind of this minimum fee to enter the block. And so that really has nothing to do with what happens at the top heavy, like long tail of this high gas fees. So yeah, that's maybe one reason why MEV and 1559 don't interact that much. The one place where they do is now these MEV strategies, they need to pay the base fee, whereas before they were able to submit more like ZEV.

zero gas price transaction. So, but this is not a huge difference. Yeah, I would second that. I think it just makes sense, just even for the sake of it, just drive from like the notion that like, EIP-159 does not fix MEV because for a long time, this was a popular talking point, I would say. And yeah, took, like, I think it's just important

to say it again and again and again. There's not really much overlap between the two apart from what Vanabey said. Mika, you un-muted yourself. Do you want to say anything? I was going to say basically the same thing. EIP-1559 does not fix censorship attacks. Like censorship attacks are still a thing, and they are still a risk. This is why we're moving to proof of stake, but that's for a separate call.

1559 will not make those go away magically. Yeah, I do think this is an important point to make. The other thing 1559 doesn't fix is high gas prices in case anybody still believes that. So yes. Oh, yeah. That's the other good one. Yes. Cool.

I guess bridging back a bit more to the technical level. Matt, one thing that was interesting is you actually implemented 1559 in Geph, and you're not part of the Get team itself. So you kind of ended up writing the reference implementation or the implementation and kind of the reference client. Can you talk this true, like what that process was like how, you know, yeah, as like a non-maintainer, you got this pretty massive change included in the code base. Yeah. So I think like the journey for working on 5059 for me started in early 2020 when we started working on account abstraction. And so my team Quill, we spent about six, seven months

working on account abstraction, we wrote an implementation in Geph of this EIP, and we were benchmarking and all these things. And during this time, there was like more discussions in the summer about how to have typed transactions in Ethereum. And this was something that Micah was proposing. And I was really interested in type transactions because that was a way to path forward to maybe having sponsored transactions in the protocol. And that's something that, like, is really exciting for me because I think that's a big U.S. problem with Ethereum. And so, So I was all on board with type transactions, and it also helped account abstraction. And this is kind of whenever I started getting more interested again in 1559, because 1559 was another

type of transaction. And so I sort of volunteered in the fall. I said, you know, it sounds like type transaction is something that's useful. Let me just implement it in Geth. And so I pinged the Go Ethereum team. I p. Martin from the team. And I said, hey, is it okay if I just implement 2718 for you? And he said, sure, go ahead, knock yourself out.

this was kind of like earlier in the cycle of Berlin and it wasn't 100% certain it was going in and so they didn't want to waste cycles on dealing with 2718. So I, and it was a pretty big change in the code base because it basically added this discriminator to, like it basically broke this transaction type up in the go theorem code base and now you have like multiple transactions and kind of this new abstract type for transactions. And so I would kind of like ping them every once in a while and say, hey, does this, does this look okay? And they would, you know, respond and say, yes, this is good.

This isn't good. And generally that would happen. I mean, a lot of this stuff happened in the open through GitHub and through PRs. And so I think that if people are like watching this, this live stream and that they're interested in core development, like a lot of the times it's just a matter of opening PRs and trying to become part of that process. So I did 2718. And that really set me up for working on 1559.

And I think, Tim, I don't know if it was started with you kind of like pinging me and you're saying, hey, are you interested in helping with 1559? And I think I was kind of like rebuffing you in the beginning because there we were working on some other things at the time. And 1559 has really never been something that like I personally was like very, very excited about because it was something that was something that made a lot of sense. But I was more interested in things like sponsor transactions. And so I kind of like rebuffed in the beginning saying, oh, there's. other things will work on. And so after I think a little bit, I just realized that, you know, there's only a handful of people right now who can implement these kinds of changes in Go Ethereum. Go Ethereum team at that time was like doing a lot of other things. They were working on

Snap Sync. That was like a really big thing they were trying to launch. And so it was like, this is something that I should do. This isn't what I want to do necessarily, but this is like for the greater good of the ecosystem. So I need to become a part of it. And like, it worked out really well. I really had a good time implementing. And so I implemented most of 1559 in like one or two weeks. The core consensus changes were like relatively straightforward. And I kind of like put a PR together and shared it with the Go Ethereum team and was able to start syncing with the 1559 test nets at the time that Adele from the Basu team had put together. And so the actual core changes were not super significant. They touched a lot of

parts of the code, but generally it wasn't a crazy change. And then basically for the next six months, it was a matter of all of the auxiliary pieces, all of the testing. And I don't think that it's, I don't think a lot of people understand, you know, just implementing an EAP, that's like 10% of the work. And, you know, I'm already standing on the shoulders of giants, all the people who have done the research vetting, vetting the idea in general. Like, I think 1559 is one of the most rigorously analyzed eaves that we've ever had go into the protocol on all aspects from, you know, original design and research to engineering, to testing, to fuzzing. And so I, for about six-month period, was just helping implement all these other things,

right, working on the MIMPOOL implementation, changing the way that the minor works. And a lot of the work lately has been RPC in points. and 1550 and 59 changed a lot of aspects of the RPC. And I think for me, like the biggest takeaway from working with 1559 is that we need better facilities for discussing changes in the Ethereum protocol. And if you look at the 1559E, it basically just implements a really stupid Ethereum client in Python because that is kind of like the best way of describing these changes. And so I think the similar thing with the.

are the RPC endpoints. It's really difficult to just discuss in pros and through one-off EIPs, how these things are changing. It's a lot simpler to follow a more traditional software engineering process and say, here's a new release of the RPC, et cetera. Yeah, thanks. And I guess a quick-related shout-out that you are working on an actual full spec of Ethereum executable spec.

So that'll be really helpful to have. Yeah. Shout out to my team, Sam and Somo, they've really been. grinding out, we're going to replace the yellow paper with the Python implementation. So that's very exciting. Yeah, that'll be great. Micah, I see you went off mute for a second. Yeah, I was just going to say that just to echo a little bit what like client said in the middle there, I think a lot of people assume that, you know, a platform that's managing $200 or $300 billion or whatever probably is being built by a company the size of Microsoft and has, you know, 40,000 people working on it.

And so surely one developer won't help. In reality, this platform that is managing, you know, hundreds of billions of dollars has far, far, far fewer people working on it than Microsoft has. And yes, one more developer definitely can help. Like there's lots of places you can contribute. Like Matt said, one of the greatest ways to get started is just find something that you can make better in just a small way and submit a PR and just make it better. You know, if you're not a developer, there's other places you can help as well.

You know, EIP editing is a lot of just kind of grammatical and clerical work, like just kind of making sure things flow through a process. You don't need to be an expert in, you know, some arcane language in order to do that. Lots of places people can contribute if you're interested. Yeah, definitely agree there. The amount of people who make this possible is shockingly small. Yeah. I guess, yeah, before we move on to audience questions,

I have kind of a final two-part question for you, Hasu. So, yeah, you were actually pretty new to the Ethereum community. And I could say, you know, 1559 was almost your entrance into this community. So I guess first I'd be curious, you know, to hear you just like talk through your experience of kind of advocating for this massive change as someone who wasn't like deeply embedded in the community. And then kind of the second part would be, is 1559 something you would want to like campaign to see elsewhere, possibly even on Bitcoin in the future? Okay. So yes, I would say that EAPU-159 was sort of my entry into the EVE community. I had been a knee-fold up before that and I was sort of following it.

But yeah, I really got my start with EIP-1559 and with DFI when I really started to appreciate what you can. can build on Ethereum. And yeah, I mean, how what that affords you basically the tradeoffs that Ethereum makes because as a Bitcoin are you always focused on the tradeoffs that Ethereum makes, but you like some people don't see all the good stuff that that buys you, right? The ability to have non-custodial, permissionless finance, have a sandbox for developers to play around. And I think we will see amazing things happening as a result of that in the next decade. And yeah, I would say that it's hard like to trace back exactly like, like where that started, like that turning point for me.

But it was around that time, definitely, like, both the IP-1-559 and DFI and seeing, you know, just writing research and just, it was like taking up so well by the community. And like the, just the feedback was so good. Like so many people were open to collaborate. It was just, I mean, it's, it sounds like a meme, but it was really like everything that like people praise about the Ethereum community. So I could really like confirm that this was definitely true for me, right? that you have a collaborative spirit and everyone's really what open to talking to you.

Like, no matter who, right, can be like really high profile people. I never had the impression that like any, there were any closed doors in that sense. So yeah, I think that's why nowadays I would definitely say I'm more, or at least just as much home in the ATM community as I'm in the Bitcoin community. And going back to sort of my intro, when George O'N I did this deep dive into block space market protocols, this was at least partially informed by sort of my like a deep-seated fear that I have about what happens in Bitcoin when the block subsidy goes away. Because until this point, like the demand to transact hasn't really been enough in any longer period of time. to pay for security and Bitcoin. So there's really like two possibilities here. Like either the demand picks up and we still have this like systemic problem,

but it's sort of not not relevant because people, there's not enough demand to transact and people are going to pay these fees. Or we make some change to the block space market mechanism or to the monetary, to the monetary policy, basically. And yeah, this was sort of the original what set us out on this quest to find what's possible. And I don't, like,

so first of all, I would, like, every chain that has a block subsidy, I would recommend to adopt EIP-1559. And I think we're seeing it almost everywhere now. Like, almost every new Ethereum competitor starts out with EIP-1559 implemented. I think we know, I've seen at least eight chains, seven, eight chains that have it, have had it before Ethereum,

which is kind of funny. But I mean, that's just how things go, right? When you have these, like, smaller, more nimble chains where there isn't a lot of at stake and you can just, you know, just do it. So for them, I would definitely recommend it. But this shows sort of why it may not be possible in Bitcoin, at least like, as the designers right now, because EAPD-1-5-9 burns, the non-priority. part of the transaction fees, which in Bitcoin is 100% of it, basically, because there's no

MEV or almost no MEV. And so you would burn all the transaction fees, simply speaking, and we already don't have enough transaction fees. So you kind of rely on there being a perpetual block subsidy that can pay for security. And you don't have that in Bitcoin. So I think unless that changes, which I see is very unlikely, I think it's unlikely that we begin. get we get to see any sort of proposal where transaction fees are burned or the protocol itself sets the price of transactions. I would support other proposals, for example, fee smoothing mechanisms where sort of part of the fee is paid forward into a security fund, for example, that can then, like when demand

to transactors high, generate more fees than necessary. So you start paying some of those maybe into a fund and later than when block subsidy as declined, you start consuming this. So at least buys you like maybe a couple more years or so until this becomes serious problem. So yeah, that's a proposal that I think would be more fitting for Bitcoin and one that I would campaign for. Yeah, that's super interesting. And you can even imagine like a naive implementation of that where if fees are on average high enough to secure the chain, but maybe not on a per block basis, then like a 1559 mechanism where the fees get sent over, say, the next 100 blocks or something can help you convert this kind of volatile income stream

into something that's a bit more predictable as a security budget. Yep. Yeah. Yeah. So everyone will have done 1559 before Ethereum and Ethereum will have done it before Bitcoin. I think this is a good place to open up for community questions. David, do you want to take it back? Absolutely.

You guys, that was an absolutely fantastic panel. I'm going to have to rewatch that myself to make sure that I caught everything. So thank you guys all for being here. I need to get Ryan back into the show because we kicked him out before just video logistics. So we're going to take community questions. If you are watching on YouTube, we have been logging some of our favorite questions in a little document, but this is your last chance to get new questions in there. We're going to cut to sponsors for a quick two-minute break.

I'm going to get Ryan back in here, and then we're going to start going through some of the community questions that we got through YouTube. So here we go. Bankless is proud to be supported by Uniswap. Uniswap is a new paradigm in asset exchange infrastructure. Instead of a cumbersome order book system where trades are matched with other humans, Uniswap is an autonomous piece of software on Ethereum, which is what Ryan and I call a money robot.

No human counterparties or centralized intermediaries, just autonomous code on Ethereum. Input the token you want to sell and receive the token you want to buy. Something brand new in the Uniswop ecosystem is the Uniswap grants, program is now accepting applications for grants. We have been saying this for a while and we'll say it again. Dow's have money and they are in need of labor. If you think that you have something to contribute to the Uniswap Dow, apply for a grant to Uniswap. Just look at the size of the Uniswap treasury. It's almost $3 billion. This mountain of capital is looking for labor. Do you have

something of value to contribute to the Uniswap Dow? No matter how big or small your idea is, you can apply for a UniGrant at Unigrant.org and help steer Uniswap in the direction that you think it should go. That's exactly what we did to get Uniswap to be a sponsor for Bankless, and you can do the same for your project. Thank you Uniswap for sponsoring Bankless. The Ave Protocol is a decentralized liquidity protocol on Ethereum, which allows users to supply and borrow certain crypto assets. AVE version 2 has a ton of cool features that makes using the AVE protocol even more powerful. With AVE, you can leverage the full power of Defi Money Legos, Yield, and Composability all in one application. On AVE, there are a ton of assets that you can supply to the protocol in order to gain yield,

and all of those same assets can also be borrowed from the protocol if you have supplied collateral. Here, you can see me borrowing 200 USDC against my portfolio of a number of different DeFi tokens in ETH. I'll choose a variable interest rate because it's a lower rate than the stable interest rate option. but I could choose the stable interest rate option if I wanted to lock in that interest rate in permanently. V2 also features the ability for users to swap collateral without having to withdraw their assets, trade them on uniswap, and then deposit them back into AVE. With AVE, users can do this in one seamless transaction, saving you time and gas costs. Check out the power of AVE at AVE.com.

That's AAVE.com. Hey, guys, we are back. The panelists are still on. We got some of your questions that came in via YouTube. we're going to ask them, David, man, it was fun to watch as a guest on one of these bankless panelist episodes. What a fantastic group of individuals, you know, Tim and crew managed to pull together. And yeah, what were some of your impressions, I guess? Yeah, my, my impressions are, there's just an entire massive playing field of just thought around EIP 1559 that like,

I've, I've thought that I was paying attention to EIP 1559, but like there's, it's one of those things that it has rabbit holes in of itself. And so like I said, right before we come, to sponsors. I'm going to have to actually relisten to this for my own benefit. Rabbit hole inception. Rabbit hole is within rabbit holes. Yeah. And I, you know, a few interesting things to me. I tweeted some of this out. It's like everyone on the panel seemed to start as skeptics and then they turned it to supporters. That's kind of interesting. You know, a panelist made the question, like Klein made the question, EIP 1559 is one of the most rigorously tested EIPs to go to the protocol. We heard Hasew's story about moving into the Ethereum community as part of protocol.

So I think this represents a lot of what's great about the Ethereum community, the level of analysis, the permissionless nature of it. It also represents some of the challenges. I don't know how many times the panelists said, hey, there's not that many of us actually doing this super important work. Like, come join us. Come submit some PRs. Like, we need your help in order to continue this whole research project and implementation project we call Ethereum. Anyway, lots of stuff to dig into. Let's get to the questions, though.

And I'm going to start here because one of the panelists actually may have thought they showed up to the wrong meeting because I pronounced this EIP 1559. And I've just been told that might not be the most canonical way to represent it. So actually somebody in our Discord channel asked this question. This is odd b a 11.eith. Maybe these panelists can tell us if it's pronounced 1559 or 1559 or as I have taken, uh, habit of saying 1559 guys, which is it?

What is the correct correct pronunciation of EIP blank? I won't bias anyone by saying what I think it is. Blake Klein, do you have any thoughts on this? Yeah. At the beginning of the show, I, you know, it was just settling in. you say, welcome, we're going to begin speaking about 15, 5, 9. I missed everything you said after that because I was like, oh, no, is this, this is the wrong call?

I guess that I've actually heard people say 1559 in a while, at least. I feel like it's 1559. That's the, I don't know, Tim probably talks about, Tom probably has dreams of different ways of pronouncing the optimal way of pronouncing 1559 but to me it's always been yeah 5059 if you want to go full formal if you want to go full formal EIP 1559 one at a time 1559 that's like formal casual that's what we do on bankless yeah that's like I guess you the right bankless branding me that's just me I don't know any other thoughts panelists I mean we're talking about naming obviously I have thoughts

My personal favorite is the 1,559th EIP since the start of Ethereum. That's usually when I'm in casual conversation. That's how I'll express myself to users. Sometimes if I'm in a more business environment, I will say the fee market change for the Ethereum chain. It really depends. Do you guys think that we're going to need to call this differently in the future after it's implemented?

Or is kind of EIP-159 here to stake? Is it stuck? Is it stuck? think that the boats of calling EAPS by not their number sailed a few years ago. Oh my God. Yeah, I mean, even stronger than that other blockchains call it EIP 5059, which always make me laugh, right? So, yeah, I think, yeah.

I don't know how many times I've had conversations with people like, you know, David and I, like, work on the layer zero, the social layer, the meme layer of Ethereum, if you will. And like, can we come up with better branding for this thing? and we threw around ideas, we had names, we tried some things, nothing stuck, like absolutely nothing. And so EIP 1559 it is, I think, for eternity. Where are we out on BIPs? Like, can we just put some like NOAABIPs in to get to BIP 1559? I don't know with a BIP. Hsu. What BIP are we on? What?

Oh, 300, 400. So I don't know how it works in Ethereum, but Bips and Bitcoin aren't given chronologically. So they are like the number goes up but like the first part of the number is reserved for like special things. Like it says what kind of what type of bit this is. So what kind of part of the system it touches basically. As long as number goes up, Bitcoiners are happy. We know that is true. David, you want to ask the next question. Yeah, maybe turning to more serious questions. A question from QB on YouTube is what happens when people send the old transaction types after EIP 1559 is switched on. Maybe I'll throw that one to Tim.

Sure. Basically what it does is behind the scenes, it'll treat your legacy transaction as, yeah, behind this Matt said in the chat, all funds are burned. That's not true. So behind the scenes, it'll send your, it'll convert your transaction to a 1559 one. And what it does is it sets your gas price equal to to both your max fee and your max priority fee.

And what this means for the user is that when you send a 1559 transaction, you basically get a refund for the difference between your max fee and the base fee plus the priority fee. So if you put a very high max fee, you'll never pay more than the base fee and your max priority fee. And that makes very easy to figure out, you know, to set a transaction because you can just set a high max fee and know you'll get included and get a refund. For legacy transactions, your max fee is equal to your max priority fee. So that means that any difference between the base fee and your gas price basically

will go straight to the minor or the validator. So it just means you kind of don't get that refund for extra fees paid. You can still, you know, if you're savvy, kind of estimate exactly what's like the right gas price and how to get that into a block. And that's basically your back to the problem we have today. But this is super important because even though it might be slightly more expensive for users, we never want to be in a spot where somebody is using your wallet that doesn't support 1559 and now they can't interact with Ethereum.

Or even another edge case is like you signed a transaction a year ago before 1559 was even considered for Mainnet and you had like this note to yourself that you were going to send this transaction on the network in two years and that transaction should still be valid. right. So yeah, legacy transactions will still work. Fantastic. Anyone want to add on to that before I move on to the next question? Hearing none, I will move on to the next question. This comes from Mr. Green, and I'm going to actually amend this question just a little bit. Mr. Green asks, what happens with your gas during a canceled or stuck transaction after the EIP 1559 goes live?

And I'll add on to this. How does the nature of a pending transaction that gets like, quote, unquote, stuck? How does that change once EIP 1559 goes live? I'll just throw that one to the open. Anyone want to take that? So if you submit a transaction after 1559 and you got very unlucky because you happen to submit it right when there is a massive increase in demand. So today you get stuck if there's any increase in demand when you submit it.

With 1559, you still can get stuck, but only if there's a huge increase in demand. And we're talking like 2X increase in demand over a very short period of time. And it's sustained. That's another key is that demand increase has to stay increased, like continue increasing for an incentive period in order for you to get stuck. If you do get stuck, then you are back in a situation you're in today. So we have very similar mechanics where you have to submit a cancellation or you'll have to submit a replacement.

And so that problem still does technically exist. I want to make sure, you know, all the listeners are aware that that problem doesn't 100% go away. The critical part is getting into that situation should now be very rare. And so, again, just reiterate, same problem, same solution, cancel or bump the price that your gas price effectively. But we really hope that if we tune things correctly, and this is what Barnaby was talking about early on the call, that after this launches, we'll be watching so we can tune things.

And we want to tune it so as few people get stuck in that situation as possible. And so maybe, you know, right after launch in a few days, we won't have gotten the tuning quite right and they'll still be, you know, a significant portion of people getting stuck. And that sucks and didn't achieve one of our goals. And so then in some future hard fork of Ethereum, we'll just dial some parameters and do some research and tweak things and try to get better. And so eventually we can hopefully get to a point where no one gets in that situation. Actually, Micah, when you're talking about, you know, tweaking things and changing things, that leads me to another question that was asked on YouTube. And this Awo's Baker, I believe is the username handle. I hear Bitcoiners using this argument against Ethereum that the Ethereum Foundation

constantly changes Ethereum. Is there any merit to what they're saying? I think this is a reflection on the critique that, hey, core developers shouldn't change the anything economic, anything to the issuance policy at all. And that is one of the virtues or merits that Bitcoin has. And Ethereum shouldn't make this tradeoff. Any thoughts on that question? Is there any merit to this argument?

I actually want to start with Hasu, is kind of our resident Bitcoin around the panel. Sure. I mean, I would say there's some merit to it. I mean, I don't think there's any merit to saying that the Ethereum Foundation chooses what upgrades get into Ethereum. I think that's not really how the EIP process works. And I'm not even sure that the Aetium Foundation pays most client developers.

Maybe that's something that the actual client developers here can shed some light on. Yeah, the short answer is they don't. There's one team on ETH1 and zero teams on ETH2 that are part of the EF. Yeah, thank you. Yeah, thank you. That's what I thought. So I would definitely say, yeah, Aethm is changing more. It's easier to get stuff implemented in ETHU.

But the IP159 is actually a great example. It is a very big change. Like I once wrote that it's the biggest change ever made to an already deployed blockchain. in. Like, proof of stake will also be a pretty big change, but I think EFP1559 is to date the biggest. And this is like a really cool thing to look at, see how much, like how long the process took and how many people were engaged in the process and how much scrutiny it received. And I mean, it took a couple of years to get EIP159 implemented. And there were a lot of skeptics, I would say, for a long time. And it was just a process of, you know, eventual consensus in the community where I would say, like, those of us who wanted the EIP just produced more and more educational material and analyses and so on, eventually like swaying some of the skeptics, you know, over to our side. And at this point, I would say it's definitely a consensus decision. So it's not like there's somebody, you know, making a top down decision that we want to have this EIP, right? It's like it has so many supporters now, and I can't think of any skeptics anymore at this point, really.

So I would say yes. So it's bad when things, I mean, there's value to things being hard to change. But if it changes in the right way, like if the right checks and balances exist, then I think there's also a lot of good that can come from, you know, adding new features. Mike, I think you've written posts on things like this. What's your take? I'm the same question. Yeah, so I think that there is definitely merit to this question. Is it better to change or is it better to not change?

When you're building a large financial system, as people are familiar with the legacy financial system, it's well known that banks do not change fast. Like from a programmer's point of view, it's always like a running joke that banks are running on code that was written in the 1980s. And it's now hard for them to hire people to change that because everybody, everybody's dead who knows how to write code in those languages. And there's a reason that banks are hesitant to change. And it's because when you're dealing with large amounts of money, especially other people's money, you ideally don't want to break things. You don't want to make a mistake

and then have people lose all their money or all your money or all of some investors' money. And so it's a very scary thing. And so from the standpoint of the argument that, well, Bitcoin is stable. That's very reasonable. Like having that stability is very valuable. People like stability. People want, especially in their financial systems, they want comfort in knowing that things will be stable. Whereas Ethereum is definitely moving fast. We're changing things every six months. We have a hard fork. Some of these hard forks are very big.

1559 is very big. And that's a very different paradigm. And I think the reason I like Ethereum personally is because I feel like the space is so new and so young that it's too soon to calcify and it's too soon to stop changing. Like there's so much we can do and there's so many things that are right around the corner. Like the technology is just so much in its infancy. It's like having a kid and then saying, okay, you're two years old. Now's a good time to stop growing. It's like there's so much opportunity.

Whereas, you know, once they get to, you know, 20 or 25, maybe that's a good time to stop growing. They've matured enough. They can be useful. They can be productive. And they have learned enough and they have advanced enough. That is a useful tool. And so I think Ethereum is not there yet. I think eventually I will eventually lobby that Ethereum,

should calcify like like the coin has i just don't think that's now i think that sometime after proof of stake sometime after sharding sometime after you know zk roll-ups on main net like like there's a number of things that i think ethereum should do before we decide that okay now's the time let's slow down let's solidify let's make this a platform that people can trust is not going to change i just have a quick follow up on that but before we do we want to thank tim beko has got to go to attend another call and uh maybe help get EIP 1559 out the door. Tim, you're a fantastic moderator, maybe future co-host of the bankless podcast. Who knows? Unlimited potential here, sir. Who's getting replaced? I don't know yet, David. It may be seen. Thank you, sir. We appreciate your moderation. Yeah, thank you so much for

having me and for setting this up. Yeah, and obviously all the other panelists, I appreciate you all taking the time to come here. Awesome. Guys, we still have a few more questions coming in if the panel can hang on. I just have a quick follow-up to Micah, though. You raised a really interesting point. Do you acknowledge, though, that the time for Ethereum to calcify is somewhat subjective? Right. So, like, how do we determine when the right time to calcify is? Like, it's obviously not now immediately, but isn't there always going to be new tech, new features on the horizon to implement? A hard question, especially since there are so many participants. I think that, at the least, like when Ethereum's yellow paper was originally produced, it said we're going to do switch to proof of stake.

So at the very least, we should wait to calcify until after proof of stake because that was like a thing that was promised and everybody kind of presumably agreed on that if you're going to use Ethereum, you acknowledge that this will eventually adopt proof of stake. So at the very least, I don't think that it's super reasonable to argue for calcification prior to that. After that, things start to become a little more questionable because we have things like State Exprey and Sharding and ZK. like magic. And those are things that, you know, weren't necessarily agreed on when Ethereum was launched, you know, six years ago or whatever it was. And so that's where things started getting a lot more murky where it's like should we, should we continue to build and iterate or should we calcify? And maybe one of the options is Ethereum just forks. And we say, okay, proof stake launched everything we promised in the yellow paper is done.

We're going to like calcify that and that will be a supportive thing and it will get security fixes. Separately, we're going to continue building off of that in this other direction and build great things. I'm personally a big fan of forking as a form of governance. I think it allows people to have, you know, different belief systems and different values and kind of live in self-segregate and operate in sandboxes that align more of their beliefs.

And so, but I know a lot of people don't like that. A lot of people would rather Ethereum stay is one big thing, one there's one Ethereum. And so I do think that we will eventually see, you know, big debates on this exact topic. And I don't think there's a clean answer necessarily. Any other panelists want to add on to that before I asked the next question? Maybe to add to this, I think the classification is kind of a default position in the mind of many people who maybe come from the Bitcoin ecosystem, like this idea that at some point, the protocol just cannot keep changing.

It's true that over time, the more things are built on it, the more difficult it is to make these changes. But rather than argue for finding the correct point at which the protocol should calcify, I would argue for finding the process that makes us decide. whether we should do it or not. So finding what Mika was describing with the checks and balances. Like in my position, I'm definitely not an mutabilist. I joined the Ethereum ecosystem because I like this idea of its ever-growing ecosystem. It's like this organism that just adapts to whatever is thrown at it. I cannot tell what will happen in 10 years.

I mean, quantum computers, ZK magic. So I would definitely be more in favor of rather than thinking, okay, is it the time to calcify? Just asking the question, how do we make the choice if we have it in the first place? Absolutely. Oh, go ahead, Hasu. I would pose a different approach to the question.

I don't think it's really necessary for us to choose when it's time to calcify. I think this is also something that just happens automatically because every upgrade has a cost. First, you have to create social consensus, which is very difficult and a long process. And then you have to, like, all of the shareholders in the system have to upgrade their systems and so on. And there's so much involved.

And this is like, this is very costly. Like a lot of companies and a lot of prefab projects and a lot of people have to spend a lot of developer hours, you know, on making this up. Every upgrade in Ethereum a reality, right? So if you ask a lot, basically, from their users. And the more users there are and the more businesses build on Ethereum as, you know, part of the infrastructure. structure stack and so on, the more people will be affected by every upgrade. And basically every upgrade needs to do more to pass their bar for still supporting it. And I think it will just get harder and harder over time to make enough people want to

upgrade. And so it just cancifies basically on its own. Matt, you wanted to add something? Yeah, I was just going to add one other thing. In terms like the calcification, one thing to me that really makes a blockchain, a blockchain, something that goes beyond just a database is having ordered available data. And where we're going with ETH2 with sharding and having massive new, massive quantities of data availability,

that is to me something that even if you don't, even if you want to do something that's not possible to do specifically on the Ethereum chain, if Ethereum provides that platform for making data ordered and available, you can begin to build different types of permatives using, client-side verification rather than having things go through the EVM. And so I think that that's going to open up an avenue for people to still use Ethereum, but really be able to experiment in like really crazy things that may not be possible on the base layer. That's a great addition to that.

We just have a couple more questions to get through and then we will have gotten through all of them. And also, I want to point this one to you because it's a little bit in the world of game theory. And I think you might be best equipped. But for the other panelists, feel free to also hop in on this. This question comes from Yuan. minors might artificially reduce the block size after 1-559 up the update so that users are forced to be in a tip bidding war like we already are now. Is this something that we can be concerned about? Is there a topic of conversation to be had about minor block size manipulation to maximally extract value for themselves?

Hasu, have you thought about this? Yeah, I mean, this is probably the most obvious thing that you have to think about, like with regards to EIP-1559 and how. it can be broken by its participants, right? So if we argue that miners don't want any fees to be burned, then they could make this a reality. They could just say, okay, we never mine blocks that are higher than the target, because the blocks higher than the target are mined, then this is what makes the base fee go up.

And if blocks lower than the target are mined, then the base fee goes down. So they mine blocks lower than the target, base fee goes to zero, And then they keep the block size below the target. And this way you can basically keep the base fee at zero forever. But if only some miners do this, then they will always have to, so they will basically have to leave transactions in the mempool of users that also pay fees. And I mean, then any other miner can come along and include all of these transactions in their block. And they can include a lot of transactions because there's all this slack, like all this extra room.

in the block size in EP159 and they can scoop up all these fees and, you know, make more profit. So I mean, this shows that you can do this, but you need all the miners to cooperate on this. So either everyone follows along or so that the miners who want to do this have to have to pressure the non-compliant miners into compliance, like, for example, by ignoring their blocks. Like when you have like 70% lines of miners that wanted to do this, then they could ignore the other 30% blocks. But it also comes at a cost, right? So if any user who basically saw their transaction valid when like the 30 or confirmed when a 30% minus block was mined and then later becomes reorganized, I think that's very bad user experience.

I think we've talked about this a lot in the last couple of weeks because of, you know, all these discussions about short term reocs in Ethereum. So basically that's the answer. So miners can do it, but they would need to be willing to make short term reorg. and basically enforce a minor-activated softfog. And once we are like in the realm of saying, hey, a minor-activated soft-fog is possible, then we also have to think, okay, so isn't this possible today? And the answer is, yes, this is totally possible today.

If minors were to collude and, like, enforce a certain high fee, like a mandatory fee that they charge users for transacting on Ethereum, then they could extract a lot more money from users than users would be willing to pay in a fair market, right? Because right now, users pay the minimum that is necessary to get into a block. But when miners were to set the prices, then users would pay the maximum they are willing to pay. Like, this would be the correct sort of pricing strategy for miners.

Miners could multiply the revenue, like if they were willing to do that, but they don't. They are not, right? Because, I mean, they are in competition with each other. And if this property of a blockchain is broken, then I think users would be. lose a lot of trust in an Ethereum and far fewer people would transact and the value of if would dwindle. And ultimately, I think it's not in mine as best interest. Guys, we're going to close it out with this last question. I think this is for each of the panelists. This is a question of timelines. Timelines in crypto in Ethereum are interesting things.

Now, I remember when EIP 1559 was first proposed. Some people are like, oh, it'll be here in a few months, right? Others will like, this will. never be deployed to main net, right? Like, never. It's not happening. Not five years, not 10 years. It's never going to happen. The truth, it seems like, turned out to be someone in the middle. I want to ask this question of on timelines. Did the timeline surprise you? Maybe first I'll turn to Hasu. Did the timeline surprise you, Haseu? I would say yes. So everybody in the Bitcoin community, so like, well, if you have all these future plans for changing the protocol, but they never shipped them.

It's just, and they were right with regards to proof of stake and with regards to sharding, both of which were part of the Ethereum white paper. So they had a lot of ammunition in that sense. But first, Ethereum shipped the beacon chain, and now they are shipping EIP-1559, and both of these have been important milestones and have contributed a lot to convincing me

that the development and governance process is actually much more functional than a function. thought and if you can deliver what it promised at least like how things are today. So maybe in the past it was like more ineffective. But but now I think we like it's building a track record basically. And this upgrade has helped a lot with that. Like client, how about you on timeline? I think whenever 1559 was originally proposed, it was I was kind of a little bit newer as the ecosystem and I was very naive. I thought that these things gave proposed and then we upgrade the master node and it's like very quick type of process. But it, you know, I've like, I think I've

become like quite jaded in the last few years, especially with some of our own proposals. I've been working on this 374 proposal. And I'm just like seeing that these timelines, they are really like multi-year timelines. And that's kind of, I've had to shift the way I think and work to try and treat things as, you know, small packets of work over periods of years. And you have to, like, I kind of have a few things that you're trying to maintain some like general high level goals the community is on board with. And 1559 was one of those things. And I wasn't really involved until kind of the very end of the process. But I can kind of see how like different people have come in to play different roles whenever their roles were needed. And I came into play my role whenever it became

more of an engineering problem. And so I think that for a lot of changes in Ethereum, that's like a better mindset to think about it. Like it's a multi-year process. And with the merge coming, I think we're not going to see very many new features in Ethereum until the merge happens. I think everybody has sort of decided that we're going to do the merge. This is the number one priority. And we're not going to focus on anything else until it happens. And so that's something that, you know, means that we're probably not going to see new, like we're not going to see new things happen in Ethereum for the next 12 to 18 months

other than merge related things. Micah, what's your take on timeline? So I'm similar to Matt. I was not young and naive back in 2018. And I thought, surely this thing is, well, after I realized that Vitalik was smarter than I gave him credit for, then I thought, okay, this is a great idea. Surely this will go through quickly. Turns out that was not true. But I think there's a good reason for this.

When you're driving down the freeway with a bus full of children and you're trying to change the wheels on it, you want to take that process very carefully. Like you don't want to just, you know, just, you know, tip over on the two side wheels, swap the wheel out real quick and keep going. You know, I just hope for the best. This is not a yolo sort of situation. And so, 4159, there was a lot of, you know, a lot of people, including myself and sounds like most people on this call, we're skeptical of it. And so the process requires us to, you know, convince all those skeptics that this is actually a good idea. And then once we convince the skeptics, then we need to, you know, actually implement it and then make sure there's no bugs. And, you know, there was a bug on Robson in the 1559 implementation as recently as, what was it, two weeks ago or something like that. And so this isn't like a simple thing.

Like, this is after massive amounts of testing and, you know, a month or so on test nets. And then we still found a bug. So this is very hard to do. And so I think that taking it slow is the right approach at this phase of Ethereum's life cycle. You know, when Ethereum was brand new and had 10 users, sure, we probably could have knocked out one. 559 in a week. It's not that hard. Just throw it out there, see what it breaks. And if it breaks, you know, restart everything. It's even worse for things like proof of stake because proof of stake had to, you know, build an entire, do a bunch of research to actually, you know, design a system

that previously wasn't designed. Like there are chains that have proof of stake, but they make tradeoffs that Ethereum's unwilling to make. And so Ethereum had to actually go through the whole research process and figure out how do we solve this problem that no one else in the world has ever solved before without making tradeoffs that we're unwilling to make. And so they finally did that. And then you have to build the whole thing. And then you have to test the whole thing. And then you have to convince everybody to actually upgrade and accept that whole thing. And so yeah, so I think it was slow, but I think there are good reasons for that. And I don't think it means we've reached that point of stagnation we talked about earlier. Micah, is that you use the metaphor changing a school

bus wheel with a bunch of children on it? Is that what it feels like to be an Ethereum maintainer, like just driving a school bus with a bunch of kids. Is that how you think of this? Are we the children? Are we the kids? Yeah, I mean, if you see children as just dollar signs, then yes, it's basically the same thing. Is that how you see kids? Deeper question.

We'll say that for a different panel. That's the EIBI-559 panel, not the 1559 panel. That's what I signed up for. Barnaby, take us home. What do you think about timeline? Yeah, I mean, I don't have so much to add, but EAP-159 was kind of my first project. I joined the EF in 2020. Before that, I was in a more academic background, let's say.

Things in academia move quite slow. And so when I joined Ethereum ecosystem and kind of started contributing, I actually thought, well, this is moving really fast. Like it's a huge system, so many moving parts and people are willing to go through these big changes. but it really gave me like such an appreciation of the work that goes on behind the scene, especially like a very thoughtful kind of staging process through the test nets, all the work that goes into making the client's work, coordinating an ecosystem which just spreads in so many different directions,

especially 1559. I mean, it touches the economic engine, it touches the client, it touches wallets, the way users interact with the network. So it's a huge amount of work. And I would say, yeah, I can't really say if it was slow or fast because I don't have a good point of comparison. But to me, it feels like it's actually quite fast. Well, guys, it is here. We could say that for sure.

This week, it is happening. EIP 1559 currently scheduled for Thursday, maybe around 5 a.m. or so Pacific time, 8 a.m. Eastern time. Join us for that live stream where we will be broadcasting hopefully a celebration when the hard fork goes live. panelists, we want to thank you so much for availing your time to us. This has been fantastic. And actually, we want to thank you on behalf of the Ethereum community for all of the work that you guys put into this. We have been excited about EIP 1559 for many reasons for a long time. And you guys are part of the core team, along with many others who are not on this panel,

but you guys have been part of the core team to make this happen. We just want to thank you for all of your work on it. Thanks a lot, guys. Thanks for spreading the word. Thank you. All right. That's what we do. We spread the word. I got to end with this. Of course, risks and disclaimers, none of this was financial advice. Eat is risky. Crypto is risky. Hard forks are risky. Fingers crossed. You could lose what you put in. But we are headed west. This is the frontier. It's not for everyone. But we're glad you're with us on the bankless journey. Thanks a lot. And if you are watching the YouTube, one of the 426 people watching the YouTube, make sure to like and subscribe for the two EIP live streams that we are having on Thursday.

not miss those. Thanks to everyone.