Ethlabs Hegotá view

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.

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.

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

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.

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.

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

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.

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