Written by: Ethlabs
Compiled by: Chopper, Foresight News
The direction of Ethereum's development concerns everyone building applications, using the network, holding ETH, and believing in Ethereum's future potential. While the long-term trajectory of Ethereum is ultimately determined by the participants who build products, operate applications, and manage communities on it daily, network upgrades are the core means for protocol iteration to match user needs. Hegotá is Ethereum's next planned network upgrade following Glamsterdam. This article will articulate the directions and reasons that Ethlabs believes Ethereum should prioritize in this upgrade.
Currently, the scope of the Hegotá upgrade is being initially determined through Ethereum's open technical process. The various proposals mentioned below compile the efforts of numerous developers, research teams, and client teams. This article clearly presents Ethlabs' recommended priorities and the areas where we have not yet formed a definitive viewpoint. We welcome evaluation, questioning, and refinement of these proposals from across the industry; over the coming days and weeks, as discussions and information updates continue, we will also iterate our views.
For the Hegotá upgrade, considering all proposed EIPs, we believe the following areas are Ethereum's primary priorities:
- Stronger censorship resistance: Anyone, regardless of identity or purpose, can have their transactions included in a block;
- A faster Ethereum: Faster block times mean faster transaction confirmations, real-time on-chain pricing, and shorter finality times;
- Native account abstraction: Accounts support passkeys, transaction sponsorship, gas payment in tokens, batched transactions, enhanced privacy protection, and a path for post-quantum key upgrades;
- Sustained L1 scaling: Applications can obtain stable, affordable network capacity even during peak demand periods.
Preliminary Note: How Does the EIP Advancement Process Work?
Before formally interpreting the proposals, it's crucial to clarify the background: Stage 2 of scoping the Hegotá upgrade has just begun. Stage 1 has already identified FOCIL as the core upgrade proposal for Hegotá. The deadline for non-core EIP proposals is August 6th, after which the ACD meeting will comprehensively evaluate the overall Hegotá upgrade plan.
All EIPs mentioned below are currently in the PFI (Proposal For Inclusion) stage. Submitting an EIP for an upgrade is permissionless, but the vast majority will ultimately not be included in the formal upgrade.
As development progresses, proposals undergo multiple rounds of review, advancing through stages with increasing certainty of implementation:
PFI (Proposal For Inclusion): The proposal is submitted for this upgrade. This stage has no entry barrier, does not imply client support, and does not guarantee final inclusion;
CFI (Considered For Inclusion): Client teams have completed their review and plan to proceed with prototyping and testing;
SFI (Scheduled For Inclusion): There is broad agreement for inclusion, provided development and testing proceed smoothly.
To understand the complete process, we recommend watching Tim Beiko's explanatory video. (https://www.youtube.com/watch?v=-S4blFZl28g)
Reading Guide
This article uses the Forkcast grading standards to express Ethlabs' priority judgment for Hegotá EIPs. To simplify decision-making, all proposals under evaluation are categorized into five tiers:
- 【S Tier】Strongly recommend inclusion
- 【A Tier】Recommend inclusion if obstacles like development difficulty, impact assessment, or ecosystem adoption are resolved
- 【B Tier】Has value, but inclusion in this upgrade is challenging
- 【D Tier】Do not recommend inclusion in Hegotá under current conditions
- 【View Pending】We are still researching and deliberating on this EIP
⚠️ Note: These are merely Ethlabs' recommendations. Our evaluation is primarily based on proposal goals, technical specifications, and estimated development complexity; for projects we are deeply involved in (e.g., Frames, Quick Slots), we have more comprehensive information. We will update our views based on ongoing feedback from ethPandaOps, testing teams, and various clients. Tags 【CL】 indicate impact on consensus layer clients; 【EL】 indicate impact on execution layer clients.
Additionally, Ethlabs has contributed to several EIPs (including FOCIL, Frame Transactions, Quick Slots). We strive to evaluate all proposals objectively, unaffected by our level of involvement, but readers may wish to note this context when considering our views.
CL Priority List
EL Priority List
Without further ado, here is Ethlabs' complete current perspective on the Hegotá upgrade.
Four Core Directions for Hegotá
FOCIL: Strengthening Censorship Resistance
EIP-7805 FOCIL has already entered the SFI stage, officially designated as Hegotá's core proposal. Three Ethlabs members (Francesco, Barnabé, Julian) are co-authors of this proposal, and we fully support its implementation. Since the plan is already set, we will only summarize briefly here: A blockchain can only become a foundation trusted by everyone if it remains neutral towards all. This is the cornerstone for Ethereum to scale, grow into a genuine settlement layer for the global economy, and serve every participant.
Quick Slots: A Faster Ethereum
Ethereum's current 12-second slot duration introduces high latency, harming user experience. Therefore, we strongly recommend including 【CL】EIP-8198 Quick Slots【S Tier】 in Hegotá, for four core reasons:
- L1 user transaction confirmation speed improves, optimizing experience;
- L1 on-chain markets obtain more updated price data, improving bid-ask spreads and liquidity provider profits;
- Finality, fast confirmation rules are tied to slot duration; faster blocks will simultaneously improve Ethereum's cross-chain interoperability;
- Increased number of block proposers per second enhances censorship resistance, including economic censorship resistance: the cost to conduct censorship by persistently emptying blocks becomes higher.
Reducing the block interval while preserving Ethereum's decentralization characteristics can increase the value of Ethereum's block space, with benefits flowing back to the network and ETH itself. Every reduction in latency directly creates value for users. Simultaneously, speeding up is one of the most requested improvements by application developers.
Initiating this transformation now is justified; slot duration adjustment cannot be achieved in one step. Consistent with scaling philosophy, iterative optimization through actual deployment provides far greater certainty for application developers than mere roadmap promises. Achieving sub-6-second slots is a long-term goal, with a two-step path:
- One-time refactor: Allow specifications and client code to support flexible slot duration changes;
- Perform the first reduction in Hegotá, with subsequent hard forks continuously lowering it, accumulating safe operational data.
Hegotá is an opportune time to bear the one-time refactor cost. The ePBS in the Glamsterdam upgrade already refactored slot-related logic; consensus layer changes for this upgrade are relatively contained. Once the decoupled consensus upgrade window opens, consensus layer development resources will be highly strained, making it difficult to have such a window in future hard forks.
Simply put, the choice is either maintaining a 12-second slot for at least the next two years, or achieving a 10-second slot in next year's Hegotá upgrade, with the potential to further compress it below 10 seconds in the following round. Two rounds of speed increase are not just theoretical optimizations; they directly enhance user value and optimize the network's economic model. We believe the time is ripe.
Response to Major Concerns
We have compiled four main concerns raised during initial communication with client development teams and the Ethereum Foundation protocol team:
- Development Complexity. The millisecond-level slot timing logic has already been integrated into the consensus specification via ePBS; both consensus layer and execution layer draft specifications for EIP-8198 are complete, with base fee, gas limit, and blob scheduling all adjusted to ensure stable network behavior per second. Remaining work focuses on adapting various client tools and edge case tests assuming fixed slot durations. After this one-time refactor, future slot reductions will only require parameter adjustments.
- zkEVM Proof Pressure. Main concerns are twofold: relative proving time and fixed proof overhead. 1) Relative proving time: The proportion of time within a slot available for proof generation. Currently, block builders can start building upon receiving the previous block's payload; the beacon block confirms the current slot's payload. The payload must be proven before the next beacon proposer publishes a block. The minimum usable time for proof generation is roughly one slot minus beacon block propagation delay. Propagation delay is difficult to compress but is itself a small value and currently not a core bottleneck. Optimized block builders can parallelize proof generation while assembling the payload, without waiting for the winning payload to be confirmed by a beacon block. 2) zkEVM proof overhead: Proof time is largely linear with block size but has a fixed overhead. Faster blocks mean higher frequency of fixed overhead, increasing latency for the same throughput. Throughput must be ensured without significant impact under a fixed latency budget. The industry has two improvement paths: engineering iterations continuously reduce fixed operation time; EIP-7862 delays state root calculation, moving significant proving work off the critical path. Both directions advancing in parallel mean faster slots will not hinder future throughput growth.
- Post-Quantum Upgrade Path. The decoupled consensus approach has garnered sufficient support to become the stable future consensus architecture direction. Decoupling moves finality votes out of the critical path of block production. Large-scale aggregation of post-quantum signatures and recursive STARK logic will both be removed from the critical path. Block production and fork-choice rules will rely only on a committee expected to comprise 512 (potentially reduced to 256) validators. Post-quantum signatures are larger in size but can propagate smoothly within the planned 10-second (with potential for further reduction) slot.
- Smart Contract and Infrastructure Adaptation. The team is comprehensively investigating scenarios where smart contracts are strongly coupled to slot duration. We are collaborating with Sourcify to analyze all verified contracts; simultaneously, we are assessing the impact of slot changes on EIP-4788 (Beacon Block Root in EVM) storing historical beacon block roots. At the infrastructure level, Etherscan feedback indicates: slot adjustment will likely increase server load, but infrastructure already adapted to variable block times during the PoW era, so the scope of changes is manageable.
Account Abstraction: Improving Experience, Security, and Privacy
The Ethereum ecosystem has long urgently needed native account abstraction (AA) to enable passkey wallets, transaction sponsorship, ERC20 gas payments, batched transactions, and other experience enhancements. However, the path to native account abstraction has been exceptionally winding: AA touches the entire Ethereum stack, encompassing clients, L2s, wallets, RPCs, and development tools, requiring multi-party coordination. This not only makes related EIPs difficult to advance through the consensus-driven development process but also presents challenges for ecosystem adoption post-launch.
Therefore, we rate the Hegotá native AA proposal Frame Transactions as A Tier. Not because it falls short of S Tier technically, but because the risks of large-scale ecosystem adoption and the massive coordination workload must be fully considered. Leveraging the team's accumulated expertise in account abstraction, Ethlabs plans to deeply promote the adoption of Frame Transactions, collaborating with L2s, wallets, and other participants to ensure smooth launch of native AA.
Now, let's look at Hegotá account abstraction-related proposals.
【EL】EIP-8141 Frame Transactions【A Tier】
We believe Frame Transactions is the optimal native account abstraction scheme for Ethereum. Compared to other native AA schemes, several characteristics align with Ethereum's CROPS development principles:
- Permissionless Account Innovation: Validation logic is executed by EVM code, allowing developers to define arbitrary validation rules; some AA schemes mandate whitelisted validation logic, lacking flexibility;
- Native Adaptation for Privacy Protocols: Based on the above, privacy protocols like Railgun can implement Frame transaction validation logic; users sending private transactions no longer need to rely on centralized relayers, significantly enhancing privacy and censorship resistance;
- Designed for Post-Quantum Security: Developed to align with Ethereum's post-quantum roadmap from the start. Supports signature aggregation; even if single post-quantum signature verification is costly, aggregation enables lower gas costs.
Frame Transactions' greatest weakness also stems from its flexibility: Validation logic is executed by EVM code, leading to dynamically variable validation costs, posing challenges for L2s pursuing high TPS.
We are optimistic that this can be resolved through supporting EIP/ERC standards (e.g., EIP-7819), where transactions statically declare validation logic, allowing sequencers to optimize the validation process using native code bypass. We will also collaborate with L2s and the Ethereum Foundation to conduct benchmarks, identifying and resolving performance bottlenecks.
[CL][EL] Frame Transactions Add-ons
Many EIPs can be viewed as extensions of Frame transactions, enhancing their functionality.
【EL】EIP-8250 Frame Transaction Key Nonce【A Tier】
We view this proposal as an integral component of EIP-8141 and recommend simultaneous launch. Introducing a two-dimensional nonce allows accounts to send multiple transactions to the mempool in parallel; privacy protocols can also store nullifiers in the two-dimensional nonce. Reading/writing the two-dimensional nonce has minimal storage cost. Compared to existing models storing nullifiers in regular storage, private transactions can achieve significant gas savings. This is especially important following the storage gas cost increase (EIP-8037) in Glamsterdam.
【EL】EIP-8272 Frame Transaction Latest Root【B Tier】
Further optimizes the experience for privacy protocols using Frame transactions. Privacy protocol validation requires reading the latest commitment root. Storing it in regular storage is not only costly but also conflicts with Frame's public mempool rules. This proposal stores root data in a system contract ring buffer, automatically cleaning old data. Rated B Tier because it significantly increases Frame complexity for a single application scenario; we are uncertain if a more general, simpler implementation exists.
【CL】EIP-8369 VOPS Profile for FOCIL Eligibility【B Tier】
Addresses the interaction between Frame and VOPS (Verification-only Statelessness). VOPS allows mempool nodes to validate transactions with minimal state, ensuring mempool censorship resistance in a future zkEVM stateless environment. Rated B Tier because this scheme is highly tied to a statelessness roadmap that hasn't yet achieved community consensus.
【EL】EIP-7906 Transaction Assertions via State Difference Opcodes【B Tier】
Improves static auditability of transaction outcomes. Users can currently assert positive outcomes but cannot constrain "no other state changes." Proving no additional state modifications requires new opcodes. Positive assertions (e.g., WETH balance increases by at least 1.5) combined with negative assertions (no other state changes) can lock down all transaction effects without simulation, a key benefit scenario for hardware wallets. This proposal is relatively complex; careful consideration is needed for inclusion in a hard fork. Advancing requires two conditions: 1) Client teams fully understand all details and chain effects; 2) Complete testing scope and potential risk assessment.
【EL】EOA Migration【B Tier】
EIP-7851 and EIP-8151 are suitable to be viewed together, forming a scheme for migrating externally owned accounts to smart accounts. The path is as follows: An EOA first delegates to a smart account via EIP-7702; EIP-7851 adds an opcode to permanently solidify the delegation, disabling the original ECDSA key; EIP-8151 makes ecRecover recognize the key is deactivated, preventing asset theft via Permit-style transactions using the old key. Rated B Tier: This is just one migration scheme; it hasn't undergone extensive review or achieved broad industry consensus. The biggest concern is cross-chain compatibility: Users would need to repeat the migration on every L2, including yet-to-be-created chains, leading to poor UX. We anticipate a scheme that uses L1 as a trust root, where a single operation applies to all EVM chains; such a scheme could potentially be upgraded to A/S Tier.
【EL】Post-Quantum Signature Standard【A Tier】
Hegotá should establish a clear path for post-quantum signature adoption but needs to finalize the optimal mechanism before formal implementation. EIP-8355 adds an ML-DSA precompile contract: Combined with Frame transactions, it enables post-quantum account security capabilities. Alternative: Pre-register support for post-quantum signatures without activation, or define a derivation format compatible with post-quantum keys.
【EL】EIP-7819 SETDELEGATE Instruction【A Tier】
Once native AA lands in Hegotá, reducing smart account deployment costs is crucial. However, EIP-8037 in Glamsterdam will increase account creation costs. EIP-7819 allows new accounts to use lightweight delegation pointers instead of proxy contracts, significantly reducing new state storage and lowering deployment overhead. Rated A Tier because lower account deployment costs can significantly reduce barriers to AA adoption.
Performance Optimization: Sustaining L1 Scaling
Glamsterdam marked a shift in Ethereum's R&D mindset: Performance became a core constraint for protocol design and client development. Lazy execution, resource pricing adjustments, and large-scale client optimizations increased network capacity from 30 million gas to at least 200 million gas within two years. Performance optimization creates optionality; the released performance margin can be used for scaling, shortening slots, lowering node hardware requirements, or achieving multiple goals simultaneously.
The need for scaling remains urgent. Project siting considers not only current gas prices but also whether Ethereum can steadily and continuously expand block space supply. Consistently delivering scaling upgrades provides far greater confidence to developers than paper roadmaps. Mainnet still has a gap before it can stably handle traffic peaks: On Ethereum's 11th anniversary, the median gas price was only ~0.1 gwei, yet a single NFT minting event pushed gas into the 10+ gwei range, raising median transaction costs above $1. The scaling trend initiated by Glamsterdam must continue into Hegotá.
In summary, the following EIPs continue Glamsterdam's scaling momentum while reinforcing the broader principle behind it: Performance should remain a primary consideration in both client work and protocol design.
【EL】EIP-8131 & EIP-8279【S Tier】
Data pricing combination proposals. After Glamsterdam, the network's core bottleneck became block payload propagation. The root cause is inconsistent gas accounting standards for different byte types, with some not even being charged. EIP-8131 unifies the transaction base floor: Extends existing minimum charging rules to data confirmable pre-execution; EIP-8279 block access list byte floor: Charges for access list bytes dynamically generated during execution.
The dynamic charging mechanism makes EIP-8279 more complex, but the two should be viewed as a bundle. The combined scheme achieves unified accounting for transaction-related bytes, limiting worst-case block payloads, while most ordinary, low-data-usage transactions remain unaffected. It plugs resource accounting gaps, clearing obstacles for future gas limit increases.
【CL】【EL】EIP-8146 【A Tier】
EIP-8146 improves the critical path itself by separating BAL propagation from the payload, thus complementing the repricing mechanism. This not only enhances propagation efficiency but also allows execution clients to get a head start on state prefetching and post-state-root computation. We consider this a low-hanging optimization not to be missed. Implementation work is primarily based on familiar CL gossip mechanisms, making this a low-effort, high-value EIP, especially in a branch with substantial EL code changes.
Other Scaling-Related Proposals
【EL】CPSB Recalibration【A Tier】
Simple change. We recommend continued progression; include based on planned gas limit increases, on-chain state, and execution gas usage. EIP-8368 CPSB Calibration for New Gas Limit: Follow-up to EIP-8037. Changes state byte cost from dynamic adjustment with gas limit to a fixed value, simplifying development/testing. Current CPSB is based on a 150M gas limit; after gas limit increases, Hegotá will likely require recalibration. EIP-8372 Standardized State Gas Limit: Extension of EIP-8368, with finer adjustment granularity for scenarios where state growth targets or regular gas targets deviate from expectations.
【EL】EIP-7862 Delayed State Root【B Tier】
The specification itself is simple, but the complexity of client implementation is, to our knowledge, not yet fully understood. State roots are pervasive in codebases. Short-term benefits are limited, with core value concentrated long-term (extending usable time for state root proofs). The execution layer already faces significant change pressure for this Hegotá.
【CL】EIP-8341 Partial Execution Payload Commitment【D Tier】
Recommend exclusion. Benefits are limited (slight delay in state root calculation), urgency is not high, and EIP-7862 can achieve stronger effects, directly serving as a substitute.
Other EIPs by Category
Next, we review the remaining proposals, grouped by theme. For some, our views are still forming and will be updated based on ongoing communication with client teams and authors.
Hegotá is expected to be a hard fork with heavier execution layer changes; we should strictly control the entry threshold for execution layer EIPs. Apart from FOCIL and Quick Slots, we should aim to limit the scope of consensus layer changes: Narrowing the upgrade scope provides client teams ample time to prepare for future large architectural transitions.
【CL】Issuance Mechanism Related
We are not assigning a priority tier to EIP-8363 Progressive Issuance and Burn. Monetary issuance policy should not be unilaterally decided by core developers. A priority list equates to providing explicit implementation recommendations to core developers. Most EIPs lean towards technical decisions, where the community delegates authority to core dev teams; but issuance mechanisms are monetary policy requiring broad community consensus. Core developer opinions should serve only as input for public discussion. Including it in a priority list alongside ordinary EIPs treats it as a routine ACD technical decision.
Technically, EIP-8363 has merit. As staked ETH increases, slashing credibility diminishes; high staking ratios mean new rewards largely offset issuance; economies of scale continually widen gaps between large operators and solo stakers. However, changes also carry risks: Staking distribution patterns are uncertain, and the monetary policy hardening process would restart. A discussion post by Ansgar comprehensively lists pros and cons, aligning with our stance. Some team members previously supported adjusting issuance and maintain that view.
We recommend discussing issuance mechanism adjustments only after all other Hegotá scope is finalized. This allows ample community discussion time and avoids disrupting the main thread of upgrade scoping.
【CL】Staking Functionality Optimization
Staking improvements have value, but prioritize optimizations for end-users; purely infrastructure changes should be deferred unless necessary.
【CL】EIP-8015 Remove Deposit and eth1data Fields【A Tier】
Lightweight cleanup of historical technical debt. Relies on EIP-7688 for forward compatibility with consensus data structures; Merkle proofs for removed fields remain unaffected, not impacting on-chain data readers.
【EL】【CL】EIP-8237 Consensus/Execution Layer Independent Sync【B Tier】
Builds on ePBS separating beacon blocks from payloads, allowing CL and EL to sync independently, potentially simplifying complex client logic.
【CL】EIP-8205 Withdrawal Credential Pre-registration【D Tier】
Recommend exclusion. While addressing a real pain point in delegated staking, existing deposit front-running solutions can handle it; adding a whole protocol mechanism brings complexity disproportionate to current benefits.
【CL】EIP-8148 Validator Customizable Slashing Threshold【D Tier】
Recommend exclusion. Complex mechanism (adds system contract, execution request, consensus logic) with limited benefits, only marginally promoting retail staker consolidation. Given current staking distribution, unlikely to significantly alter overall validator centralization trend.
【CL】EIP-8372 ePBS Execution Rewards Mandatory Burn【D Tier】
Recommend exclusion. Likely only fosters more off-chain channels. Years of MEV burn discussion haven't yielded a broadly agreed scheme.
【CL】EIP-7716 Anti-Correlation Proof Penalty【D Tier】
Recommend exclusion. Lacks sufficient evidence to justify major staking incentive adjustments, and decoupled consensus upgrades will redesign the staking incentive system.
【CL】EIP-8333 Checkpoint Aligns Epoch Boundary Blocks【D Tier】
Recommend exclusion. An optimization/cleanup task that can be deferred to a larger decoupled consensus upgrade.
【CL】EIP-8359 Beacon Block Reporting Field【View Pending】
【CL】Post-Quantum Upgrade Preparatory Work
The following proposals reduce reliance on BLS signatures, paving the way for long-term post-quantum transition.
【CL】EIP-8365 Deprecate BLS Withdrawal Credentials【A Tier】
Deprecates old withdrawal credentials, simplifying protocol and paving the way for future post-quantum transition. Simple change suitable for current implementation.
【CL】EIP-8367 Deprecate BLS Validator Balance Expiry Mechanism【D Tier】
Recommend exclusion. The vast majority of 0x0 credential validators will migrate credentials (withdraw funds or continue staking) around the time EIP-8365 goes live. No need for a dedicated mechanism to handle remaining legacy; implement EIP-8365 first and observe the situation.
【CL】EIP-8321 Hash Chain RANDAO【D Tier】
Recommend exclusion. Achieving post-quantum security solely for RANDAO is of limited value as validator BLS keys remain at risk; also adds 32 bytes of data per validator and new key management logic for a single purpose. A complete post-quantum consensus scheme is not yet finalized. We support iterative upgrades, but the first step should follow a unified roadmap to avoid schemes being superseded by final standards.
【EL】【CL】zkEVM Adaptation & Optimization
Most zkEVM preparatory optimizations offer limited short-term benefits, merely facilitating specific groups to run full nodes, while consuming development resources and potentially increasing EVM runtime costs. Only proposals where long-term value significantly outweighs short-term costs are suitable for inclusion.
【CL】EIP-8025 Optional Execution Proof【D Tier】
Should not be included in this upgrade. The proposal itself doesn't mandate a hard fork; bundling it with Hegotá is a priority request we do not agree with. Before implementing optional proofs, the long-term final form should be clarified, progressing steadily, not rushing implementation before validator/state models are solidified. Core unresolved questions: Should validators retain/store partial state, or become completely stateless? Validators are an important node group with hardware and network resources; changes weakening their role require a higher entry bar.
【EL】EIP-7666 Identity Precompile EVM-ification【A Tier】
Small change with practical utility.
【EL】EIP-8200 Precompile EVM-ification【B Tier】
Replaces three types of native precompiles with EVM bytecode. Two have low usage, migration is simple; the third is widely used for SNARK proofs. Needs impact assessment to confirm migration cost is manageable, or remove the third type from scope, after which we could upgrade to A Tier.
【EL】EIP-7709 BLOCKHASH Read from Storage and Adjust Gas【D Tier】
Gas increase is substantial, causing significant disruption, and urgency is low. To reduce risk, conduct impact assessment or pair with a block warming mechanism for deferred implementation.
【EL】EIP-8268 Include Storage Root in Block Access List【B Tier】
Need to assess actual impact on access list size and transaction gas cost (EIP-8279 will charge for access list bytes), as each accessed account entry would include an additional storage Merkle root.
【EL】EVM Native Functionality
Hegotá will still include some scattered EVM improvements. We believe after this upgrade, Ethereum should collaboratively develop a long-term EVM evolution roadmap with the entire EVM ecosystem; Ethlabs will participate.
【EL】EIP-5920 PAY Opcode【A Tier】
Logic is concise; a valuable low-level primitive for EVM. Still needs further clarification on real use cases.
【EL】EIP-8163 Reserve EXTENSION (0xae) Opcode【A Tier】
Highly practical for L2s, almost zero cost for L1, merely reserving an identifier.
【EL】Contract Code Reuse【B Tier】
EIP-8058 Contract Bytecode Deduplication Discount, EIP-8298 SETCODEFROM Code Reuse Instruction. Based on client storage model: Contract code stored separately, accounts point to code via hash. Both proposals achieve storing identical code only once, reducing deployment costs. The concept is attractive but needs assessment of impact on forward compatibility with binary tree storage structure. No clear preference between the two proposals currently.
【EL】Memory Pricing Reform【B Tier】
We haven't yet determined if memory reform is suitable for Hegotá. Current understanding of design space is insufficient.
EIP-7686 Linear EVM Memory Limit: Smaller change, removes quadratic growth cost for memory expansion;
EIP-7923 Paged-Based Linear Memory Pricing: More comprehensive underlying rule refactor but higher complexity.
【EL】EIP-8219 Overflow-Checked Arithmetic Opcodes【B Tier】
Adding safe arithmetic as a native EVM feature has value. Needs benchmarks to confirm proper pricing; after impact assessment (scale of benefiting transactions, compiler adaptation), could be upgraded to A Tier.
【EL】EIP-8360 TCREATE Opcode【B Tier】
Supports creating temporary contracts within a transaction's lifecycle, a generic low-level primitive. Proposal complexity is relatively high; could be re-rated after development and testing difficulty assessment.
【EL】EIP-7645 ORIGIN Alias to SENDER【D Tier】
Recommend exclusion. A breaking change that misuses ORIGIN semantics.
【EL】EIP-8182 Native Private ETH and ERC20 Transfers【D Tier】
Recommend exclusion. Change scope is massive, introduces ZK dependencies. If implemented in the future, should be a core upgrade proposal.
【EL】EIP-2488 Deprecate CALLCODE Opcode【View Pending】
【EL】EIP-4758 Deactivate SELFDESTRUCT【View Pending】
【EL】EIP-7979 EVM Call and Return Opcodes【View Pending】
【EL】EIP-8173 EVM Control Flow Basics【View Pending】
【EL】EIP-8253 Zero Nonce Storage Account Nonce Autoincrement【View Pending】
【EL】EIP-8030 Add P256 Algorithm Support【View Pending】
【EL】EVM Pricing Mechanism
Glamsterdam increased gas costs for operations priced too low, constraining throughput. Related pricing proposals for Hegotá go the opposite direction: lowering costs for operations currently priced too high, limiting application adoption, but offering limited contribution to overall network scaling, belonging to "nice-to-have" optimizations. We support targeted price adjustments, but proposals introducing new charging models must be well-designed, have committed proponents fully validating risks before inclusion.
【EL】EIP-8358 Account Change Net Gas Charging【B Tier】
Benefits questionable. Data from a sample of 900 mainnet blocks, 400k transactions shows: Only 2.07% of transactions save gas, total gas saved per block is only 1.14%.
【EL】EIP-7973 Hot Account Write Charging【View Pending】
【EL】EIP-7609 Lower TLOAD/TSTORE Base Gas【View Pending】
【EL】EIP-7971 Transient Storage Hard Cap【View Pending】
【EL】EIP-3298 Remove Gas Refunds【View Pending】
【EL】EIP-8374 Retain Hot Access Set After Revert【View Pending】
【EL】EIP-8115 Block-End Bulk Priority Fee Collection【View Pending】
【EL】EIP-8188 Account & Storage Slot Latest Write Block Recording【View Pending】
【EL】【CL】Execution Data & Indexing
【EL】【CL】EIP-7668 Remove Bloom Filter【View Pending】
【EL】【CL】EIP-7807 SSZ Execution Block Format【View Pending】
【EL】EIP-8116 Simplify Cumulative Receipt Field【View Pending】
【EL】EIP-8304 Trustless Log & Transaction Indexing【View Pending】
【EL】【CL】Networking Layer
Ethereum's P2P network still has room for targeted optimization, especially in transaction, blob, and attestation message propagation mechanisms.
【CL】EIP-8371 RowDAS Distributed Blob Reconstruction【A Tier】
Avoids full reconstruction and full node hosting becoming a bottleneck for blob scaling. Long-term, a distributed reconstruction mechanism will likely need to be incorporated into the protocol, potentially removing blob hosting requirements for validators. Further assessment of implementation complexity is still needed.
【CL】EIP-8142 Blob-in-Block BiB【D Tier】
Premature, urgency is lacking, leaves many open questions (whether to use KZG, new broadcast topic). Unwilling to introduce KZG mechanisms into the block production critical path; alternatives are unclear.
【CL】EIP-8243 Origin Bulk Broadcast Attestations【D Tier】
Cannot guarantee shortening finality times, load limits unclear; mechanism's DoS resistance needs verification.
【EL】EIP-8077 eth/XX Nonce-Based Transaction Broadcast【View Pending】
【EL】EIP-8094 eth/vhash Blob-Aware Mempool Protocol【View Pending】
【CL】EIP-8334 Bulk Attestation Broadcast【View Pending】
Conclusion
Ethereum upgrades carry extremely high risk, hence inevitable complexity. Thousands of nodes globally must switch rules synchronously in the same slot without network interruption. This rigor underpins Ethereum's history of smooth upgrades, achieving a decentralized network with 11 consecutive years of zero downtime.
The above represents Ethlabs' current judgment for Hegotá. As development progresses and discussions deepen, we will continuously update our views upon new evidence. Some EIPs are spearheaded by Ethlabs members, while others originate from Ethereum's vast pool of excellent researchers, client developers, and independent contributors. However, for any proposal to succeed, it requires the collaboration of client teams, wallets, applications, L2s, infrastructure providers, institutions, node operators, and end-users. Ethereum belongs to the world; its major network advancements have never been the achievement of a single organization.
