Ethlabs Hegotá view

EIP-7805: FOCIL is already SFI’d and confirmed as Hegotá’s headliner. Three members of the Ethlabs team (Francesco, Barnabé and Julian) are among its co-authors, and we strongly support its inclusion. Given that the decision is already locked in, we keep this short. Only a chain that is neutral toward everyone can become the root of trust for everyone. This is what lets Ethereum scale to become the true settlement layer for the global economy, and for every single person within it.

Ethereum’s 12-second slot is a latency cost that degrades user value. We therefore strongly recommend including [CL] EIP-8198: Quick Slots [S-tier] in Hegotá, for four reasons:

1. Improved UX on L1 with faster tx confirmation.
2. Onchain markets on L1 run on fresher prices, improving spreads and LP economics.
3. Finality and the fast confirmation rule inherit the slot time, so both get faster with faster blocks, improving interoperability with Ethereum.
4. More block proposers per second means increased censorship-resistance, including economic censorship-resistance: the amount you need to pay to keep blocks empty for some period of time.

Going faster while preserving Ethereum’s unique decentralization makes Ethereum blockspace more valuable, and that value accrues to the network and to ETH. Every decrease is more value immediately delivered to our users. Finally, faster blocks stand as one of the most requested changes from application developers.

The case for starting now is that slot time reduction will never be a one-and-done change. As with scaling, delivered reductions give applications more certainty than roadmap commitments. The road to sub-6-second slots starts with making slot time changeable, then changing it iteratively. EIP-8198 splits the work in two:

• A one-time refactor that makes slot time easier to update in specifications and client code.
• A first decrease in Hegotá, followed by more decreases in subsequent forks, as the roadmap progresses and empirical evidence of safety are obtained.

Hegotá is the right fork to pay the one-time cost. ePBS in Glamsterdam already restructures the slot. Hegotá is then a comparatively light fork for the consensus layer, a window that closes with decoupled consensus in I*, so the CL bandwidth for the one-time refactor is available now in a way it will not be again for several forks.

Meaning: We either commit to staying at 12 seconds for the next two years minimum, or land 10 seconds in ~a year in Hegotá, and possibly less than 10 seconds by the year after. These two decreases are not theoretical improvements. They directly obtain increased user value and improved network economics. We think it is time to get started.

#The most common pushbacks

We discuss here 4 important points that were raised during preliminary discussions with client developers and EF Protocol:

1. Implementation complexity: Millisecond-precision slot timing is already merged into the consensus specs through the ePBS work, and draft CL and EL specs for EIP-8198 exist, with base fee, gas limit and blob schedule rescaled to preserve per-second behavior. The remaining cost is a tail of edge cases in clients and tooling that assume a fixed slot time, plus testing. The one-time refactor frontloads exactly this work. Afterwards each decrease is a parameter change.
2. zkEVM proving: The two main issues are relative proving time and the constant proving overhead.
   1. Relative proving time measures the share of slot time dedicated to proving, and how this share changes when the slot time changes. Here is a short description of the relevant moments in the slot. Current builders observe the release of the previous payload, and can start building immediately. The current beacon block then commits to the current slot’s payload. This payload must be proven before the next beacon proposer’s block release.
      
      For proving, the minimum relative time is a full slot, minus the latency of a beacon block release. The latency of the beacon block release is incompressible, but is short by construction, hence does not fundamentally limit us at this stage. There is also the possibility that optimised builders co-prove the payload while it is being built, allowing them to start proving before the winning payload is committed by the beacon block proposer.
   2. zkEVM proving mostly scales linearly with the block size, except for some fixed overhead. Faster slots mean that the fixed overhead is paid more frequently, which adds more latency for the same amount of throughput. Given fixed budget of latency, one must then ensure that good throughput can still be obtained. Here we see two opportunities: First, engineering progress will continue to drive down the latency of these fixed operations. Second, delaying the state root computation, as described by EIP-7862, moves more of the proving outside of the critical path, meaning that we can increase our latency budget for incompressible operations. The convergence of these two opportunities tell us that faster slots will not hamper ample throughput increases in the future.
3. Post-quantum transition: The decoupled consensus approach has garnered sufficient support to be considered stable as it pertains to future consensus architecture. Decoupling means moving finality voting outside of the critical path of block production. In particular, large scale aggregation of PQ signatures, and all related recursive STARK machinery, will be outside of the critical path. What remains for producing blocks, and obtaining a fork choice rule to track the head of the resulting chain, is a subcommittee currently expected to comprise 512 validators, and possibly 256. Post-quantum signature sizes are larger, but are comfortable to propagate within the proposed slot time of 10s and likely less in the future.
4. Smart contracts and infra: Reliance on the slot time in smart contracts and infra is currently surveyed. For smart contracts, we have partnered with Sourcify to run analysis on all verified contracts. We are studying the impacts of a slot time update to historical beacon block roots, as stored according to EIP-4788: Beacon block root in the EVM. With regards to infra, as anecdata, Etherscan mentioned that a slot time change was likely to lead to more load, but that the infra had been built at the time of variable slot times in Proof-of-Work, hence did not require much changes.

Ethereum and its broader ecosystem are long-due for native AA, which will bring about UX benefits such as passkey wallets, sponsored transactions, ERC20 gas payments, transaction batching, and more.

However, the road to native AA has been particularly bumpy because AA touches every part of the Ethereum stack, including clients, L2s, wallets, RPCs, dev toolings, etc., so it requires buy-in from a huge variety of stakeholders. This makes it hard for any AA EIP to push through Ethereum’s consensus-driven dev process, but also to achieve practical adoption after the EIP is shipped.

We therefore put Hegotá’s native AA proposal, Frame Transactions, into the A-tier, not because it’s not good enough for S technically speaking, but because we want to account for practical adoption risks which will take a massive amount of coordination to resolve. Given our team’s background in AA, Ethlabs intends to play a major role in bringing Frame Transactions to the market, by working with stakeholders such as L2s and wallets to deliver a successful rollout for native AA.

Now onto the specific AA proposals for Hegotá.

#

[EL] EIP-8141: Frame Transactions [A-tier]

Note: since initially publishing Ethlabs’ view EIP-8141 has been SFI. We leave our view unchanged for the record.

We believe that EIP-8141: Frame Transactions is the best candidate for Ethereum’s native AA system. Compared to other native AA proposals, Frames has a number of desirable properties that make it uniquely aligned with Ethereum’s CROPS mandate:

• Permissionless account innovation: the validation logic is handled by EVM code, so developers are free to develop any validation logic they want, as opposed to some other AA approaches that mandate a whitelist of validation logic.
• First-class support for privacy protocols: as a corollary of the first point, a privacy protocol such as Railgun can handle the validation logic of frame transactions, allowing users to send private transactions without relying on any centralized relayers like they do today. This makes privacy protocols significantly more private and uncensorable.
• Post-quantum safety: frame transactions have been developed with Ethereum’s broader PQ roadmap in mind. For example, frame transactions are explicitly designed such that signatures can be aggregated, allowing Ethereum to eventually charge low gas for PQ signatures even though individually each signature can be very expensive to validate.

Frame Transactions’s main weakness also stems from its greatest strength: because validation is handled by EVM code, validation now induces a dynamic cost instead of fixed cost, which can pose challenges for high-TPS chains such as L2s. We are optimistic that this issue can be addressed through further EIPs or ERCs on top of frame transactions such as EIP-7819, where transactions can statically indicate their validation logic so that sequencers can “shortcut” validation with native code if necessary. We also intend to work with L2s and the EF to conduct benchmarks on frame transactions so we can identify and tackle any performance bottlenecks.

#

[CL][EL] Frame Transactions add-ons

There are a number of EIPs that can be seen as extension of Frame txs, building on its capabilities.

• #[EL] EIP-8250: Keyed Nonces for Frame Transactions [A-tier]
  • We think of this EIP as conceptually part of EIP-8141: Frame Transactions, and believe it should be shipped with it.
  • This EIP introduces 2D nonces to Frame transactions. 2D nonces enable accounts to send parallel transactions to the mempool, as well as allow privacy protocols to store nullifiers as 2D nonces. This is important because 2D nonces are special storage that costs very little to read and store, so privacy transactions get to save significantly on gas compared to if they store nullifiers in regular dynamic storage like today. This is especially important in the context of Glamsterdam’s storage repricing (EIP-8037: State Creation Gas Cost Increase).
• #[EL] EIP-8272: Recent Roots for Frame Transactions [A-tier]
  • This EIP enables private transactions without relayers, sent through the public mempool. Privacy protocols validate spends against a recent commitment-tree root, but public mempool validation rules for frame txs do not allow reading application storage (for good DoS protection reasons). EIP-8272 gives applications a contract to publish recent roots and a canonical frame that verifies them before account validation, making private transactions first-class mempool citizens.
  • No consensus surface. The recent roots verification frame has standard behavior in the block, where there’s no restriction on storage reads. Accepting it in the mempool requires extending the Frames mempool rules, which is the main surface of the EIP.
• #[EL] EIP-7906: Transaction Assertions via State Diff Opcode [B-tier].
  • This EIP improves the static auditability of transaction outcomes. Users can already assert what should happen, but not that nothing else happened. Proving the absence of state changes requires a new opcode. Combining positive assertions (e.g. WETH balance increased by at least 1.5) with a negative assertion (no other state changed) lets users bound a transaction's full effects by construction, without simulation, with hardware wallets as one clear beneficiary.
  • Given the complexity, including it in the hard fork would be a very committal choice. We suggest to only make this if (a) client teams really understand the nuances and implications of this specific EIP, and (b) the testing surface and complexities are very well understood.
• #[CL] EIP-8369: VOPS Profiles for FOCIL Eligibility [D-tier]
  • We recommend rejecting. It is unclear what exactly it would mean to include this informational EIP in the fork. Is it a commitment to change the FOCIL EIP with the VOPS-friendly verification rules that this EIP specifies? Does it apply to Hegotá?
  • It addresses the interaction between Frames, FOCIL and possible future VOPS interactions (validity-only partial statelessness, a proposal to let nodes store only enough state to be able to validate transactions, relevant to a future zkEVM world allowing partial statelessness).
  • The overall goal is to allow frame txs to be included in ILs. For now, that would just need some cap on the allowed verification gas (as specified here, though it ultimately belongs in the FOCIL EIP). The remaining question that this EIP concerns itself with is forward-compatibility with stricter verification constraints in the future, as would for example be required with partial statelessness. We think it’s a discussion worth having.

#

[EL] Code dedup and cheaper contract deployment

With native AA likely to land in Hegotá, it's important that the cost of deploying new smart accounts is low, but deploying accounts will actually get more expensive in Glamsterdam due to EIP-8037. These proposals in this space all tackle this, with different mechanisms but the same core idea: letting an account use already-deployed code instead of storing its own copy.

• #[EL] EIP-8298: SETCODEFROM Code Reuse Instruction [A-tier]
  • Our preferred mechanism. The account references existing deployed code through its code hash, and becomes an ordinary smart-contract account. The same primitive serves as one half of a possible EOA-migration story (discussed separately).
  • Doing away with code immutability is a fairly major conceptual change. We should make sure all possible repercussions are clearly identified before the final decision on the EIP.
• #[EL] EIP-7819: SETDELEGATE instruction [D-tier]
  • We recommend rejecting. It lets contracts set a delegation as well. The delegation pointer plays the role of code hash in 8298.
  • After Frames, we see delegation as primarily a tool for EOA migration or to enhance existing EOAs. We don’t think we should bifurcate the account stack between delegated accounts and regular ones.

#

[EL] EOA migration

We want existing EOAs to have a credible path to becoming full smart accounts, including retiring their ECDSA key entirely. This also enables the post-quantum transition. The migration story goes:

1. Delegate to a smart account via EIP-7702 (live today).
2. Remove the EOA's transaction origination, via EIP-7851 (make the delegation permanent) or EIP-8298 (adopt real code and become an ordinary smart account)
3. Make ecrecover aware of the EOA key retirement via EIP-8151, so a retired key can't drain funds through Permit-style flows.

However, this is only one of many approaches to migrate EOAs to smart accounts, and this particular approach has not received wide review or buy-in. In particular, we are worried that this approach doesn’t answer the multi-chain question: how does the same EOA migrate on L2s? The user would have to perform the same action on ALL chains, including chains that don’t yet exist, which will make for bad UX. We suspect that there may be a better approach where L2s can leverage the L1 as the “root of trust” for EOA migration.

• [EL] EIP-8298: SETCODEFROM Code Reuse Instruction [A-tier]
  • Within this migration story, this would be our preferred second step: the migrated EOA ends as a plain code account rather than a permanent delegation pointer.
  • Separately already discussed as a code deduplication EIP, which is mainly what decided the rating.
• #[EL] EIP-8151: Account Code Restricted ecRecover [B-tier]
  • Closes this migration story, pairing naturally with 8298.
  • One specific open question beyond the overall migration story: rejecting retired keys must not make ecrecover more expensive for everyone else. This may need a pure-cryptography ecrecover precompile alongside it.
• #[EL] EIP-7851: Code-Controlled EOA Delegation [D-tier]
  • We recommend rejecting. Superseded by 8298 if implemented: both remove EOA origination, but 7851 freezes the account as a delegation pointer forever.
  • See also the point on 7819 about not bifurcating the account stack

#

[EL] PQ signature scheme [A-tier]

Hegotá should establish a credible path to post-quantum signatures, but we should confirm the right mechanism before committing. Shipping Frames without support for any PQ signature scheme is incomplete.

• #EIP-8355: Add ML-DSA verification precompiles, making post-quantum account security concrete alongside Frame Transactions.
• Alternative: Pre-register PQ support without activating it, or define a derivation format that can accommodate PQ keys later.

Glamsterdam has marked a shift in how Ethereum approaches R&D, with performance treated as a first-class R&D constraint, both in protocol design and in client work. Delayed execution, resource repricings and lots of client optimization work allow for scaling from 30M to (at least) 200M over the last two years. In general, performance work gives us optionality: the headroom we gain can be used for scaling, to shorten slots, to lower node requirements, or all of the above.

Taken together, the following EIPs, as well as the already discussed EIP-8198: Quick Slots, continue Glamsterdam’s scaling momentum and kickstart that of a faster Ethereum, while reinforcing a broader principle: performance should remain a first-class concern in both client work and protocol design. In particular, we start by shouting out a handful of high-impact EIPs for L1 scaling and faster Ethereum.

#

Continued L1 scaling

Today, we still see continued scaling as a necessity. Applications decide where to build based not only on current prices, but on whether Ethereum can expand blockspace supply predictably over time. Consistently delivering increases provides more certainty than roadmap commitments alone. Mainnet capacity is also still quite far from being able to handle demand spikes: on Ethereum’s eleventh birthday, the daily median base fee was only ~0.1 gwei, yet an NFT mint pushed it above 10 gwei for some time, with median transaction costs reaching about $1 and the 90th percentile more than $5. Glamsterdam’s scaling push should therefore continue into Hegotá.

#

[EL] EIP-8131 & EIP-8279 [S-tier]: Data repricing bundle

After Glamsterdam, the next binding constraint is payload propagation, partly because different sources of payload bytes are reflected inconsistently, or not at all, in gas accounting. EIP-8131: Unified Transaction Content Floor extends the existing transaction floor to content known before execution, while EIP-8279: Block Access List Byte Floor covers BAL bytes created dynamically during execution.

This dynamic metering makes EIP-8279 the clearly more complex of the two. However, we suggest thinking of them as a bundle. Together, they establish consistent accounting for the bytes associated with a transaction, bounding the worst-case payload while leaving most ordinary, non-data-heavy transactions unaffected. This fixes the underlying resource-accounting gap and clears the way for further gas-limit increases.

#

Faster Ethereum

The scaling push is well under way after Glamsterdam, while faster Ethereum is just getting off the ground. It rests on two pillars: faster slots and faster finality. Quick Slots (EIP-8198) is the main item of faster Ethereum, and we have discussed it in its own section above because of how important we think it is to get started with it now. Faster finality is the second pillar, which will hopefully be the target of the I* fork with decoupled consensus. However, time to finality is ultimately bounded by the performance of attestation propagation, which is also a constraint on the slot time. The item below targets precisely that, setting the stage for improvements in both.

#

[CL] EIP-8334: Bundled Attestation Propagation [A-tier]

Attestation propagation is one of the most valuable things the CL can optimize: it affects both the slot time and the finality time. Plain Gossipsub is not built for this kind of highly structured gossip, with thousands of messages per slot that share most of their data and are batch-verifiable. EIP-8334 is a backwards compatible (negotiated per peer) change that takes advantage of that structure by building on the Gossipsub partial-messages extension machinery of EIP-8136: attestations travel in bundles that state the shared data once and are reconciled by validator index, with simulations showing around 50% bandwidth savings and up to 30% lower latency. We rank it A, pending further validation of its impact.

#

Other related EIPs

• [EL] CPSB Recalibration [A-tier]
  • Very simple changes, we recommend keeping them in the pipeline and including one of the two if deemed necessary based on planned gas limit increases and observed usage of state and execution gas.
  • #EIP-8368: CPSB Recalibration for New Gas Limit
    • Pre-planned follow up to EIP-8037, compensating for the fact that the cost per state byte (CSPB) has been made static rather than a function of gas limit, purely as an implementation and testing simplification. Idea was to replace the block-by-block adjustment with one-time adjustments at forks, as needed to keep state growth on target as the gas limit increases. Since the current CPSB was calibrated on a 150M gas limit, it’s likely that an adjustment in Hegotá will be warranted.
  • #EIP-8372: Normalized state gas limit
    • Still fairly minimal superset of EIP-8368, allowing for a more fine-grained adjustment than just the CPSB, compensating for either the state growth target or the regular gas target being undershot due to relative mispricing.
• #[CL][EL] EIP-8146: Block Access List Sidecars [B-tier]
  • EIP-8146 complements the repricings by improving the critical path itself, by propagating BALs separately from the payload, which improves propagation, and gives execution clients a head start on state prefetching and post-state-root computation.
  • It’s generally a good pattern to not bundle messages, and a familiar one (much work went into splitting blobs into subnets even pre-DAS). The networking improvement from split propagation could be superseded by adoption of chunked payload propagation in the future however, which would reduce the benefits to the execution side. The impact there needs more analysis.
  • The implementation work is mainly familiar CL gossip machinery. In a fork that is shaping up to be quite EL-heavy, it might be sensible to dedicate some resources to it if impact is confirmed.
• #[EL] EIP-7862: Delayed State Root [D-tier]
  • We recommend rejecting. EIP is simple to spec, but complexity of client implementations is not very well understood as far as we are aware. The state root is pervasive in codebases.
  • While there is some benefit in lowering the barrier of access to competitive building (fast state root computation), the main benefit of the EIP in our view is as a zkEVM precursor (more time to prove the state root computation). As we discuss later, we do not think this should be a focus of Hegotá.
• #[CL] EIP-8341: Partial Execution Payload Commitments [D-tier]
  • We recommend rejecting. Small benefit (slightly delay the state root computation), not urgent, and superseded by EIP-7862: Delayed State Root. While we recommend rejecting both for Hegotá, we think we should consider doing EIP-7862 in the future.

Staking improvements can be valuable, but user-facing benefits should take priority over infrastructure-only changes, unless strictly necessary.

• #[CL] EIP-8015: Remove deposit and eth1data fields [A-tier]
  • Very simple cleanup of technical debt. Thanks to EIP-7688: Forward compatible consensus data structures, Merkle proofs of unrelated fields are unaffected, so no impact on chain consumers.
• #[EL][CL] EIP-8237: Independent CL/EL Sync [B-tier]
  • Builds on the separation of beacon block and payload introduced by ePBS, to let the EL and CL sync independently. We think this has the potential to simplify a complex part of Ethereum clients.
• #[CL] EIP-8205: Withdrawal credentials preregistration [D-tier]
  • We recommend rejecting. While the EIP provides an in-protocol solution for a real problem in delegated staking, we think that the existing pre-deposit solution is adequate and the complexity of the added machinery is not currently justified.
• #[CL] EIP-8148: Custom sweep threshold for validators [D-tier]
  • We recommend rejecting. We think the EIP is too complex (new system contract, new execution request, CL machinery) for its benefits, which we see as primarily encouraging some marginal additional consolidation from the home operator pool. We don’t think this will have much of an effect on overall validator consolidation given how stake is distributed.
• #[CL] EIP-8375: ePBS Mandatory Burn of Execution Rewards [D-tier]
  • We recommend rejecting. We think this will likely just lead to more side-channeling. Moreover, years of discussions on MEV burn strategies did not lead to any proposal that reached broad research consensus.
• #[CL] EIP-7716: Anti-correlation attestation penalties [D-tier]
  • We recommend rejecting. We don’t think there’s enough clear evidence that such a fairly large change in the staking incentives is warranted. Moreover, staking incentives will likely be reworked as part of decoupled consensus.
• #[CL] EIP-8333: Align Checkpoint with Epoch Boundary Block [D-tier]
  • We recommend rejecting. While a nice cleanup, we think it’s worth deferring it to the large upcoming decoupled consensus transition.
• #[CL] EIP-8359: Beacon Block Reporting Field [D-tier]
  • We recommend rejecting because very low priority, though not a strong opinion.

Most zkEVM preparation offers limited near-term benefits beyond making full-node operation easier for a narrow set of users, while consuming implementation bandwidth and potentially making the EVM more expensive. We should include only changes whose long-term value clearly justifies those immediate costs.

• [EL] EIP-8200: EVMification [D-tier]
  • We recommend rejecting. This EIP replaces four precompiles with equivalent EVM bytecode, both a protocol cleanup (removing consensus critical bug surface) and useful for zkEVMs. Though some of this migration is straightforward (especially the identity precompile), we find it overall premature for Hegotá. See the EF’s assessment as well.
  • #EIP-7666: EVM-ify the identity precompile
  • #EIP-8200: EVMification
    • Two precompiles see little use and appear straightforward to migrate. The third is widely used in SNARK verification, so impact assessment should be done before supporting its removal.
• #[CL] EIP-8025: Optional Execution Proofs [D-tier]
  • We recommend rejecting this EIP. It does not require a hard fork. The proposal to bundle it with Hegotá is purely an expression of prioritization, and we disagree with that choice. We think work should continue on it, but Hegotá should not be blocked on it.
  • Before shipping optional proofs we should work towards defining the end state first, then accelerate towards that, rather than shipping optional proofs before a clear view of the long-term validator/state model.
  • The core open question is what role validators should have with respect to state: whether they should keep serving or holding some of it, rather than becoming fully stateless. Because validators are a core node cohort with real hardware and network value, changes that weaken that role should clear a higher bar.
• #[EL] EIP-7709: Read BLOCKHASH from Storage and Update Cost [D-tier]
  • We recommend rejecting the EIP. It is quite disruptive due to the very large gas cost increase, and not urgent.
  • Derisking it could involve an impact analysis, or doing it later with some form of block level warming (or ad-hoc warming of these values) to reduce impact.

Hegotá will still require some ad hoc EVM decisions. We believe that after Hegotá Ethereum should work towards a long-term EVM roadmap shaped by the broader EVM ecosystem. Ethlabs will contribute to that.

• #[EL] EIP-5920: PAY opcode [A-tier]
  • Very simple, and we think it’s a good primitive for the EVM to have
  • Would be important to understand concrete use cases better
• #[EL] EIP-8163: Reserve EXTENSION (0xae) opcode [A-tier]
  • Very useful for L2s, no real cost for L1 (just informational)
• #[EL] EIP-8253: Bump nonce of zero-nonce storage accounts [A-tier]
  • Simple cleanup, small benefit for all future contract deployments
• #[EL] EIP-7923: Linear, Page-Based Memory Costing [B-tier]
  • We need decide whether we at all want to do memory reform in Hegotá. It’s not clear to us that we currently have a sufficient understanding of the design space to make this assessment
• #[EL] EIP-8219: Checked Arithmetic Opcodes [B-tier]
  • Overall adding safe math to the EVM seems useful.
  • Pricing would need to be confirmed with benchmarks. How complex is that?
  • With benchmarks and an impact analysis (how many txs could benefit, how much, which compilers would add support?) it could be [A-tier].
• #[EL] EIP-8360: TCREATE Opcode [B-tier]
  • The EIP introduces the ability to create transaction-scoped temporary contracts. This is a nice primitive to have in general.
  • EIP adds significant complexity. With a more thorough implementation & testing complexity assessment, it could be [A-tier].
• #[EL] EIP-4758: Deactivate SELFDESTRUCT [B-tier]
  • Plausible cleanup, though not a priority.
• #[EL] EIP-7645: Alias ORIGIN to SENDER [D-tier]
  • We recommend rejecting. Breaking change, improper use of ORIGIN.
• #[EL] EIP-8182: Private ETH and ERC-20 Transfers [D-tier]
  • We recommend rejecting. Huge change, adds zk dependencies. If ever introduced, we think it should be a headliner.
• #[EL] EIP-2488: Deprecate the CALLCODE opcode [D-tier]
  • We recommend rejecting. Complexities not explored, doesn’t seem to have a champion
• [EL] EVM Subroutines [B-tier]
  • In discussion for several hard forks, generally sensible:
  • #[EL] EIP-7979: Call and Return Opcodes for the EVM [B-tier]
  • #[EL] EIP-8173: Foundations of EVM Control Flow [D-tier]
    • We recommend rejecting this EIP just because as a meta EIP it should not itself be CFIed.

Glamsterdam raised prices for underpriced operations that constrained overall throughput. Hegotá’s EVM-pricing proposals mostly address the other side: lowering prices for individual operations whose current cost limits their use, but not network scalability. These are therefore nice-to-haves with lower per-EIP impact. We are open to targeted repricing, but proposals that introduce new metering mechanisms should be included only if their design is sound and sufficiently de-risked by a committed champion.

• #[EL] EIP-3298: Removal of refunds [A-tier]
  • Very large simplification of a tricky area of the EVM, as evidenced by the experience with EIP-8037. Removing them could greatly simplify future changes.
  • Refunds are of limited utility given the 1/5 cap, so user impact is low.
  • EIP-8037 introduced net accounting for storage slots within a single tx: slots that are created and cleared in the same transaction are not charged. Only clearing of storage created in previous txs is impacted.
  • Refunds are very clearly not a long term answer to state management (or at all effective as a state management tool).
• #[EL] EIP-8358: Net Gas Metering for Account Changes [B-tier]
  • Not convinced of the impact. In 900 sampled mainnet blocks, ~400k txs: 2.07% of all transactions would save gas & 1.14% of block gas would be saved
• #[EL] EIP-8374: Persist Warm Access Sets Across Reverts [B-tier]
  • The impact appears limited: as per Maria’s analysis only 0.9% of call frames revert.
• #[EL] EIP-8115: Batch priority fees at end of block [D-tier]
  • We recommend rejecting, disagreeing with the motivations stated in the EIP:
    • parallelization concerns as stated don’t apply post BALs
    • mempool concerns not plausible, such transactions are simply rejected
    • accounting complexities not clearly motivated
    • ETH log cost: interesting argument, but doesn’t really expand on what should logically be the correct behavior here
• #[EL] EIP-8188: Last-Written Block for Accounts and Slots [D-tier]
  • We recommend rejecting, referring to the EF State team’s opinion.

• #[EL] EIP-7668: Remove bloom filters [B-tier]
  • It’s reasonable, but low priority.
• #[EL] EIP-8116: Replace cumulative receipt fields [B-tier]
  • It would require user validation, but generally reasonable.
• #[EL] EIP-7807: SSZ execution blocks [D-tier]
  • We recommend rejecting. Nice cleanup, not urgent, high complexity.
• #[EL] EIP-8304: Trustless log and transaction index [D-tier]
  • We recommend rejecting. Sensible feature in principle, but very unclear impact and significant complexity.

Ethereum’s P2P layer has room for targeted improvements, especially in how transactions, blobs, and attestations are propagated across the network.

• #[EL] EIP-8077: eth/XX - announce transactions with nonce [A-tier]
  • Reasonable: announcing sender and nonce lets nodes fetch selectively and fill nonce gaps instead of guessing, for a modest bump in announcement size and no hard fork.
• #[CL] EIP-8371: RowDAS - Distributed Blob Reconstruction [B-tier]
  • Prevents full reconstruction and full custody node performance as a bottleneck towards scaling blob count.
  • Valuable, eventually some form of distributed reconstruction should definitely make its way in the protocol, removing the dependency on full custody nodes and possibly removing validator custody.
  • On the other hand, we are very far from full custody nodes being prohibitively expensive to run, and the network only needs a handful to ensure reconstruction. If validator custody is a concern (too high of a load on nodes with 100s of validators), we can much more easily deal with that in the short term by increasing BALANCE_PER_ADDITIONAL_CUSTODY_GROUP which does not need a fork or even coordination (just uncoordinated client releases). See this draft EIP.
  • Complexity is quite high.
• #[EL] EIP-8094: eth/vhash - Blob-Aware Mempool [B-tier]
  • Addresses blob txs by versioned-hash in the mempool instead of transaction hash, allowing fee replacement (RBF) to be done without re-broadcasting the blobs themselves.
  • RBF has been a real problem for blobs, especially in times of congestion, in some situations preventing L2s from getting timely inclusion even while willing to pay for it. The root cause is that blob RBF is heavy for the network: a replacement re-broadcasts the full blob content, which is why clients demand a 2x fee bump for it. That punitive rule is in turn why batch posters bid near-zero tips and replace slowly, most recently on September 4, when Robinhood Chain's and Arbitrum One's blobs stopped landing for ~14 minutes during the L1 fee spike.
  • Underspecified, especially the interaction with EIP-8070, which restructures the same mempool messages at cell granularity and is already included in Glamsterdam. If that is resolved convincingly, we think this EIP should strongly be considered for Hegotá.
• #[CL] EIP-8383: Reduce CL Block Retention Window [B-tier]
  • Reduces the minimum block-serving window from 33,024 epochs (~146 days) to 8,192 (~36 days).
  • We are not opposed to reconsidering this window, and the complexity is low. Mainly blocked on two things: a convincing rationale for the specific period, and spelling out all relevant CL <> EL interactions.
  • Retention and serving of unfinalized blocks during non-finality should be MUST.
• #[CL] EIP-8142: Block-in-Blobs (BiB) [D-tier]
  • We recommend rejecting. Premature, no strong urgency, quite last minute, lots of questions left (KZG or not? New gossip topics or not?).
  • Don’t want to introduce KZG into the critical path of block production
  • Simpler alternatives are currently being proposed, though outside of the regular process.
• #[CL] EIP-8243: Batching Attestations at Source [D-tier]
  • We recommend rejecting. Unclear whether we can rely on this to decrease time-to-finality, doesn’t put a clear bound on the load.
  • DoS-resistance of the mechanism not fully clear.