Inside Ethereum Upgrades: Hegotá

What Ethlabs is prioritizing for Hegotá and why.

Ethereum’s direction matters to everyone who builds on it, uses it, holds ETH, or simply believes in what it can become. While that future will ultimately be determined by the people, applications and communities building on Ethereum every day, network upgrades are one of the primary ways the protocol evolves to meet their needs. Hegotá is the next planned Ethereum network upgrade after Glamsterdam, and this document shares Ethlabs’ view on what we believe Ethereum should prioritize for it, and why.

Ethlabs is an 8-week old non-profit R&D lab for Ethereum and ETH and our mission is to make Ethereum the settlement layer of the global economy. We sit between real-world Ethereum usage and protocol development, and we spend our time listening to users, wallets, applications, rollups, institutions, ETH holders, researchers, and client teams. Sometimes we even build onchain, because you cannot build an arena without participating in it! We believe that great protocol engineering should make great products possible, and great products should help to inform where the protocol goes next.

Hegotá’s scope is currently in the early stages of being shaped through Ethereum’s open technical process, and the proposals below reflect work from many individuals and research and client teams. This document is a transparent account of what we recommend prioritizing and where our views are still forming. These are positions that we would love for others to evaluate, challenge, and help improve, and we will iterate on them as we discuss and learn more over the coming days and weeks.

For the Hegotá upgrade, given all proposed EIPs, these are the areas we see as highest priority for Ethereum:

1. Stronger censorship resistance: Anyone should be able to get a transaction included, no matter who they are or what they use Ethereum for.
2. Faster Ethereum: Faster blocks mean faster confirmations, fresher onchain prices, and faster finality.
3. Native account abstraction: Accounts should support passkeys, sponsored transactions, gas paid in tokens, batching, and stronger privacy, with a path to post-quantum keys.
4. Continued L1 scaling: Applications need capacity that stays affordable and predictable, also when demand spikes.

Working in the open is a core goal for Ethlabs, which is why we write weekly updates and, on occasions like this one, post very lengthy technical pieces to share our thinking 😅. We’ll also publish more bite-sized content over the coming weeks for those who just want the highlights. This next part is going to be long and technical. For those of you who read it all, godspeed!

First things first: how does the EIP process even work?

Before diving into the proposals themselves, one important point: the second phase of Hegotá’s scoping process has just begun. The first phase selected FOCIL as the headliner of Hegotá. On Aug 6 there was a deadline to propose non-headliner EIPs, and the ACD process will now move to assess the Hegotá upgrade in its entirety.

All EIPs below are currently at the PFI (Proposed for Inclusion) stage, with the exception of EIPs that went through the headliner process. Proposing an EIP for inclusion is permissionless, and most never make it into the final upgrade.

Specifically, as implementation work progresses, proposals move through progressively stronger stages of review and confidence of eventually shipping:

• PFI (Proposed for Inclusion): an idea has been proposed for the upgrade. This stage is permissionless and does not imply client support or eventual inclusion.
• CFI (Considered for Inclusion): client teams have reviewed the proposal and intend to prototype and test it.
• SFI (Scheduled for Inclusion): there is broad intent to include it, assuming implementation and testing continue to go well.

To learn more about how this process works, we recommend watching Tim Beiko’s quick breakdown here.

Housekeeping: how to navigate this article

We follow Forkcast’s tier listing to express our view of EIP prioritization for Hegotá. To minimize the decision we map all reviewed EIPs into four tiers with the following interpretations:

• [S-tier] strongly recommend inclusion.
• [A-tier] recommend inclusion if remaining blockers such as implementation complexity, impact analysis, or adoption are resolved.
• [B-tier] worthwhile, but a stretch for this upgrade.
• [D-tier] do not recommend inclusion in Hegotá in its current form.
• [forming opinion] we’re still forming our opinion on this EIP.

Please note that these are Ethlabs’ \recommendations\. We evaluate each proposal mainly in terms of purpose, spec, and our understanding of plausible implementation complexity, except where we have more certainty or direct involvement (e.g. Frames and Quick Slots), and will update our view based on assessments from ethPandaOps, testing teams, and clients as we move along in the process.

[CL] means an EIP affects consensus-layer clients and [EL] means it affects execution-layer clients.

Note that we are co-authoring and involved in several EIPs (including FOCIL, Frame Transactions, and Quick Slots). While we strive to assess all EIPs independently of our involvement or not, please take this into consideration when evaluating our position.

tl;dr

CL ranking

You can iterate on this specific [CL] ranking on Forkcaster here.

EL ranking

You can iterate on this specific [EL] ranking on Forkcaster here.

Now, without further ado, here are our views on the Hegota upgrade as they stand today, in its entirety:

Themes for Hegotá

0. FOCIL: strengthen censorship-resistance

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.

1. Quick Slots: Faster Ethereum

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.

2.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.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.

2. Account Abstraction: improve UX, security, and privacy

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]

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 [B-tier]

• This is another EIP that enhances the experience of using privacy protocols with Frame transactions. Privacy protocols need access to recent commitment roots during validation, which if stored in regular storage can be not just expensive but also conflict with Frames’s public mempool rules. EIP-8272 solves these issues by exposing a system contract for storing these roots in a ring buffer that automatically purges old roots.
• We put it in B-tier because this EIP adds significant complexity to frames for a specific use case, and we are unsure if there might be a more general/elegant way of achieving the same goal.

[CL] EIP-8369: VOPS Profiles for FOCIL Eligibility [B-tier]

• This EIP addresses the interaction between Frames and VOPS (validity-only partial statelessness), which is a proposal for letting mempool nodes store just enough state to validate transactions, so that even in a world of statelessness (due to zkEVM) the mempool can remain censorship-resistant.
• We put it in B-tier because this EIP is strongly tied to a particular vision of statelessness which the community has not yet fully aligned on.

[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.

[EL] EOA migration [B-tier]

[EL] EIP-7851: Code-Controlled EOA Delegation [B-tier] and [EL] EIP-8151: Account Code Restricted ecRecover [B-tier] are best viewed as paired standards that together present a story for how EOAs can transition to smart accounts. In this story, an EOA would first delegate to a smart account via EIP-7702. Then, the opcode that EIP-7851 introduces would make the 7702 delegation permanent, disabling the root ECDSA key. On the other hand, EIP-8151 would make ecrecover aware of the deactivation, so the old key can’t drain funds via Permit-style flows.

We rate this pair in the B-tier because it’s 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, so we reserve the A/S-tiers for approaches that would enable users to migrate once for all EVM chains.

[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.

• 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.

[EL] EIP-7819: SETDELEGATE instruction [A-tier]

• With native AA likely to land in Hegota, 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. With EIP-7819, new accounts would use simple delegate pointers instead of proxy contracts, vastly reducing the amount of new state that needs to be created, thereby reducing deployment cost.
• We put this EIP in A-tier because we believe a lower account deployment cost would significantly lower the friction for adopting AA.

3. Performance engineering: continued L1 scaling

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.

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á.

Taken together, the following EIPs continue Glamsterdam’s scaling momentum while reinforcing the broader principle behind it: performance should remain a first-class concern in both client work and protocol design.

[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.

[CL][EL] EIP-8146: Block Access List Sidecars [A-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. We see this as the kind of low hanging optimization that we should not leave on the table. The implementation work is mainly familiar CL gossip machinery, making this a low-lift, high-value EIP, especially so in a fork that is shaping up to be quite EL-heavy.

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.

[EL] EIP-7862: Delayed State Root [B-tier]

• 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 most substantial upside of the EIP is in the future in our opinion (more time to prove the state root computation).
• EL is already the heavy side 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 (which gives much more time for it).

Other EIPs

We now cover the rest of the EIPs, loosely grouped by topics. On some EIPs we are still forming our opinion. We will update this doc as we learn more from client teams and EIP authors over the coming days and weeks.

Since Hegotá is looking to be an EL-skewed hard fork, we suggest staying disciplined and upholding a high bar for any EL-side EIP to clear. We think keeping Hegotá relatively CL-light beyond FOCIL and Quick Slots is desirable: a narrower scope preserves bandwidth to give client teams room to prepare for the larger architectural transition.

[CL] Issuance

We intentionally do not assign EIP-8363: Tapered Issuance Burn a tier. We think issuance is not a decision core devs should make on their own, and a tier list is an explicit recommendation to core devs. For most EIPs the ACD process works well because the decisions are primarily technical, and the community has effectively delegated them to core devs. Issuance is different in that it is a monetary policy question the community itself has to reach rough consensus on. Core dev opinions matter, but as input to that public discussion. Ranking EIP-8363 alongside the other EIPs would treat it as a normal ACD decision, which we think it should not be.

Technically we see merit in changing issuance in line with EIP-8363. The problems it addresses are real: the credibility of slashing erodes as more ETH is staked, high staking ratios mean rewards mostly offset dilution, and economies of scale keep widening the gap between large operators and solo stakers. A change also has risks, from uncertainty of effects to the stake distribution and resetting the monetary policy ossification clock. Ansgar’s thread lays out both sides and reflects our position. Some of us have argued for issuance changes in the past and continue to have conviction in that path.

We recommend making the issuance decision after all other Hegotá scoping decisions. This gives the community discussion the time it needs and avoids distracting from the scoping process itself.

[CL] Staking features

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 [forming opinion]

[CL] Further PQ-prep

These proposals reduce remaining BLS dependencies ahead of a future post-quantum transition.

[CL] EIP-8365: BLS withdrawal credential retirement [A-tier]

• Retires a legacy withdrawal credential, setting up the stage for protocol simplifications and simplifying the future PQ transition.
• Given how simple it is, we think it’s worth including now.

[CL] EIP-8367: Balance sunset for retired BLS validators [D-tier]

• We recommend rejecting. We think it’s likely that most 0x0 validators will do a credential change (BLSToExecutionChange) before or after EIP-8365: BLS withdrawal credential retirement is activated, either to withdraw their funds or to be able to keep staking. We don’t think there’s great urgency to introduce a mechanism for dealing with the remaining 0x0 stake. We recommend just including EIP-8365 and seeing the outcome of that before deciding on next steps.

[CL] EIP-8321: Hash-Chain RANDAO [D-tier]

• We recommend rejecting. Making RANDAO post-quantum-safe in isolation provides little protocol-level security while validator BLS keys remain vulnerable, yet adds roughly 32 bytes per validator, new secret-management machinery, and a largely single-purpose mechanism. The broader PQ consensus design remains unsettled. We support an iterative transition, but its first step should follow an agreed roadmap rather than risk being superseded by the eventual design.

[EL][CL] zkEVM prep

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.

[CL] EIP-8025: Optional Execution Proofs [D-tier]

• The EIP does not require a hard fork. The proposal to bundle it with Hegota 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-7666: EVM-ify the identity precompile [A-tier]

• useful, small change

[EL] EIP-8200: EVMification [B-tier]

• EIP-8200 replaces three native precompiles with equivalent EVM bytecode. Two see little use and appear straightforward to migrate. The third is widely used in SNARK verification, so we would want an impact assessment before supporting its removal.
• If the impact analysis finds low migration costs for affected users, or if the third precompile is removed from scope, we would move EIP-8200 to [A-tier].

[EL] EIP-7709: Read BLOCKHASH from Storage and Update Cost [D-tier]

• Quite disruptive due to the very large gas cost increase, 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.

[EL] EIP-8268: Storage Roots in Block Access Lists [B-tier]

• Might need an analysis of concrete impact on BAL sizes, and related impact on tx costs (EIP-8279 is proposing to charge for BAL bytes), since the BAL entry for each touched account gets an additional storage trie root.

[EL] EVM features

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] Code reuse / deduplication [B-tier]

• EIP-8058: Contract Bytecode Deduplication Discount and EIP-8298: SETCODEFROM Code Reuse Instruction both try to leverage the fact that contract code is stored separate from the corresponding account in clients, with the code hash as pointer between them. So identical shared code can be stored deduplicated. Both EIPs allow for a way to cheaply set account codehash to the hash of an elsewhere existing code.
• We consider this an attractive general idea, but it would be important to understand implications and forward compatibility to binary trees. No preference for now between the two.

[EL] Memory pricing reform [B-tier]

• We need to decide whether we at all want to do memory reform in Hegota. It’s not clear to us that we currently have a sufficient understanding of the design space to make this assessment.

EIP-7686: Linear EVM memory limits

• Smaller change, just gets rid of the quadric memory expansion cost.

EIP-7923: Linear, Page-Based Memory Costing

• Deeper, more principled rework, but more complex.

[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-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 [forming opinion]

[EL] EIP-4758: Deactivate SELFDESTRUCT [forming opinion]

[EL] EIP-7979: Call and Return Opcodes for the EVM [forming opinion]

[EL] EIP-8173: Foundations of EVM Control Flow [forming opinion]

[EL] EIP-8253: Bump nonce of zero-nonce storage accounts [forming opinion]

[EL] EIP-8030: P256 algorithm support [forming opinion]

[EL] EVM pricing

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-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-7973: Warm Account Write Metering [forming opinion]

[EL] EIP-7609: Decrease base cost of TLOAD/TSTORE [forming opinion]

[EL] EIP-7971: Hard Limits for Transient Storage [forming opinion]

[EL] EIP-3298: Removal of refunds [forming opinion]

[EL] EIP-8374: Persist Warm Access Sets Across Reverts [forming opinion]

[EL] EIP-8115: Batch priority fees at end of block [forming opinion]

[EL] EIP-8188: Last-Written Block for Accounts and Slots [forming opinion]

[EL][CL] Execution data and indexing

[EL][CL] EIP-7668: Remove bloom filters [forming opinion]

[EL][CL] EIP-7807: SSZ execution blocks [forming opinion]

[EL] EIP-8116: Replace cumulative receipt fields [forming opinion]

[EL] EIP-8304: Trustless log and transaction index [forming opinion]

[EL][CL] Networking

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

[CL] EIP-8371: RowDAS - Distributed Blob Reconstruction [A-tier]

• Generally 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. This could let us remove validator custody
• Need to better understand the complexity

[CL] EIP-8142: Block-in-Blobs (BiB) [D-tier]

• 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, alternatives are unclear and would add further complexity.

[CL] EIP-8243: Batching Attestations at Source [D-tier]

• 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.

[EL] EIP-8077: eth/XX - announce transactions with nonce [forming opinion]

[EL] EIP-8094: eth/vhash - Blob-Aware Mempool [forming opinion]

[CL] EIP-8334: Bundled Attestation Propagation [forming opinion]

If you somehow are still with us, thank you for reading till the end. Feel free to reply with with any questions, and we will do our best to get back to you! If you skipped and just scrolled down here because peering through a gargantuan wall of text was not how you decided to spend your Sunday, you will find pleasure in knowing that this next part is brief.

A few (more) words...

Ethereum upgrades are complex because the stakes are high. Thousands of nodes across the world switch to new rules at the same slot, and the network does not pause for even a second while they do. That rigor has carried every upgrade Ethereum has shipped, resulting in a decentralized network that has celebrated 11 years of 100% uptime.

Our positions on Hegotá are our best assessments as of today, but we will update our thinking whenever new evidence from discussions or implementation work changes our view.

Some of these EIPs were authored or advanced by members of Ethlabs, others come from the incredibly vast, talented, and well-intentioned researchers, client devs, and individual contributors across Ethereum. However, all of them will require collaboration among client teams, wallets, applications, L2s, infra providers, institutions, node operators, and ultimately, users to succeed. Ethereum is the world’s shared project, and meaningful network progress is never the work of one organization.

We are grateful to be a small part of this ecosystem, and we look forward to helping Ethereum realize its potential.

– Ethlabs