Has anyone checked on EIP-1559 recently?

Seriously, is he okay? He's not answering my emails

Author’s Note: This post assumes a pre-existing understanding of EIP-1559 gas markets. If you do not understand EIP-1559, you are probably reading the wrong newsletter. If you’re interested in learning about EIP-1559, read the EIP and ethresearch. If you are interested in talking about ultrasound money, please consider subscribing to Bankless. It will not challenge your beliefs with accurate technical info.

⛩️ for no particular reason. Photo by Matthieu Bühler on Unsplash

Life before 1559

昔々大昔、イーサリアムのブロックガスはマイナー達の投票に限定されました。

Long long ago, in the land before 1559, Miners set the block size via a simple voting mechanism. Each block, that block’s Miner could move the block gas limit up or down by a factor of up to 1/1024. So as miners mined blocks, the gas limit would move towards the hashrate-weighted average of miner preferences. This voting mechanism had been in place since the dawn of Ethereum.

With the advent of EIP-1559, the gas limit doubled, but the method of setting the limit did not. Post-1559, pre-merge, miners voted on the gas target, and the limit was defined to be twice the target. E.g. if the pre-1559 limit was 10mm, the post-1559 target was 10mm, and the post-1559 limit was 20mm. 1559 provided an effective blocksize increase with Serious Consequences (in the form of the base fee adjustment). Miners in the 1559 regime could vote on the gas target, via the same 1/1024 per-block adjustment system.

Now 1/1024 (0.09%) may seem like a small amount, however, it translates to increasing by about 5% every 50 blocks, or about every 12.5 minutes, or doubling about every 3 hours. Hypothetically you could take a nap and wake up to a doubled gas limit (or a halved gas limit)!

A Quick Aside and Refresher

EIP-1559 takes 2 inputs and produces 2 outputs:

                      Inputs      Outputs
            Target Gas Usage      Gas Limit
            Actual Gas Usage      Base Fee

Block producers set the target gas usage by adjusting the target up to 1/1024 every block. In this way, the indirectly set the limit (2x the target). The block-producer set target is combined with the actual gas usage to set the base fee. When actual > target the base fee rises. When actual < target the base fee falls. There’s a complex elasticity relationship here, but don’t worry about it. It’s arbitrary and capricious¹.

It’s important to remember that the target usage has no impact on the actual usage. In fact, each block producer sets both the target (via the adjustment mech) and the actual usage (by including transactions while building the block).² In effect, each block producer controls both inputs to EIP-1559, and can therefore control the outputs (for their particular block). The block target in any given block is the outcome of the producer’s latest move in an indefinitely iterated “set the gas target game”. So the behavior of the average over time converges to values set by equilibriums in that game.³

1559 With the Merge

The Merge had 2 main effects on the Gas Limit system:

1. The 5% increase period shortened to 10 minutes, because block times are slighly shorter. This results in potential doubling (or halving) around every 2.4 hours.

2. Miners were replaced by “stakers” or “validators” or whoever.

The first one constitutes a non-trivial increase to an already fast compounding process. Probably not important.

The second, tho, much more important, I think. But not in isolation, only as part of a larger system trend. Let’s come back to it later.

I searched unsplash for “Merge” and this looked cool. Photo by pine watt on Unsplash

What stops the target from rising?

So you might be wondering to yourself. Why doesn’t the block target rise? Wouldn’t it make transactions cheaper for users (good), and make Validators more money (also good)? If those things seem nice, why is the target 15,000,000 and not say, 15,000,000,000,000? Why is a 15mm target (30mm limit) the current equilibrium?

Well, the main reason is that it has always been set at the recommendation of the core devs. Historically, it has risen all at once⁴. The received wisdom says that we set it at a level we know the clients can process in a reasonable amount of time. Gigantic high-gas blocks would DoS nodes and prevent confirmation. The Validator (previously the Miner) has to build the block, and verify other peoples’ blocks. And if the block is too large to build or verify reliably in the 12 second block period, then the Validator will lose money when it fails to confirm. Validators (and Miners before them) hate losing money. This also creates network instability, as nodes may handle gigablocks poorly.

EIP-1559 touches on this in a pretty short security section contemplating security with respect to block size:

This EIP will increase the maximum block size, which could cause problems if miners are unable to process a block fast enough as it will force them to mine an empty block. Over time, the average block size should remain about the same as without this EIP, so this is only an issue for short term size bursts. It is possible that one or more clients may handle short term size bursts poorly and error (such as out of memory or similar) and client implementations should make sure their clients can appropriately handle individual blocks up to max size.

We tend to believe that Validators are profit-motivated enough to keep block limits in a reasonable range, and that the 15mm target is reasonable given the state of the clients.

Is EIP-1559 still safe with PBS?

So MEV-PBS⁵ changes things. With PBS, Proposers no longer directly pay block building costs. They outsource that entire process to the Builder. In fact, common MEV-PBS constructions like the Flashbots relay hide the block from the Validator⁶ until it commits to propose the block. As part of the construction process, the validators communicate their preferred gas limit to the relay⁷.

The Builder uses specialized, optimized software (not an off-the-shelf client) to construct a block, and then communicates the block (with the gas limit adjustment) to the relay. The relay ensures that the Builder’s block matches the proposers requirements.

This creates an interesting situation. The Proposer is now forbidden from paying the building costs. Builders are specialized to pay those costs, and need not worry as much about larger gas limits. So in the MEV-PBS world, why should the target remain low?

It is not still safe.

The Proposer has always had an incentive to push the target up indefinitely in order to eliminate the basefee, but has been limited by the costs and risks of doing so. On the other hand, the Builder wants to confirm blocks, and has a disincentive to building blocks too large to verify in a confirmable time period. In other words, the Builder is walking a tight-rope of profitability. They need to carefully balance building larger actual blocks with more extraction vs the impact the block size has on confirmability. If the Builder produces a block too large for attestors to verify in the slot, they risk losing out on the entire block’s reward. This means the Builder has a strong incentive to hold actual block size down to a reasonably verifiable size, regardless of gas target.

Proposers, on the other hand, have no such balancing act. They can simply push the protocol-enforced target up indefinitely, and let the Builders figure out a profitable equilibrium. Doing this eliminates the base fee, while keeping actual block space constrained⁸.

By raising the target (and protocol-enforced limit) while keeping actual block size in normal ranges, Proposers not only allow more MEV extraction via outlier block sizes during major MEV events, they ALSO eliminate the basefee while artificially constraining supply. If the Builders keep blocks small, then users will have to pay gas tips, recreating the pre-1559 FPA fee market and essentially nulling EIP-1559. In effect, they can patch out EIP-1559 by “hypothetically” increasing block space, and then refusing to let anyone use it.

Kneecapping EIP-1559 seems like a clear win for the Proposer and Builder. They can BOTH extract more MEV for themselves in edge cases (by building huge blocks occassionally) AND convert all basefee burning to tips paid by artificially constraining supply. And, the cartel is incentive compatible, as neither party seems to profit from deviating. Dope.

This brings me to the central question of this article.

When will Proposers and Builders cooperate to increase the gas target to 100mm+?

Given the constraints on confirmability, Builders should keep the ACTUAL block size near current values regardless of the target size. Some reasonably low size maximizes their profit. However, for a Proposer, some absurdly high target maximizes their profit. Because the Proposers and Builders are no longer the same party, they can each maximize their profits by colluding to push target up while keeping actual size down.

As long as blocks stay around 15,000,000, isn’t a gas target of 15,000,000,000 more incentive compatible than a gas target of 15,000,000?

Conclusion

Hey Validators! Builder0x69! Or whoever!⁹ ¹⁰ ¹¹ ¹² start pumping the gas target, but keep actual blocks produced small. You’ll make more money! It’s free real estate.¹³

1. Kinda weirdly rationalized too.

2. This is important.

3. This is also important.

4. Check out this cool chart for an example

5. Miner-extractable value-driven Proposer//Builder separation. Here’s some reading, or if it suits you, refer to my earlier note wrt Bankless.

6. This prevents MEV theft attacks like the April 2023 incident.

7. Whom they trust to tell the Builder

8. Oh boy.

9. Due to the design of the relay API, Flashbots and other relays could actually adjust the gas target unilaterally. They give the builder the “actual” size, reject blocks consuming more gas than that, and then adjust the protocol limit in the block after the builder builds it.

10. Basically the relays could implement this fee regime all on their own without anyones’ permission or cooperation. The Proposers and Builders become puppets for the relay.

11. We should probably stop using unaccountable TTPs for critical processes like block building.

12. Or we could just add more SGX. Lmao.

13. It’s a free fucking house.