## 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 case. 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. [l2b]: https://l2beat.com [arb]: https://l2beat.com/projects/arbitrum/ [eip4444]: https://eips.ethereum.org/EIPS/eip-4444 [eip4488]: https://eips.ethereum.org/EIPS/eip-4488