EIP-1559: The Road to Mainnet

Transcript

okay hey everyone yep yeah give me a second [Music] okay do you still see my screen okay um great i can only see my slides so we'll go with this um so hi everyone um i'm tim baco i work with the ethereum foundation uh facilitating the awkwardness calls and i'm here today to give a kind of historical overview of eipe 1559 um so i'll go over kind of how it came

to be how we implemented it and got it ready for my net and how it might evolve in the future um oh well and i have uh some transitions that i forgot to take out um but yeah if you want to get these slides you can get them at bitly ecc-1559 so apologies in advance it's gonna be heavy transitions between slides um so the height level uh eip 1559's goal is to move uh the ethereum fee market away from first price auctions because it's known that these are economically inefficient and the way that it does that is it specifies what's the minimum amount you

need to pay for a transaction in every block and we call that minimum amount a base fee and what we do is we basically raise or lower this this base fee based on how much demand there is for block space um so in order to uh to uh engage the demand on the network uh will double the block size after eip15 and allow blocks to be up to basically 200 followed and when they're more than 100 fold then we start raising the minimum price um and one thing that's nice as a side effect of that is that um blocks on average will always have extra capacity so it will result in better transaction inclusion guarantees

um one other well-known fact about 1559 is it obviously burns the baits fee um to prevent miners from manipulating yet uh either low or high and um this results kind of in a nice feedback loop because the more people use ethereum and the more eath gets burned so it's like more demand for the network with uh results in uh more of a pressure on the supply side um but the goal of my thought today is not to give a full overview of 1569 and how it's worked um there's a bunch of other talks and resources that do that so i've linked a couple here for people who might not be as familiar um but yeah the rest of this will be less about the eip itself and more about

kind of the the process surrounding it so um if if we look at kind of the pre-history of 1559 um the first time something like this was mentioned uh that i could find is uh in 2016 on the ethereum foundation blog in a post by vitalik um where he mentions that uh we could achieve kind of uh the the transaction the transaction fee regime that we want if we determine a protocol minimum fee that transactions must pay and have the protocol take away the rest um which is pretty close to how 1559 works today with basically having

the base fee and burning that um so there was already kind of a hint of that um then two years later vitalik made an eth research post um about uh first prize versus second price auctions and blockchains um and actually kind of wrote down what uh the kind of mechanism by which you could update uh the base fee under 1559. um so those were all kind of really early posts in the history um and then about a month after that in august 2018 um vitalik actually opened a github issue against zcash uh proposing that uh they evaluate eip1559 as a transaction fee

mechanism for that network um and the text of that proposal is is pretty close to uh the actual eip1559 text but then um basically two months or no sorry we're like four months after that uh eip1559 was uh was properly opened against the ethereum eips repo um and that's what it got its name um it stayed dormant for a few months um until basically in march 2019 eric connor uh kicked off the discussion about it on if there are magicians asking if it could be considered for the next network upgrade um

there was a lot of back and forth about it um and you know it led to people realizing they would want to have this in an upgrade but we need to prototype it extensively first um so that's when the vulcanized team started to work on it um and this was also kind of the first time where uh so the core developers so specifically the get team um raised some concerns about the denial of service risks uh from eip1559 um yeah but uh basically uh the volcanized team uh went along the first thing they did was actually to commission an implementation study to analyze the eip what changes would be required and guest how we could actually deploy the main

net and they came up with this two fork approaches which would deploy at the eip on the network in two stages the first um the first fort uh would add a new transaction type for eip1529 transactions and then have those run in parallel to legacy transactions uh there's a type on my slide um and then this at the same time as you've added this new transaction type um you would add a transition function where over time you just reduce how much gas you have available for old transaction types so that would basically force people to upgrade because um even though uh you know transactions that were not 1559 style transactions

would still be valid on the network um at some point there would just be no more gas in a block available for them um and then you'd have a second fork which would basically kind of uh clean up and and do a on every factors but also basically uh give the full block space for 1659 style transactions so we could then deprecate at the legacy once so that was the original way we we planned to go about it um and what was nice about this is um it was kind of a stick and carrot approach where uh on one hand you know the reducing block size is an incentive to to stop using legacy transactions

um and the other idea that was proposed by vulcanize is that you could have gas cost reductions only ever happen on 1559 style transactions so that means you'd also have an incentive to switch to them um early on so um around february uh vulcanize opened a pull request against the get code base uh for a proof of concept basically of this uh of this approach then um last year or sorry two years ago now at ecc in 2020 um which was march 2020 uh there was some conversations about eip-1859 and especially at the time we

were talking a lot about uh stateless ethereum and how we could get that on the roadmap um and it felt like 1559 was something that was far enough that we could try and get it out before stateless ethereum um so that's when uh the idea of having kind of a working group dedicated on on actually getting this from a proof of concept to something that's ready for mainnet came together um so in april 2020 one month after atc we had our first 1559 contributor call our goal was to get 15 59 on main net by end of 2020 uh this obviously did happen um and at that time the basu team which i was a part of then i started working on an implementation as well to go alongside the get one

then early like later that spring um we spent a lot of time looking at different designs for eip1559 and different models that it could look like uh the main one was uh dan finley's escalator fee proposal um which would say instead of 509 where you specify kind of the minimum price in the network and then um an optional tip for the miners um dan's proposal would you would have you specify kind of the the amount of time you wanted your transaction to be valid for so like you know from one to ten blocks and the amount of uh the amount that you're willing to pay

so say up to 10 goe and then it would just escalate your bid over time so say you're willing to wait over 10 blocks and pay 10 great and you would bid one way in the first block to go in the second and so on and so that would give users a lot of granularity about um how they could uh how they could submit their transactions um so metamask uh made some mock-ups for both options which you can see here so on the left side you had the 1559 approach and on the right side you had uh the the escalator fee proposal um in the end we decided to not go with the escalator fee after considering a lot of designs um one of the main reasons for this was it added a bit of complexity but it's also something that was possible to do

outside of the core protocol um so a wallet could just do this on your behalf there's a bit of extra overhead and reasonability on those transactions but still we decided that it was better to keep 1559 as simple as possible and to potentially implement something like escalator fees at the wallet level and not in the core protocol um after this uh around june we started realizing this would be a pretty big effort it would require not only implementers from all the different teams but also some research um some prototyping and whatnot so we put together a bitcoin grant to pay for this um we were very uh i guess lucky in that we raised the largest

amount on git coin up to that point uh for over a hundred thousand dollars um we got i think was also the largest number of individual donors uh through a grant um on bitcoin so that was like a really big success and it gave us the funds that we needed to uh basically cover uh most of the work that was already being done by either consensus or the ethereum foundation um and in you know by the end of the summer in august we had this uh maintenance readiness checklist uh which basically had a list of all of the open issues that we still had with uh with the with the eip so the stuff that was basically stopping it from being ready for maintenance and so things like

actually managing how the transaction pull sorting would work um how do we uh deal with with things that were introduced in berlin like eip278 and whatnot so we just started working through all of these issues on our on our list and then in september 2020 um a lot of people were starting to ask sorry a lot of people were trying to ask what 1569 would be ready so we started put together this upgrade and these updates on uh on eip1559 so that the community could kind of keep track of their progress um about a month after that uh we solved one of the biggest technical

problems uh we had left uh so one big uh thing that we wanted to avoid at this point was this kind of two hard fork approach that was initially proposed by vulcanize we felt it would be much cleaner if we could just do everything at once um but the one big challenge there was how do you keep supporting legacy transactions um and also how do you not have two different transaction pools one for legacy and one for 1559 transactions and the original implementations all had that um so in october uh we figured out a way where if you send legacy transactions we could literally interpret it as a 1559 one where your gas price is equal to your base fee and it's equal to your tip

um what's nice about this is that uh it makes it very easy to sell legacy transactions and it basically makes eib 1569 support optional so if a wallet doesn't want to support it the network can always support legacy transactions um but it also gives an incentive to support 1569 where um when you send a legacy transaction basically the entire difference between uh the current base fee and your gas price would go to the miner whereas when you send a 1559 transaction you can specify exactly how much you want the miner to get um and get a refund for any excess excess feed you have um so it's slightly more kind of gas efficient to send a 1559 transaction but if you

what you're worried about is backwards compatibility um then you know you can always send a legacy transaction which is which is really nice um about a month after that uh we we started launching uh we called the 1559 toolbox but just a set of apis and json rpc endpoints for people to actually start interacting with 1559 on a development network that we had um and finally around the end of the year we had tim roughgarden publish a 50-page economic analysis at 1559. um this was really good because up to then we didn't have kind of a formal paper that that walked through the mechanism and tried to explain why it was actually better than today um so

timbre of garden did like an excellent job of articulating that um it convinced some of the kind of most vocal skeptics that were still remaining who didn't think 1559 would necessarily work as x as expected and then we started wrapping up at the beginning of this year uh on on the implementation side so um around january we had our last official 1559 focus call um the quilt team came up with a way that we could we could do transaction pool management uh very efficiently um we also decided to create a separate ep for a base free

up code so that smart contracts could access this um and vitalik uh publishing analyses around uh this denial of service risks that we mentioned at the very beginning saying that after berlin you know he thinks these would be fine um and and uh people agreed with him on that and finally the last thing we needed to test was uh whether we could have a network which had a large state uh handle blocks that were 200 fold for a long period of time so we built an entire tool that would uh generate a network from scratch with a state basically as large as its mainnet and that we could spam this uh with transactions for hours on end um to see whether the network would fall behind

um and after a few kind of hiccups with the initial tests uh we managed to get it all up and running and show that that it was good uh so it was just really kind of helped their confidence uh before pushing it to the public networks that you know the actual client implementations could could support 1559 so then uh we were finally ready to get it uh accepted into a network upgrade so in march 2021 um a year after we kind of started this working group uh which was already kind of six months after the initial proof of concept started uh efp1559 got accepted for the london hard fork which is expected to go live

early august this year um we uh basically got it implemented in all of the clients uh we've got it deployed across the other eips that are going into london across uh in the client integration test nets um and the spraying as as kind of the work in the clients was wrapping up we started having more community calls uh with wallets infrastructure providers and whatnot uh to help them add 1559 support and then um in june 1559 i was announced to go live on the test nets it did um and finally in july just last week uh we scheduled the main network

for uh august 4th roughly or block uh 12 million 965 000. um so this kind of shows kind of how long of a process it was to get 1559 from uh an initial idea to then an e to a proof of concept to something we thought was viable to ship on my net to then tested deployed on the test nets and now scheduled for maintenance um looking forward uh there's a few things that we'll want to do uh with regards to eip15 uh the first is just collecting uh metrics once it goes live uh so we'll be able to see kind of the average gas prices paid

at the variance about that in a block and what not and and quantify kind of is 59 truly better in terms of of uh pricing transactions in our current model and if so by how much um one small change we might want to do in the future is kind of symmetric basically updates uh so right now the base fee gets updated by one eight uh to the maximum either to the upside or the downside but that means if you go up to a large number uh the the actual amount that gets that it gets updated by is smarter than when you start going down because you basically take the 1 8 from the previous block so that means that um the base fee is kind of quicker to go down than it is to

go up so that's something that's kind of a small fix we might update in the future um obviously once the merge happens um we'll just have to kind of reroute transaction fees from uh from going to validators rather than going to minors um and finally um oh there's another typo here but the data starting uh so when we deploy shards on ethereum 2 we'll also use a 1559 type mechanism to price the cost of storing data on those shards um so that's all i have uh again if you want these slides you can find them at bitly.hcc

1859. um i'm not sure if there is the time or a way for questions but if so i'm happy to take them uh yeah great question so i i'm aware that

metamask and mike crypto have been working on adding support for it um and they both plan to be ready for august 4th um i'm not 100 sure about the other wallets i know also there's an open pull request against the trezler hardware wallet um they don't think they'll be ready for august uh they're just gonna have a firmware updated in september um so those three are the ones i'm aware of um like i mentioned also like um if your wallet doesn't support it it's not the end of the world at first um yeah but i i know that metamask and my crypto are trying hard to add support for it yeah so definitely like

in the next year i i don't see it going away um one thing we did in berlin we introduced the eip2718 which is kind of a transaction type wrapper which allows us to create kind of more transaction formats um and there's you know there was an eip uh that added a new transaction format in berlin with access lists now we have these 1559 transactions and there's more eips that are kind of looking at different transaction types and so i suspect uh we would probably go to a world where like you know we're likely here to have like five to ten transaction types than to have just one or two um so if you know if there was ever a reason to deprecate legacy transactions

maybe we could do it um but the yeah it's more likely we just end up in a spot where we support many more the thing that's hard about deprecating transactions is always like what if somebody signed a transaction two years ago you know and for some reason they can't like resign it or whatever and they were planning to deploy it on the network in two years and then they you know they realize that they can't um so it's yeah you're always kind of scared that you you block somebody out cool

cool thanks everybody you