TL;DR¶

• We consider the floating escalator, a combination of 1559's "default price" and the escalator's "incremental bidding".
• We define and compare the efficiency of two user strategies:
  • Hurrying users set the escalator slope to their cost for waiting one more unit of time, and balk whenever their current value is negative.
  • Fixed duration users all set the length of the escalator to the same value, and set the slope to ramp as much as possible within that length.
• The two strategies give rise to different dynamics, which we interpret visually.
• While the social welfare is higher in hurry than in fixed, this may not matter as neither were shown to be equilibrium configurations. We focus instead on user efficiency, the total value realised by users in the market.
• We discuss optimality of fee markets and settle on a definition that seems natural for this setting. The user efficiency of both strategies is compared with this optimum, as well as a "random benchmark".

We've discussed EIP 1559 over the course of several notebooks. A competing proposal, dubbed "escalator", was introduced by Dan Finlay, taking inspiration from a paper by Agoric.

We take the current first-price auction paradigm as our benchmark. 1559 removes the auction component, attempting to quote a price for users based on supply of gas and demand for it. Users become price-takers most of the time, with their only decision being whether to transact or not.

The escalator proposal is a somewhat orthogonal direction from 1559. It retains some aspect of the first-price auction mechanism (users competing against each other) but allows users to "bump up" their bid following a linear formula. For instance, I initially bid 10 and specify that with each passing block, my bid should be increased by 5, until it reaches some maximum that I also defined. If I am included immediately, my gas price is 10. One block later, it is 15, etc.

The pattern of resubmitting transactions at a higher bid is known to most users of Ethereum. Manual resubmission of transactions is enabled by most wallets, while services such as any.sender allow you to programmatically emulate resubmission. The escalator automates it in protocol, in the sense that users do not need to manually resubmit, but set the parameters for the fee increase once and for all before sending the transaction to the pool, where its bid increases.

So on one axis we have a protocol-determined objective fee equalising supply and demand. On the other, we have control over bidding behaviour. The first is useful most of the time, in particular when demand is stationary. Yet the second may be desirable for these short periods where demand drastically changes and user behaviour reverts to strategic first-price auction-style bidding. Could we combine the two?

In this notebook, we investigate the floating escalator, a proposal to do so. We'll introduce its dynamics and study some user behaviours under this paradigm.

Setting up¶

See this repository's README, for more instructions on how to run this notebook. The first step is to import the relevant objects from our library.

Floating escalator 101¶

Since the floating escalator relies on a combination of both 1559 and the escalator, we'll introduce each one in turn before looking at their combination.

Basefee in 1559¶

EIP 1559 targets a specific block size c. When blocks are too full, a price known as the basefee increases. More people want in? Fine, we'll raise the price. Over time, the basefee fluctuates, with higher values reached when more users want to transact.

The basefee is governed by a simple equation

basefee[t+1] = basefee[t] * (1 + d * (gas_used[t] - c) / c)

where gas_used[t] is the amount of gas used by block t. Note that blocks can use at most 2 * c gas, twice the target. When they do, and are full, the update rule above becomes basefee[t+1] = basefee[t] * (1 + d).

The adjustment speed d is currently set at 12.5%, which implies that the basefee after a full block increases by 12.5% (and basefee after an empty block decreases by 12.5%) .

Escalator¶

In the escalator paradigm, a user submits:

• Their starting bid start_bid
• The starting block start_block
• How many blocks the bid is valid for, length
• Their maximum bid max_bid

Over length blocks, the true bid bid[t] at block t follows a linear interpolation of start_bid and max_bid, with

bid[t] = start_bid + (t - start_block) / length * (max_bid - start_bid)

At t = start_block, bid[t] = start_bid. At t = end_block, bid[t] = end_block.

In other words, the bid escalates slower or faster, depending on how much time it is valid for and how high the maximum bid is.

For example, if I submit 10 as my initial bid, 20 as my maximum, and 5 as the number of blocks over which my bid is valid for, then, as long as my transaction hasn't been included yet, my bid will increase by 2 every block for the next 5 blocks (in other words, until my bid reaches 20).

Floating escalator¶

In the escalator paradigm, users must set a large number of parameters (start bid, max bid, duration of the escalator). Meanwhile, 1559 gives us this nice gas price "oracle" that tells you the market conditions as you start transacting. Combining the two would be nice! What if our escalator could "start" with the current 1559-predicated price, the basefee, and climb the bid from there?

What exactly climbs in the floating escalator? Remember that, under 1559, users specify a gas premium (or the maximum amount that a miner can receive from including the transaction). During transitions -- for example, a spike in demand -- we've seen users become strategic and "overbid". Ideally, there would exist some sort of fixed premium that would be expected to compensate the cost for a miner to include one extra transaction. The escalator governs the dynamics of this premium.

We call this hybrid "floating": we see the basefee as a kind of tide, rising and lowering with demand. The escalator starts at or near the tide, depending on start_premium. Meanwhile, the gas premium offered to the miners climbs in excess of the basefee. For instance, assume Alice starts her escalator at the basefee equal to 5 Gwei and increases the bid by 1 Gwei each block. She also specifies that she never wants to pay more than 15 Gwei.

Notice the distance between the basefee (in blue) and Alice's bids (in orange) increases over time, by 1 Gwei per block, until Alice reaches her maximum bid of 15.

At block 6, the basefee is 8 Gwei, so Alice's bid is 14 Gwei (8 Gwei from the basefee, 6 Gwei from her escalator). Then at block 7, the basefee increases to 10 Gwei. While Alice's bid ought to be 17 Gwei (10 Gwei from the basefee, 7 Gwei from her escalator), it is capped at 15 Gwei (the maximum amount Alice is willing to pay). We'll assume that after 10 blocks, Alice's transaction simply drops out.

Suppose a different user, Bob, starts at the same block as Alice, with an increase of 0.5 Gwei per block, and the same 15 Gwei limit.

We see Bob's bids in green. Notice that they keep below Alice's bids. In a sense, Bob is more conservative than Alice is. Alice might be in a hurry to get her bid included, and doesn't mind "overpaying" (i.e. taking the risk that the increment she chose was too large). Bob, on the other hand, prefers to slowly escalate his bid. All things equal, Alice should be included before Bob is, since miners receive the difference between her bid and the basefee.

Hurried users in the floating escalator¶

In our model, users have both a value for the transaction, $v$, and a cost for waiting, $c$. Getting included immediately nets you a payoff of $v$, minus the transaction fees expended. Getting included 2 blocks later, $v - 2c$, minus the transaction fees, etc.

Since $c$ represents the time preferences of the user (a higher $c$ means it is more costly for me to wait), we could decide the escalator slope based on $c$: the higher the $c$, the higher the slope and escalator increments. This is an appropriate strategy for users who care about getting in as fast as possible given their waiting costs. For instance, users chasing an arbitrage opportunity or optimistic rollup dispute resolution transactions have high waiting costs, and thus would ramp up quickly within a short amount time.

Which brings us to the question: How long should the escalator ramp up for? Given bid increments of amount $s$, after $t$ blocks, assuming a constant basefee $b$, my bid is $b + t \times s$. Meanwhile, if my transaction is included at $t$, my payoff is $v - t \times c - (b + t \times s)$. We never want this payoff to become negative: since this would mean we would be worse off transacting than not! To ensure this never happens, we can figure out the number of blocks $t$ after which the previous expression becomes negative and use that as the duration of the escalator.

So how large should our increments be? We could set them to some fraction of the cost per unit, to respect the intuition that users who are in a hurry should set higher increments. To simplify for now, we'll set them to be exactly the user's cost per unit.

In our simulations, the users' bids won't start on the basefee exactly. We'll define the start_premium parameter as one escalator increment: if this increment is $c$, the first bid the user places is $b + c$ [2].

We've written a "dummy" UserFloatingEsc class in the library (abm1559/users.py) that we extend here to specify the parameters discussed above.

Note that since the floating escalators have an expiry date (the max block after which they cannot be included), we create a new transaction pool which removes expired transactions.

As in our previous notebooks, we'll write out the main simulation loop.

We'll only simulate UserHurryEsc first, setting the average number of new users spawning between two blocks at 2,500. Our blocks can only accommodate 952 of them at most, so this will create congestion.

Let's observe some results!

We recognise dynamics that should be familiar to us now. While the same average number of users spawn each block, and blocks are full in the first few steps, by the end of the simulation a much smaller number of users decides to actually transact (decided_txs). A new phenomenon is the pool_length being exactly zero by the end. Since transactions expire, old unincluded transactions are removed, while new transactions in the pool are all included. The basefee has reached its stationary level after which most users are priced out. This is confirmed by the following plot.

Note the average tip in orange: in the first 20 blocks, when there is true competition from a shift in demand, many users want in given the low basefee amount, too many for all to be included. Those who wait in the pool see their bids escalate with increments equal to their cost per unit of waiting time. Miners of the blocks including highly escalated bids receive a much heftier tip, the difference between the user's bid and the current basefee. This comes to an end once basefee is stationary, after which priced out users do not even care to join the pool, escalating bids or not.

Below, we are plotting the distribution of users included in each successive block. On the x-axis, we represent the value of the user $v_i$, while on the y-axis, we plot the cost per unit of time waiting $c_i$. Each point on one plot corresponds to one included transaction, with the point located at the (value, cost per unit) coordinates of the user. Additionally, we give a distinct colour to each wave of new users: users spawned before block 0 are blue, those spawned between blocks 0 and 1 are orange etc.

The plot is quite busy, but we can observe the following:

• Focusing on the first plot (block_height = 0), we clearly see that only users with higher time preferences (high cost per unit) are included. This is not entirely surprising since they offer a premium equal to their cost for waiting, so miners who rank users according to that premium will prefer users with higher premiums -- and thus higher time preferences.
• On the second plot (block_height = 1), we see that most included users are new users in orange (who appeared just before block 1), while some users from the previous wave (in blue) are included too. These late users are users spawned before block 0 with relatively low cost per unit. Yet, having waited one block already, their escalating premium is higher than some of the new users spawned just before block 1, which justifies their inclusion.
• This goes on for the following steps, further waves of users appear, with the most hurried of these users included in the block as they appear while others wait for their turn, yielding their spots to users from previous waves who have waited longer.
• Another item to notice is the progressive shift to the right of the points. Remember that while all these transactions are included, blocks are getting full, and the basefee increases! This means low-value users are progressively getting discouraged from sending their transactions in. By block 15, only users with value greater than 10 Gwei per gas unit are included.
• It is not only progressively shifting to the right, it is also narrowing at the base. We even see users spawned in the first wave, before block 0, included in block 15. These users have a high value for the transaction, but a really low cost for waiting: they don't mind getting in much later as long as they get in eventually. The increments of their escalators are very small, but to stay in the race long enough, they must have a much higher value than fresher users with higher cost for waiting.

Computing social welfare¶

The question then is: does the extra transaction expressivity afforded by the escalator improve the efficiency of the fee market? We first need to be clear what efficiency means in this context. A common measure in algorithmic game theory is the social welfare: the total payoff received by all users (transaction senders and miners) minus the costs they incur.

In our case, we have users with personal values $v_i$ and cost for waiting $c_i$. We run the fee market for blocks over time period $T$, when blocks $B_1, \dots, B_T$ are produced. Transaction senders pay transaction fees to miners, so this cost to the senders is merely extra payoff for the miners. In other words, the transaction fees do not participate to the social welfare calculation. The basefee does however, it is burnt, irretrievable and constitutes a cost to the system of miners and senders [3].

where $g_i$ is the gas used by sender $i$, $w_i$ is how long the user has waited and $b_t$ is the basefee at block $t$. The social welfare (SW) is determined by the realisation of $(b_t)_t$ and $(w_i)_i$, which are not exogenous to the system (while $(g_i)_i, (v_i)_i$ and $(c_i)_i$ are).

The sum above is only carried over included users. Users who are not included pay nothing and receive no value either [4]. All things equal, SW is higher whenever users with higher costs for waiting get in quickly, or whenever users with higher values are included.

Let's investigate by computing the social welfare in the previous simulation. user_txs_hurry_df holds user data of all users who were included. Since all transactions in our simulation use the same amount of gas, we do not include this parameter in the social welfare.

We store in a new column total_sw the welfare achieved by each included transaction. We'll now sum them all up to obtain the social welfare.

Hmmm, cool, I guess? That number alone is not very useful -- we'd better find something to compare it with. Why not try a different user strategy?

The fixed escalator length strategy¶

We've looked at a behaviour, hurry, where the length of a user escalator depends on the value and the cost of waiting for that user. Now, we look at the fixed strategy, which assumes the length of the escalator is fixed and the slope depends on the user value and waiting costs.

This strategy is suitable for users who know how long they are willing to wait for but don't necessarily care for being included so quickly, for instance, buying an NFT and waiting for delivery.

Say all users set up their escalators to last $\ell = 10$ blocks. After waiting for 10 blocks, the value for inclusion to user $i$ is $\overline{v}_i = v_i - 10c_i$. We can use this value as the maximum fee they are ever willing to pay. If the basefee increases significantly in the meantime, their bid may reach the limit earlier, but at least users are guaranteed to never overpay and realise a negative payoff.

Once again, we'll want their initial bid to be the basefee plus one increment of their escalator. To determine the slope of the escalator, we simply look for the value $s_i$ such that

This is implemented in the UserFixedDuration class below.

We'll run the simulation again with these new users.

Checking out the results...

What stands out immediately is that many more users decide to join the pool, even in the last blocks, after the basefee has mostly priced everyone out. Previously, we always observed decided_txs == included_txs by blocks 45-49, with priced out users not deciding to join the pool in the first place.

But with the fixed duration strategy implemented, we never allow a user to ever realise a negative payoff, so there is no reason for a user not to join, and so we have users == decided_txs. Meanwhile, the transaction pool checks for transaction validity, and removes all invalid transactions. We can define validity in two ways. Either we only call a transaction valid when its max_block parameter is higher than the current block, or we add the constraint that the basefee must be smaller than the gas price posted by the transaction [5]. A pool might accept transactions from users already submerged by the basefee, but it certainly cannot include them in a block.

In the chart above, we note that, this time, the basefee settled at a level lower than in the previous simulation. This could be a clue that the user strategy we have defined, with fixed escalator lengths, achieves lower efficiency: this is because a high basefee indicates the presence of high-value users in the system (if there were none, the basefee would settle lower).

Let's repeat the steps we've done in the first simulation to understand our results.

Once again, we plot the value and costs of included users across the first 16 blocks.

There are some interesting regularities!

1. While we previously had early users included in late blocks (e.g., users from the first wave included in block 15), now users must either be included within 10 blocks or drop out. Not surprising since we set the escalator length to the fixed duration of five blocks, and adjusted the slope from there.
2. Once again, users are "stratified" in blocks. Low-valued users with high costs for waiting from earlier waves get in earlier than low-valued users with high costs for waiting from the current wave.
3. The oblique stratas are due to the condition we spelt out earlier, requiring that users with $v - c \ell < 0$ do not join the queue, since these would not be guaranteed a positive payoff in any scenario.
4. We observe again the shift towards the right, with low-valued users priced out as the basefee increases.

What of the social welfare now?

Recall that the social welfare with hurry strategies was given by:

Seems that our alternative, fixed, has a higher social welfare than the hurry strategies we explored previously. What gives?

Although both social welfare measures are in the same "unit" (payoffs minus costs, so ethers), we are still not fairly comparing the two situations. In a sense, the "fixed length" escalator users are not at equilibrium: a high value user ought to bid higher to get in quickly, and not be discouraged by the possibility of not being included after the (arbitrary) escalator duration.

This is not to say that all users implementing the hurry strategy is an equilibrium either. Yet the basefee settles at a noticeably higher level, as if it were better able to match the existing demand to the supply. Since the social welfare as we defined it is lower when the basefee is higher, it is worse in the hurry scenario than in the fixed one.

The takeaway is that social welfare comparisons are not that informative when comparing two non-equilibrium profiles. As an alternative, we could adopt the following metric: look only at the profile of users who are included and compute the value they obtained -- their initial value minus waiting costs. We call this user efficiency.

User efficiency and optimality of hurry and fixed¶

User efficiency is more helpful to compare the efficiency of the mechanism (and strategies) relative to some optimum measure. But defining the optimum is another issue. For instance, here is an unreasonable optimum: everyone is included! Since this is not a feasible scenario, we restrict our optimum to meaningful cases, where the constraints of the chain apply.

With each new wave of users, we have a new distribution of values and costs. We instantiate here a "greedy" optimum definition. At each wave, we include in a block as many valid users as we can, with users who receive the highest current value from inclusion (value minus waiting costs) first. The dynamics are the same as before, except we replace our strategic miner optimising for their tips, with a benevolent dictator whose sole objective is to maximise the total current value of users in a block.

We subclass our TxPool object to implement this benevolent miner behaviour.

We'll also modify our users to have them transact always. The pool will decide who gets in or not.

Let's rerun the simulation loop, using our new GreedyTxPool and AlwaysOnUsers.

We now obtain the total user efficiency, the sum of all [value minus waiting costs] of users. We'll also check the average level of basefee after it stabilises.

Both user efficiencies of hurry and fixed simulations are below our greedy optimum [6]. They are not far from each other, but user efficiency of hurry is higher than fixed. This sits better with our intuition that a higher basefee entails the "correct" users are matched, so the user value realised with everyone playing hurry should be greater than the value under fixed.

To expand on this, hurry puts users with higher waiting costs in front of line, at the expense of potentially high value users who have low waiting costs. Meanwhile, fixed gives precendence to high value users with low waiting costs, who will have a higher escalator slope. The downside is that high value users with high waiting costs do not join, since they expect a negative payoff. Losing this part of the population means the basefee can afford to be lower than it is under the hurry strategy.

Conclusion¶

In the best of all worlds, the same users who are included in the idealised greedy scenario are actually included on-chain. Is this possible? It could be if we find a user strategy which induces an equilibrium, a situation where no user would prefer to play a different strategy, and if in turn this equilibrium induces the optimal allocation.

Yet the optimal allocation is not always an equilibrium (think about the Prisoner's dilemma). Is this the case here? What is the best strategy for users in the floating escalator paradigm? And under this strategy, does the floating escalator achieve higher user efficiency than plain vanilla 1559 does?

(Bonus) A random benchmark¶

We could check the efficiency of a "bad" transaction pool behaviour to get a "lower bound" benchmark. A very bad transaction pool behaviour may be to include low value users first, the opposite of the optimum pool, or include no one at all, in which case the total value is zero. We don't think these are very informative. A reasonably bad transaction pool behaviour would sample at random valid transactions in its pool and include them in the next block.

Let's look at the basefee and average tip in the block.

How much value do users achieve?

This is lower than anything we've seen so far, confirming that the random inclusion policy is not a very good one. Let's compare all four environments.