The block size debate rages forward past the affective Bitcoin Cash fork. As with many arguments, there are more than just the two sides of the debate people think there are.
Instead of detailing the wholistic political philosophies behind each, I will outline here the main drawbacks of each idea, and show another construction which has some key benefits.
With Bitcoin we have the hard 1 MB block limit. The main drawback of this, is simply transaction throughput. We can only have a few TXs per second and therefore the market for these TXs will become more expensive as the bitcoin network grows more important in society.
Bitcoin Cash has taken the approach of allowing block size to be voted on by miners with a hard cap at 32 MB. This solves the current problem of throughput, but makes no promises about the future. As far as historical narratives are important to communities I would imagine that when the 32 MB becomes a problem again, another hard fork will gain significant consensus to move the limit higher. The problem here is that full nodes are the only way to really audit a blockchain, and as they get larger, the cost for running one (which is not really incentivized) becomes much more costly. Without a real incentive mechanism, Bitcoin has remained healthy largely from the fact that running these full nodes is nearly free (cost of a 200GB hard drive and an internet connection).
Ethereum has a block gas-limit which is effectively a block size AND computation limit in one. It uses a voting mechanism of the miners to determine its value, and historically has followed direct suggestions from Vitalik. It does not have any hard limit, and therefore can grow as big as the miners decide is most profitable for themselves collectively.
All three blockchains can and will receive pressures to raise limits as time goes on. This will never stop. One can attribute the Bitcoin Cash fork to this pressure without any doubt.
Security as a function of block size:
I myself certainly am against arbitrarily increasing block size, but it’s important to note that the reason is this subtle but real loss in security.
As computers become more powerful the cost of running a full node will drop. A drop in computing price can increase security as more users decide to run full nodes, hardening the peer-to-peer network
Security as a function of hardware cost
It is quite probable that a 1 MB block limit today is more secure than a 500 KB block would have been in 2009.
My proposal is to programmatically combine the two concepts above so that neither miner voting nor community hard forks are used to determine block size. Instead the advent of increased hardware ability itself can be used as a more secure and predictable way to calculate this “decision”.
Current difficulty at the last hash (Dn) multiplied by some constant (K) could be used to calculate the size limit of the next block (Bn+1).
This system is imperfect, because it is possible that hashing speed and currency price could advance far faster than state storage and internet speeds.
To leave large conservative margins let’s use the square root of the difficulty (or possibly the log of it). This would ensure security only grows with hardware capabilities. Block size would grow at a rate slower than hardware advances. Security would improve and so would blockchain throughput, but neither would decrease in sacrifice for the other.
Bn+1 = K √(Dn)
By solving K against the existing Blockchain data, we can allow block size to grow while the the cost of running a full node also falls.