The Prague/Electra (Pectra) Hardfork Explained

In our previous article, we extensively reviewed the lifecycle of Ethereum validators, discussing several aspects related to the upcoming Electra hardfork. Now, it’s time to focus on the upcoming changes in both the Electra and Prague upgrades and explain them in detail.

The history of Ethereum 2.0 "proof-of-stake" hardforks is complex. It began with the addition of the beacon layer to the existing execution layer, launching the proof-of-stake consensus on the beacon layer while still maintaining proof-of-work on the execution layer (the Phase0 and Altair hardforks). PoS was then fully activated at the Bellatrix hardfork (though withdrawals were not enabled). Subsequently, the Capella hardfork allowed withdrawals, completing the validator lifecycle. The most recent hardfork, Deneb (part of the Dencun(Deneb/Cancun) upgrade), brought minor revisions to beacon chain parameters, such as the time window for including attestations, handling voluntary exits, and the validator churn limit. The primary changes in Dencun were on the execution layer, introducing innovations like blob transactions, blob gas, KZG commitments for blobs, and deprecating the SELFDESTRUCT operation.

Now, the Prague/Electra hardfork introduces significant upgrades to both the execution and consensus layers. As auditors for the Lido project, our focus is mostly on the consensus and staking-related changes in this hardfork. However, we can't ignore the execution layer changes in Prague, as they include critical features that impact Ethereum’s network and validators. Let’s dive into the details of these changes.

Electra introduces numerous features for the beacon layer. The primary updates include:

• Allowing validators to have an effective balance ranging from 32 to 2048 ETH (instead of a fixed 32 ETH).
• Enabling validators to initiate exits with secondary "withdrawal" credentials (no longer requiring the active validator key).
• Changing how Eth1 deposits are processed by the beacon layer (moving away from parsing events from the deposit contract).
• Adding a new, general-purpose framework for handling requests from regular Eth1 contracts on the beacon layer (similar to how deposits were managed before Electra).

Meanwhile, Prague introduces changes to the execution layer, such as:

• A new precompiled contract supporting the BLS12-381 curve for verifying zkSNARK proofs (in addition to the popular BN254 curve).
• A new system contract for storing and accessing up to 8192 historical block hashes (useful for stateless clients).
• Increased calldata gas costs to reduce block size and encourage projects to move calldata-intensive operations (like rollups) to blobs, which were introduced in Dencun.
• Support for a greater number of blobs per Eth1 block, along with an API to read these numbers.
• Allowing EOAs (Externally Owned Accounts) to have their own account code, dramatically expanding what EOAs can do, like executing multicalls or delegating execution to other addresses.

Let’s reference the relevant Ethereum Improvement Proposals (EIPs) to facilitate further discussion:

• EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
• EIP-7002: Execution layer triggerable exits
• EIP-6110: Supply validator deposits on chain
• EIP-7549: Move committee index outside Attestation
• EIP-7685: General purpose execution layer requests
• EIP-2537: Precompile for BLS12-381 curve operations
• EIP-2935: Save historical block hashes in state
• EIP-7623: Increase calldata cost
• EIP-7691: Blob throughput increase
• EIP-7840: Add blob schedule to EL config files
• EIP-7702: Set EOA account code

Some of these EIPs primarily address the consensus (beacon) layer, while others pertain to the execution layer. Some span both layers, as certain operations like deposits and withdrawals require synchronized changes across the consensus and execution layers. Because of this interdependence, separating Electra and Prague is impractical, so we’ll review each EIP sequentially and specify the affected Ethereum component in each case.

Reference: EIP-7251

Since the first Phase0 hardfork, implemented to prepare Ethereum for Proof-of-Stake, and until Electra, the maximum effective balance of a validator was fixed at 32 ETH. Activating a validator requires at least the spec.min_activation_balance (32 ETH). After activation, the validator begins with this maximum effective balance but can reduce its effective balance to the spec.ejection_balance (16 ETH) and is ejected upon reaching that threshold. This "minimum" logic remains unchanged in Electra, but now the spec.max_effective_balance has increased to 2048 ETH. As a result, a validator can deposit anywhere between 32 and 2048 ETH for activation, with all amounts in this range contributing to their effective balance. This shift marks a move from "proof-of-32ETH-stake" to a "proof-of-stake" :)

This variable effective balance will now be used:

• to increase the probability of being a block proposer, proportional to the effective balance
• to increase the probability of being a sync committee member, proportional to the effective balance
• as a basis for calculating relative slashing and inactivity penalties amounts

The first two activities are the most rewarding actions for validators. Consequently, after Electra, validators with larger stakes will more frequently participate in block proposing and sync committees, proportional to their effective balance.

Another effect is related to slashings. All slashing penalties are proportional to the validator's effective balance:

• "Immediate" and "deferred" slashing penalties are larger for validators with higher stakes.
• "Deferred" slashing penalties for slashed validators alongside large-stake validators are also larger, as the "slashed" fraction of the total stake becomes greater.
• A whistleblower who reports a validator with a higher effective balance receives a larger fraction of the slashed stake.

Electra also proposes changes in slashing quotients, defining a fraction of validators balance being slashed and received by whistleblower.
Inactivity effects are next. When a validator is offline while active (attesting or proposing), an inactivity score accumulates, leading to inactivity penalties applied each epoch. These penalties are also proportional to the validator's effective balance.

Validator "churn limits" also experience changes due to increased effective balances. In "pre-Electra" Ethereum, validators generally have the same effective balance, and the exit churn limit is defined as "no more than 1/65536 (spec.churn_limit_quotient) of the total stake can exit in one epoch." This creates a "fixed" number of validator exits with the same stake. However, in "post-Electra," a scenario is possible where only a few "whales" exit, as they represent a significant portion of the total stake.

Another consideration is the rotation of many validator keys on a single validator instance. Large validators are currently forced to run thousands of validator keys on a single instance to accommodate large stakes, splitting them into 32 ETH parts. With Electra, this behavior is no longer mandatory. Financially, this change makes little difference since rewards and probabilities scale linearly with the staked amount. Thus, 100 validators with 32 ETH each are equivalent to one validator with 3200 ETH. Additionally, multiple active validator keys can have the same Eth1 withdrawal credentials, allowing all rewards to be withdrawn to a single ETH address and avoiding gas costs associated with reward consolidation. However, managing a large number of keys incurs extra administrative costs.

Ability to consolidate balances of validators adds another type of execution layer request. Previously, we had deposits and withdrawals. Now, there will be another type: a consolidation request. It will merge two validators into one. This operation request will include the source validator's pubkey and the target pubkey, and will be processed similarly to deposits and withdrawals. Consolidations will also have pending requests and balance churn limits, just like deposits and withdrawals.

To summarize:

• For small solo validators, Electra introduces the ability to automatically increase their effective balance (and rewards). Previously, any surplus above 32 ETH could only be withdrawn, but after Electra, this surplus will eventually contribute to their effective balance. However, effective balance can only increase in multiples of spec.effective_balance_increment (1 ETH), meaning the increase occurs only after reaching the next "1 ETH bound.”
• For large solo validators, Electra offers significant management simplification by allowing the consolidation of multiple active validator keys into one. While not a game changer, operating a single 1x2048 stake is undeniably simpler than managing 64x32 stakes.
• For liquid staking providers, who gather small stakes from users and distribute them among validators, Electra adds more flexibility in stake distribution schemes but, at the same time, requires serious refactoring of validator accounting, which is currently based on a fixed 32 ETH effective balance.

Another important topic is historical data and profit estimation for validators, which is especially relevant for new participants trying to evaluate risks and returns. The 32 ETH cap (both minimum and maximum, in practice) before Electra (as of the writing of this article) created uniformity in historical data. All validators had equal effective balances, rewards, individual slashing penalties, block proposal frequencies, and other metrics. This uniformity enabled Ethereum to test its consensus mechanism with a large number of validators without statistical outliers, gathering valuable network behavior data.

After Electra, the distribution of stakes will change significantly. Large validators will participate more often in block proposals and the sync committee, receive larger penalties in slashing events, and have greater influence on deferred slashings, activation queues, and exit queues. While this could create challenges in data aggregation, Ethereum's consensus ensures that non-linear calculations are minimal. The only non-linear component uses sqrt(total_effective_balance) to calculate the base reward, which applies uniformly to all validators. This means validator rewards and slashings can still be estimated on a "per 1 ETH" basis (or, more precisely, per spec.effective_balance_increment, which could potentially change in the future).

For more details, refer to our previous article on validator behavior.

Reference: EIP-7002

Each validator in Ethereum has two keypairs: an active key and a withdrawal key. The active public BLS key serves as the main identity of the validator in the beacon chain, and this keypair is used for signing blocks, attestations, slashings, sync committee aggregates, and (until this EIP) voluntary exits (to initiate the validator's exit from the consensus after a delay). The second keypair ("withdrawal credentials") can either be another BLS keypair or a regular Eth1 account (private key and address). Now, withdrawing to an ETH address requires a withdrawal message signed by the active BLS private key. This EIP changes that.

In practice, the owners of these two (active and withdrawal) keypairs can be different. The validator's active key is responsible for validation duties: running servers, keeping them operational, etc., while the withdrawal credentials are usually controlled by the stake owner, who receives rewards and is responsible for the funds. Currently, a stake owner who only controls the withdrawal credentials cannot initiate the validator's exit and can only withdraw rewards. This situation allows the validator's active key owner to effectively hold the validator's balance as "hostage." Validators can "pre-sign" exit messages and give them to stake owners, but this workaround is not ideal. Furthermore, both withdrawals and exits currently require interacting with the beacon layer validator using specialized APIs.

The optimal solution is to allow stake owners to perform both exit and withdrawal operations using a regular smart contract call. This involves a standard Eth1 signature check, greatly simplifying operations.

This EIP allows stake owners to trigger withdrawals and exits via a standard transaction from their ETH address to a dedicated smart contract (similar to the existing deposit process that uses the "Deposit" contract). The process of withdrawal (or exit if sufficient stake is removed) works as follows:

• The stake owner sends a withdrawal request ("in" request) to the system "Withdrawals" contract.
• The contract charges a specific fee (in ETH) to mitigate potential griefing attacks and operates similarly to EIP-1559, with fees increasing when the request queue is busy.
• The contract saves the "in" withdrawal/exit request to its storage.
• When a block is proposed to the beacon layer, the queued "in" withdrawal/exit requests are retrieved from storage.
• The beacon layer processes the "in" requests, interacting with the active validator's balance, scheduling the validator for exit, and forming "out" withdrawal requests.
• The "out" withdrawal requests are processed on the execution layer, and the stake owner receives their ETH.

While deposits were operations triggered in Eth1 blocks and then "moved" to the Beacon layer using the "pending" deposits queue, withdrawals followed a different scheme. They were triggered at the Beacon layer (via the CLI) and then "moved" to Eth1 blocks. Now, both schemes will operate using the same generic framework (described below): creation of requests at the Eth1 layer, processing of the "pending" deposits/withdrawals/consolidations queue, and processing at the Beacon layer. For "output" operations like withdrawals, the output queue is also processed, and the results are "settled" in Eth1 blocks.

With this EIP, stake owners can withdraw and exit their validators using regular ETH transactions without needing to interact directly with the validator CLI or access the validators' infrastructure. This greatly simplifies staking operations, particularly for large staking providers. Validators' infrastructure can now be almost fully isolated, as only active validator keys need to be maintained, while all staking operations can be handled elsewhere. It removes the need for solo stakers to wait for active validator actions and significantly simplifies the off-chain parts for services like Community Staking Module from Lido.

As a result, this EIP "completes" staking operations by fully migrating them to the Eth1 layer, significantly reduces infrastructure security risks, and enhances the decentralization of solo staking initiatives.

Reference: EIP-6110

Currently, deposits are implemented via events in the system "Deposit" contract (as discussed in detail in a previous article). The contract accepts ETH and validator credentials, emits a "Deposit()" event, and these events are later parsed and transformed into deposit requests on the beacon layer. This system has numerous drawbacks: it requires voting for eth1data on the beacon chain layer, which adds significant delays. Additionally, the beacon layer needs to query the execution layer, introducing further complexity. These issues are discussed in detail in the EIP. A simpler method, eliminating many of these problems, involves directly including deposit requests in Eth1 blocks at a designated location. This mechanism mirrors the withdrawal handling process described in the previous EIP.

The changes proposed in this EIP are promising. The eth1data processing can now be entirely removed, eliminating the need for voting or long delays between events on the Eth1 side and deposit inclusion on the beacon layer (currently around 12 hours). It also removes the logic for deposit contract snapshots. This EIP streamlines deposit processing and aligns it with the withdrawal processing scheme described above.
For both stake owners and validators, these changes significantly reduce the delay between a deposit and validator activation. Top-ups, which are necessary when a validator is slashed, will also be faster.

There isn’t much more to say about this EIP other than that it removes outdated logic, simplifying processes and creating better outcomes for everyone involved.

Reference: EIP-7685

This EIP should arguably have been presented before the three previous deposit/withdrawal/consolidation-related EIPs, as it lays the foundation for them. However, it is introduced here to emphasize the growing need for generic mechanisms to consistently move specialized data between the Eth1 (execution) and Beacon (consensus) chain blocks (layers). This EIP affects both layers, making the processing of requests triggered by regular ETH transactions more efficient. Currently, we observe:

• Deposit events in Eth1 blocks being "moved" from Eth1 to Beacon blocks for processing.
• Withdrawal requests in Beacon blocks (using CLI) being "moved" to Eth1 blocks for processing.
• The need to handle validator consolidations, that are also the Eth1->Beacon requests.

These three operations demonstrate the necessity of consistent handling for the various types of requests as they transition between the execution and beacon layers. Additionally, we need the ability to trigger these operations using the Eth1 layer only, as this will allow us to isolate validators' infrastructure from stake management infrastructure, enhancing security. Therefore, a generic solution for managing such requests is both practical and essential.

This EIP establishes a framework for at least three primary cases: deposits, withdrawals, and consolidations. This is why earlier EIPs introduced fields like WITHDRAWAL_REQUEST_TYPE and DEPOSIT_REQUEST_TYPE, and now consolidations will add another, CONSOLIDATION_REQUEST_TYPE. Additionally, this EIP will likely include common mechanisms to handle limits for such requests (reference constants: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).

Although detailed implementation specifics for this framework are not yet available, it will certainly incorporate key request types, integrity mechanisms (e.g., hashing and Merkle-izing requests), and pending queue processing with rate limiting.

This EIP carries architectural significance, enabling Eth1 to trigger critical actions in the Beacon layer through a unified framework. For end users and projects, this means all requests triggered at the Eth1 layer will be delivered and processed on the Beacon layer much more efficiently.

Reference: EIP-2537

If you don't want to delve too deeply, you can think of the BLS12-381 precompile as a complex cryptographic "hashing" operation that can now be used in smart contracts. For those interested, let's explore this further.

Mathematical operations on elliptic curves like BLS12-381 (and its counterpart: BN-254) are currently used for two primary purposes:

• BLS signatures, where a special operation called "pairing" is used to verify these signatures. BLS signatures are widely employed by validators because they enable the aggregation of multiple signatures into one. Validators rely on BLS signatures based on the BLS12-381 curve (though they can also be implemented using any curve that supports pairings, such as BN254).
• zkSNARK proofs verification, where pairings are used to validate proofs. Additionally, the KZG commitments to blobs (introduced by the Dencun hard fork) also use pairings for verifying blob commitments.

If you want to verify a BLS signature or a zkSNARK proof within a smart contract, you must compute these "pairings" which are computationally expensive. Ethereum already has a precompiled contract for BN254 curve operations (EIP-196 and EIP-197). However, the BLS12-381 curve (which is now recognized as more secure and is much more widely used today) has not been implemented as a precompile. Without such a precompile, implementing pairings and other curve operations in smart contracts requires heavy computations, as shown here, and consumes enormous amounts of gas (~10^5 to 10^6 gas).

This EIP opens the door to many potential applications, particularly in enabling cheap verification of BLS signatures based on the BLS12-381 curve. This makes it possible to implement threshold schemes for various purposes. As mentioned earlier, Ethereum validators already use BLS12-381-based signatures. With this EIP, standard smart contracts can now perform efficient verification of aggregated validator signatures. This can simplify consensus proofs and the bridging of assets between networks, as BLS signatures are widely used across blockchains. Threshold BLS signatures by themselves allow the construction of many efficient threshold schemes for voting, decentralized random number generation, multisigs, etc.

Cheaper zkSNARK proof verification will, in turn, unlock numerous applications. Many zkSNARK-based solutions are currently hindered by the high costs of proof verification, making certain projects almost impractical. This EIP has the potential to change that.

Reference: EIP-2935

This EIP proposes storing 8192 (~27.3 hours) historical block hashes within the blockchain state, providing an extended history for stateless clients (such as rollups) and smart contracts. It suggests retaining the current behavior of the BLOCKHASH opcode, maintaining the restriction to 256 blocks, while introducing a new system contract designed specifically to store and retrieve historical hashes. This contract performs a set() operation when the execution layer processes a block. Its get() method, accessible to anyone, retrieves the required block hash from a ring buffer.

Currently, it is possible to reference historical block hashes within the EVM, but access is limited to the 256 most recent blocks (~50 minutes). However, there are cases where access to older block data is essential, such as for cross-chain applications (which require proving data from previous blocks) and stateless clients, which periodically need access to earlier block hashes.

This EIP extends the time horizon available to rollups and cross-chain applications, allowing them to access historical data directly in the EVM without the need to gather it externally. As a result, these solutions become more robust and sustainable.

Reference: EIP-7623

Calldata costs regulate the available size of transaction payloads, which in some cases can be quite large (for example, when passing large arrays or binary buffers as parameters). Significant calldata usage is primarily attributed to rollups, which send payloads via calldata containing the current rollup state.

The ability to introduce large, provable binary data into the blockchain is essential for rollups. The Dencun (Deneb-Cancun) upgrade introduced a major innovation for such use cases — blob transactions (EIP-4844). Blob transactions have their own dedicated "blob" gas fees, and while their bodies are stored temporarily, their cryptographic proofs (KZG commitments), along with their hashes, are integrated into the consensus layer. Blobs thus provide a superior solution for rollups compared to using calldata for data storage.

Encouraging rollups to transition their data to blobs can be achieved using a "carrot and stick" approach. Reduced blob gas fees serve as the "carrot," while this EIP functions as the "stick" by increasing calldata costs, thereby discouraging excessive data storage in transactions. This EIP complements next EIP-7691 (Blob throughput increase), which raises the maximum number of blobs allowed per block.

Reference: EIP-7691

Blobs were introduced in the previous Dencun hard fork, and the initial values for the maximum and target number of "per-block" blobs were conservative estimates. This was due to the complexity of predicting how the p2p network would handle the propagation of large binary objects between validator nodes. The initial configuration has proven to work well, making this an appropriate time to test new values. Previously, the target/maximum numbers of blobs per block were set at 3/6. These limits are now being raised to 6/9, respectively.

When combined with previous EIP-7623 (Increase calldata cost), this adjustment further motivates rollups to transition their data from calldata to blobs. The search for optimal blob parameters continues.

Reference: EIP-7840

This EIP proposes adding the target and maximum number of "per-block" blobs (discussed earlier) and baseFeeUpdateFraction values into the Ethereum Execution Layer (EL) configuration files. It also enables clients to retrieve these values through the node API. This feature is particularly useful for tasks like estimating blob gas fees.

Reference: EIP-7702

This is a highly significant EIP that will bring major changes for Ethereum users. As we know, an EOA (Externally Owned Account) cannot have any code but can provide a transaction signature (tx.origin). In contrast, a smart contract has bytecode but cannot put forward "its" direct signature. Any interaction from a user that requires additional, automatic, and verifiable logic can currently only be achieved by calling an external contract to perform the required actions. However, in such cases, the external contract becomes the msg.sender for subsequent contracts, making the call "a call from a contract, not the user."

This EIP introduces a new SET_CODE_TX_TYPE=0x04 transaction type (we previously had the old 0x1 transactions, newer 0x02 transactions from the Berlin and EIP-1559 upgrades, and 0x03 blob transactions introduced in Dencun). This new transaction type enables setting code for an EOA account. Essentially, it allows an EOA to execute external code "in the context of its own EOA account". From an external perspective, it looks like, during a transaction, the EOA "borrows" code from an external contract and executes it. Technically, this is made possible by adding special authorization data tuples to the "code" storage of the EOA address (prior to this EIP, this "code" storage was always empty for EOAs).

Currently, this EIP proposes that the new 0x04 transaction type includes an array:

where each element allows the account to use the code from the specified address (from the last valid authorization item). Processing such a transaction sets the code of the given EOA to a special 0xef0100 || address (23 bytes) value, where address points to a contract with the desired code to be executed, || denotes concatenation, and 0xef0100 represents a special magic value that regular smart contracts cannot contain (as per EIP-3541). This magic value ensures that this EOA cannot be treated as a regular contract or have calls made to it as such.

When this EOA initiates a transaction, the specified address will be used to call the corresponding code within the context of that EOA. While full implementation details of this EIP are not yet known, it is certain that it will bring significant changes.

One major impact is enabling the ability to make multicalls directly from an EOA. Multicalls are an ongoing trend in DeFi, with many protocols offering this feature as a powerful tool (examples include Uniswap V4, Balancer V3, or Euler V2). With this EIP, multicalls can now be made directly from EOAs.

For example, this new feature resolves a common issue in DeFi: the inefficiency of approve() + anything() requiring two separate transactions. This EIP allows for a generic "pre-approval" logic, enabling actions like approve(X) + deposit(X) to be completed in a single transaction.

Another advantage introduced by the ability to delegate transaction execution "on behalf" of an EOA is the concept of sponsorship. Sponsorships are frequently discussed and highly desired features for onboarding new users to Ethereum.

Programmable logic associated with an EOA unlocks numerous possibilities, such as implementing security restrictions, setting spend limits, enforcing KYC requirements, and much more.

Naturally, this shift also raises many design questions. One issue is the use of chain_id, which determines whether the same signature can or cannot be valid across multiple networks based on its inclusion or exclusion in the signature. Another complex matter is whether to use the address of the target code versus embedding the actual bytecode. Both approaches have unique features and limitations. Additionally, the usage of nonce plays a key role in defining whether permissions are "multi-use" or "single-use." These elements influence features and security concerns, including aspects like mass invalidation of signatures and ease of use. Vitalik has raised these questions in a discussion (here), which are worth exploring further.

It is crucial to note that this change will impact one of Ethereum's security mechanisms, tx.origin. Further details about the implementation of this EIP are required, but it seems like that the behavior of require(tx.origin == msg.sender) will change. This check has been the most reliable way to ensure that msg.sender is an EOA and NOT a contract. Other methods, such as checking EXTCODESIZE (to check if it IS a contract), often fail and can be bypassed (e.g., by calling from a constructor or by deploying code at a predefined address after a transaction). These checks have been used to prevent reentrancy and flashloan attacks but are far from ideal as they also hinder integrations with external protocols. After this EIP, even the reliable require(tx.origin == msg.sender) check seems to become obsolete. Protocols must adapt by removing such checks, as the distinction between "EOA" and "contract" will no longer apply — now every address can potentially have associated code.

The traditional EOA and smart contract separation continues to blur. This EIP brings Ethereum closer to designs like TON, where every account is essentially executable code. This evolution is natural as interactions with protocols grow increasingly complex, making it necessary to use programmable logic to improve the UX for end users.

The Prague/Electra (Pectra) upgrade is scheduled for March 2025. Its most significant planned changes include:

• variable validators' effective stake, up to 2048 ETH, which will significantly alter the stake distribution, validator schedules, and simplify management for large staking providers by consolidating smaller stakes
• improved execution-to-consensus layer interaction, streamlining the exchange of data between Eth1 execution blocks and Beacon chain blocks. This will greatly simplify deposits, activations, withdrawals, and exits, speeding up these processes and laying the groundwork for further interactions between the consensus and execution layers
• support for cheaper BLS signature and zkSNARK verifications directly in smart contracts through the new "pairing-friendly" BLS12-381 precompile
• continuing to encourage rollups to adopt blob transactions instead of calldata by increasing blob transaction thresholds and raising calldata costs
• enabling EOAs to act as programmable accounts, empowering them with features like multicalls, sponsorships, and other advanced functionalities

As you can see, Pectra will significantly impact both the staking and consensus layers, as well as end-user experience at the execution layer. While we cannot analyze all these changes in detail through the code at this stage, as development is ongoing, we will cover these updates in future articles.

Stay tuned!