## 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
Last changed by  
 
Felix Lange
5756

Read more

Ideas for rollup-geth integration into upstream

Date: 2025-04-07 In this document, I'd like to lay out some of the ideas for L2 forks of go-ethereum to work with the upstream code. At a high level, what we want to achieve is that L2 projects can use go-ethereum as upstream and have kind of a good time. Conflicts from upstream changes, especially larger ones, should be minimized. Common features across L2s, and even L2 common core features, should be implemented directly in the upstream where possible. L2 project authors should be able to collaborate via the upstream. What to do about rollup-geth, the repository The existing rollup-geth project at https://github.com/NethermindEth/rollup-geth has some features merged and others implemented as PRs. We won't just merge their project directly into upstream. We will need to collaborate with the rollup-geth development team in order to schedule submission and review of each change into upstream on an individual basis, and this process should also take into account the perspective of the intended consumers of rollup-geth, the L2 downstream projects. As such, we will have calls with these actors over a longer period of time in order to figure out the sequence of changes.

4/8/2025
State of the RPC Standardization Process (01/2025)

This document is a bit of a brain dump of the RPC Standardization problem space. Mostly just posting this for discussion purposes, and also as an intro for people who aren't familiar with the space. There are some solution pointers at the end. If you are familiar with Ethereum's RPC, you may want to skip to that. The Spec The canonical Ethereum JSON-RPC specification is at https://github.com/ethereum/execution-apis The spec uses the OpenRPC format. After a lot of work over the last year or so, it's pretty comprehensive and covers most methods that can be relied on by users.

1/13/2025
Read more from Felix Lange
Published on HackMD