## Geth Position on EIP-4488
This document summarizes our (the geth team's) position on [EIP-4488][eip4488]. We are
**against** the inclusion of this EIP in a fork before the merge.
EIP-4488 is a tweak to the economic balance of Ethereum. It does not enable anything
that's currently impossible, the change just makes it more economically feasible. Such a
change should not be hastily implemented ahead of an already scheduled major fork.
### Technical Concerns
Decreasing the costs of data-heavy transactions will make typical Ethereum transactions
more expensive, favoring L2 transactions. This might be fine, but it may also be a
non-obvious side effect that users should be aware of.
Specifically, we fear that EIP-4488 will, due to the 2-dimensional nature of the scheme,
favor rollup transactions so much that it won't be possible for non-rollups to use the
blockchain. The EIP should present significantly more evidence that this will not be the
At this time, EIP-4488 attempts to keep usage balanced by allowing transactions smaller
than 300 bytes even when the block size limit is already reached. While the exception will
allow for simple value transfers to be included alongside a data-heavy rollup transaction,
any transaction larger than 300 bytes needs to outbid all rollups for block space.
While the EIP limits the worst case block to the same size as it is currently, the average
size will be incentivized to gravitate towards the worst case. One does not simply propose
adding 3 TB of chain data growth per year without providing a working technical design for
storing this data. Referencing [EIP-4444][eip4444], noting that it should be 'implemented
either at the same time or soon after' is not a suitable way to deal with this problem
because EIP-4444 is not easily implementable.
EIP-4488's issues are not limited to storage problems caused by chain growth. It is also
important to verify experimentally whether block propagation will survive the jump to 1.5
MB block sizes.
### About Rollups
As noted in the EIP's motivation section, the goal of the change is making rollup
implementations cheaper. However, all existing rollup schemes are either insecure, or not
fully trustless. Incentivizing people to use them might be too early because they don't
guarantee the same or similar security as L1.
The current L2 landscape is summarized on [l2beat.com][l2b]. Checking the page for
[information about the most popular system 'Arbitrum'][arb] (claimed to have 41% market
share), we find it relies on a single centralized validator and contains a zero-delay code
upgrade feature in its main contract.
More research into EIP-4488 can mitigate our concerns. Nonetheless, the fact that more
research is needed should prevent immediate inclusion of this EIP.