Ethereum’s New 1MB Blocksize Limit

Abstract: We look at a new Ethereum improvement proposal (EIP-4488), published around one week ago by Vitalik Buterin. This proposal is designed to make a potential so-called “layer 2” scaling solution, called rollups, more affordable. As a result of this, to mitigate the high level of block space these rollups could consume, a new blocksize data limit is introduced. We explain the very basics of how rollups work, particularly in the context of Bitcoin and discuss some of the challenges Ethereum may face, caused by the new blocksize limit, which we think could undermine some of the benefits of EIP-1559. 

EIP-4488 Overview

EIP-4488 is a recent proposal, written by Ethereum founder Vitalik Buterin, published towards the end of November 2021. It is a proposal to reduce the cost of one byte of calldata in the Ethereum blockchain, to 3 gas from 16 gas. This is a large c81% reduction in gas cost for the data. The aim here is to make rollups cheaper. Rollups on Ethereum use up a lot of space and are seen as critical to scaling. Many regard the fees on Ethereum as far too high to attract new users, with transactions often costing hundreds of dollars and this is said to be driving users to alternative systems such as Solana or Avalanche. Using so-called “layer 2” solutions, such as rollups, one can reduce fees significantly and rollups such as Aribitrum are starting to gain traction. Many of the Defi projects under development we have spoken to, have switched to using rollups during the build phase and exchanges such as Binance will accept rollup deposits. However, the possible fee reduction of rollups are only around 10x, with some users still paying reasonably high fees. Therefore, EIP-4488 was put forward as a quick fix, to potentially reduce these fees by almost another order of magnitude, at least in the short term. Since “layer 1” Ethereum transactions also use calldata, there will be a small fee saving here too, perhaps around 2%.

The problem here is that if the gas cost of calldata is lowered, Ethereum blocks could become larger which could cause too much centralisation pressure. The current gas limit is 30 million units, with a target of 15 million. Therefore the maximum size of a block is 30,000,000/16 = 1.875 MB. Reducing the gas cost to 3, would increase the maximum blocksize to 10 MB (30,000,000/3). This was considered too large and therefore the proposal also includes a new limit, a calldata blocksize limit of 1MB. (Some have argued increasing this limit to 1.875 MB, such that all possible old transactions remain valid, however if your transaction needs to use around 30 million gas, you are pushing it a bit.)

This new 1MB limit is somewhat ironic, given years of fighting in Bitcoin, about Bitcoin’s old 1MB blocksize limit. We even wrote a book about it! Although of course, the target block time in Ethereum is far lower than 10 minutes, (around 13 seconds now and 12 seconds after the transition to Ethereum 2.0), therefore the 1MB blocksize is not a direct comparison.


It is at this point that it is probably worth trying to explain what a rollup is. Using a rollup, transactions are processed and executed off-chain, but the transaction data is still included in the main Ethereum chain, such that there is no significant blockspace saving as a result of the rollup. Typically, in the Ethereum world, when using the phrase “off-chain”, it means another blockchain (not a peer to peer network like Bitcoin’s lightning network, which doesn’t have a blockchain). Therefore, rollups are a sidechain system, the latest and perhaps most advanced iteration of the idea originally proposed by Bitcoin developer Johnson Lau all the way back in 2013. The rollup sidechain is EVM compatible and one can use Solidity smart contracts. Therefore a blockchain is required to get the full functionality of Ethereum.

The benefits here are scalability. The sidechain does not have the restrictive computational gas limits of the main chain, therefore throughput is higher and transactions should be cheaper. The downside of rollups are that the sidechain requires new consensus agents and these agents have the power to order transactions. There is also the problem of moving funds from the sidechain to the mainchain, which is necessarily slow for security reasons.

Fraud proofs and bonds

The type of rollups generating the most excitement on Ethereum is a subset of the wider rollup concept, called “optimistic rollups”. The way these work is that users assume the rollup state is valid, however sidechain validators have the ability to submit a fraud proof to the main Ethereum chain if the rollup is considered invalid. This proof can then be verified by all mainchain Ethereum nodes. The entity which puts the original rollup transaction data into the Ethereum chain is also required to put in place an Ethereum bond. In the event they submit an invalid state and this is proven, they can lose their bond. This incentive structure is designed to keep the rollup sidechain secure. There are some parallels here with proof of stake systems and penalties for bad behaviour.

This bonding type system may seem complex, unnecessary and even a bit weak. For instance how do system designers ensure the bond is of sufficient value to deter fraud, while also that entities have enough liquidity? This could be challenging given the large and volatile flow of funds in the space. One needs to make several assumptions in order for such a system to be necessary:

  • Throughput on the sidechain is high, such that not many entities run a fully validating sidechain node and the sidechain system is too centralised to be secure
  • Storing data on the mainchain is cheap, while computationally the system is capacity constrained

In this scenario this complicated bonding system may make sense and the sidechain, which itself is considered insecure, is secure enough due to the fraud proof and bonding system. Ethereum may currently be in a sweet spot where optimistic rollups make sense. Therefore there is considerable excitement about optimistic rollups and many consider them critical to scaling Ethereum. 

Rollups in the Bitcoin context

There is another irony here, when rollups are evaluated in the Bitcoin context. For years several so-called “Bitcoin maximalist” types have argued that a major weakness of Ethereum is that smart contracts are processed on-chain. They have claimed that this process should occur off-chain, while only the data and results of these computations should appear on-chain. This is exactly what rollups do. However, we have not seen many “Bitcoin maximalists” turn more positive on Ethereum as a result of this development. At the same time, we don’t see many Ethereum developers thanking Bitcoiners for promoting this idea for years.

The next question that some have asked us is “Can Bitcoin do rollups?”. The answer is yes, Bitcoin can, in theory anyway. Infact, if one was to try to execute these types of smart contracts on Bitcoin then it must do rollups, because there is no way of making existing Bitcoin full nodes validate these complex smart contracts. Therefore, the only way of doing it would be to put the smart contract data on the Bitcoin blockchain, and have the smart contract transactions executed and validated by other node software, which runs the sidechain. Technically you can argue that in order to be a real rollup, the layer 1 transaction must be able to enforce the layer 2 transactions, since on Bitcoin you cannot do this, perhaps it should not be called a rollup. However, on Bitcoin, with this type of sidechain construction you can still do almost anything, including making the system Ethereum Virtual Machine (EVM) capable with Solidity smart contracts. Of course such a system may not be effective or efficient on top of Bitcoin, but in theory it could work.

One weakness of creating this sidechain rollup type system on top of Bitcoin, is that unlike with Ethereum, you could never do the fraud proof, optimistic rollup type system. However, it is not clear to us that this would be needed or desirable. The purpose of constructing these rollups on top of Bitcoin, would be to add Ethereum like smart contracting capability to Bitcoin. In contrast the purpose of rollups on Ethereum is higher capacity, not improved smart contracting capabilities. Therefore, in this theoretical Bitcoin construct, users can choose whether or not they want to validate the sidechain in addition to the mainchain or not, and the fraud proof system is not necessary. Storage on Bitcoin is not cheap and we don’t have the starting assumption that the sidechain needs to have very high throughput such that centralisation is too high, such that we have a major security risk due to a lack of validators. In our view, this apparent sweet spot, where optimistic rollups make sense for Ethereum, may not last too long there anyway.

Our above analysis ignores the issue about how to quickly and securely move non-custodial Bitcoin into and out of the smart contract enabled rollup sidechain, however we will leave this complex and challenging topic for another occasion. This area may be another theoretical weakness Bitcoin has with respect to Ethereum, when building rollups and sidechains.

Two fee market buckets

One potential issue with EIP-4488 is the creation of the new 1MB calldata limit. Ethereum blocks therefore have two limits, the gas limit and the calldata limit. Block construction could now become more complicated, as block producers now have a multi-dimensional problem to consider when selecting revenue maximising transactions. This weakness was discussed in the EIP. The view was that block production is already complicated due to factors such as Miner Extractable Value (MEV). This problem of two block constraints is far more simple than working out how to extract MEV when producing blocks, therefore it was argued that the two limits does not increase complexity for block producers.

However, we still think the two limits could add complexity for users and wallets, which need to decide on the fee or tip for their transactions. As now there appears to be “two fee market buckets”. There is some more irony here, when comparing this to Bitcoin. Two fee market buckets was a criticism levied against the SegWit upgrade to Bitcoin in August 2016. 

A slide pointing out some weaknesses in Bitcoin’s SegWit from 2016


Although, back then the criticism was incorrect, since Bitcoin’s new block weight limit was consistent with the old blocksize limit and since block producers could be assumed to have upgraded to SegWit due to the activation system, there should only have been one fee market bucket. However, based on our understanding of this new Ethereum limit, we could now actually have two fee market buckets and the associated “economic complexity”. Although, we could be making a similar mistake to those SegWit critics back then, if we don’t fully understand EIP4488. We would appreciate feedback on this issue.

Undermining EIP-1559

The new blocksize limit could also undermine EIP-1559, to a certain extent. EIP-1559 introduces a block gas limit target and a base fee. The base fee adjusts according to whether gas usage is above or below the target. As far as we are aware, there is no adjustment mechanism for this new calldata limit. Therefore, if the calldata limit comes into play, which it may well do if rollups succeed, there could be fee market volatility again and the primary benefits of EIP-1559 could be lost. However, we could be wrong here and plan to conduct more research into this area.


Ethereum blocks are currently typically around 80KB in size or around 4MB in a ten minute time period. However, the size of blocks has never been a significant issue when it comes to syncing an Ethereum node. As we explained in our recent piece comparing the blockchain size between Ethereum and Bitcoin, Bitcoin’s blockchain is actually larger than Ethereum. However, this does not mean Bitcoin is harder to sync or validate than Ethereum. Ethereum is far harder to validate, it perhaps takes around 10x longer than Bitcoin on a comparable machine based on our recent experiences (there is no perfect like for like comparison). Our point is that with Ethereum, it has never been about the blocksize. If rollups gain in traction, which we think is quite likely, things could change. The difficulty in syncing an Ethereum node and a major force of centralisation could quickly become primarily about the blocksize.

As for the complexity of two block limits and two fee buckets, this may be unnecessary and is something we think should be avoided. Perhaps one could consider a more simple solution, such as lowering the gas cost of a byte of calldate to 8 rather than 3. This would limit the maximum blocksize to around 4MB, while avoiding the complexity of two limits and still cut the calldata costs by 50%. EIP-4488 is not meant as a long term scaling solution, but it’s only a quick fix. Maybe as a temporary gapstop, the two limits are ok, as long as they are removed again later on. What we are convinced of however, is that optimistic rollups alone cannot solve Ethereum scaling, it will simply make blocks larger until their size is a new problem. There will need to be more technologies deployed to scale Ethereum, in what is becoming a monumental challenge.