Ethereum undergoes upgrades in two main layers: the Execution Layer (EL) and the Consensus Layer (CL). The EL upgrades are named after cities that have hosted Devcon events, such as Shanghai and Cancun. The latest EL upgrade is titled after the city of Prague.

In contrast, the CL upgrades follow a different naming convention, as they are named after stars in alphabetical order. Similarly, after the 'Deneb' CL upgrade, the Ethereum community has decided the next upgrade to be named after the star 'Electra'.

What is the upgrade about?

The Electra upgrade is a planned improvement to the Ethereum network's consensus layer (CL). Upgrades to the CL involve changes to the underlying rules and mechanisms that govern how transactions are processed, how new blocks are added to the blockchain, and how network participants reach consensus.

Electra upgrade, includes EIPs that are considered for inclusion in this upgrade. The developers prioritize and decide on which proposed changes will be implemented in the Electra upgrade to enhance the functionality, security, and efficiency of the Ethereum network.

Furthermore, there is a dedicated page to oversee the Ethereum Improvement Proposals (EIPs) put forward for consideration in the Electra upgrade.

Electra EIPs for Discussion

The Ethereum community discussed proposed EIPs for inclusion in the upcoming Electra upgrade. The list of EIPs under consideration include:

EIP-7002: Enhanceing control with triggered exits

EIP-7002 aims to allow withdrawal credentials to trigger exits, enhancing security in cases of key loss. Its primary benefit is enabling more trustless staking pool designs on Ethereum. In the recent ACDC call(CL call 126), Danny Ryan provided a background on EIP-7002 addressing a flaw in the relationship between active and withdrawal credentials for validators.

EIP-6110: Supply validator deposits on chain

EIP-6110 is focused on improving the security and user experience(UX) for validators by including validator deposits directly in the execution layer blocks. Currently, the system relies on a voting mechanism to include deposits, but this EIP suggests a new in-protocol method.

  • How It Works:

    • Validator deposits are included in a block by parsing deposit contract log events from each deposit transaction.
    • A new block structure is introduced, starting from a specific block, which includes a list of deposit operations.

In simple terms, EIP-6110 aims to make the process of including validator deposits more secure, efficient, and less dependent on external factors.

EIP-2537: BLS12-381 Precompile for Ethereum

EIP-2537 proposes the addition of a precompile for BLS12-381 curve operations on the Ethereum blockchain. The purpose of this precompile is to efficiently perform operations such as BLS signature verification and SNARKs verifications, providing higher security compared to existing precompiles.

Proposed addresses table

Precompile Address
BLS12_G1ADD 0x0c
BLS12_G1MUL 0x0d
BLS12_G1MULTIEXP 0x0e
BLS12_G2ADD 0x0f
BLS12_G2MUL 0x10
BLS12_G2MULTIEXP 0x11
BLS12_PAIRING 0x12
BLS12_MAP_FP_TO_G1 0x13
BLS12_MAP_FP2_TO_G2 0x14

EIPs in Electra *Consideration

EIP Number EIP Name Consideration Reasoning
EIP 6110 Supply validator deposits on chain Confirmed for inclusion in Electra >Major security improvement; >Support from both CL and EL client teams
EIP 7002 Execution layer triggerable exits Considered for inclusion in Electra >Enable more trustless staking pool designs; >Support from both CL and EL client teams
EIP 7549 Move committee index outside attestation Confirmed for inclusion in Electra >Efficient aggregation of consensus votes; >Favored simplest implementation
EIP 6914 Reuse validator indices Not prioritized for Electra >Important for long-term health, but not prioritized for Electra; >Desire for a narrow and focused upgrade
EIP 7547 Inclusion lists Not prioritized for Electra >Mechanism for censorship resistance; >Complexity concerns and potential scope issues
EIP 7251 Increase the MAX_EFFECTIVE_BALANCE Ongoing discussions >Controversial due to complexity and dependencies; Discussions on implementation over multiple hard forks
EIP 7594 Peer Data Availability Sampling (PeerDAS) Conditional inclusion, ongoing discussions >Extension of EIP 4844; >Concerns about implementation and potential delays
SSZ EIPs SSZ Transactions Root, Withdrawals Root, Receipts Root, Transaction Signature Scheme, StableContainer Further discussions needed >SSZ-related changes to reduce size of transaction inclusion proofs and improve protocol complexity

These decisions underscore a deliberate approach by developers to make sure that the Electra upgrade enhances the network's security and functionality.

In the final stages of the decision-making process, proposals for the Prague-Electra upgrade are anticipated to undergo further scrutiny and discussion within the Ethereum community. The path forward involves achieving rough consensus on the selected proposals, and those reaching this consensus are likely to be advanced to the development network (devnet) for thorough testing and validation.

_____________________________________________________________________

Disclaimer: The information contained in this website is for general informational purposes only. The content provided on this website, including articles, blog posts, opinions, and analysis related to blockchain technology and cryptocurrencies, is not intended as financial or investment advice. The website and its content should not be relied upon for making financial decisions. Read full disclaimer and privacy Policy.

For Press Releases, project updates and guest posts publishing with us, email to contact@etherworld.co.

Subscribe to EtherWorld YouTube channel for ELI5 content.

Share if you like the content. Donate at avarch.eth or Gitcoin

You've something to share with the blockchain community, join us on Discord!

Follow us at Twitter, Facebook, LinkedIn, and Instagram.