Eth1.x Archives: EIP-1559 and Ethereum's Road to Improvement
Editor's Note: This article comes fromUnitimes（ID：Uni-times）Editor's Note: This article comes from
, by Griffin Ichiba Hotchkiss, translated by David, published with permission.
I've been thinking a lot about post-apocalyptic wastelands lately, specifically this scene from the movie Mad Max: Fury Road, where the protagonists have just escaped the first wave of pursuit, ahead of would-be pursuers. They need to keep going, but still need to maintain the heart of the film: a huge "chariot" truck that transports them to safety. So heroine Charlize Theron needs to climb under the cab while the truck is in motion to do some repairs:
The idea of doing repairs on a complex truck that's still moving fits the film's intense drama perfectly. When I saw this, I realized it was an apt metaphor for the EIP (Ethereum Improvement Proposal) process and the work of the core developers.
Changes to the Ethereum protocol happen in real-time, and a lot of careful, complex engineering goes into crafting upgrades so that everything and everyone (if possible) can move forward through the upgrade process. There are still bumps in the road in the blockchain wasteland, but in general, Ethereum is still far ahead of other marauding vehicles (technical debt) - as long as the truck keeps moving forward and does not stop moving towards the horizon. New proposals may cause some disruption to the status quo in the short term, but overall they are generally valuable improvements to the protocol.
Usually in this series of articles, I try to "deep talk" very methodically, but in this article, I want to focus more on the content and characteristics of the discussion around these proposals, rather than the technology contained in them detail. Before we get into how the discussions have progressed and where we are, let's look very briefly at two proposals, EIP-1559 and the "Escalator".
EIP-1559
secondary title
A good place to start is by looking at the motivation for the original EIP-1559 [1] proposal. The original motivation for this proposal was fairly simple:
"The current "top price auction" fee model in Ethereum is inefficient and costly to users. This EIP proposes an alternative to this mechanism by adjusting a base network fee based on network demand, thereby creating more Good fee price efficiencies and reduces the complexity of client software needed to avoid paying unnecessarily high fees."
In the current Ethereum system, newly submitted transactions must wait to be packaged into the next block by a miner, but these transactions can be increased by increasing the gasPrice parameter to make it higher than the network average, thereby incentivizing miners to package their own transactions . If miners are rational, they will always want to include the transaction with the largest transaction fee in the new block, so the transactions expected to be included in the next block are always those with the highest gas price.
The problem with this top-price auction model is that things can quickly get out of hand during periods of high transaction demand. When a block is close to being full, the cost of getting a transaction included in the next block (transaction fees) can skyrocket as users try to get their transactions included at a higher price than others.
EIP-1559 introduces the concept of a "base fee" for gas fees, which is set to be dynamically adjusted so that the total gas usage of a single block approaches the current cap of 10 million gas. This "base fee" will not go to the miner's pocket, but will be burned. In order to motivate miners to package transactions, users will also set a "Tip" (tip) parameter, and set a maximum amount they are willing to pay in order to have their transactions included in the block, and miners will receive this "Tip" (tip).
Since the "base fee" does not fluctuate violently according to the instantaneous changes in network demand, users are somewhat away from the inefficiencies brought about by the "top price auction" model (the "Tip" fee is still the top price model), because The "base fee" is burned instead of being given to miners, so that miners have no incentive to try to manipulate transaction fees. Importantly, this mechanism also attempts to solve a major problem that wallet developers have with automatically estimating network transaction fees, making transaction fee estimates more predictable.
For more information about EIP-1559, I recommend you to read the EIP-1559 FAQ [3] published by Vitalik, and if you want to go deeper, you can read this Jupyter notebook [4] published by Barnabe Monnot.
secondary title
A New Challenging Proposal Emerges: Escalator
The inefficiency of the current "highest price auction" system for Ethereum transaction fees is an undisputed fact, and it's important to state clearly that the current transaction fee mechanism can be made better, no one is going to argue about it Dissent, and finding another mechanism to replace the first-price auction model will undoubtedly benefit the Ethereum network as a whole - and ultimately this will benefit developers and end users. We can and should all agree on this.
However, the new mechanism proposed in EIP-1559 works differently from the current mechanism, and changing it will cause problems, especially for any software that builds and submits Ethereum transactions for users. Wallets in particular will need major changes to accommodate this new mechanism. Even if things end up being better for everyone in the long run, in the short term, the EIP-1559 proposal places a huge burden on developers who need to adapt to the change and prevent their software from breaking.
After EIP-1559 had been floating around in its initial soup for a while, the Ethereum community began to weigh in, including wallet developers most affected by the proposal. Instead of resisting the proposal, the wallet developers chose an interesting line of discussion: they reconsidered the core motivation of the proposal (i.e., improving the user experience of Ethereum transactions), and put the proposal in that context, essentially In their statement "if we're going to do all this work anyway, we should have an idea from the start of what this is going to look like for users, and we should use that to help guide what is being proposed in this proposal."
This briefly explains Dan Finlay's proposal against EIP-1559: The Escalator Algorithm [5]. This proposal shares many similarities with the mechanics of EIP-1559, and has nearly the same motivations and goals. But the Escalator mechanism was proposed as another improvement proposal, pushing the community to have a more detailed discussion of the two mechanisms proposed separately.
"In order to drive a more productive and concrete discussion in the community about gas fee markets, I think it's important to come up with an alternative that is significantly better than the status quo, so that any of the features claimed in the EIP-1559 proposal can be compared to a viable compared to alternative improvements.”
This escalator mechanism is similar to the current single-price auction model, with some important changes:
Instead of submitting a transaction with a fixed bid, users submit "step-up" bids, specifying the maximum amount they are willing to pay to have their transaction included. All bids are put into a queue of "escalators" that incrementally and predictably increase all bids in the queue at the same rate. When the miner looks at the queue of all escalators, it will choose the transaction with the highest bid, no matter which escalator these transactions are on. When a transaction is included in a block, the user will pay the "second highest price" next to the highest bid in the queue, instead of paying the user's current bid.
The main advantage of the Escalator mechanism is that it enables efficient price discovery. , while preventing users from overpaying by charging the second highest price while in line. It also has some of the same advantages as EIP-1559, making it easier for users to choose the correct fee, even when the network is congested. It is worth noting that the Escalator mechanism itself does not change the mechanism for determining the block size.
The Escalator Algorithm proposal is interesting in its own right, and I highly recommend reading the "user strategy" [6] section of the proposal for a high-level comparison of the three different transaction processing models. If you are interested in this, the paper [7] introducing the Escalator Algorithm is also worth digging into, but I digress a bit...
In a conference call with implementers of EIP-1559, Dan Finlay gave some models of how various parameters in the wallet would be presented to the user, highlighting how these could be hidden or revealed depending on the level of user intervention required. parameter. See below:
secondary title
The Future of Ethereum
The Future of Ethereum
Improving Ethereum (Eth1.x) and other public chains is an arduous journey. The right line of discussion should be one that keeps those meaningful improvement proposals still on the horizon, but also ensures that the voices of developers and users most affected are heard and their concerns are integrated. Because in the end we're all going to be driving the same big truck to the gates of Valhalla...well, aka Serenity (Ethereum 2.0). Staying ahead of Ethereum's state inflation problem [9] means constantly suggesting, criticizing, and amending changes constructively without losing momentum, our survival depends on it!
Reference link:
[3]https://notes.ethereum.org/
