L2BEAT's research team Hegotá ranking


Link

How to interpret our ranking

  • S: EIPs that we really want to see in the next fork and we would be disappointed if they don’t go in.
  • A: EIPs that we would be very happy to see included, sad but not too sad if not included.
  • B: EIPs we’d be happy to see included in this fork but definitely okay to postpone.
  • C: EIPs we like but that we’d like to see postponed.
  • DFI: EIPs we wouldn’t include in any fork.

The ranking represents the opinion of L2BEAT’s research team composed by Basti, Luca, Sergey and Vincenzo.

Motivation

S tier

  • Keyed Nonces (8250) + Recent roots (8272): Unconditional privacy should be one of the top, if not the top, priority for Ethereum. Ethereum today forces people who want to withdraw from a privacy protocol to either solve a chicken-and-egg problem or rely on a third party relayer, which most of the time is hard to find, is expensive, or enforces some sort of compliance. These two EIPs allow users to safely and autonomously propagate their withdrawal.

A tier

  • Transaction Assertions (7906): Allowing wallets and users to specify what should NOT change when calling a contract is a massive security improvement when interacting with untrusted contracts, and our years of experience suggests that very few users actually read the code of the contracts they interact with. This EIP should not delay 8141 and the S tier EIPs.

  • Optional Execution Proofs (8025): Shipping the entirety of mandatory proofs in one fork is not realistic, and optional proofs are a great way to test the infrastructure on Mainnet. Risk-taking but resource-constrained users would already benefit from running stateless, non-executing but fully validating nodes, and it’s good to provide the option even if mandatory proofs never ship. This work can also help inform the infrastructure needed to allow stateless nodes to read the state. This EIP should not delay Hegotá.

  • RowDAS (8371): Blob reconstruction should be available to everyone, not only to supernodes, and should not force the download of all blobs wasting precious home bandwidth. Blob scaling should not have such tradeoffs. This upgrade also simplifies long-term blob storage for nodes that are only interested in specific applications (L2s, socials).

B tier

  • EVMification & BLOCKHASH from Storage (7666 + 8200 + 7709): As with 8025, it’s good to split the work to get to mandatory proofs in different forks. These EIPs would immediately benefit nodes running optional proofs, even though it’d be ok to ship optional proofs without.

  • Withdrawal credentials preregistration (8205): Existing solutions to the problem are not good enough as they either introduce significant delays (as in Rocket Pool) or permissioned actors (as in Lido). Projects should not be forced to make this tradeoff.

  • SETCODEFROM (8298): This EIP provides an effective way to disable existing ECDSA-based accounts and can simplify smart contract upgrades.

  • Trustless Log/tx index (8304): Applications embedding light clients become more powerful with this EIP. This includes apps we particularly like: Kohaku, Ambire, Freedom Browser, but it could also convince others to integrate them instead of forcing the user to rely on trusted RPCs.

C tier

  • Anti-correlation attestations (7716): This EIP can credibly increase the resilience of the network, even though effects need to be studied more. Might be worth coupling with decoupled consensus.

  • SSZ execution blocks (7807): We understand the benefits but it might be too early.

  • Block-in-Blobs (8142): This EIP immediately benefits nodes running optional proofs, but definitely not necessary. More relevant for mandatory proofs.

  • Quick slots (8198): 10s is not a significant improvement over the current 12s and it’s not clear whether slot time can be made easily “configurable”. Not worth pushing out EIPs in the A or B tier for this.

  • Precompiles for ML-DSA (8355): 8141 already allows for post-quantum signature schemes to be used, so it might be worth waiting to see how the wallets react first.

DFI tier

  • Reserve EXTENSION (8163): No clear benefit for Ethereum.

  • Private ETH and ERC-20 (8182): Better solved at the application layer. More powerful solutions like Wormholes are preferred in the future.

  • Tapered Issuance Burn (8363): Effects on the validator set are not properly modelled and should not be underestimated. The consequences of this EIP as a monetary policy change are not researched enough. The incentives to replace ETH with LSTs whenever possible with the current curve are real and we’d like to see a more convincing proposal to solve the problem.

1 Like

On EIP-8163 (Reserve EXTENSION (0xae) opcode), placed in DFI with “No clear benefit for Ethereum”: the EIP is addressed to alt-L1s and L2s, and Ethereum benefits from the EVM R&D it enables in two ways:

  • With 0xae as a risk-free option, alt-L1 and L2 features can use an opcode wherever an opcode is the right tool. The resulting designs are better, and they are public, so Ethereum can later consider them in its own R&D.
  • Alt-L1 and L2 EVM R&D also strengthens the broader EVM ecosystem: features can be considered upstream, tooling improves, and adoption widens.

The EIP asks for no client changes in return. For more context, see examples of demand from alt-L1s. Any further detail on your reasoning would help us address the concern.