Why don't Ethereum increase the block gas limit? In my understand, it can increase total throughput(transactions per second), but also increase uncle block rates either. But i couldn't find any exact materials but only some comments. How does it increase the uncle block rate and why is it problem?


As the other two answers have pointed out, if you increase the block gas limit:

  • You increase the likelihood of uncle blocks, partly due to how long it takes to create the block, and partly because of an increase in network propagation time;
  • You increase the chance of centralisation, due to block validation taking longer, which in turn skews the advantage in favour of the more powerful nodes in the network who can keep up.

If you take the second of these points a step further, and include game theoretical effects, an increase in the block gas limit is more likely to lead to empty blocks, which potentially decreases the throughput of the network.

During the Great CryptoKitty Crisis of 2017, when we were up against the block gas limit for a prolonged period of time, one of the main pools was reguarly (deliberately) mining empty blocks. If pool A creates an empty block X, containing no transactions, while pool B creates a full block X, then the empty block will propagate around the network more quickly, and be validated by other nodes more quickly.

Yes, the miner loses out on transaction fees (there aren't any), but increases his chance of gaining the block reward. At the time of the CryptoKitty mayhem, this was, at least some of the time, a valid strategy. The larger we allow blocks to get, the greater the disparity between the propagation and validation of empty blocks when compared to full blocks.

  • I would argue that your last argument is not valid since the benefit of the strategy of mining empty blocks is a market signal that transaction fees (gas prices) are too low. Apr 27 '18 at 13:14
  • 1
    +1 for the term "Great CryptoKitty Crisis of 2017" Apr 27 '18 at 13:17
  • Only if everyone agrees on the signal. And even then it may be a bluff. Perhaps it should be worded more along the lines of: "when the uncle rates are (very) high, if you're a big pool, it's sometimes better to mine an empty or partially full block to decrease the chances of your block becoming the uncle". Apr 27 '18 at 13:23
  • 1
    Okay, apologies - I was looking at it from a different perspective - I understand what you're saying now :-) This was basically my "at least some of the time" clause, except there was no further explanation on the effect of an increased gas price. Thanks for pulling me up on this. Apr 27 '18 at 14:01
  • 1
    I could have expressed myself more clearly. I think this is a very valid discussion and I am pretty sure that it is something that Vitalik Butering and other core developers have discussed. Apr 27 '18 at 14:07

The longer it takes to mine a block and execute its transactions the more probable it is to generate uncle blocks. If the block gas limit is high, there are more transactions and/or more demanding transactions in the block.

Uncle blocks are generated when you succesfully mine a block but it doesn't become part of the canonical chain. If it takes longer time to mine a block (higher block gas limit) more separate miners manage to mine the same block (with possibly different contents) and only one of them becomes part of the canonical chain and the rest become uncles.

Uncle blocks are a small problem in the sense that they are wasted processing power even if they still contribute to the general security of the network.


Limiting the block size is a way to avoid centralization which is a priority for the Ethereum developers. More powerful computers with faster networks would receive a huge benefit if the block size increased since you do not start mining on a new block until you have confirmed that the block you just received is valid. And this takes longer, the slower your computer is and the slower your network is.

So miners need to confirm that the received block is valid, and the larger this block is, the longer they would spend confirming the received block.

Nodes also need to be more powerful (and thus more expensive) if the block size grows.

So the trick is to avoid too much centralization while allowing the network to scale.

  • Interesting. Your approach is totally different compared to mine. I wonder if mine is even correct then? :) Apr 27 '18 at 13:03
  • I think both our answers are correct :) I consider both uncle blocks and avoiding centralization as valid arguments for not allowing blocks to become too large. Apr 27 '18 at 13:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.