Ethlabs Hegotá view
Sharing Ethlabs’ view here. You can otherwise also find Ethlabs’ Hegotá view on our website that we keep up-to-date incl. a changelog. It also comes with a Hegotá EIP explorer to navigate the 60+ EIPs more easily.
Intro
The ACD process is currently scoping Hegotá, an upcoming hardfork for Ethereum. We believe that Ethereum’s next upgrade should prioritize the following themes:
CL
-
Stronger censorship resistance: Anyone should be able to get a transaction included, no matter who they are or what they use Ethereum for.
-
Faster Ethereum: Shorter slots mean faster confirmations, fresher onchain prices, and faster finality.
EL
-
Performance engineering: continued L1 scaling & faster Ethereum. 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.
-
Native account abstraction: Accounts should support passkeys, sponsored transactions, gas paid in tokens, batching, and stronger privacy, with a path to post-quantum keys.
Housekeeping
We follow Forkcast’s tier listing to express our view of EIP prioritization for Hegotá. To minimize the decision we map all EIPs into only four tiers with the following interpretations:
-
[S-tier] strongly recommend inclusion
-
[A-tier] recommend inclusion if blockers are cleared (e.g., complexity assessment, impact analysis, path to adoption)
-
[B-tier] stretch goal
-
[D-tier] recommend rejection
For easier parsing for client teams we tag EIPs relevant for [CL]s and [EL]s as such.
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.
tl;dr
CL ranking. Iterate on it here. Note that EIP-7805: FOCIL is already SFIed and thus not included in this ranking.
EL ranking. Iterate on it here. Note that EIP-8141: Frame Transactions is already SFIed and thus not included in this ranking.
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 fort he 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:
-
Improved UX on L1 with faster tx confirmation.
-
Onchain markets on L1 run on fresher prices, improving spreads and LP economics.
-
Finality and the fast confirmation rule inherit the slot time, so both get faster with faster blocks, improving interoperability with Ethereum.
-
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:
-
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.
-
zkEVM proving: The two main issues are relative proving time and the constant proving overhead.
-
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.
-
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.
-
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.
-
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]
Note: since initially publishing Ethlabs’ view EIP-8141 has been SFI. FporWe 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] 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:
-
Delegate to a smart account via EIP-7702 (live today).
-
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)
-
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.
3. Performance engineering: continued L1 scaling & faster Ethereum
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.
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.
Note: Text too long for ethmagicians, part 2 follows:
