I’ve been pondering lately about post-apocalyptic desolation. In particular, there’s this moment in Mad Max: Fury Road, when the primary protagonists have just evaded the first wave of chasing forces, maintaining their lead on potential captors. They must continue their journey, yet they also need to perform maintenance on the centerpiece of the film: an enormous “war rig” truck transporting them to safety. Therefore, Charlize Theron ventures beneath the cab to carry out some repairs while on the move:
The notion of executing repairs on a large, intricate truck while it remains in motion is just so fitting for the film’s adrenaline-fueled tension. It struck me during my viewing that this scenario serves as a fitting metaphor for the EIP process and the efforts of the core developers.
Modifications to the Ethereum protocol occur IN REAL TIME, and substantial, meticulous engineering is involved in devising enhancements to ensure that everything, and everyone (if feasible), keeps progressing smoothly. There are still obstacles present in the blockchain wasteland, but generally, Ethereum stays well ahead of any other pursuing vehicles (technical debt) — as long as the rig maintains its speed and doesn’t cease moving toward the horizon. New initiatives can cause some disruption in the short term to the established order, but they typically represent valuable advancements for the protocol overall.
The upgrade I wish to discuss today belongs to the category of “Ethereum 1.x”, but it’s not associated with the Stateless Ethereum initiative: A new gas fee marketplace / block size system. This proposal has evolved into a fascinating case study in community and developer feedback regarding Ethereum enhancement. By examining how this EIP has morphed over time amid further developer dialogue, I believe we can glean a great deal about constructive conversation in Ethereum development, and perhaps gain some clear insights (or at the very least, ambiguous maxims) to assist in guiding discussions on significant alterations beyond the Stateless Ethereum agenda.
Typically in this series, I aim to be very systematic and ‘into the details’, but in this instance, I want to emphasize more on the essence and nature of the discussions surrounding the proposals, rather than the technical specifics within. However, we need to have some understanding of the subject matter, so let’s briefly explore what EIP-1559 and ‘Escalator’ propose before shifting focus to a broader perspective and assessing how the discourse has advanced and its current state.
EIP 1559
The motivations behind the original EIP 1559 provide a solid foundation, and they are rather straightforward:
The existing “first price auction” fee structure in Ethereum is inefficient and unnecessarily expensive for users. This EIP suggests replacing it with a system that modifies a base network fee according to network demand, enhancing fee price efficiency while simplifying client software needed to prevent incurring excessively high fees.
Under the current setup, newly initiated transactions must wait to be integrated into the next block by a miner, but they can motivate miners to include their transaction by raising the gasPrice parameter above the network average. Rational miners will always aim to fill new blocks with transactions that maximize their earnings; hence, the transactions included first in the subsequent block are usually those with the highest gas price.
The issue with this first-price auction model is that conditions can escalate rapidly during times of high demand. When blocks approach fullness, the price of getting a transaction included in the next block can surge as users compete against each other for inclusion. Even though miners currently have some capacity to increase the number of transactions packed into a single block, that limit cannot change swiftly; realistically, miners prefer to capitalize on small full blocks instead of pushing the block gas limit higher (larger blocks are more perilous for miners due to Uncle rates). Particularly if your wallet employs pricing algorithms to aim for inclusion within a designated time frame (i.e., ensuring a favorable ordinary user experience), you might find yourself paying quite outrageous fees to ensure your transaction gets into a (nearly) complete next block.
EIP 1559 presents the concept of a ‘base fee’ in gas that is programmed to dynamically adjust so that the total gas consumption in a block approaches the current limit of 10 million gas. Instead of benefiting miners, the base fee is burned. To encourage inclusion, users indicate a ‘tip’ parameter along with the maximum fee they are willing to pay for their transaction to be incorporated into a block, while miners retain the tip.
Since the base fee doesn’t vary drastically with the immediate network demand, users are somewhat shielded from the inefficiencies of a first-price auction model (the ‘tip’ remains first-price), and because the base fee is incinerated rather than given to the miners, there is no motivation for miners to manipulate the fee. Importantly, the mechanism also seeks to address a significant challenge for wallet developers who are automatically estimating network fees by making them far more predictable.
For further reading regarding EIP 1559, I would recommend Vitalik’s EIP1559 FAQ and Barnabe’s Jupyter notebook for more in-depth exploration.
A new adversary approaches: Escalator
The inefficiency of the current first-price auction framework for Ethereum fees is not debatable; it’s crucial to articulately highlight this: No one contests that the existing fee framework could be improved, and identifying an alternative to the first-price auction would unequivocally benefit Ethereum as a whole — ultimately enhancing the experience for both developers and end users. We all can and should concur on this matter.
Nonetheless, the new mechanism proposed within EIP 1559 is simply different from the current practice, and altering it will lead tosome challenges, particularly with any applications that create and submit Ethereum transactions on behalf of users. Wallets, specifically, will require substantial modifications to embrace the new system. Even if conditions ultimately improve for everyone over time, in the immediate term it places a significant strain on the developers striving to adapt to the modification and avert their software from malfunctioning.
After EIP 1559 had been circulating in the communal conversation for some time, the community began to weigh in, including wallet developers who would be most impacted by the proposed adjustments. Instead of opposing the EIP, wallet developers adopted a noteworthy approach to the dialogue. They re-evaluated the fundamental objectives of the EIP (enhancing the user experience of Ethereum transactions), and positioned the EIP within that framework, essentially stating “If we’re going to be undertaking all this effort regardless we should initially have a vision of what it will resemble for a user, and we should use that as a guide for what is being suggested”.
This is the overly simplified narrative behind Dan Finlay’s alternative proposal to EIP 1559: The Escalator Algorithm. It is similar in many respects to the mechanism of 1559, sharing nearly identical motivations and objectives. Escalator is presented as an alternative enhancement proposal which allows for a far more nuanced discussion of either mechanism considered in isolation.
To enable a more fruitful and substantive conversation regarding the gas fee market, I felt it was crucial to introduce an alternative that is evidently superior to the current state, allowing any asserted characteristics of EIP-1559 to be contrasted with a feasible alternative enhancement.
The Escalator mechanism resembles the existing single price auction model, with several key alterations:
- Instead of submitting a transaction with a fixed offer, users present aptly-named ‘escalating’ offers and specify a maximum amount they are prepared to pay to ensure the transaction is included. All offers are placed into a queue of ‘escalators’ that steadily and predictably increase every offer in the queue at the same pace. This provides a solid mechanism for price discovery that still allows users to adjust their settings based on how urgently they desire a transaction included, and how much they are willing to spend for it.
The primary benefit of escalator is that it facilitates exceptionally efficient price discovery, while simultaneously safeguarding users from over-paying by charging the second price in line. It shares some of the same advantages as 1559, simplifying the process for users to choose the appropriate fee, even during periods of network congestion. Notably, the escalator alone would not alter the mechanisms that dictate block size.
The “Escalator Algorithm” proposal is intriguing in its own right, and I highly recommend perusing the ‘user strategy’ section for a solid high-level comparison of the three distinct models of transaction processing. If you enjoy this sort of content, the paper that introduces the escalator algorithm is also worth exploring, but I digress…
During an EIP1559 implementer’s meeting, Dan presented mock-ups displaying how the various parameters in a wallet would appear to a user, emphasizing how they could be concealed or revealed depending on the desired level of user engagement.
The designs were intended as a reference for community discussions, and to assist in visualizing both 1559 and the escalator algorithm from a user’s perspective.
By introducing a sensible alternative proposal and reframing developer feedback to emphasize the challenges faced by users, the EIP 1559 / Escalator dialogue has skillfully created new avenues for exploration with the ultimate objective of enhancing the fee market. It’s far from prepared for the next hardfork, but similar to the large vehicle in Mad Max, it continues to progress.
The future of Ethereum: All shiny and chrome
I believe EIP1559 / Escalator is a crucial matter for the Ethereum community to monitor and learn from, particularly as it shares many of the same traits as another more distant (and more dramatic) enhancement on the Stateless Ethereum horizon: Oil/Karma EVM semantic modifications. Just as in the fee market, some of the suggested alterations will have significant secondary effects on developers and users. Additionally, as with 1559, there is a definitive user experience facet to unite around, presenting an opportunity for collaboration with developers who grasp that experience to help proposals maintain momentum toward a successful upgrade.
Enhancing Ethereum (1.x) and any other public blockchain is a challenging expedition. The right path for discussion should be one that keeps meaningful enhancements still within reach, and furthermore ensures that the developers and users most affected are acknowledged and their concerns integrated. Because at the end of the day, we’re all navigating the same large vehicle toward the gates of Valhalla… er, Serenity. Staying ahead of the state bloat challenge requires continuously and constructively proposing, critiquing, and modifying changes without losing momentum— our survival relies on it!
