Read on Twitter
I think it is dangerous to raise #ethereum's gas limit right now. There are several factors that I think we need to look at wrt. this decision. Looking at only one (uncle rate) is just not enough. Thread 
(tldr: lots of things to consider, solutions on the horizon)
(tldr: lots of things to consider, solutions on the horizon)
Uncle rate: The uncle rate is the most discussed metric when assessing whether a gas limit increase is safe. Bigger blocks travel slower through the network thus increasing the probability of uncles. However the uncle rate mostly concerns the size of the block not the actual
execution, as blocks are propagated (at least by geth) if the PoW checks out and not if they execute correctly. Thus a small transaction that does a lot of storage operation won't increase the uncle rate as much as a bigger transaction that does less operations.
State size: The big limiting factor I currently see is the fast growing state size. Transactions that create accounts or contracts, or store data increase the size of the blockchain drastically. Since our nodes are not capable of pruning the state fast enough, a lot of
unnecessary state is stored on disk. This is also why a freshly synced geth node consumes ~350GB while a node that ran for some time already consumes > 500GB. Increasing the gas limit would directly contribute to this state bloat.
Sync times: It currently takes several days to sync a full node with a full sync. This is due to several factors. Increasing the gas limit increases the time to sync a new node significantly. New syncing protocols (e.g. snap sync) can decrease this time.
Execution times: Whenever a new block arrives, all executions have to be executed and the state has to be updated. This is a bit different than sync because some shortcuts we can take while syncing can not be done when processing a block.
Increasing the gas limit directly increases the execution time of a block. If a block takes longer than 13 seconds (the current blocktime) to execute, the entire network breaks down as forks would occur almost every block.
There are some issues currently in ethereum that might be used to create such heavy blocks. We hope to fix them with EIP-2718.
Archive nodes: While full nodes are sufficient for most use cases, archive nodes (nodes that store the all intermediate states of the past) still have their use-case and many services, like block explorers or accounting tools, rely on them.
Increasing gas limits puts extreme pressure on those nodes. While we generally don't focus on these type of nodes we still need to support them.
Solutions: As you can see, this is a multifaceted problem that we have to consider when making a decision about raising the gas limit. I don't think it is save to increase it right now. But I also see some solutions on the horizon that might enable us to do so in the future.
Snapshots and Snap Sync: With our next release, we'll publish a new feature to @go_ethereum called snap sync which greatly reduces time and network capacity needed to sync a node. Additionally a snapshot feature provides faster reads to the current state.
Regenesis: Regenesis is a proposal to prune the history of ethereum and basically create a new genesis block with the current state. This allows us to drop a lot of logic to verify old blocks and greatly reduces sync times, for example by pruning the shanghai attacks away.
Flat DB: Turbo-geth introduced a different data structure for their state which reduces the amount of random disk reads and writes needed to execute a block. Go-ethereum is currently unable to replicate this format as some wire packages require our current data format.
Once we dropped old eth-protocol versions, we will be able to adopt a similar format which also enables us to increase gas limits.
Pruner: Geth is currently unable to use inmemory pruning to decrease the unnecessary states that are written to disk which results in a state bloat of ~1 GB per day. @Gary_Rong is currently working on a solution to prune these states away using the aforementioned snapshot feat.
Doing so would greatly decrease the space requirements for full nodes.
TxPool and Retransmission: Frontrunners and high frequency traders currently pay exorbitant prices to execute their transactions and to update their transaction to spent less gas when reverting.
TxPool and Retransmission: Frontrunners and high frequency traders currently pay exorbitant prices to execute their transactions and to update their transaction to spent less gas when reverting.
Changes to the transaction pool and the retransmission rules might alleviate some of the pressure there.
Layer2: Increasing the usage of layer 2 solutions greatly decreases the transaction load of the ethereum network. I hope that a lot of projects use the current situation to consider trying out some of the exisiting layer 2 solutions.
I personally prefer a congested network over a broken network where users are unable to run their own nodes to verify the network. What do you think?
