I’ve been thinking about post-apocalyptic wastelands recently. Specifically, about this scene from Mad Max: Fury Road, when the main characters have just escaped the first wave of pursuit and are running ahead of their would-be captors. They need to keep moving, but they still need to maintain the centerpiece of the movie: a giant truck that takes them to safety. So Charlize Theron heads out under the cab to do some repairs along the way:
The idea of carrying out repairs on a large and complicated truck. while it’s still moving it’s so fitting for the high-octane drama of the film. As I watched, it occurred to me that this situation is an apt metaphor for the EIP process and the work of core developers.
Changes to the Ethereum protocol occur LIVE, and a lot of careful and complex engineering is required to create upgrades to keep everything, and everyone (if possible), moving forward. There are still bumps in the road in the blockchain wastelands, but overall Ethereum stays well ahead of any other marauding vehicle (technical debt), as long as the platform keeps pace and doesn’t. stop moving towards the horizon. The new proposals have the potential to be a bit disruptive in the short term to the status quo, but they are generally worthwhile improvements to the protocol overall.
The upgrade I want to talk about today fits into the “Ethereum 1.x” category, but it is not part of the Stateless Ethereum effort: a new gas fee market / block size mechanism. The proposal has become a really interesting case study in community and developer feedback for Ethereum improvement. By looking at how this EIP has changed over time with more developer discussion, I think we can learn a lot about constructive discussion in Ethereum development and hopefully have some clear ideas (or at least vague aphorisms) to help guide the discussion. about significant changes beyond the Stateless Ethereum initiative.
Usually in this series I try to be very methodical and ‘in the weeds’, but in this case I want to put more emphasis on the content and character of the discussion surrounding the proposals, rather than the technical minutiae contained in they. but we have to have some I have no idea what we’re talking about here, so let’s look very briefly at what EIP-1559 and ‘Escalator’ propose before turning “meta” and considering how the discussion has progressed and where it stands today.
EIP 1559
The motivations of the original. EIP 1559 are a good place to start, and are pretty straightforward:
The current “first price auction” fee model on Ethereum is inefficient and unnecessarily expensive for users. This EIP proposes a way to replace this with a mechanism that adjusts a base network fee based on network demand, creating better fee pricing efficiency and reducing the complexity of the client software needed to avoid paying unnecessarily high fees. .
In the current system, recently submitted transactions must wait for a miner to include them in the next block, but they can incentivize miners to include their transaction by increasing the gas price parameter above the mean of the network. Miners, if they are rational, will always look to fill new blocks with transactions that maximize their payout, and therefore the transactions included first in the next block can always be expected to be the ones with the highest gas price.
The problem with this first-price auction model is that things can quickly get out of hand in times of high demand. When blocks are nearly full, the cost of including a transaction in the next block can rise dramatically as users try to outbid each other for inclusion. Although miners currently have some ability to increase the number of transactions included in a single block, that limit can’t change very quickly and realistically miners are happy to capitalize small entire blocks rather than increase the gas limit of the block. block (larger blocks). are, due to Uncle’s fees, a riskier proposition for a miner). Especially if your wallet is using pricing algorithms to target listing within a specific time frame (read: provide a normal good user experience), you could end up paying pretty ridiculous fees to get your transaction in a next (almost) full block.
EIP 1559 introduces the concept of a ‘base rate’ on gas that dynamically adjusts so that total gas usage in a block moves towards the current limit of 10 million gas. Instead of going into the pockets of the miners, the base fee is burned. To incentivize inclusion, users specify a “tip” parameter, along with the maximum amount they are willing to pay for the transaction to have it included in a block, and miners keep the tip.
Because the base rate does not fluctuate wildly at the whim of instant network demand, users are somewhat insulated from the inefficiencies of a first-price auction model (the ‘tip’ is still first price), and because the base fee is burned instead of given to miners, there is no incentive for miners to try to manipulate the fee. Importantly, the mechanism also tries to solve a big problem for wallet developers trying to automatically estimate network fees by making them much more predictable.
There are several places to read more about EIP 1559; I would recommend Vitalik EIP1559 Frequently Asked Questions Y Barnabe’s Jupyter Notebook if you want to go deeper.
A new challenger is coming: Escalator
The inefficiency of the current first price auction system for Ethereum fees is not controversial, and it is important to point this out explicitly: no one disputes that the current fee mechanism could be better, and finding an alternative to the first price auction would inarguably be good for Ethereum as a whole – at the end of the day, it will make things better for both developers and end users. We all can and should agree on this.
The new mechanism proposed in EIP 1559 is, however, only different because of the way it’s done now, and changing it will cause some problems, particularly with any software that creates and sends Ethereum transactions for users. Wallets in particular will need to make significant changes to accommodate the new mechanism. Even if things do eventually get better for everyone in the long run, in the short run it places a huge burden on developers working to adapt to change and prevent their software from breaking.
After EIP 1559 had been floating around in the mainstream soup for a while, the community began to weigh in, including the wallet developers who would bear the brunt of the proposed changes. Instead of resisting the EIP, the wallet developers took an interesting discussion route. They reconsidered the core motivations for the EIP (improving the UX of Ethereum transactions) and placed the EIP in that context, essentially saying “If we’re going to do all this work anyway we should have an idea early on of what it will look like to a user, and we should use that to help guide what is proposed.”
This is the simplified story behind Dan Finlay’s Counterproposal to EIP 1559: The Escalator Algorithm. It is similar in many ways to the 1559 mechanism and has almost identical motivations and objectives. The escalator is presented to be presented as a alternative proposal for improvement that allows for a much more nuanced discussion of any mechanism presented in isolation.
To facilitate a more productive and concrete discussion of the gas rate market, I felt it important to present an alternative that is clearly superior to the status quo, so that any claimed property of EIP-1559 can be compared to a plausible alternative improvement.
The Escalator mechanism is similar to the current single-price auction model, with a few important changes:
- Instead of submitting a transaction with a fixed offer, users submit ‘escalated’ offers with appropriate names and specify a maximum amount they are willing to pay for the transaction to be included. All offers are placed in a queue of “escalators” that gradually and predictably increase all offers in the queue. at the same speed. This provides a nice mechanism for price discovery that still allows users to modify their settings based on how urgently they want a transaction to be included and how much they are willing to pay for it.
The main advantage of escalators is that it enables price discovery very efficiently and at the same time protects users from overpaying by charging the second price in the queue. It also has some of the same strengths as 1559, making it easy for users to choose the right rate, even during times of network congestion. In particular, the escalator alone would not make any changes to the mechanisms that determine the block size.
The “Escalator Algorithm” proposal is interesting in its own right, and I recommend reading the ‘user strategy’ section to get a good high level comparison of the 3 different models of transaction processing. If you like this kind of thing, the article introducing the escalator algorithm It’s also worth digging into, but I digress…
On an EIP1559 implementer call, Dan presented mockups showing what the various parameters in a wallet would look like to a user, highlighting how they can be hidden or exposed depending on the desired level of user intervention.
The designs were meant to be a reference for community discussion and to help us imagine both 1559 and the escalator algorithm from a user’s perspective.
By presenting a reasonable alternative proposal and reframing developer criticism to prioritize user challenges, the EIP 1559 / Escalator discussion has cleverly created new exploration space. towards the ultimate goal of improving the rate market. It’s far from ready for the next fork, but just like the big truck from Mad Max, it’s still moving forward.
The future of Ethereum: all shiny and chrome
I think EIP1559/Escalator is an important topic for the Ethereum community to watch and learn from, particularly as it has many of the same features as another more distant (and more dramatic) improvement on the horizon for stateless Ethereum: Oil/Karma EVM Semantic Changes. Similar to the rate market, some of the proposed changes are going to have significant second-order effects on developers and users. Also, as in the case of 1559, there is a clear aspect of the user experience to support and therefore an opportunity for coordination with developers who understand that experience to help proposals maintain momentum towards an eventual successful update.
Improving Ethereum (1.x) and any other public blockchain is an arduous journey. The correct path of discussion should be one that keeps significant improvements still on the horizon, and also ensures that the most affected developers and users are heard and their concerns incorporated. Because at the end of the day, we’re all riding in the same truck to the gates of Valhalla… er, Serenity. stay ahead of the problem of state inflation it means continually and constructively proposing, critiquing and amending changes without losing momentum – our survival depends on it!
