Analysis of Ethereum Bidding Upgrade Algorithm EIP-2593
Editor's Note: This article comes fromDeribit Deri's trading class (ID: deri_trader), published with permission.
Editor's Note: This article comes from Deribit Deri's trading class (ID: deri_trader) Today, we will continue to analyze the block space market proposal and analyze EIP-2593², which is known as the "bidding upgrade algorithm", or "escalator" for short. The proposal is advertised as an alternative to EIP-1559, which largely overlaps in design goals. Despite the simplicity of the proposal, there has been a great deal of public misunderstandingⁱ (see Note i for details). This article will focus on analyzing the escalator proposals specified in the Ethereum Improvement Proposals (EIPs) themselves. Now, as developers are increasingly vocal about changes in the blockspace market, we have also decided to provide our insights. secondary title What is the Escalator Proposal? According to the Escalator proposal, users continue to participate in first-price auctions for block space. However, each transaction can optionally provide parameters for an escalating bid, creating a time-based auction for block producers to include that transaction in a block. Starting price: the lowest price the user wishes to pay for the transaction; Maximum price: the highest price that the bidder is willing to pay to achieve the transaction; Maximum block: The last block the user is willing to wait for this transaction to be processed. secondary title Comparison of design goals Both Proposition 1559 and Proposition 2593 seek to improve the user experience of the blockspace marketplace. Nevertheless, Proposal 1559 has three additional design goals, as detailed in Analysis of Ethereum Improvement Proposal EIP-1559³. The three design goals are: implement slack mechanisms; Separate Ethereum network security from transaction fees; In contrast, Proposal 2593 is much narrower in scope, as it does not support any of the aforementioned features. This is not a critique of the proposal itself, just a correction of how its proponents (including the original EIP) promoted it. Proposal EIP-1559: This mechanism attempts to establish a fixed-price sale of blockspace most of the time. The only time a fixed-price sale does not happen is when the block is close to full (ie: the slack mechanism is exhausted), at which point the system will conduct a first-price tip auction. This allows users to make binary decisions about whether or not they want to trade, rather than trying to guess the correct rate. Due to the base fee (BASEFEE) mechanism, the duration of the first-price tip auction is minimized. Proposal EIP-2593: This mechanism attaches an escalating bid to transactions, gradually testing what the best bid is. A low starting bid helps prevent overpayment, since miners should include transactions in blocksⁱⁱ for the lowest price they are willing to accept (see note ii for details). The bid escalation mechanism assumes that the bid will exceed the miner fee in the network, thus ensuring that the transaction will eventually be included. This helps prevent underpayment. secondary title Evaluate the Escalator Algorithm Adding an escalator function will add a second dimension to the transaction, as users can predetermine the fee many blocks into the future, assuming the transaction has not yet been included in a block. This gives users more control and should be a serious improvement over the status quo. In the real world, users can broadcast their own transactions at any time, but this process will bring computational costs to the network and psychological and operational costs to users. So the overall logic still holds. For users with high time preference, it is easy to understand why this proposal cannot change the status quo. If a trade is chasing the chance to close within 1-2 blocks (as is the case with all arbitrage trades, DeFi liquidations, etc.), there simply isn't enough time to start bidding. Such a trader is more afraid of underpaying (missing the block's entry point) than overpaying. Therefore, they will continue to greatly increase the safety factor of fees. For traders with low time preference and high price sensitivity (and for now, most trades most of the time), the escalator algorithm is a welcome improvement on the status quo. Since these users can more safely place their bids in the low-to-mid range of recently processed transactions, we see that the number of overbids for block space may decrease. It is uncertain whether this will reduce transaction fees for individual users, because any user experience benefits will also induce the need for further transactions. secondary title Assessing the analysis of EIP The most important part of EIP is the scenario analysis of the current block space market mechanism, EIP-1559 proposal and EIP-2593 proposal. In addition, the author also considers the situation of two levels of users (high time preference and low time preference) at three different levels of congestion: (1) "usually in a half-full block", (2) "usually less than half-full blocks", (3) "repeatedly full blocks in an unexpected ("black swan") sequence of events". This creates 2 × 3 × 3 = 18 different scenarios that the author simulates in his head to find the correct user strategy based on user preferences. Finally, he evaluates the results for the respective user types. There are several problems with this analysis. First, for the first two of the three congestion levels, escalators are not important at all. As long as the block is not full, miners will include any transaction that pays the lowest fee. This is true for all proposals, and no first-price auctions will occur. Escalators only make sense if first-price auctions are activated, which makes some of the author's discussions and considerations about proper user strategy moot. Empirically, this part of the analysis can also be ignored, as block utilization has been high for some time. To this end, we analyzed the congestion situation from January 1, 2020 to todayⁱⁱⁱ (see note iii for details). After excluding 4% of empty blocks (these empty blocks are not caused by insufficient demand), 77% of the remaining blocks have a utilization rate higher than 95%, and 86% have a block utilization rate higher than 50%. However, the mechanism by which this system pushes blocks to 50% utilization does not and cannot exist in Proposal 2593 because it presupposes the existence of a base fee. We refer to this elastic block size as one of the design solutions uniquely enabled by a similar base fee mechanism. Maybe I'm worried about bidding wars between wallets representing users, but that doesn't make sense either, since there's no benefit to bidding more than the minimum price, and one wallet doesn't have to worry about how much another wallet bids. Based on the miner's binary decision of whether to include a transaction, an equilibrium point with a minimum tip should emerge. secondary title Escalators improved the way first-price auctions are conducted today, while Proposition 1559 attempted to minimize the number of first-price auctions in the first place. In such a framework, it is clear that, far from being mutually exclusive, the two proposals are actually complementary. You could implement Proposition 1559 and then use the escalator when the tip auction happens. secondary title The strategies adopted by the escalator algorithm are the ones that users can use manually, and the ones they actively use today. If their transaction is not included in a block with the chosen rate, they can click "accelerate transaction" in the wallet to broadcast it again at a higher rate. The main benefit of Proposition 2593 is to internalize the markup process for users. secondary title More reliable: implementations outside the protocol require human replaying of transactions, so there must be an active off-chain actor (such as a background process in a wallet, or a dedicated service like any.sender). Less data-intensive: it allows a single message to encode an escalator strategy, rather than a user raising the fee ᵛⁱ every time a new message is broadcast (see note vi for details). secondary title Arguments against escalators within the agreement Less flexibility: more complex escalator strategies can be implemented externally, and there is more competition among suppliers to find an algorithm that suits users (Proposal 2593 can be changed during the EIP phase, but cannot be changed after it goes live). Different readers have different views on the weight of these pros and cons. Personally, we strongly believe that base layer protocols should be as lean as possible. Given the growing number of outside options for using escalators, the opportunity cost of not implementing Proposition 2593 is low. It also depends on adoption. The more users that take off-protocol escalators, the more transactions need to be replayed. At some point, it will become attractive to encode these strategies into a single transaction, saving users time and resources. You might want to observe wallet adoption before internalizing that functionality, which can be an attractive middle ground. secondary title in conclusion Through the analysis in this paper, we try to show that the design scope of the escalator algorithm is much smaller than that of the EIP-1559 proposal, and it is very different. It is often described as an alternative, a positioning we strongly disagree with. Proposal 2593 is much smaller in scope, and even for where their goals overlap, it is difficult to compare results (100% first-price auctions vs ~5% first-price auctions). Instead, the two proposals complement each other, and we support both, but not necessarily their base layer. Today, escalator algorithms are already in use, whether manually by users, internally at companies that do a lot of transactions on Ethereum, or as a service provided by professional services. This proves that escalators are a mainstream strategy for users to adopt. So the correct question is not whether the escalator algorithm is useful, but whether it should be implemented inside or outside the protocol. This concludes our analysis of Ethereum blockspace market proposals. Next, we'll turn our focus to Bitcoin's past and future proposals. Note i : Perhaps the biggest myth started by a recent Ethereum.org⁵ blog post which states: "The main advantage of the escalator is that it enables efficient price to protect users from overpaying." This is simply wrong, as there is no specification of second-price auctions in EIP. In fact, you simply can’t do a second-price auction⁶ without burning money. Otherwise, miners will always fill blocks with their own high-gas transactions to prop up the liquidation price. Note ii: Miners can wait for the escalator to raise fees, but at the risk of having that reward earned by other miners., published with permission.
Starting block: the first block that makes the transaction valid;
Even so, let’s compare their overlapping areas of goal and see how Prop. 1559 and Prop. 2593 each seek to improve the user experience.
Specifically, Escalator is an incremental improvement over the existing first-price auction model (you could call it an "optimized first-price auction") because it allows users to predetermine their own bidding strategy. So it works as long as there is a first-price auction and the user's time preference is not high.
Third, it assumes that in the EIP-1559 proposal, when the block utilization is at or below half, the system will conduct a first-price auction (presumably using a tip, but this is not stated further). One benefit of Proposition 1559 is that it eliminates the need for first-price auctions most of the time. Users only need to pay the minimum fee that the miners will accept, and there is no need to pay more. They don't have to compete with any other users to include transactions in blocks because there is always block space to spare.
Mutually Exclusive or Complementary
The problem with redefining the escalator algorithm
Arguments in favor of escalators within the agreement
in conclusion
2. EIP-2593
4. any.sender
5. Ethereum.org
