Analysis of EIP-2593 (Escalator)

Today, we continue our analysis of blockspace market proposals by looking at EIP-2593, more widely known as “escalating bid algorithm”, or simply “escalator”. It is being advertised as an alternative to EIP-1559 with a big overlap in design goals.

For such a simple proposal, there is a remarkable amount of misconceptions floating around in the public discourse(1). In this analysis, we want to focus on the escalator proposal as specified in the EIP itself. With the developers call on blockspace market changes coming up today, we decided to offer our perspective as well.

What is the escalator proposal?

In the escalator proposal, users continue to participate in first-price auctions for blockspace. However, each transaction has the option of providing parameters for an escalating bid, creating a time-based auction for block producers to include that transaction.

EIP-2593 Introduces the following parameters which must be specified by a user:

• START_PRICE: The lowest price that the user would like to pay for the transaction.
• START_BLOCK: The first block that this transaction is valid at.
• MAX_PRICE: The maximum price the sender would be willing to pay to have this transaction processed.
• MAX_BLOCK: The last block that the user is willing to wait for the transaction to be processed in.

Comparing design goals

Both 1559 and 2593 seek to address UX problems in the blockspace market. However, 1559 has three more design goals, which we explain in our analysis of the proposal. It (1) implements a slack mechanism, (2) separates Ethereum’s security from transaction fees, and (3) prevents economic abstraction. 2593 is a much narrower proposal, because it does not enable any of these functionalities. This is not a criticism of the proposal itself, but merely a correction on how it is advertised by its supporters (incl. the original EIP).

That said, let’s compare them in the area where their goals overlap, by looking at the ways 1559 and 2593 want to implement their respective UX improvements.

EIP-1559: The mechanism attempts to create a fixed-price sale for blockspace most of the time. The only time a fixed-price sale does not occur is when blocks are near-full (i.e. the slack is exhausted), and the first-price tip auction kicks in. This allows users to make a binary decision whether they want to transact or not rather than expend mental cycles on guessing the correct fee rate. Due to the behavior of the BASEFEE mechanism, the duration of first-price tip auctions is minimized.

EIP-2593: This mechanism attaches an escalating bid to transactions, to slowly test what the optimal bid is. Starting from a lower fee helps against overpaying, as miners should include the transaction at the minimum price they are willing to accept(2). The escalating ensures a transaction is included eventually, assuming it reaches a value that is higher than the gas prices in the network. This helps against underpaying.

Evaluating escalator algorithms

2593’s small scope makes it relatively straightforward to evaluate. Every user has preferences on two main dimensions: cost, and speed. In a hypothetical world where each user can broadcast a transaction only once, they need to encode both preferences into a single value: their fee rate.

Adding an escalator function would add a second dimension to that transaction, as the user can determine the fee in advance for many blocks into the future assuming the transaction hasn’t been included. This gives the user more control, and should be a strict improvement over the status quo. In the real world, users can broadcast their transactions as often as they want, but this process carries computational costs for the network and mental and operational costs for users. So the overall logic still holds.

Specifically, an escalator is an incremental improvement on the existing first-price auction model (you might call it optimized first-price auction), because it allows users to pre-define their bidding strategy. As a result, it comes into play whenever there is a first-price auction, and the time preference of users is not high.

For users with high time preference, it’s easy to see why the proposal can’t change things. If a transaction chases an opportunity that closes within 1-2 blocks (which is the case for all arbitrage transactions, DeFi liquidations, etc.), then there’s simply not enough time for a bidding process to play out. Such transactors are much more afraid of underpayment (missing the cut for the block) than overpayment. As a result, they will continue to add a large margin of safety to their fees.

For transactors with lower time preference and higher price sensitivity (which is, as of today, most transactions most of the time), escalator algorithms are a welcome improvement over the status quo. As these users can more safely set their bids at the middle to lower range of recently processed transactions, we find it likely that the amount of overbidding for blockspace would decline. Whether that reduces fees for individual users is impossible to say, since any UX gain can also induce demand for further transactions.

Evaluating the EIP’s analysis

The biggest part of the EIP is a scenario-analysis of the current blockspace market mechanism, EIP-1559, and EIP-2593. Further, the author considers two tiers of users (high vs. low time preference) under three different levels of congestion: (1) “blocks that are regularly half full”, (2) “blocks that are regularly less than half full”, and (3) “blocks that repeatedly full in a surprising (“black swan”) series.”

This creates 2 x 3 x 3 = 18 different scenarios, which he mentally simulates to find the correct user strategy given their preferences. Finally, he evaluates the outcome for the respective user type. We see several problems with this analysis.

First, in two of the three congestion levels, the escalator simply doesn’t matter. Whenever blocks are not full, miners will include any transaction paying the minimum fee. This is the same in all proposals, and no first-price auction takes place. Since escalators don’t matter unless there is a first-price auction, it also makes some of the authors’ considerations on the correct user-strategy moot.

This part of the analysis can also be ignored on empirical grounds, as block utilization has been high for some time now. For this purpose, we analyzed congestion between January 1, 2020 and today (3). After excluding 4% of empty blocks (which were not empty due to lack of demand), 77% of the remaining blocks were at least 95% full, and 86% of blocks were at least 50% full.

Second, the remaining congestion level describes blocks that are repeatedly full as a “surprising series” or even “a black swan”. The rationale behind that is puzzling to us, given that most blocks are full. One explanation is that the author looked at 1559’s proposal to double the blocksize and then always target 50% utilization by changing the BASEFEE.

However, such a mechanism where the system pushes blocks to be 50% full does not exist in 2593, and can’t exist because it depends on the existence of a BASEFEE. We give this elastic blocksize as one of the design options uniquely enabled by a BASEFEE-like mechanism.

Third, it assumes a first-price auction takes place in EIP-1559 when blocks are half-full or less-than half full (presumably using the tip, but this is not specified further). One of the benefits of 1559 is that it removes the need for first-price auctions most of the time. There is no reason for users to bid more than the minimum fee miners would accept. They are not in competition with any other users for inclusion, since there is always excess blockspace.

Maybe the author is worried about bidding wars between wallets on behalf of users, but this also makes no sense, since there is no benefit to bidding more than the minimum and one wallet doesn’t have to worry what another bids. An equilibrium for the minimum tip should emerge based on the binary decision for miners to include a transaction or not.

In summary, we find that the analysis either over indexes on unrealistic assumptions (such as empty or half-full blocks) or ignores additional benefits (such as the benefit of a fixed-price sale over a first-price auction). This is not a criticism of the proposal per se, which is a small but solid improvement, but merely of the unnecessarily weak arguments made in its favor. It implies a zero-sum mentality that we don’t see necessary at all.

Mutually exclusive or complementary?

Escalators improve the way first-price auctions are done today, whereas 1559 tries to minimize the number of first-price auctions that happen in the first place. When framed like this, it becomes clear that the two proposals are not mutually exclusive, but actually complement each other. You can implement 1559 and then use an escalator for the tip auction whenever it takes place.

As we can see in the above diagram, in a world of today + escalator, 100% of blocks still have a first-price auction(4). It is only more optimized by the existence of an escalator. In a “naive” 1559, there is a fixed-price sale 95% of the time and an unoptimized first-price auction 5% of the time(5). Finally, an escalator would make 1559’s remaining 5% of first-price auctions more efficient.

Reframing the question of escalator algorithms

The strategy employed by the escalator is one that users can use in manual form, which they actively do today. If their transaction is not included at the chosen fee rate, they click “accelerate transaction” in their wallet to broadcast it again with a higher fee rate. The main benefit of 2593 is internalizing the bumping process for users.

However, there are already companies emerging that do this kind of transaction management professionally for users, such as any.sender. In theory, nothing prevents this from being implemented in every wallet. So the question isn’t if we should implement 2593, it already is implemented manually by users and automatically by companies and soon probably mainstream wallets. The question is if it should be done in protocol instead.

Arguments for in-protocol escalators

• More reliable: Extra-protocol implementation requires manual rebroadcasting of the transaction, so there must be an active off-chain actor (like a background process on a wallet, or a dedicated service such as any.sender)
• Less data-intensive: It allows a single message to encode an escalation strategy vs. the user broadcasting a new message every time to bump the fee(6).

Arguments against in-protocol escalators

• Feature creep on the base layer: Anything that can be done outside the protocol should be done outside the protocol.
• Worse privacy: Users reveal their fee preferences and strategy (how much they’re willing to pay) to the entire network compared to a single party.
• Less flexibility: More elaborate elevator strategies can be implemented outside and there is more competition between providers to find an algorithm that works for users (2593 can be changed while in EIP phase, but not really after it’s live)

Different readers will have different views on the weight of these pro and contra arguments. Personally, we strongly believe base layer protocols should be as lean as possible. The opportunity cost of not implementing 2593 is low, given that external options to use escalators are increasingly available.

It also depends on adoption. The more users employ a protocol-external escalator, the more transactions have to be rebroadcast. At some point, it becomes attractive to encode these strategies into a single transaction, saving users time and resources. It could be an attractive middle ground to observe adoption in wallets first, and then internalize the feature when it becomes popular.

Conclusion

In this analysis, we tried to show that the escalator algorithm has a much smaller, and very different design scope than EIP-1559. It is often described as an alternative, a framing that we strongly disagree with. 2593 has a much smaller scope and even where their goals overlap, the results are difficult to compare (100% first-price auction vs ~5%). Instead, the two proposals complement each other, and we are in favor of both, though not necessarily at the base layer.

Escalator algorithms are already used today, both manually by users and internally by firms that transact a lot on Ethereum, and offered by professional services. This proves that escalators are a dominant strategy for users to adopt. Hence, the right question is not whether escalator algorithms are useful, but whether they should be implemented in- or outside the protocol.

This concludes our analyses of Ethereum blockspace market proposals. Next, we will turn our attention towards past and future proposals for Bitcoin.

(1) Maybe the biggest myth is perpetuated by a recent Ethereum.org blog post: “The main advantage for escalator is that it enables highly efficient price discovery, while at the same time protecting users from over-paying by charging the second price in queue.” This is entirely wrong, as there is no specification about any second price auction in the EIP. In fact, you simply cannot have second price auctions without a fee burn. Otherwise, miners will always fill blocks with their own high gas transactions to prop up the clearing price.

(2) A miner can wait for the escalator to bump the fee, but at the risk of another miner earning that reward.

(3) Specifically from blocks 9195000 to 10324328

(4) Technically, there is no first-price auction in blocks that aren’t near-full, as all users can pay the minimum fee. In practice, the protocol has no way of enforcing less than 100% block utilization.

(5) The 95/5 split is simply used to illustrate a point, it’s impossible to know how frequent first-price auctions would be ahead of time. However, we can get a good instinct by looking at how fast BASEFEE rises whenever blocks are near 20m gas (the only time a first-price auction takes place.) Blocks can only stay there for a short period of time, before BASEFEE pushes them back down violently.

(6) Realistically speaking, we do not expect a fee-bump transaction to be rebroadcast over 5 times. Therefore, the burden of re-signing and re-broadcasting a transaction on the user, the network and other nodes should be negligible.