# Geth Glamsterdam EIP ranking This document presents our ranking of the EIPs proposed for Glamsterdam. We have interpreted the tiers as follows: - **S tier - showcase**: These are EIPs that we want to highlight above the rest, because they potentially represent non-consensus views and should help determine the ultimate priority of the non-repricing EIPs. - **A tier - repricing**: This tier is for the set of EVM repricing EIPs that we think are sensible and should be done. Overall, we think the repricing effort is very important from a scaling perspective. - **B tier - easy wins**: Here we put EIPs that are relatively easy to implement (in the EL), and would provide big benefits to Ethereum users. - **C tier - if we get to it**: For this tier, we selected EIPs that seem sensible but may contain significant complexity. We do think these could be added after work on A/B/S tier EIPs is completed. - **D tier - no**: we vote to reject the EIPs listed in tier D, either because they are not sensible changes, or because it feels like the wrong time for them. We believe that shipping the fork by June 2026 can be possible if we focus on shipping EIPs listed in tier S, A, B only. Note we did not rank CL-only EIPs. We also excluded Pureth from the ranking, since it is a meta-EIP and all of its component EIPs are ranked individually.  ## Comments on individual EIPS ### EIP-7610 Revert creation in case of non-empty storage This change removes a corner-case in state processing. It's just about clarifying the semantics in a case that is impossible to occur without a hash collision. ### EIP-7708 ETH transfers emit a log Users have requested this feature ever since the chain launched. Its absence is one of the main reasons why users, especially wallets, regularly have to re-execute transactions to capture call traces. Logs and log indexing is built into the protocol to solve this, so we think it should really be used for transfers as well. The implementation is straightforward and will solve one of the biggest pain points for smart contract wallet developers. ### EIP-7745 Trustless log index This EIP updates makes the in-protocol log indexing useful again, and enables servers to prove the results of filtering. We think this is required because it gives users a way to cross check the filtering results that their RPC provider gives to them. It also combines very nicely with EIP-7708. ### EIP-8024 Backward compatible SWAPN, DUPN, EXCHANGE We are highlighting this EIP because it provides a way to solve the 'stack too deep' issue for compiler authors, while maintaining the ability to use the stack for storing variables. It is also simple to implement. We recognize that compiler authors can opt to using memory for variables, however, it is more expensive to do so, and this will make the cost of local variables nonobvious. We see no issue with clients substantially lifting size constraints on the stack as it is very efficient and priced appropriately. ### EIP-7976 Increase Calldata Floor Cost We think this EIP is very important to reduce the worst-case block size. With recent increases to gas limit, we have increased worst-case block sizes propotionally. This causes much of the original analysis (i.e. [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028) to no longer hold true. The EIP hits the perfect sweet-spot of being easy to implement and having a high impact on scaling. ### EIP-8070 Sparse Blobpool With the advent of PeerDAS, the consensus layer network now has an efficient mechanism to scale blobs with reduced impact to a node's bandwidth. However, the majority of the blobs still go through the public blobpool. This means the blobpool mostly negates the improvements done by the CL. This EIP brings a similar sampling mechanism to the EL blobpool with an expected 4x reduction in average bandwidth consumption. We continue to work actively on this proposal, regardless of its official acceptance in the fork. We included it into S tier for visibility. However, since it is purely a networking change, it is not required to include it into the chain hardfork definition. ### EIP-2926 Code chunking This EIP has three purposes: lifting the maximum code size limit, reducing the size of MPT proofs, and fixing some of the zk prover killers. It rationalizes the resource usage of code execution, by adding fine-grained costs for code access, and only accessing the parts of the code that are effectively used. The stated goal of the glamsterdam fork being scalability and UX improvements, this EIP is an important step in this direction by making witnesses smaller and removing an attack vector on zkvms. ### EVM Repricing Bundle (A-Tier) We don't want to comment on all EVM repricing EIPs individually, just want to note the following: the repricing EIP set is critical to ensure the safety of gas limit increases. We cannot support raising the gas limit of the chain without fixing all the operation mispricings. EVM resource pricing is a balance between various factors like compute, memory, storage and others. Not all repricing EIPs are fully thought out yet, and they may even conflict with each other. The EIPs we selected for the A tier seem least problematic, but they do require further investigation and concrete numbers before we are able to commit to a specific path forward. ### EIP-8053 milligas, EIP-8059 gas units rebase We placed these EIPs in the C tier specifically because we think the additional precision in gas accounting which they offer is not required right now. This means at worst, some opcodes will be priced at 1 gas when their true "harmonized" cost is actually less, say 0.75 gas. We have the ability to indirectly influence this by increasing the gas limit broadly, but it's likely some simple opcodes will continue to be marginally overpriced. We believe the complexity of evaluating the compatibility is very high, and introducing these changes may have big consequences for the user experience, so we would rather focus on them later. ### EIP-7872 Max blob flag We reject this EIP because we feel that client command-line flags should not be proposed in EIPs. ### EIP-7805 FOCIL While we believe an important property of Ethereum is the timeliness of including transactions, regardless of the builder structure, we also find that 1) FOCIL failed to be included under the headliner process and, by the original definition of the process, should not be considered for inclusion now as a normal EIP; and 2) Glamsterdam is already shaping up to be massive upgrade on both EL and CL. We won't comment on the feasibility of FOCIL on the CL, but will note that there is interplay with the EL and if we want to end up with the best possible solution for the cross-layer interactions, we'd like it to be a headliner focus. ### EIP-7923 Linear, Page-Based Memory Costing This EIP is an opinionated modification to support traditional (call) stack and heap organization in memory. The mechanism isn't trivial and, as specified, feels like it introduces a lot of paging machinary that will almost never be used since few contracts use more than ~700 bytes of memory (i.e. the point when memory pricing becomes meaningfully quadratic), let alone the 4096 page size. We would like to see more discussion amoung compilers about the benefit of switching to this type of memory model. ### EIP-7932 & EIP-8030 Alternative signature transaction types While this transaction type does offer clear benefits for L2s, namely in the form of minimizing transaction size since they can avoid the additional secp245k1 signature of typical native transactions when using alternative crypto, the proposal doesn't yet make sense on L1. With the introduction of EIP-7702 and the existing ERC-4337 rails, there is not yet a strong reason why we should forever support altnernative signature schemes for native transactions. We also believe that this work has a very low priority compared to other efforts such as gas repricing. ### EIP-7997 Deterministic Factory Predeploy In the spirit of doing easy EIPs to make user and developer experiences better, we are very supportive of a deterministic factory predeploy. It is one of the oldest requested features in Ethereum and if we have the bandwidth in the fork, we should simply deliver it. ### EIP-8058 Contract Bytecode Deduplication Discount We have seperated this EIP from the other pricing-focused EIPs and placed it in tier C. We did this because we believe it is not trivial to implement successfully and given the current docket of EIPs, it is not the highest priority item to resolve in Glamsterdam.