Can we have the same 30M gas limit on L2Geth as L1?

[diwu1989]

Eth L1 has per block gas limit of 30M OP L2 has block gas limit of 15M, so jumbo transactions fail.

Can we have the same 30M gas limit on L2? Otherwise, it isn't really equivalent if we cannot push through a 20M gas transaction successfully on L2.

[smartcontracts]

This is a really interesting topic that we've discussed before in depth. I brought up the same concern with jumbo txns that succeed on L1 but would fail on L2. Main problem with increasing the gas limit is that Optimism's block times are much, much lower than Ethereum's block times, so increasing the gas limit creates the potential for the chain to become rapidly bloated.

We're planning to mostly resolve this issue in Bedrock with the following modifications to the protocol:

• Optimism's block times will be fixed at one block every 2 seconds
• Blocks will have a target gas limit of 2.5m with an elasticity multiplier of 8, meaning the maximum gas limit is 20m
• We may increase the maximum to 30m if we feel it's safe to do so

We ran some analytics and found that at 20m the protocol can still be safe while also being able to execute a vast majority of the txns that have ever been executed on L1. If you have a specific jumbo txn that you want to execute that wouldn't work with a 20m gas limit, let me know.

[diwu1989]

Optimism's block times will be fixed at one block every 2 seconds This makes some really drastic change to OP that make it not as useful as it currently is, with instant L2 finality. Many use-cases that rely on instant confirmation / rejection will go away, can we please tighten this down to at most 500ms? or even less?

Usecases that are actually in production on OP today are:

1. Trading between CEX (which has instant finality) and OP (which also has effectively instant finality right now)
2. Near real time payment confirmation, 2s is very slow compared to instant confirmation
3. At 2s per block, OP is not really that different from Polygon, it loses a lot of the "effectively syncronous" advantages at the network level.

Blocks will have a target gas limit of 2.5m with an elasticity multiplier of 8, meaning the maximum gas limit is 20m What is the difference between 20M and matching L1 spec of 30M? As far as I can tell, the bottleneck is in how many EVM byte codes the L2Geth interpreter can crank through, and that's directly a result of single threaded CPU performance. CPU have been getting faster and faster in recent year, especially if you look at the Epyc Milan series of public cloud CPU. Next generation Intel Sapphire Rapids server CPU will also bring same or better single thread perf. All of this means that with the right hardware on the sequencer, cranking through 30M gas blocks is only going to get easier over time. If you change block time to 200ms, the right CPU in GCP (T2D or N2D milan architecture) can churn through a 30M gas transaction just fine.

If you have a specific jumbo txn that you want to execute that wouldn't work with a 20m gas limit, let me know. With 30M gas, you can do a LOT more computation on-chain. Protocols like DHedge for example can actually become a lot more sophisticated on-chain if they are allowed to do more number crunching in the contract, vs rely on offline solvers.

[diwu1989]

What is the advantage of a 2s block production rate vs a 200ms/500ms block production rate? Human perceive >1s as not instant, but a 200ms or 500ms block time still feels instant to human.

P2P gossip UDP packets can travel across the world in ~150ms (worst case going around the entire world), so I might see an network level argument for 500ms block timing to allow for a few round trips to happen at the P2P layer, but 2s just feel like sand bagging the block production rate.

[smartcontracts]

What is the difference between 20M and matching L1 spec of 30M?

Matching the 30M spec seems reasonable and I will probably push for it. We're using 20M as a baseline for now (at the 2s block time) and will see how high we can reasonably crank up the gas limit before things get shaky. Further decreasing block times while increasing the gas limit to 30M would be fundamentally unsafe. Geth performance is mainly IO bound, not CPU bound. Accessing the state trie only gets worse as state gets more bloated. Requiring top-of-the-line sever hardware would reduce the future decentralization of the network by significantly increasing the cost to run a verifier that can actually keep up with block producers.

This makes some really drastic change to OP that make it not as useful as it currently is, with instant L2 finality.

Although it's a significant change, it's one we believe is necessary for the long-term health and decentralization of the network. Best way to safely distribute unconfirmed L2 sequencer blocks to L2 nodes is to use a p2p network in the same way that Ethereum does. Most L2s today rely on a single centralized sequencer data feed, which ends up being extremely susceptible to DoS attacks and becomes a massive engineering problem to manage. By distributing via a p2p network, you can safely sit the sequencer behind a series of sentry nodes that then broadcast blocks to the rest of the network. It's much more stable and much more resistant to denial of service attacks.

What is the advantage of a 2s block production rate vs a 200ms/500ms block production rate?

Producing blocks much faster than every 2s induces a load on the p2p network that may end up not being manageable. Additionally, it may not be feasible to produce blocks faster than ~200ms simply because of the amount of time required to recompute state roots (the MPT is an annoying and inefficient data structure). MPT performance only gets worse as the state trie gets bigger. 500ms may be the lower bound of safe and consistent block production. 1s may be more realistic. Again, like the block gas limit, 2s is an initial safe baseline for the sake of the devnet and we'll attempt to reduce that number as much as we can safely get away with. We've spoken in depth to many different projects on this topic and none are fundamentally broken by this change. Many projects also rely on a constant block production rate, so no matter what we'd remove the "instant" feature and replace it with a short-but-constant block time which can usually seem "instant enough" for most use-cases.

[diwu1989]

Geth performance is mainly IO bound, not CPU bound. Accessing the state trie only gets worse as state gets more bloated. L2Geth's leveldb layer isn't well optimized, you can just optimize the KV layer to reduce the I/O and do smarter caching. It's not really I/O bound, it's "current crappy LevelDB implementation bound" and competitive arb operators have custom code to accelerate the storage layer already, so its doable to get rid of the I/O bound and make it effectively still CPU bound.

1s may be more realistic Can we launch bedrock with 1s? This is my one and only wishlist.

500ms may be the lower bound of safe and consistent block production Moore's law is picking up again these days because AMD and Intel are finally innovating on single threaded IPC again.

[smartcontracts]

I definitely think it's worth at least stress testing a Bedrock devnet with 1s block times to study the overall impact

[smartcontracts]

L2Geth's leveldb layer isn't well optimized, you can just optimize the KV layer to reduce the I/O and do smarter caching. It's not really I/O bound, it's "current crappy LevelDB implementation bound" and competitive arb operators have custom code to accelerate the storage layer already, so its doable to get rid of the I/O bound and make it effectively still CPU bound.

Although I agree it's feasible to do this, we're currently trying to launch Bedrock with a minimal diff to Geth. Optimizing the K/V layer is something we're interested in doing (and are actively pursuing) but will realistically not be in prod before Bedrock is out.

Moore's law is picking up again these days because AMD and Intel are finally innovating on single threaded IPC again.

Also worth keeping an eye on. And like I said, I'll push to at least stress test at lower block times just to see how the system behaves and figure out what its absolute limits are at the moment.

[diwu1989]

Although I agree it's feasible to do this, we're currently trying to launch Bedrock with a minimal diff to Geth

Are you guys running with GCP Zonal SSD PD or Local SSD? If you're using local SSD on the sequencer (and on Bedrock run a HA set of sequencer where god forbid the main sequencer craps out, after heartbeat timeout, the secondary sequencers get elected), you should be able to get high availability AND insane local IOPS performance even out of the current unmodified Geth leveldb.

375GB zonal PD = 11,250 iops 375GB local SSD = 170,000 iops

one order of magnitude higher rand read iops and drastically lower latency

The IOPS perf bottleneck can be solved without rewriting code if the storage is set to local SSD + spin up backup sequencers.

[diwu1989]

@smartcontracts Another question. When the block production becomes every N seconds, does that mean there will be insane priority gas auction / insane bribes paid to sequencer via flashbot side-channel collusion?

The nice thing about OP right now is that nobody can sandwich attack / front run my CEX <-> DEX arbs, as long as i'm the first one to submit it. But with a 2s delay, someone else can PGA me and frontrun me?

[andresbach]

Hey @smartcontracts :wave:

Would you know if the 20M limit is still standing or if that was upgraded to match mainnet? Thanks in advance.

Matching the 30M spec seems reasonable and I will probably push for it. We're using 20M as a baseline for now

[smartcontracts]

Mainnet limit should be 30m. 3m target with 10x elasticity.