EIP-8081: Hegotá Network Upgrade Meta Thread

EIPs
1

View the current status of the fork here: Hegotá Upgrade - Forkcast

Hegotá Scoping Timeline

Following the Glamsterdam scoping process, I’d propose the following approach for Hegotá scoping. This is a preliminary timeline that may see modifications pending the Fusaka retrospective and any further process improvements we find as we finish getting Glamsterdam to mainnet.

  1. [Jan 8th - Feb 4th] Headliner Proposals
    • Headliner champions must open an Ethereum Magicians thread with the hegota tag by the deadline, including relevant information about their proposal. A template is found at the bottom of this post.
    • Note: While technical readiness is a factor, an EIP is not required at this stage. For instance, a proposal focusing on “reducing disk requirements for nodes” is acceptable even without a specific EIP.
    • Champions must be willing to present the proposal at an ACD call - add the proposal to the appropriate agenda (ACDE or ACDC) and be prepared to give a 2-minute overview of the proposal.
    • This period should evaluate not only Core Dev preferences for the next upgrade but also broader community preferences. While ACD can provide feedback around which stakeholders should be consulted, headliner champions are responsible for gathering sufficient evidence of support.
  2. [Feb 5th - Mar 26th] Headliner discussion & Finalization
    • Once candidate headliners are identified, ACD will spend the next month evaluating them, soliciting community feedback, and finalizing decisions on which feature(s) to prioritize for Hegotá.
    • Headliner chosen: FOCIL. Frames was CFI’d as placeholder AA implementation and the decision to promote to headliner or not deferred. All other headliners DFI’d. See discussion here: AllCoreDevs - Execution #233 - Forkcast
  3. [Apr 9th - Aug 6th] Non-Headliner EIP Proposals
    • Process will generally follow that listed in the Glamsterdam document.
  4. [By Devcon] Non-Headliner EIP CFI Decisions
    • Process will generally follow that listed in the Glamsterdam document.
  5. [TBD] CFI → SFI EIP Decisions

Headliner Proposal Template

NOTE: The headliner selection process is complete. No more can be proposed. FOCIL was chosen for the CL and no headliner was chosen for the EL, with the caveat that AA is being considered generally as a non-headliner with the option to promote it to headliner later, if one proposal can reach broad consensus and be considered a strong candidate. This was due to strong support for “AA generally” and controversy over the right specific implementation. (note added by Nixo, 7 May)

Create the post in the EIPs category with the title “Hegota Headliner Proposal: [title of EIP]” and tag the post with the hegota tag.

  • Summary (ELI5): Concise, plain-language explanation of the proposal, why it matters, and who directly benefits.

  • Champion: point-of-contact for the EIP

  • Detailed Justification:

    • What primary and secondary benefits exist, ideally supported by data or clear rationale?

    • Clearly articulate “Why now?”—Why prioritize this feature today?

    • Justify this specific approach compared to alternative solutions (considering lower risks, higher value).

  • Stakeholder Impact:

    • Positive: Identify beneficiaries clearly and document explicit support.

    • Negative: Identify potential negative impacts, document objections, and describe mitigations or accepted trade-offs.

  • Technical Readiness: Assess technical maturity clearly, providing links to specifications, tests, and client implementations.

  • Security & Open Questions: Document explicitly known security risks, open issues, or unclear aspects. Include threat models, preliminary audit plans, or next steps.

* It should be noted that any headliner proposals which are not selected for the fork cannot later be re-proposed as a non-headlining feature. Once DFI’d, the feature must wait until the next fork to be proposed again.

6 Likes
2

Fork focus

As part of headliner proposals, we should explicitly define the focus for Hegotá.

  • Scale L1
  • Scale L2
  • UX
  • DX
  • Decentralization

Examples from: Community Consensus, Fork Headliners & ACD Working Groups

Scalability & Lower Fees: Meaningfully increase throughput, lower transaction costs, and unlock new use cases.

Developer & User Experience: Simplify protocol complexity, enhance smart contract security, and reduce development friction.

Security & Resilience: Strengthen the network’s security posture, enhance attack resistance, and mitigate emerging threats without compromising decentralization or censorship resistance.

3

I know it’s very late but can you consider EIP-7923 (Linear, Page-based EVM Memory cost) as non-headliner inclusion?

4

@gunboatsss the EIP has been proposed for inclusion by @jochem-brouwer for upcoming ACDE #243

1 Like
5

Hi @gunboatsss I am proposing this for next week ACDE. If you want we can also discuss that EIP to see both what we want out of it (I am not an author of that EIP).

One note: if you want to propose other EIPs, you should announce your intent to propose it before ACDC tomorrow, so if there are other EIPs you want to propose for inclusion (PFI) then you should act now :smiley: :+1:

1 Like
6

Thank you! No more from my side.

2 Likes
7

Hegota, from the Protocol Architecture team (EF)

by Justin, Thomas, Toni, and Vitalik, authored by Toni.

Hegota is taking shape, and we now have to decide which EIPs to CFI.

This post gives a quick overview of the EIPs that we, as the Protocol Architecture team at EF, believe make the most sense to ship.

It does not cover every PFI’d EIP. We have no opinion on some, and not enough insight into others.

image

We see Hegota forming around the following themes:

  • Censorship resistance: FOCIL (EIP-7805)
  • Security, privacy & UX: Frame Transactions (EIP-8141), Keyed Nonces, Recent Roots, and Transaction Assertions for Frame Transactions (EIP-8250, EIP-8272, and EIP-7906)
  • Data repricing and scaling: EIP-8131, EIP-8146, EIP-8279, and EIP-8368, to reprice data and state growth, seperate the BAL from the payload and unlock the 500-600M block gas limit we’ve been pushing for with Glamsterdam.
  • zkEVM prep: EIP-8025, to de-risk a future zkEVM implementation, prepare specs and testing frameworks, and maintain the great momentum.

Native privacy

  1. EIP-8141: Frame Transactions
  2. EIP-8250: Keyed Nonces
  3. EIP-8272: Recent Roots for Frame Transactions

Together, these EIPs remove the need for trusted relayers inside privacy pools (see presentation). The pool can be the transaction sender and fee payer, while anyone can broadcast the transaction.
Keyed nonces let many users share the pool sender without competing for one linear nonce. Recent Roots give applications a standard way to publish the roots used during transaction validation.
With FOCIL support for Frame Transactions, privacy pool deposits and withdrawals can benefit from protocol inclusion guarantees.

This enables privacy transactions without trusted intermediaries, makes them future-proof for partially stateful nodes, and adds censorship resistance through FOCIL. The earlier we commit to the bundle, the sooner developers can build and test the required tooling and applications.

Depending on its readiness, EIP-7906: Transaction Assertions via State Diff Opcode would fit the theme of “frame + extensions” well and provides users with a frequently demanded security feature.

Data and state repricing

  1. EIP-8131: Unified Transaction Content Floor
  2. EIP-8279: Block Access List Byte Floor
  3. EIP-8368: CPSB Recalibration for New Gas Limit

After Glamsterdam, the extent to which we can safely raise the gas limit will depend heavily on how much execution time the consensus layer can guarantee the execution layer.

The earlier we can set the payload execution deadline, the more time the EL gets to execute the block, and the higher we can safely set the gas limit.

As we increase the gas limit, worst-case block size matters more and more. EIP-8131 ensures that transaction data costs at least 64 gas per byte, covering calldata, access lists, EIP-7702 authorizations, and blob hashes. EIP-8279 does the same for BAL data created during execution. Together, they bound data added by user transactions to block_gas_limit / 64 bytes.

E.g., the worst-case block would not consist solely of calldata, but of a mix of calldata and cold state accesses, with the latter contributing additional BAL bytes.

Similar applies to state creation costs, which must be adjusted depending on the block gas limit we land at (see EIP-8368).

BAL and payload separation

EIP-8146: Block Access List Sidecars

In Glamsterdam, the BAL travels together with the execution payload inside the payload envelope.

EIP-8146 separates the two, which allows us to set an earlier BAL PTC deadline, so validators can receive and use the BAL before the full payload arrives. This creates additional scaling headroom by improving worst-case performance.

Clients can then prefetch the state needed by the incoming payload, begin computing the post-state root, and optimistically advance the state and build inclusion lists against the expected post-state.

Builders can safely release the BAL before the payload because it does not reveal the transactions or any independently signed transaction content.

For example, a BAL observation deadline of five seconds and a payload deadline of six seconds would give validators an additional second of useful work in the worst case. This improves execution efficiency while also leading to better inclusion lists for FOCIL.

Another reason to separate the BAL from the payload is to reduce the size of each propagated object. At a 400M block gas limit, we would have to deal with >10 MB ExecutionPayloadEnvelopes (which hits the EIP-7934 cap). Splitting the BAL from the payload results in two ~5 MB objects instead.

zkEVM prep

EIP-8025: Optional Execution Proofs

We believe Optional Proofs is a good candidate for Hegota. Shipping it would maintain zkEVM momentum, allow proofs to be tested under mainnet conditions, and prepare for the transition to mandatory proofs. Given the EIP’s readiness and the fact that it is not consensus-critical, we think an optional phase spanning multiple forks is justified to reduce later risk. However, specification, client, testing, and maintenance work would still be required. We would therefore preserve the option to defer EIP-8025 by one fork if its inclusion would delay Hegota. For now, CFI it.

Check out this repo, put together by EF’s zkEVM team, with additional info on Optional Proofs for Hegota.

Quick Slots

EIP-8198: Quick Slots

Shortening the slot duration from 12s to e.g. 10s as a first step sounds reasonable, and we would generally support such a change for Hegota.

Further slot time decreases towards 8s or 6s will need to go hand in hand with empirical analysis of missed blocks/votes, reorgs, etc., and must take zkEVMs, which require some minimum ramp-up time for proof generation, into account.

8 Likes
8

Hi all, @Nerolation has already posted a ranking above with explanation. Just to state for clarity: this is the canonical place to post your EIP rankings of Hegotá with explanation and I invite everyone to post your rankings with explanation here so we have this place as complete overview of rankings. Thanks! :smiley: :+1:

3 Likes