Written by: Ethlabs

Compiled by: Chopper, Foresight News

The development direction of Ethereum concerns everyone who builds applications, uses the network, holds ETH, and believes in the future potential of Ethereum. The long-term direction of Ethereum will ultimately be decided by the participants who build products, operate applications, and engage with the community on a daily basis; however, network upgrades are a core means of protocol iteration and matching user needs. Hegotá is the next planned network upgrade after Glamsterdam. This article will explain the direction and reasons that Ethlabs believes Ethereum should focus on advancing during this upgrade.

Currently, the scope of the Hegotá upgrade is being preliminarily defined through an open technical process by Ethereum. The proposals mentioned below gather the results from numerous developers, research teams, and client teams. This article clearly presents the directions Ethlabs recommends prioritizing, as well as viewpoints that have not yet reached a conclusion. We welcome all sectors of the industry to evaluate, question, and refine these claims; in the coming days to weeks, as discussions continue and information updates, we will also iterate our views.

For the Hegotá upgrade, considering all proposed EIPs, we believe the following areas are Ethereum's top priorities:

• Stronger censorship resistance: Anyone, regardless of identity or purpose, should be able to have their transactions included in blocks;
• Faster Ethereum: Faster block production means quicker transaction confirmations, real-time on-chain pricing, and shorter final confirmation times;
• Native account abstraction: Accounts should support universal keys, transaction sponsorship, token payment for gas, batch transactions, stronger privacy protection, and reserve a pathway for post-quantum key upgrades;
• Ongoing L1 scaling: Even during peak demand periods, applications should be able to obtain stable and affordable network capacity.

Preliminary Note: How does the EIP advancement process work?

Before formally interpreting the proposals, let's clarify the key background; the definition of the scope for the Hegotá upgrade's second stage has just begun. The first stage has confirmed FOCIL as the core upgrade proposal for Hegotá. The deadline for non-core EIP proposals is August 6; after this, the ACD meeting will comprehensively evaluate the overall plan for the Hegotá upgrade.

All EIPs mentioned below are currently in the PFI (Proposed for Inclusion) stage. Submitting an EIP to the upgrade proposal does not require permission, but the vast majority of proposals ultimately cannot be adopted into the formal upgrade.

As development advances, proposals will undergo multiple rounds of review, with stages progressively improving, and the certainty of implementation increasing:

PFI (Proposed for Inclusion): The proposal has been submitted for this upgrade. This stage has no entry threshold, does not represent client support, nor guarantees that it will ultimately be launched;

CFI (Considered for Inclusion): Client teams complete their reviews and plan to carry out prototype development and testing;

SFI (Secured for Inclusion): All parties generally agree to inclusion, provided that development and testing progress smoothly.

For a complete understanding of the process, it is recommended to watch Tim Beiko's explanatory video. (https://www.youtube.com/watch?v=-S4blFZl28g)

Reading Guidance

This article uses the Forkcast classification standard to express Ethlabs' prioritization judgment of each EIP for Hegotá. To simplify decision-making, all proposals included in the assessment are categorized into five tiers:

• [S tier] Strongly recommended for inclusion
• [A tier] Recommended for inclusion if obstacles such as development difficulty, impact assessment, and ecological implementation are resolved
• [B tier] Valuable, but difficult to include in this upgrade
• [D tier] Not recommended for inclusion in Hegotá under current conditions
• [Viewpoints Pending] We are still evaluating this EIP

⚠️ Note: The above is only Ethlabs' suggestion. Our assessments are primarily based on proposal goals, technical specifications, and estimated development complexity; for projects with deep involvement (such as Frames, Quick Slots), we have more thorough information. In the future, we will combine feedback from ethPandaOps, testing teams, and various clients to continuously update our views. The tag [CL] represents impacts on consensus layer clients; [EL] represents impacts on execution layer clients.

Additionally, Ethlabs has collaborated on several EIPs (including FOCIL, Frame Transactions, Quick Slots). We strive for objective evaluations of all proposals, unaffected by our degree of involvement, but readers can consider this background when referencing our views.

CL priority list

EL priority list

Without further ado, here are Ethlabs' complete views on the Hegotá upgrade at this stage.

Four Core Directions of Hegotá

FOCIL: Strengthening Censorship Resistance

EIP-7805 FOCIL has entered the SFI stage and has been officially confirmed as the core proposal for Hegotá. Three members of Ethlabs (Francesco, Barnabé, Julian) are co-authors of this proposal, and we fully support its implementation. Since the plan is set, we will briefly state: only a blockchain that maintains neutrality for all can serve as the foundation of trust for everyone. This is the cornerstone of Ethereum's expansion and its growth into the true settlement layer of the global economy, serving every participant.

Quick Slots: A Faster Ethereum

The current 12-second slots of Ethereum lead to high latency, harming user experience. Therefore, we strongly recommend the inclusion of [CL] EIP-8198 Quick Slots [S tier] in Hegotá, with four core reasons:

• Increased confirmation speed for L1 user transactions, optimizing experience;
• L1 on-chain market receiving updated price data, improving buy-sell spreads and liquidity provider profits;
• Final certainty, fast confirmation rules tied to slot durations, with faster blocks improving Ethereum's cross-chain interoperability;
• Increased number of block proposers per second, enhancing censorship resistance, including economically: the cost required to implement censorship by persistently clearing blocks is higher.

Shortening the interval between blocks while preserving Ethereum's decentralization characteristics can enhance the value of Ethereum's block space, with profits flowing back to the network and ETH itself. Every reduction in delays directly creates value for users. At the same time, speeding up is one of the most anticipated improvements by application developers.

Currently, initiating this transformation is reasonable; however, adjusting slot durations cannot be completed in one step. Consistent with scaling ideas, iterative optimizations through empirical tests will provide developers with more certainty than mere roadmap commitments. Achieving slots within 6 seconds is a long-term goal, with a two-step pathway:

• One-time reconstruction: Allowing norms and client code to flexibly modify slot durations;
• Completing the initial shortening in Hegotá, followed by continuous reductions in future hard forks, accumulating safety operating data.

Hegotá is a suitable time to bear the one-time reconstruction costs. The ePBS of the Glamsterdam upgrade has already restructured slot-related logic; the consensus layer changes of this upgrade are relatively controllable. Once entering the decoupled consensus upgrade window, resources for consensus layer development will be in high demand, creating future hard forks without similar opportunities.

In simple terms, either maintain 12-second slots for at least the next two years, or achieve a 10-second slot in one year during the Hegotá upgrade, with the potential of further compressing it to under 10 seconds in the next round. These two speed-ups are not merely theoretical optimizations; they can directly enhance user value and optimize the network's economic model. We believe the timing is ripe.

Main Controversy Responses

We have sorted out four main concerns that emerged during preliminary communications with client development teams and the Ethereum Foundation protocol team:

• Development complexity. Millisecond-level slot timing logic has already been integrated into the consensus specification based on ePBS; the drafts of EIP-8198 consensus layer and execution layer specifications have been completed, with base fees, gas limits, and blob scheduling fully calculated to ensure stable network behavior per second. The remaining workload focuses on adapting various client tools and boundary scenario testing based on fixed slot assumptions. Once this one-time reconstruction is completed, subsequent slot reductions will only require parameter adjustments.
• zkEVM proof pressure. There are major concerns regarding two points: relative proof time and fixed proof overhead. 1) Relative proof time: The proportion of time within a slot that can be used for proof. Current block builders can start building once receiving the load of the previous block; beacon block confirmation indicates the load of the current slot. The load must be completed before the next beacon proposer publishes a block. The shortest time available for proof completion is approximately equal to one slot minus the beacon block propagation delay. While propagation delay is difficult to compress, it is already relatively small, and at this stage will not become a core bottleneck. Optimized block builders can parallelize proof while assembling loads without waiting for winning loads to be confirmed by the beacon block. 2) zkEVM proof overhead: Proof time generally correlates linearly with block size but has fixed overhead. Faster block production means more frequent triggers of fixed overhead, leading to increased latency at the same throughput. Under fixed delay budget constraints, throughput must not be significantly impacted. There are two improvement paths in the industry: engineering iterations that continuously reduce fixed operational overhead; EIP-7862 delayed state root calculations, moving a significant amount of proof work out of the critical path. Pursuing these two directions together means that faster slots will not hinder future throughput growth.
• Post-quantum upgrade pathways. The decoupled consensus scheme has gained sufficient support and has become a stable direction for future consensus architecture. Decoupling means moving final confirmation voting out of the critical path of block production. Large-scale aggregation of post-quantum signatures and recursive STARK-related logic will also be detached from the critical path. Block production and fork selection rules will rely solely on a group composed of approximately 512 validators (expected to reduce to 256). Post-quantum signatures are larger in size, but can be smoothly propagated within the planned 10-second (and potentially further reduced) slots.
• Smart contract and infrastructure adaptation. The team is conducting a comprehensive survey of smart contracts and scenarios where slot durations are strongly coupled. We are collaborating with Sourcify to analyze all verified contracts; meanwhile, we are assessing the impact of slot changes on EIP-4788 (storing historical beacon block roots in the EVM). On the infrastructure level, Etherscan provides feedback: slot adjustments will likely increase server load, but infrastructure has already been adapted to variable block times since the PoW era, so the changes are controllable.

Account Abstraction: Optimizing Experience, Security, and Privacy

There has long been a pressing need for native account abstraction (AA) in the Ethereum ecosystem, to achieve upgrades such as universal key wallets, transaction sponsorship, ERC20 payment for gas, and batch transactions. However, the path to implement native account abstraction has been exceptionally tortuous: AA touches all layers of Ethereum, covering clients, L2, wallets, RPC, and development tools, requiring multi-party collaboration. This not only makes related EIPs difficult to advance through consensus-driven development processes, but also presents challenges for ecosystem implementation post-launch.

As a result, we classify the native AA proposal Frame Transactions for Hegotá as A tier. This does not mean that it does not meet S tier technical standards at a technical level, but rather that we need to fully consider the risks of large-scale ecosystem implementation and the significant coordination required. Leveraging the team's experience in account abstraction, Ethlabs plans to deeply promote the implementation of Frame Transactions, working with L2, wallets, and other participants to ensure the smooth launch of native AA.

Looking at the account abstraction-related proposals for Hegotá.

[EL] EIP-8141 Frame Transactions [A tier]

We believe Frame Transactions is the optimal solution for Ethereum's native account abstraction. Compared to other native AA solutions, several features align with Ethereum's CROPS development guidelines:

• Permissionless account innovation: Verification logic is executed via EVM code, allowing developers to customize any verification rules; some AA solutions impose mandatory whitelist verification logic, lacking flexibility;
• Native support for privacy protocols: Building on the previous point, privacy solutions like Railgun can carry Frame transaction verification logic, allowing users to send privacy transactions without relying on centralized relayers, significantly enhancing privacy and censorship resistance;
• Post-quantum security design: Designed from the outset to align with Ethereum's post-quantum roadmap. Supports signature aggregation; even though the cost of verifying a single post-quantum signature is high, aggregation can achieve lower gas overhead.

Frame Transactions' biggest weakness also stems from its flexibility: verification logic is executed by EVM code, and verification costs fluctuate dynamically, posing challenges for L2s seeking high TPS.

We are optimistic that this can be resolved through supporting EIP/ERC standards (e.g., EIP-7819), with transaction static declaration verification logic in which sorters can optimize verification processes with native code bypass. At the same time, we will collaborate with L2 and the Ethereum Foundation to conduct benchmark testing to locate and address performance bottlenecks.

[CL][EL] Frame Transactions Add-Ons

Many EIPs can be seen as extensions of Frame transactions, enhancing their functionality.

[EL] EIP-8250 Randomness for Frame Transactions [A tier]

We view this proposal as an organic component of EIP-8141 and recommend launching it simultaneously. Introducing a 2D nonce allows accounts to submit multiple transactions to the transaction memory pool in parallel; privacy protocols can also store null values in the 2D nonce. The read/write storage cost of a 2D nonce is extremely low, significantly saving gas for privacy transactions compared to the existing approach of writing null values into standard storage. This is particularly important in the context of increased storage gas costs (EIP-8037) during Glamsterdam.

[EL] EIP-8272 Latest Root for Frame Transactions [B tier]

Further optimizes the experience of using Frame transactions for privacy protocols. The verification process for privacy protocols needs to read the latest commitment root; if stored in normal storage, it not only incurs high costs but will also conflict with the rules of Frame's public transaction pool. This proposal stores root data via a circular buffer in the system contract, automatically cleaning up old data. Classifying it as B tier is due to the significant increase in complexity for a single application scenario; we are unsure if a more general, simpler implementation exists.

[CL] EIP-8369 VOPS Configuration Files for FOCIL Qualification [B tier]

Addresses the interaction between Frame and VOPS (only validity stateless). The VOPS solution allows memory pool nodes to maintain only the minimal state to verify transactions, ensuring future zkEVM environments remain censorship-resistant. Classifying it as B tier is due to its high binding to a suite of stateless routes that have not yet gained community consensus.

[EL] EIP-7906 Transaction Assertions via State Difference Opcode [B tier]

Enhances the static auditability of transaction results. Users can currently assert positive outcomes, but cannot constrain "no other state change exists". To prove that no additional state modification has occurred, new opcodes are needed. Positive assertions (e.g., WETH balance increased by at least 1.5) combined with negative assertions (no other state changes) can lock in all transaction impacts without simulation; hardware wallets are a key beneficiary scenario. This proposal has high complexity and requires careful consideration for inclusion in a hard fork. We suggest advancing it only if two conditions are met: ① Client teams fully understand all details and chain reactions; ② the scope of testing and potential risk assessments are complete.

[EL] EOA Migration [B tier]

EIP-7851 and EIP-8151 are suitable to be viewed together, forming a smart account migration solution for external accounts. The pathway is as follows: EOA first delegates to the smart account via EIP-7702; EIP-7851 adds an opcode that permanently solidifies the delegated relationship, disabling the original ECDSA keys; EIP-8151 allows ecRecover to recognize that keys have been disabled, preventing old keys from stealing assets through Permit-like transactions. Rated B tier: this is merely one of the EOA migration solutions, and has not yet gained widespread review and industry consensus. The biggest risk lies in multi-chain compatibility: users need to repeat the migration process on every L2, including chains that have not yet been born, resulting in poor user experience. We anticipate a solution that relies on L1 as a trust root, with one operation applicable to all EVM chains, as this type could potentially rise to A/S tier.

[EL] Post-Quantum Signature Standards [A tier]

Hegotá should establish a clear path for the implementation of post-quantum signatures, but the optimal mechanism needs to be finalized before formal adoption. EIP-8355 adds an ML-DSA precompiled contract: it will deliver post-quantum account security capabilities when combined with Frame transactions. Alternatives may include pre-registering support for post-quantum signatures without activating them just yet, or defining derivation formats compatible with post-quantum keys.

[EL] EIP-7819 SETDELEGATE Instruction [A tier]

Once native AA is established in Hegotá, reducing the deployment costs of smart accounts is crucial. However, Glamsterdam's EIP-8037 will increase the account creation costs. EIP-7819 allows new accounts to use lightweight delegation pointers instead of proxy contracts, significantly reducing additional state storage and lowering deployment expenses. Rated A tier because lower account deployment costs can significantly reduce the threshold for AA implementation.

Performance Optimization: Continuous L1 Scaling

Glamsterdam marked a shift in Ethereum's R&D thinking: performance has become the core constraint of protocol design and client development. Delayed execution, resource pricing adjustments, and large-scale client optimizations have increased the network's capacity from 30 million gas to at least 200 million gas within two years. Performance optimization provides options, and the released performance surplus can be used to scale up, shorten slots, lower node hardware thresholds, or achieve multiple goals simultaneously.

Scaling demand remains urgent. Project location selection not only refers to current gas prices but must also consider whether Ethereum can continuously and stably expand block space supply. Continuously delivering scaling upgrades provides developers with more confidence than simply being presented with roadmap proposals. The mainnet still has a gap before it can smoothly accommodate peak traffic: on Ethereum's 11th anniversary, the median gas price was only about 0.1 gwei; a single NFT minting event pushed gas prices up to the 10 gwei range, and the median transaction cost exceeded $1. The scaling trends initiated by Glamsterdam need to be sustained through Hegotá.

In summary, the following EIPs extend the momentum of Glamsterdam's scaling while further reinforcing broader principles: performance should always be the primary consideration in client work and protocol design.

[EL] EIP-8131 & EIP-8279 [S tier]

The data pricing combination proposal after the Glamsterdam upgrade turned the network's core bottleneck into block load propagation. The root cause lies in the lack of unified gas accounting standards for different types of byte resources, and some do not even have billing. EIP-8131 unifies the basic lower limit for transactions: extending the existing minimum billing rules to data verifiable before execution; EIP-8279 establishes a byte lower limit for block access lists: billing for access list bytes dynamically generated during execution.

The dynamic billing mechanism makes EIP-8279 more complex, but the two should be viewed together. The combination scheme achieves unified accounting of transaction-related bytes, limiting the worst-case scenario of block loads, while the vast majority of ordinary, low-data consumption transactions remain unaffected. Closing resource accounting loopholes clears obstacles for further increasing the gas upper limit.

[CL][EL] EIP-8146 [A tier]

EIP-8146 improves the key path itself by spreading BAL and payload, thereby enhancing the repricing mechanism. This not only increases propagation efficiency but also gives execution clients a head start on state prefetch and post-state root calculations. We believe this is a low-barrier optimization that cannot be overlooked. Implementation work is primarily based on the familiar CL gossip mechanism, making this a low-investment, high-value EIP, especially within a branch with a significant amount of EL code.

Other Scaling-Related Proposals

[EL] CPSB Recalibration [A tier]

The changes are straightforward. We recommend continuing to advance, adjusting the gas upper limit based on planned increases, and the use of on-chain state and execution gas, selecting one for inclusion. EIP-8368 calibrates CPSB for the new gas upper limit: subsequent assistance to EIP-8037. The state byte cost shifts from being dynamically adjusted with the gas upper limit to a fixed value, simplifying development and testing. Current CPSB is computed based on a 150 million gas limit, and Hegotá will likely need recalibrating as the gas upper limit is raised.

[EL] EIP-7862 Delayed State Root [B tier]

The specification itself is simple, but as far as we know, the complexity of client implementation has not been fully understood. State roots are widely present in the codebase. The short-term benefits are limited, with core value focusing on the long term (extending the usable time for the state root proof). The pressure of execution layer changes for this Hegotá upgrade is already significant.

[CL] EIP-8341 Partial Execution Payload Commitment [D tier]

Not recommended for inclusion. The benefits are limited (slight delay for state root calculations), there is no urgent demand, and EIP-7862 can achieve stronger effects and can directly replace it.

Remaining EIP Classification Discussion

Next, we outline the remaining proposals and group them by theme. We still have ongoing evaluations regarding some proposals, and we will continue to update our feedback in conjunction with client teams and authors.

Hegotá is expected to be a hard fork focusing more on execution layer changes, and we must strictly control the entry thresholds for execution layer EIPs. Apart from FOCIL and Quick Slots, we should attempt to minimize the scope of changes in the consensus layer: limiting the scope of upgrades to provide sufficient time for client teams to cope with future large-scale architectural transitions.

[CL] Issuance Mechanism Related

We do not prioritize EIP-8363 for gradual issuance and destruction. The inflation issuance policy should not be determined unilaterally by core developers; priority rankings are equivalent to issuing clear landing suggestions to core developers. The vast majority of EIPs lean towards technical decisions, with the community entrusting decision-making power to the core development team; however, the issuance mechanism is part of monetary policy, requiring broad community consensus. Core developers’ opinions should only serve as references for public discussions. If we rank it alongside ordinary EIPs, it is equivalent to considering it a conventional ACD technical decision.

From a technical perspective, EIP-8363 has merit. As the total amount of staked ETH rises, the credibility of the penalty mechanism diminishes; under high staking rates, new rewards mostly offset inflation; the scale effect continues to widen the gap between large operators and independent stakers. However, the changes also come with risks: there is uncertainty in the staking distribution pattern, and the process of solidifying monetary policy will restart. Ansgar's discussion post comprehensively lists pro and con viewpoints, aligning with our position. Some team members previously supported adjustments to the issuance mechanism, and they still maintain this judgment.

We recommend discussing adjustments to the issuance mechanism only after all other scopes of Hegotá are finalized. This will provide ample time for community discussions and avoid interfering with the main lines of the upgrade scope definition.

[CL] Staking Function Optimization

Improvements to staking hold value, but priority should be given to optimizations aimed at end-users, deferring purely infrastructure changes unless necessary.

[CL] EIP-8015 Deleting Deposit and eth1data Fields [A tier]

Lightweight cleaning of historical technical debt. Relying on EIP-7688 ensures backward compatibility with consensus data structures; irrelevant field Merkle proofs will not be affected, and will not impact on-chain data reading.

[EL][CL] EIP-8237 Independent Synchronization of Consensus Layer / Execution Layer [B tier]

Based on ePBS separating beacon blocks from loads, allowing CL and EL to synchronize independently offers the potential for simplifying client complexity.

[CL] EIP-8205 Withdrawal Credentials Pre-registration [D tier]

Not recommended for inclusion. Although it addresses real pain points of entrusted staking, the existing deposit pre-solution can already cope and the complexity introduced by the new protocol mechanism makes it difficult to match with benefits at the current stage.

[CL] EIP-8148 Custom Liquidation Thresholds for Validators [D tier]

Not recommended for inclusion. The mechanism is complex (new system contracts, execution requests, consensus layer logic), and the benefits are limited, only slightly promoting the integration of retail staking. Considering the current staking distribution pattern, it is hard to significantly change the overall trend of validator concentration across the network.

[CL] EIP-8372 ePBS Execution Reward Forced Destruction [D tier]

Not recommended for inclusion. It will likely only create more off-chain pathways. Years of discussions on MEV destruction have not resulted in a broadly agreed-upon solution.

[CL] EIP-7716 Counteracting Proof Punishment [D tier]

Not recommended for inclusion. There is insufficient evidence to support major adjustments to the staking incentive mechanism, and the decoupled consensus upgrade will redesign the staking incentive system.

[CL] EIP-8333 Checkpoint Alignment with Epoch Boundary Blocks [D tier]

Not recommended for inclusion. It belongs to optimization cleaning work and can be deferred to coincide with a larger-scale decoupled consensus upgrade.

[CL] EIP-8359 Beacon Block Report Fields [Viewpoints Pending]

[CL] Pre-Work for Post-Quantum Upgrades

The following proposals reduce reliance on BLS signatures, paving the way for future post-quantum transformations.

[CL] EIP-8365 Eliminating BLS Withdrawal Credentials [A tier]

Eliminates outdated withdrawal credentials, simplifying protocols and paving the way for future post-quantum transformations. The changes are straightforward and suitable for immediate implementation.

[CL] EIP-8367 Eliminating BLS Validator Balance Expiry Mechanism [D tier]

Not recommended for inclusion. The vast majority of 0x0 credential validators will complete credential migration, extract funds, or continue staking before and after EIP-8365 goes live. There is no need for a special mechanism to handle the remaining stock; we should implement EIP-8365 and observe the actual situation.

[CL] EIP-8321 Hash Chain RANDAO [D tier]

Not recommended for inclusion. Simply implementing RANDAO has limited post-quantum security significance, and validator BLS keys still present risks; meanwhile, each validator adds 32 bytes of data, introducing new key management logic, while the usages are singular. The complete post-quantum consensus plan has yet to be realized. We support iterative upgrades, but the first step should follow a unified roadmap to avoid the solution being replaced by the final standards.

[EL][CL] zkEVM Adaptation Optimization

Most zkEVM pre-optimizations yield limited short-term benefits, merely facilitating specific groups to run full nodes while consuming development resources and potentially increasing EVM operating costs. Only proposals that offer significantly greater long-term value than short-term costs should be included.

[CL] EIP-8025 Optional Execution Proof [D tier]

This upgrade should not be included. The proposal does not mandate a hard fork, and bundling it with Hegotá merely represents a priority call, which we do not agree with. Before implementing optional proofs, we should first clarify the long-term final form and proceed steadily, avoiding hasty launches before the validator/state model is well-defined. The core issue to resolve is whether validators should retain or store some state or be completely stateless. Validators are important node groups that hold hardware and network resources, so changes that weaken their role require higher admission standards.

[EL] EIP-7666 Identity Precompilation EVM Transformation [A tier]

The changes are small in scale and carry practical value.

[EL] EIP-8200 EVM Transformation of Precompiled [B tier]

Replaces three categories of native precompiled with EVM bytecode. Two categories have low usage, which means little migration difficulty; the third category is widely used for SNARK proofs. An impact assessment needs to be completed to confirm migration costs are controllable, or we can exclude the third category, at which point we might raise it to A tier.

[EL] EIP-7709 Gas Adjusting for Reading BLOCKHASH from Storage [D tier]

The gas adjustment is large, with evident disruptions, and demand is not urgent. To reduce risks, conducting an impact assessment or deferring implementation with a block warming mechanism is advisable.

[EL] EIP-8268 Including Block Access Lists in Storage Roots [B tier]

We need to evaluate the actual impacts of access list sizes and transaction gas costs (EIP-8279 will charge for access list bytes), with each access account entry carrying an additional storage Merkle root.

[EL] EVM Native Functions

Hegotá will still implement certain scattered improvements to the EVM. We believe that after this upgrade, Ethereum should collaborate across the entire EVM ecosystem to establish a long-term EVM development roadmap, and Ethlabs will participate in this co-construction.

[EL] EIP-5920 PAY Opcode [A tier]

The logic is concise and constitutes a valuable primitive in the EVM. Further clarification of real application scenarios is still required.

[EL] EIP-8163 Reserving EXTENSION (0xae) Opcode [A tier]

This is highly practical for L2 and has virtually no costs for L1; it only serves as a reservation identifier.

[EL] Contract Code Reuse [B tier]

EIP-8058 contract bytecode deduplication discount and EIP-8298 SETCODEFROM code reuse instruction depend on the client storage model: contract code is stored independently and accounts only point to the code through the code hash. Both proposals achieve the same code being stored once, reducing deployment costs. The concept is attractive but needs to be assessed for its forward compatibility impact on the binary tree storage structure. No clear preferences exist for the two proposals at this time.

[EL] Memory Pricing Reform [B tier]

We have yet to determine if memory reform is suitable for implementation in Hegotá. Our understanding of the design space is still insufficient.

EIP-7686 linear EVM memory cap: the changes are minor, eliminating secondary growth memory expansion costs;

EIP-7923 page-based linear memory pricing: reconfigures the underlying rules and improves greatly, but with higher complexity.

[EL] EIP-8219 Arithmetic Opcodes with Overflow Checks [B tier]

Adding secure arithmetic functionality to the EVM is valuable. It requires benchmark testing to confirm reasonable pricing; upon completing impact assessments (benefiting transaction scales and compiler adaptations), it is expected to be raised to A tier.

[EL] EIP-8360 TCREATE Opcode [B tier]

Supports creating temporary contracts within the transaction lifecycle, providing a universal underlying primitive. However, the proposal’s complexity is relatively high, and it can be re-rated after assessing development and testing difficulty.

[EL] EIP-7645 ORIGIN Alias Pointing to SENDER [D tier]

Not recommended for inclusion. This constitutes a disruptive change, and it abuses the semantics of ORIGIN.

[EL] EIP-8182 Native Private ETH and ERC20 Transfers [D tier]

Not recommended for inclusion. The scope of changes is vast and introduces ZK dependencies. If launched in the future, it should be central to the upgrade proposals.

[EL] EIP-2488 Deprecated CALLCODE Opcode [Viewpoints Pending]

[EL] EIP-4758 Deprecating SELFDESTRUCT [Viewpoints Pending]

[EL] EIP-7979 EVM Call and Return Opcodes [Viewpoints Pending]

[EL] EIP-8173 Basic Control Flow for EVM [Viewpoints Pending]

[EL] EIP-8253 Zero Nonce Storage Account Nonce Auto-Increment [Viewpoints Pending]

[EL] EIP-8030 New P256 Algorithm Support [Viewpoints Pending]

[EL] EVM Pricing Mechanism

The gas cost of operations that limit throughput has been raised too low in Glamsterdam. The pricing proposals related to Hegotá are in the opposite direction: reducing currently overly high operation costs that restrict application implementation, but with limited contributions to overall network scaling, they are more like optimizations that embellish an already good situation. We support targeted pricing adjustments, but proposals for new billing models must be well-designed and thoroughly validated with significant risk mitigators before they can be included.

[EL] EIP-8358 Net Gas Billing for Account Changes [B tier]

Benefits are questionable. Sample data from 900 mainnet blocks and 400,000 transactions show: only 2.07% of transactions save gas, constituting a mere 1.14% of the total gas saved in a block.

[EL] EIP-7973 Hot Account Write Billing [Viewpoints Pending]

[EL] EIP-7609 Reducing TLOAD/TSTORE Base Gas [Viewpoints Pending]

[EL] EIP-7971 Instant Storage Hard Cap [Viewpoints Pending]

[EL] EIP-3298 Removal of Gas Refund [Viewpoints Pending]

[EL] EIP-8374 Retain Hot Access Sets After Rollbacks [Viewpoints Pending]

[EL] EIP-8115 Batch Priority Fee Collection at Block End [Viewpoints Pending]

[EL] EIP-8188 Latest Write Block Record for Accounts and Storage Slots [Viewpoints Pending]

[EL][CL] Execution Data and Indexing

[EL][CL] EIP-7668 Remove Bloom Filters [Viewpoints Pending]

[EL][CL] EIP-7807 SSZ Format Execution Blocks [Viewpoints Pending]

[EL] EIP-8116 Simplify Cumulative Receipt Fields [Viewpoints Pending]

[EL] EIP-8304 Trustless Log and Transaction Indexing [Viewpoints Pending]

[EL][CL] Networking Layer

The Ethereum P2P network still has directional optimization space, especially concerning transaction, blob, and proof message propagation mechanisms.

[CL] EIP-8371 RowDAS Distributed Blob Reconstruction [A tier]

Avoids full reconstruction and ensures that full node hosting does not become a bottleneck for blob scaling. In the long run, a distributed reconstruction mechanism must be included in the protocol, potentially relieving validators of blob hosting requirements. Further assessment of implementation complexity is required.

[CL] EIP-8142 Embedded Blocks into Blobs BiB [D tier]

The timing is not mature, urgency is insufficient, and there are numerous unresolved issues remaining (e.g., whether to adopt KZG, and creating new broadcast topics). We do not wish to introduce the KZG mechanism into the critical path of block production, but alternatives are still unclear.

[CL] EIP-8243 Source Bulk Broadcast Proofs [D tier]

It is unclear whether it can effectively shorten final confirmation times, and the load limits are not clear; DoS defense capabilities of the mechanisms need to be validated.

[EL] EIP-8077 eth/XX nonce-based broadcast transactions [Viewpoints Pending]

[EL] EIP-8094 eth/vhash supports transaction pool protocols for Blob [Viewpoints Pending]

[CL] EIP-8334 Bulk Proof Broadcasting [Viewpoints Pending]

Conclusion

Ethereum upgrades carry extreme risks, making complexity unavoidable. Thousands of nodes worldwide need to synchronize and switch rules simultaneously without interrupting network operations. This rigor supports Ethereum's successful upgrades, maintaining a decentralized network with no downtime for 11 consecutive years.

The above are Ethlabs' current evaluations on Hegotá. As development progresses and discussions deepen, we will continue to update our views whenever new evidence emerges. Some EIPs are led by Ethlabs members, while other proposals come from a wealth of excellent researchers, client developers, and independent contributors in Ethereum. However, for all proposals to be realized, cooperation from client teams, wallets, applications, L2, infrastructure providers, organizations, node operators, and end users is essential. Ethereum belongs to the whole world, and significant progress in the network has never been the result of a single organization.