I hate to break out the old cliche, but let’s think about this from first principles: what are we trying to accomplish?

I can think of a few options and none of them are very convincing to me

1. lower gas prices

2. defeat the laughably asinine “etHeReUm sTopPeD iNnovaTiNg oN l1” narrative

3. “we just should raise the gas limit because we haven’t for awhile and disks are cheaper than when we last raised it”

4. Bring back apps to l1

Gas prices are already relatively low. The average transaction price over the last month was 16 gwei. That sort of average fee seems eminently reasonable to me.

“etHeReUm sTopPeD iNnovaTiNg oN l1” is simply a marketing problem at least in part fomented by Banklust choosing to platform bad faith critics. But here’s the thing: when the criticism is this silly, substance doesn’t actually matter.

Again, gas prices are reasonably low, raising the gas limit isn’t innovation.

As for option #3, I actually think this is fairly reasonable if we decided as a community to slowly raise the gaslimit as disk space and I/O improve because it would be a credible commitment, but as a standalone reason I think it’s pretty poor.

Some people really want to bring apps back to layer1, but there’s a real problem of induced demand here. You raise the gaslimit a lot, you bring back a bunch of apps, everything is great for awhile, and then demand overwhelms supply and it routinely costs 120 gwei for a transaction again

BUT WAIT EVAN, WE ARE AUTISTIC NERDS, WE ONLY CARE ABOUT WHAT THE NETWORK CAN HANDLE

Ok, but this isn’t a simple question. “What the network can handle” over the short and long run is complicated.

State size isn’t a huge issue. It’s not actually that big at ~300 gigs now, (h/t @notnotstorm and @gakonst https://paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1…). History is actually a bigger problem but there’s a plan to deal with that in about 6 months.

State I/O and bandwidth are bigger issues.

Recently we raised the blocksize when we added blobs, and tbh for awhile post-Pectra when I was streaming something where I didn’t want buffering (ahem, la pelota

>>>>> gd2md-html alert: error handling inline image
(Back to top)(Next alert)
>>>>>

) I was taking my home non-staking node offline.

Clients have generally made big strides on bandwidth in the past 6 months, and maybe I just had a router issue, but we’re also planning on raising the block size again when we add more blobs. Let’s not overdo bandwidth requirements.

Disk I/O is also possibly a bigger issue than bandwidth. If I’m being honest, I think quantifying this is one of the more under-researched things in Ethereum. I think we’re fine on the margin for now, but long-term I think there’s some variables I’m unclear on. I’m also very much not an expert in this area.

BLAH BLAH BLAH EVAN, CAN WE RAISE THE GASLIMIT?

I think we could marginally raise the gaslimit, absolutely. I intend to propose raising it marginally when I think it makes sense, to something like 33m. If it goes well, we can evaluate and raise again. Yes there are significant coordination costs, but actually these are a good thing: we should never let our ability to coordinate atrophy unless we want it to deteriorate.

I don’t think we should raise the gas limit to 60m any time in the near future, even if there was demand. I simply don’t think we’ve proven the case yet and Ethereum is past the point of YOLOing.

I respect the case of those who disagree but we have different burdens of proof.

WAIT, YOU THINK WE CAN RAISE THE GASLIMIT BUT DON’T WANT TO?

Glad you’re still reading.

Yes, I don’t think there’s any good reason right now. Gas fees are low. We aren’t bringing apps back to l1 (nor should we) with marginal gaslimit increases.

It’s true that we have gas spikes, and then long periods of low gas prices. See screenshot below.

THE BIGGER PROBLEM IS THE SPIKES

This is a normal problem in commodities markets (btw crypto prices also tend to look similar to commodities). you have long drawn out downswings and short violent spikes

I don’t have an easy way to solve this problem (increase max to 60m but leave target at 15?), but it’s the way to go.

A CURVEBALL

If you don’t pay close attention to Ethereum blockspace like I do, you probably don’t know that gwei was held artificially high in 2022-2023 by a HEX fork called XEN. It literally created a floor on ETH gas price that kept ETH at negative net issuance for the bear market (until Pectra added blobs).

Look I don’t generally believe in being judgmental about people who use blockspace. If you pay for it, that’s reasonable.

But again, let me go back to what I said above: there are peak demand times over a 7 day period. It gets high, and then it drops off a cliff at other times.

Incentivizing non-urgent transactions that aren’t high value like XEN is hardly the sort of thing we want bloating our state for…what exactly?

Generally speaking, I think keeping state size/IO manageable preserves optionality until we SNARK it or some other silver bullet solution. As I’ve said multiple times recently, Ethereum wants to be the internet’s money and the global settlement layer. That means we don’t take risks. So we always try to preserve optionality.

Even if we have stateless validation in the future, there will be some beefy servers doing block building. The more we increase the RAM necessary, the more we increase barriers to entry. Historically, one of the great things about Ethereum is that you can contribute technically to things like this even if you don’t have the capital.

Again, I like to keep optionality open as much as possible. I don’t find the tradeoff worth it.

Ok, that’s it, some friends asked me to explain why I’m against the gaslimit increase, so I have done so. I did this off the top of my head with minimal editing.

Corrections and disagreements welcome.

tldr: we should raise the gas limit when it makes sense, but right now gas prices are fairly low and the median transaction fee is quite reasonable. Preserve optionality. Raise gaslimit when it makes sense.

Disclaimer:

1. This article is reprinted from [Evan Van Ness]. All copyrights belong to the original author [@evan_van_ness]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Copying, distributing, or plagiarizing the translated articles is prohibited unless mentioned.