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