# RIG's view on Glamsterdam *This document is authored by members of the Robust Incentives Group: [Anders Elowsson](https://x.com/weboftrees), [Caspar Schwarz-Schilling](https://x.com/casparschwa), [Julian Ma](https://x.com/julian_ma), [Maria Silva](https://x.com/misilva73), [Marios Ioannou](https://x.com/qedem0nstrandum), and [Thomas Thiery](https://x.com/soispoke).* In this document we outline the [Robust Incentives Group](https://rig.ethereum.org/)'s view on EIP prioritization for Glamsterdam. RIG has (co-)authored many of the EIPs proposed for Glamsterdam: leading with FOCIL & most of the smaller EIPs on the consensus layer (CL), and repricing effort (18 EIPs) & sparse blobpool EIP on the execution layer (EL). Please note that we only take a view on EIPs we can offer domain expertise in: * on the CL side we consider all proposed EIPs * on the EL side we "only" consider *Repricings* and the sparse blobpool EIP. To minimize the decision tree we map all EIPs into only three tiers with the following interpretations: * <font color="green">**[S-tier]**</font>: definitely include * <font color="orange">**[B-tier]**</font>: only include if capacity * <font color="red">**[D-tier]**</font>: decline for inclusion We have meaningfully less confidence that B-tier EIPs can still reasonably "fit into" Glamsterdam and wish to signal this by skipping the A-tier altogether. ## Glamsterdam high-level priorities For Glamsterdam, ACD for the first time adopted a new process by choosing headliner(s) to pick a fork theme. Both headliners, EIP-7732 (ePBS) on the CL and EIP-7928 (BALs) on the EL, were chosen for their ability to scale Ethereum L1. We argue to double down on Glamsterdam's L1 scaling theme and think that the bar for EIPs not focused on L1 scaling should be even higher: (1) extremely important, and/or (2) extremely simple. * On the EL side we think [*Repricings* are a silent hero for Glamsterdam](https://notes.ethereum.org/@ansgar/repricings-for-glamsterdam): They (1) meaningfully scale Ethereum L1, and (2) unlock the full scaling potential of both headliner EIPs. * On the CL side we argue for FOCIL as extremely important and a few simple wins that we consider important steps towards faster finality — a priority for Ethereum going forward in our view. ## Ranking tl;dr *Please remember that we only consider Repricings and sparse blobpool on the EL.* ![](https://notes.ethereum.org/_uploads/H1gdoLSzeWx.png) --- ## CL * <font color="green">**[S-tier]**</font> * EIP-7805: FOCIL * EIP-8062: Add sweep withdrawal fee for 0x01 validators * <font color="orange">**[B-tier]**</font> * EIP-8061: Increase churn limits * EIP-8045: Exclude slashed validators * EIP-8071: Prevent using consolidations as withdrawals * <font color="red">**[D-tier]**</font> * EIP-8068: Neutral effective balance design * EIP-7688: Forward compatible consensus data structures --- #### <font color="green">**[S-tier]**</font> [EIP-7805: FOCIL](https://eips.ethereum.org/EIPS/eip-7805) * FOCIL guarantees the fast inclusion of all transaction, a core value of Ethereum. * Correctly prioritizing FOCIL is difficult and Caspar attempts to steelman both sides of the argument in [this document](https://notes.ethereum.org/IMgvFD7MSTa4GGwnlZ0A5g). In short, there’s the concern about Glamsterdam’s timelines and fork complexity on one side, and the risk of shipping FOCIL becoming more controversial over time on the other. It’s inherently hard to reason about this tail risk and ultimately an especially subjective assessment. * We suggest erring on the side of caution: It is critical for Ethereum to be able to *guarantee* the fast inclusion of transactions, and thus advocate for including FOCIL in Glamsterdam. #### <font color="green">**[S-tier]**</font> [EIP-8062: Add sweep withdrawal fee for 0x01 validators](https://eips.ethereum.org/EIPS/eip-8062) & <font color="red">**[D-tier]**</font> [EIP-8068: Neutral effective balance design](https://eips.ethereum.org/EIPS/eip-8068) * Ethereum needs to offer faster finality to its users. Fast finality protocols can only handle smaller validator sets (in the order of [10,000 nodes](https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989)). Today Ethereum still has ~1M validators and existing validators are only [slowly consolidating](https://pectrified.com/mainnet). * EIP-8062 and EIP-8068 address this by putting accumulating `0x02` validators on equal footing with distributing `0x01` validators. EIP-8062 ensures that `0x01` validators pay for the additional resources they consume. EIP-8068 ensures that `0x02` validators earns equal yield as `0x01` validators. Accumulating `0x02` validators currently earn lower yield, due to a non-neutral rounding of the effective balance. * If both EIPs are included, EIP-8062 can be implemented with the proposed fee setting. However, EIP-8068 is more complex to implement than EIP-8062. We therefore suggest a possible compromise: * Implement only EIP-8062 (simple!), but set the fee substantially higher to compensate also for the higher yield of `0x01` validators, which would have been corrected by EIP-8068. * Given the importance of fast finality but slow consolidations, and the existing tradeoff between complexity and effectiveness between both EIPs, we suggest EIP-8062 for S-tier with a higher fee accordingly (and decline EIP-8068 for inclusion). #### <font color="orange">**[B-tier]**</font> [EIP-8045: Exclude slashed validators](https://eips.ethereum.org/EIPS/eip-8045) * Goal: Avoid chain degradation (missed slots) in mass-slashing events. * EIP-8045 prevents slashed validators from being selected as block proposers, avoiding many missed slots in mass-slashing events. This can be considered cleaning up "tech debt" and is a simple one-line change. Even old tests should be fine + adding one to check slashed vals are actually not selected to propose. * We think that avoiding chain degradation in a mass slashing event is worth it given how simple of a change EIP-8045 is. #### <font color="orange">**[B-tier]**</font> [EIP-8061: Increase churn limits](https://eips.ethereum.org/EIPS/eip-8061) * Goal: Making faster finality possible sooner by increasing validator consolidation throughput (it would currently take ~1.3y to consolidate all 0x01 validators). It also improves the staking experience by reducing validator exit queue times (better liquidity). * EIP-8061 increases the validator exit and consolidation churn limits, but leaves the deposit churn unchanged maintaining the spirit of status quo, namely [EIP-7514](https://eips.ethereum.org/EIPS/eip-7514). This is reflected in an [update](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8061.md) of the EIP. * Considerations: The consolidation churn limit is currently not the bottleneck for consolidations but with the right incentives (EIP-8062) and big staking pools still planning migration to 0x02 credentials this EIP makes sure faster finality is not constrained by this. #### <font color="red">**[D-tier]**</font> [EIP-7688: Forward compatible consensus data structures](https://eips.ethereum.org/EIPS/eip-7688) * While useful to reason about consensus in smart contracts, e.g., staking pools, we consider this EIP to be a "nice-to-have" but not a priority right now. ## EL * <font color="green">**[S-tier]**</font> * ["Minimal Repricing Bundle"](https://notes.ethereum.org/@misilva/SkkvIsxk-g#Minimal-Repricing-Bundle) * EIP-7904: General Repricing. * EIP-8038: State-access gas cost update. * EIP-2780: Reduce intrinsic transaction gas. * EIP-7981: Increase access list cost. * EIP-7976: Increase Calldata Floor Cost. * EIP-8037: State Creation Gas Cost Increase. * Two EIPs from the ["Recommended Repricing Additions"](https://notes.ethereum.org/@misilva/SkkvIsxk-g#Recommended-Additions): * EIP-7778: Block Gas Accounting without Refunds. * EIP-8032: Size-Based Storage Gas Pricing. * <font color="orange">**[B-tier]**</font> * EIP-8070: sparse blobpool [note: not strictly necessary to be rolled out with hardfork) * EIP-8053: Milli-gas for High-precision Gas Metering * EIP-7971: Hard Limits for Transient Storage. * EIP-8058: Contract Bytecode Deduplication Discount. * EIP-7973: Warm Account Write Metering. * <font color="red">**[D-tier]**</font> * EIP-7923: Linear, Page-Based Memory Costing OR EIP-7686: Linear EVM memory limits. * EIP-8011: Multidimensional Gas Metering. * EIP-8057: Inter-Block Temporal Locality Gas Discounts. * EIP-8059: Gas Units Rebase for High-precision Metering. --- #### <font color="orange">**[B-tier]**</font> [EIP-8070: Sparse Blobpool](https://eips.ethereum.org/EIPS/eip-8070) * Goal: Unlock higher blob throughput, a key strategic priority for Ethereum. * Without EIP-8070, Ethereum’s blob propagation remains fully replicated across all nodes, making higher blob targets infeasible due to bandwidth limits. Conceptually, this EIP completes Fusaka: sparse blobpools shards the EL, in the same way that PeerDAS shards the CL. * Although there are some questions to address, we believe the sparse blobpool [can be made DoS resistant](https://hackmd.io/@gMH0wL_0Sr69C7I7inO8MQ/rk3TSjgJbe). * This EIP does not strictly need to activate with a hardfork. However, throughput gains are constrained until *all* clients have implemented this EIP, or else low-bandwidth nodes running a client without sparse blobpools will be dropped. * We believe this EIP is critical for Ethereum's blob scaling ambitions but recognize it can be shipped inbetween hardforks. We still want to anchor it in discussions today to give it the attention it deserves. We want to avoid it only getting scoped for Heka — by which point Ethereum will have already been unable to scale blobs further due to bandwidth constraints. ### Repricing EIPs Our selection is based on the breakdown from the [Gas Repricings for Glamsterdam](https://notes.ethereum.org/@misilva/SkkvIsxk-g) document by Maria. #### <font color="green">**[S-tier]**</font> [The Minimal Repricing Bundle](https://notes.ethereum.org/@misilva/SkkvIsxk-g#Minimal-Repricing-Bundle): [EIP-7904](https://eips.ethereum.org/EIPS/eip-7904), [EIP-8038](https://eips.ethereum.org/EIPS/eip-8038), [EIP-2780](https://eips.ethereum.org/EIPS/eip-2780), [EIP-7981](https://eips.ethereum.org/EIPS/eip-7981), [EIP-7976](https://eips.ethereum.org/EIPS/eip-7976), [EIP-8037](https://eips.ethereum.org/EIPS/eip-8037) - It includes a broad repricing of compute and state operations, aligns the cost of ETH transfers with the relevant compute and state operations, and updates data costs. - It is the smallest set of EIPs that allow us to harmonise the key burst resources (compute, state I/O, and data) while mitigating state growth under higher gas limits. - It also allows us to correctly price the gains obtained from ePBS and BALs. - The numbers and exact scope for these EIPs is not final. Once we collect the data from the current opcode benchmarks, we can assess which operations result in the biggest gains in throughput and bottleneck elimination and focus on those. However, we expect the need to touch all these resources, even if we focus on a subset of operations. #### <font color="green">**[S-tier]**</font> [EIP-7778: Block Gas Accounting without Refunds](https://eips.ethereum.org/EIPS/eip-7778). - This proposal excluded refunds from block accounting, thus mitigating the worst-case block from state access operations. - This is a simple change that tackles a concrete bottleneck. #### <font color="green">**[S-tier]**</font> [EIP-8032: Size-Based Storage Gas Pricing](https://eips.ethereum.org/EIPS/eip-8032). - This proposal scales the cost of `SSTORE` with the contract’s storage size, allowing smaller contracts to write to their storage more cheaply while addressing the state access bottleneck in large contracts. - With this EIP, we can lower costs for state access and state growth for the majority of users, while penalizing contracts that are putting the most pressure on state resources at the moment. - This EIP changes to the state trie and introduces a transition period to backfill it, which requires additional testing and preparation. However, RIG is not in a position to clearly assess the level of fork complexity such a change would bring. We still rank this EIP highest based on its effectiveness in pricing away a significant bottleneck while mitigating its impact on normal users, leaving more detailed complexity considerations to coredevs. #### <font color="orange">**[B-tier]**</font> [EIP-8053: Milli-gas for High-precision Gas Metering](https://eips.ethereum.org/EIPS/eip-8053): * This proposal removes rounding errors from efficient compute operations, which occupy on average 4% of block space per transaction. However, it adds the complexity of a new gas counter plus transaction-level rounding, which requires additional testing. * It is a still good addition, but can be done in another fork if scope is a concern. #### <font color="orange">**[B-tier]**</font> [EIP-7971: Hard Limits for Transient Storage](https://eips.ethereum.org/EIPS/eip-7971). * This proposal decreases the costs of TLOAD and TSTORE and adds a limit to available storage slots, thus improving the usability of transient storage. It also requires the addition of a new transaction-level counter to track the number of transient storage slots used, which adds some complexity. * Pushing more users to leverage transient storage will ease the burden on state access, which is a positive change EVM for resource management. However, this improvement could be postponed if fork scope is a concern. * [Reply form Charkes](https://ethereum-magicians.org/t/eip-7971-hard-limit-and-cost-reduction-for-transient-storage-allocation/24542/4?u=charles-cooper) to the concern with an attack leveraging Account Abstraction. #### <font color="orange">**[B-tier]**</font> [EIP-8058: Contract Bytecode Deduplication Discount](https://eips.ethereum.org/EIPS/eip-8058). * This proposal reduces the cost of deploying duplicated contracts, thus lowering the cost of popular contract deployments such as Uniswap pools. * Even though being a good addition that better aligns contract deployment costs with the actual resource consumption, we think it can be postponed if fork scope is a concern. #### <font color="orange">**[B-tier]**</font> [EIP-7973: Warm Account Write Metering](https://eips.ethereum.org/EIPS/eip-7973). * This proposal introduces a discount to account writes to warm accounts (i.e., accounts that were previously updated in the same transaction), thus making multiple writes to the same account cheaper. While this repricing does tackle a mispriced operation, it introduces the complexity of tracking whether the account was previously changed in any account write operation. * Similarly to other EIPs on this list, in spite of being a good addition that improves EVM gas pricing, we believe it can be postponed if fork scope is a concern. #### <font color="red">**[D-tier]**</font> [EIP-7923: Linear, Page-Based Memory Costing](https://eips.ethereum.org/EIPS/eip-7923) OR [EIP-7686: Linear EVM memory limits](https://eips.ethereum.org/EIPS/eip-7686). * Based on out current knowledge, we will not need to update memory costs in this fork. #### <font color="red">**[D-tier]**</font> [EIP-8011: Multidimensional Gas Metering](https://eips.ethereum.org/EIPS/eip-8011). * This new gas accounting enables more throughput and better control of excessive resource usage, with minimal changes to the UX. However, it does introduce complexity to the EVM by changing how gas is tracked and limits are enforced. * Even though we believe it is a positive addition to the EVM, given the number of changes to the gas model we need in this fork, we sugest to move this proposal to a future fork. #### <font color="red">**[D-tier]**</font> [EIP-8057: Inter-Block Temporal Locality Gas Discounts](https://eips.ethereum.org/EIPS/eip-8057). * This is a more recent proposal that does not seem quite ready. More analysis and thought is needed. #### <font color="red">**[D-tier]**</font> [EIP-8059: Gas Units Rebase for High-precision Metering](https://eips.ethereum.org/EIPS/eip-8059). * In our opinion, if we want to address rounding erros in a fork, EIP-8053 is a better approach. Such a rebase could be done in practive over a longer period of time, as we increase the gas limit slowly over the years instead of abruptly in a single fork.
Last changed by  
 
Caspar Schwarz-Schilling
246

Read more

FOCIL Prioritization

EIP-7805: FOCIL guarantees fast inclusion of transactions. This is achieved by moving the decision of which transactions to include in a block from a single block builder to a wide set of attesters. FOCIL can be thought of as a mempool attestation gadget, ensuring that a block builder cannot arbitrarily deviate from the global view of existing transactions. At a high level FOCIL democratizes transaction inclusion by moving the decision from a single actor to a decentralized set of attesters. This document does not argue about the merits of FOCIL itself and assumes as given that FOCIL ought to be shipped. It focuses on considerations of when to include it on mainnet. With headliners locked in and implementations well underway, ACD is shifting its focus to choosing non-headliner EIPs to include in Glamsterdam. There are good reasons to include FOCIL in Glamsterdam and also good reasons to postpone its inclusion until later forks, e.g. H*-fork. Jumping ahead briefly, the main tradeoff is between cumulative complexity and Glamsterdam delays on the one side, and the tail-risk of FOCIL never shipping on the other. The following is an exercise to steelman both sides. The for & against of FOCIL in Glamsterdam There are several key dimensions to reason about when deciding when to include FOCIL: (1) Shipping environment, (2) Hardfork timelines, (3) Hardfork complexity, and (4) Short-term value of FOCIL. Please note that at this moment in time FOCIL is the best mechanism available to achieve guaranteed fast tx inclusion. This can change over time. And so some arguments are less about the FOCIL mechanism specifically and should rather be interpreted as arguments for any mechanism able to guarantee fast tx inclusion.

11/6/2025
Electra: Issuance Curve Adjustment Proposal

by Caspar and Ansgar In this document we argue for a change of the issuance curve in the upcoming network upgrade Electra. For a more detailed account of the current issuance policy, its drawbacks as we see them, and an endgame vision for staking economics, read our writing on stake participation targeting. Many thanks to Anders, Barnabé, Francesco, Mike, and Dom for feedback and discussion. Reviews $\neq$ endorsements. This post expresses opinions of the authors, which may not be shared by reviewers.

2/22/2024
Endgame Staking Economics: A Case for Targeting

by Caspar and Ansgar. This post explores the status quo of staking economics, its drawbacks as we see them and what the endgame of staking economics could look like. Read about our separate proposal for an immediate issuance policy update in Electra here. Many thanks to Anders, Barnabé, Francesco, Julian, Dankrad, Thomas, Vitalik, Mike, Justin, Jon, Nixo, and Sam for feedback and discussions. Reviews $\neq$ endorsements. This post expresses opinions of the authors, which may not be shared by reviewers.

2/21/2024
(Un-) Timeliness in PoS Ethereum

Background info A slot is 12 seconds long. The proposer is supposed to release their block at the beginning of it. The spec forsees the following schedule within a slot for an honest validator that is selected to attest: A validator should create and broadcast the attestation to the associated attestation subnet when either (a) the validator has received a valid block from the expected block proposer for the assigned slot or (b) 1 / 3 of the slot has transpired (4s into the slot) -- whichever comes first. Further, If the validator is selected to aggregate, then they broadcast their best aggregate as a SignedAggregateAndProof to the global aggregate channel 2 / 3 of the way through the slot-that is, 8 seconds after the start of slot.

9/19/2022
Read more from Caspar Schwarz-Schilling
Published on HackMD