Parse Ethereum's upcoming hard fork - Pectra Upgrade

introduce

In our previous article, we reviewed the life cycle of Ethereum validator in detail, discussing multiple aspects related to the upcoming Electra hard fork. Now, it's time to focus on changes in the upcoming Electra and Prague upgrades and explain them in detail.

The history of the "Proof of Stake" hard fork of Ethereum 2.0 is complex. It starts with adding a beacon layer to the existing execution layer, which maintains the proof of work (Phase0 and Altair hard forks) while the beacon layer initiates the proof of stake consensus. Subsequently, PoS is fully activated in the Bellatrix hard fork (although withdrawal is not enabled). Then, Capella hard fork allows withdrawals, completing the validator life cycle. Recent hard forks Deneb (part of Dencun (Deneb/Cancun) upgrades) have made minor revisions to beacon chain parameters, such as time windows containing proofs, handling of voluntary exits and validator replacement restrictions. The main changes in Dencun occur at the execution layer, launching blob transactions, blob gas, KZG promises for blobs, and abandoning SELFDESTRUCT operations.

Now, the Prague/Electra (i.e. Pectra) hard fork introduces important upgrades to the execution and consensus layers. As auditors for the Lido project, we focus primarily on consensus and staking-related changes in this hard fork. However, we cannot ignore the execution layer changes in Prague, because they include important features that affect the Ethereum network and validators. Let's dig into the details of these changes.

A higher level overview of Pectra

Electra introduces numerous features to the beacon layer. Main updates include:

• Allows the valid balance of the verifier to vary between 32 and 2048 ETH (rather than a fixed 32 ETH).

• Allows verifiers to initiate exits through secondary "withdrawal" vouchers (the active verifier key is no longer required).

• Changes how the beacon layer handles Eth1 deposits (the event is no longer parsed from the deposit contract).

• Add a new common framework for handling requests from regular Eth1 contracts on the beacon layer (similar to how pre-Electra deposits are managed).

Meanwhile, Prague introduced the following changes to the execution layer:

• A new precompiled contract that supports the BLS12-381 curve to verify zkSNARK evidence (except for the popular BN254 curve).

• A new system contract for storing and accessing up to 8192 historical block hashes (very useful for stateless clients).

• Increase calldata gas costs to reduce block size and encourage projects to migrate calldata-intensive operations such as rollup to blobs introduced in Dencun.

• Supports more blobs per Eth1 block and provides an API to read these numbers.

• Allowing EOA (External Owner Account) to have its own account code greatly expands what EOA can do, such as executing multicalles or delegating execution to other addresses.

Let's refer to the relevant Ethereum Improvement Proposal (EIP) for further discussion:

• EIP-7251: Added MAX_EFFECTIVE_BALANCE

• EIP-7002: Execution layer triggers exit

• EIP-6110: Verifier deposit is provided on-chain

• EIP-7549: Move the committee index out of the proof

• EIP-7685: General Execution Layer Request

• EIP-2537: Precompilation of BLS12-381 Curve Operation

• EIP-2935: Save historical block hash in state

• EIP-7623: Increase calldata cost

• EIP-7691: blob throughput increases

• EIP-7840: Adding blob schedule to EL configuration file

• EIP-7702: Setting up EOA Account Code

Some of these EIPs mainly involve the consensus (beacon) layer, while others are related to the execution layer. Some span two layers, because certain operations (such as deposits and withdrawals) require synchronous changes between the consensus and execution layers. Due to this interdependence, it is impractical to separate Electra and Prague, so we will review each EIP in turn and specify the Ethereum components affected in each case.

EIP-7251: Added MAX_EFFECTIVE_BALANCE

Reference: EIP-7251

Since the first Phase0 hard fork, in order to prepare proof of stake for Ethereum, the maximum valid balance of the verifier was fixed at 32 ETH until Electra. Activation validator requirements are at least spec.min_activation_balance (32 ETH). After activation, the validator starts with this maximum valid balance, but can reduce its valid balance to spec.ejection_balance (16 ETH) and be evict when this threshold is reached. This "minimum" logic remains unchanged in Electra, but now spec.max_effective_balance has been increased to 2048 ETH. Therefore, the validator can deposit between 32 and 2048 ETH to activate, all of which will contribute their valid balance. This shift marks the shift from "32ETH-Proof of Stake" to "Proof of Stake" :)

This variable valid balance will now be used for:

• Increase the probability of becoming a block proposer, proportional to the effective balance

• Increase the probability of becoming a member of the synchronous committee, proportional to the effective balance

• As the basis for calculating the amount of relative cuts and inactive penalties

The first two activities are the most rewarding actions for validators. Therefore, after Electra, validators of large stakes will participate more frequently in the block proposal and synchronization committees, with frequency proportional to their effective balance.

Another impact has to do with cuts. All cuts are proportional to the valid balance of the verifier:

• "Immediate" and "Delay" cuts are even greater for validators of high stakes.

• The "delayed" cut fines are also greater with the cut-off validators with high pledges, as the "cut-off" part of the total pledge becomes larger.

• Whistleblowers who report validators with higher valid balances receive a larger proportion of reduced stakes.

Electra also proposed changes to the cut ratio, defining a portion of the slashed validator balance and receiving it by the whistleblower.

Next is the impact of invalidity. When the validator is offline when active (prove or propose), the invalidity score accumulates, resulting in the imposition of invalidity penalty for each cycle. These penalties are also proportional to the valid balance of the validator.

Due to the increase in valid balance, the "replacement limit" of the verifier has also changed. In Ethereum "before Electra", validators usually have the same valid balance, and the exit replacement limit is defined as "In a cycle, there cannot be a maximum of 1/65536 (spec.churn_limit_quotient) total stake to be exited." This creates A "fixed" number of verifier exits with the same stake. However, after Electra, there may be only a few "whales" exit because they represent an important part of the total pledge.

Another consideration is the rotation of many verifier keys on a single verifier instance. Large validators are currently forced to run thousands of validator keys on one instance to accommodate large staking, splitting them into 32 ETH sections. With Electra, this behavior is no longer mandatory. From a financial perspective, this change has little impact because the rewards and probability are linearly scaled with the amount of pledge. Therefore, 100 validators for each 32 ETH are equivalent to one 3200 ETH. Additionally, multiple active verifier keys can have the same Eth1 withdrawal credential, allowing all rewards to be withdrawn to a single ETH address, thereby avoiding gas costs associated with reward mergers. However, managing large amounts of keys incurs additional administrative costs.

The ability to aggregate validator balances adds a new execution layer request type. Before, we had deposits and withdrawals. Now, there will be another type: aggregate request. It combines two validators into one. This operation request will include the source verifier's public key and the target public key and will be processed similarly to deposits and withdrawals. Aggregations will also have pending requests and balance replacement restrictions, just like deposits and withdrawals.

The summary is as follows:

• For small independent validators, Electra introduces the ability to automatically increase their effective balance (and rewards). Previously, any surplus exceeding 32 ETH could only be withdrawn, but after Electra, this surplus will eventually contribute to its effective balance. However, the effective balance can only increase by multiples of spec.effective_balance_increment (1 ETH), which means that the increase only occurs after the next "1 ETH limit".

• For large independent validators, Electra provides significant management simplification by allowing multiple active validator keys to be consolidated into one. While this won't change the game, operating a 1x2048 stake is undoubtedly much easier than managing 64x32 stakes.

• For mobile staking providers, who collect small staking from users and allocate between validators, Electra adds more flexibility in the staking allocation scheme, but also requires accounting for validators based on fixed 32 ETH valid balances Perform severe refactoring.

Another important topic is the historical data and profit estimation of validators, especially relevant to new participants, who try to assess risks and rewards. Prior to Electra (as of this writing), the 32 ETH cap (both smallest or largest, actually) created uniformity in historical data. All validators have the same validation balance, rewards, individual cut penalties, block proposal frequency and other metrics. This uniformity allows Ethereum to test its consensus mechanism without statistical outliers, thereby collecting valuable network behavior data.

After Electra, the distribution of staking will change significantly. Large validators will be involved in block proposals and synchronization committees more frequently, with greater penalties in cuts and greater impact on delayed cuts, activation queues and exit queues. While this may create challenges in data aggregation, Ethereum’s consensus ensures that nonlinear computing is minimal. The only nonlinear component uses sqrt(total_effective_balance) to calculate the base reward, which applies to all validators. This means that validator rewards and cuts can still be estimated on a "per-1 ETH" basis (or more precisely, based on spec.effective_balance_increment, which may change in the future).

For more details, see our previous article on validator behavior.

EIP-7002: Triggerable execution layer exit

Reference: EIP-7002

Each validator in Ethereum has two key pairs: an active key and an withdrawal key. An active public BLS key serves as the primary identity of the verifier in the beacon chain, which is used to sign blocks, proofs, cuts, synchronize committee aggregations, and (before this EIP) voluntary exit (to follow a delay Initiate the verifier's consensus exit). The second key pair ("withdrawal voucher") can be another BLS key pair or a regular Eth1 account (private key and address). Now, withdrawal messages that are signed by the active BLS private key are required to be extracted to the ETH address. This EIP has been changed.

In fact, the owners of these two (active and withdrawal) key pairs can be different. The verifier's active key is responsible for verification responsibilities: running the server, keeping it running normally, etc., and withdrawal vouchers are usually controlled by the stake owner, who receives rewards and is responsible for funds. At present, only the pledge owner who controls the withdrawal voucher cannot initiate the verifier's exit, and can only withdraw the reward. This situation allows the verifier's active key owner to effectively hold the verifier's balance as a "hostage" in his hand. The verifier can "pre-sign" the exit message and hand it over to the stakeholder, but this workaround is not ideal. In addition, both extraction and exit currently require interaction with beacon layer validators through a dedicated API.

The best solution is to allow the stake owner to perform both exit and withdrawal operations through regular smart contract calls. This involves standard Eth1 signature checking, which greatly simplifies operations.

This EIP allows stakeholders to trigger withdrawals and exits by sending standard transactions to dedicated smart contracts from their ETH address (similar to the existing deposit process using "deposit" contracts). The process of extracting (or exiting when sufficient stake is removed) is as follows:

• The pledger sends a withdrawal request ("in" request) to the system's "withdrawal" contract.

• The contract charges specific fees (in ETH) to mitigate potential malicious attacks, and similar to EIP-1559, the fees increase 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 "in" withdrawal/exit request in the queue is retrieved from the storage.

• The beacon layer processes the "in" request, interacts with the balance of the active verifier, arranges the verifier to exit, and forms a "out" withdrawal request.

• "out" withdrawal request is processed at the execution layer, and the stakeholder receives their ETH.

Although deposits are operations triggered in the Eth1 block and then "moved" to the beacon layer through the "pending" deposit queue, withdrawals follow different schemes. They are triggered on the beacon layer (via the CLI) and then "moved" to the Eth1 block. Both schemes will now operate through the same common framework (as described below): create a request at the Eth1 layer, process the "pending" deposit/withdrawal/merge queues, and process it at the beacon layer. For "output" operations like withdrawal, the output queue will also be processed, and the result will be "settled" in the Eth1 block.

With this EIP, stakers can use regular ETH transactions to extract and exit their validators without directly interacting with the validator CLI or accessing the validator's infrastructure. This greatly simplifies staking operations, especially for large staking providers. Verifier infrastructure can now be almost completely isolated because only the key of the active verifier is maintained, while all staking operations can be handled elsewhere. It eliminates the need for independent stakers to wait for active validator actions and significantly simplifies the off-chain portion of Lido services like Community Staking Module.

Therefore, this EIP "completes" the staking operation, completely migrating it to Eth1 layer, significantly reducing infrastructure security risks and enhancing the decentralization of independent staking initiatives.

EIP-6110: Supply of verifier deposits on the chain

Reference: EIP-6110

Currently, deposits are achieved through events in the system's "deposit" contract (as discussed in detail in previous articles). The contract accepts ETH and verifier credentials and issues "Deposit()" events, which are then parsed and converted into deposit requests on the beacon layer. The system has many disadvantages: it requires voting on the eth1data of the beacon chain layer, which adds significant delays. In addition, the beacon layer needs to query the execution layer, which further increases complexity. These issues are discussed in detail in the EIP. An easier way to do without dealing with many of these issues is to include deposit requests directly in the Eth1 block at the specified location. This mechanism is similar to the withdrawal processing process described in the previous EIP.

The changes proposed in this EIP are promising. The eth1data processing can now be completely removed, no longer having to vote or prolonged delays between events on the Eth1 side and deposit inclusions on the beacon layer (currently approximately 12 hours). It also removes the logic of deposit contract snapshots. This EIP simplifies deposit processing and aligns it with the withdrawal processing scheme described above.

For stakers and validators, these changes significantly reduce the delay between deposit and validator activation. When validators are cut, the necessary supplements will also be faster.

There is nothing more to say about this EIP, except that it removes outdated logic, simplifies the process and creates better results for all involved.

EIP-7685: General Execution Layer Request

Reference: EIP-7685

This EIP should have been proposed before the first three EIPs related to deposit/withdrawal/consolidation because it lays the foundation for these EIPs. However, the introduction here is to emphasize the growing demand for consistent mobile dedicated data between Eth1 (execution) and beacon (consensus) chain blocks (layers). This EIP affects two layers, making request processing triggered by regular ETH transactions more efficient. Currently, we observe:

• The deposit event in the Eth1 block is "moved" to the beacon block for processing.

• The withdrawal request in the beacon block (using the CLI) is "moved" to the Eth1 block for processing.

• Verifier merge needs to be processed, which is also Eth1->beacon request.

These three operations demonstrate the necessity of consistent processing of various types of requests when switching between the execution layer and the beacon layer. Furthermore, we need the ability to trigger these operations using only Eth1 layer, as this will allow us to isolate the validator's infrastructure from the staking management infrastructure, thereby improving security. Therefore, a general solution to manage such requests is both practical and necessary.

This EIP establishes a framework for at least three main situations: deposits, withdrawals and mergers. This is why early EIP introduced fields like WITHDRAWAL_REQUEST_TYPE and DEPOSIT_REQUEST_TYPE, and now merge will add another field, CONSOLIDATION_REQUEST_TYPE. In addition, this EIP may include a common mechanism for handling restrictions on such requests (reference constants: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).

While detailed implementation details of this framework are still unavailable, it will certainly include critical request types, integrity mechanisms (e.g., hashing and Merkelized requests), and pending queue processing and rate limiting.

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

EIP-2537: Precompilation of BLS12-381 Curve Operation

Reference: EIP-2537

If you don't want to get a deeper look, you can think of the precompilation of BLS12-381 as a complex encryption "hash" operation that can now be used in smart contracts. For those interested, let us explore further.

Mathematical operations on elliptic curves such as BLS12-381 (and their corresponding BN-254) are currently mainly used for two purposes:

• BLS signatures, where a special operation is used called "pairing" to verify these signatures. BLS signatures are widely used by verifiers because they aggregate multiple signatures into one. Verifiers rely on BLS signatures based on BLS12-381 curves (although they can also be implemented using any curve that supports pairing, such as BN254).

• Verification of zkSNARK proofs, where pairing is used to verify proofs. Additionally, the KZG commitments for large chunks introduced by the Dencun hard fork also use pairing to validate block commitments.

If you want to verify BLS signatures or zkSNARK proofs in a smart contract, you have to calculate these "pairs", which is computationally expensive. Ethereum already has a precompiled contract (EIP-196 and EIP-197) for BN254 curve operation. However, the BLS12-381 curve (now considered safer and more widely used today) has not yet been implemented as precompiled. In the absence of such precompilation, implementing pairing and other curve operations in smart contracts requires a lot of calculations, as shown here, and consumes huge gases (about ~10^5 to 10^6 gas).

This EIP opens the door to many potential applications, especially in cheap BLS signature verification based on the BLS12-381 curve. This makes it possible to achieve threshold solutions for various purposes. As mentioned earlier, Ethereum validators have used BLS12-381-based signatures. With this EIP, standard smart contracts can now efficiently verify aggregated verifier signatures. This can simplify the bridging of proof of consensus and across network assets, as BLS signatures are widely used in blockchains. The threshold BLS signature itself allows the construction of many efficient threshold schemes for voting, decentralized random number generation, multi- signature, etc.

Cheaper zkSNARK proof verification will in turn unlock a large number of applications. Many zkSNARK-based solutions are currently hampered by high proof verification costs, which makes certain projects almost impractical. This EIP has the potential to change this.

EIP-2935: Save historical block hash in state

Reference: EIP-2935

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

Currently, it is possible to reference historical block hash in EVM, but access is limited to the most recent 256 blocks (approximately 50 minutes). However, access to older block data is critical in some cases, especially for cross-chain applications (data that requires proven previous blocks) and stateless clients, which periodically require access to early block hashes.

This EIP extends the timeframe available for rollup and cross-chain applications, allowing them to directly access historical data in the EVM without having to collect it externally. As a result, these solutions become more robust and sustainable.

EIP-7623: Increase calldata cost

Reference: EIP-7623

The calldata cost regulates the available size of the transaction payload and can be large in some cases (e.g., when passing large arrays or binary buffers as parameters). Significant calldata usage is mainly attributed to rollups, which send payloads through calldata containing the current rollup state.

Introducing large, proven binary data into blockchain is crucial to rollup. The Dencun (Deneb-Cancun) upgrade introduces an important innovation to such use cases - blob transactions (EIP-4844). Blob transactions have their own special "blob" gas fees. Although their subject is temporarily stored, its cryptographic proof (KZG promise) is integrated into the consensus layer along with its hash. Therefore, blob provides a better solution for rollup than using calldata to store data.

Encourage rollup to transfer its data to the blob. This can be achieved by "carrot and stick". The reduced blob gas fee is used as a "carrot", and this EIP suppresses excessive data storage in transactions by increasing calldata cost as a "leverage". This EIP complements the next EIP-7691 (increased Blob throughput), which increases the maximum number of blobs allowed per block.

EIP-7691: blob throughput increases

Reference: EIP-7691

Blobs were introduced in the previous Dencun hard fork, and the initial values ​​of the maximum and target number of blobs "per block" are conservative estimates. This is due to the complexity of predicting how the p2p network will handle the propagation of large binary objects between validator nodes. The previous configuration has proven good, which makes this the right time to test new values. Previously, the target/maximum blob number per block was set to 3/6. These restrictions are now raised to 6/9 respectively.

Combined with previous EIP-7623 (increasing calldata costs), this adjustment further motivated rollup to transfer its data from calldata to blobs. The work of finding the best blob parameters continues.

EIP-7840: Add blob schedule to EL configuration file

Reference: EIP-7840

This EIP proposes to add the target and maximum "per-block" blob count (discussed earlier) and the baseFeeUpdateFraction value to the Ethereum Execution Layer (EL) configuration file. It also enables clients to retrieve these values ​​through the node API. This feature is especially useful for tasks such as estimating blob gas costs.

EIP-7702: Set up EOA Account Code

Reference: EIP-7702

This is a very important EIP that will bring significant changes to Ethereum users. As we know, EOA (external owned account) cannot have any code, but can provide a transaction signature (tx.origin). In contrast, smart contracts have bytecode, but cannot proactively propose a direct signature of "it". Any user interaction that requires additional, automatic and verifiable logic can currently only perform the required actions by calling external contracts. However, in this case, the external contract becomes the msg.sender of the subsequent contract, causing the call to "the call from the contract, not the user".

This EIP introduces a new SET_CODE_TX_TYPE=0x04 transaction type (we previously had old 0x1 transactions, new 0x02 transactions from Berlin and EIP-1559 upgrades, and 0x03 blob transactions introduced in Dencun). This new transaction type allows you to set up codes for EOA accounts. In fact, it allows EOA to execute external code "in the context of its own EOA account." From an external perspective, during the transaction process, EOA seems to "borrow" the code from the external contract and execute it. Technically, this is achieved by adding a special authorized data tuple to the "code" store of the EOA address (this "code" store was always empty to the EOA before this EIP).

Currently, the new 0x04 transaction type proposed by this EIP contains an array:

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

Each element allows the account to use the code from the specified address (from the last valid authorization item). When processing such transactions, the given EOA's code is set to a special 0xef0100 || address value (23 bytes), where the address points to a contract with the required code, || means the connection, and 0xef0100 means that the regular smart contract cannot be included Special magic value (according to EIP-3541). This magic value ensures that this EOA cannot be considered a regular contract, nor can it be called like a regular contract.

When this EOA initiates a transaction, the specified address will be used to call the corresponding code in the context of the EOA. Although the complete implementation details of this EIP are not clear, it is certain that it will bring significant changes.

One major impact is the ability to make multicalls directly from EOA. Multiple calls are a persistent trend in DeFi, and many protocols provide this feature as a powerful tool (such as Uniswap V4, Balancer V3, or Euler V2). With this EIP, you can now initiate multiple calls directly from EOA.

For example, this new feature solves a common problem in DeFi: approve() + anything() requires inefficiency of two independent transactions. This EIP allows common "pre-authorization" logic, so that like approve(X) + deposit(X) can be completed in a single transaction.

Another advantage of being able to “represent” EOA commissioned transaction execution is the concept of sponsorship. Sponsorship is a frequently discussed and highly desireable feature to help new users enter Ethereum.

The programmable logic associated with EOA unlocks many possibilities such as implementing security restrictions, setting spending caps, mandatory KYC requirements, and more.

Of course, this change also raises many design issues. One problem is the use of chain_id, which determines whether the same signature can be valid across multiple networks, depending on whether it is included or not included in the signature. Another complex problem is the choice between using the address of the target code and embedding the actual bytecode. These two methods have their own unique characteristics and limitations. In addition, the use of nonce plays a key role in defining whether permissions are “multi-purpose” or “single-purpose”. These elements affect functional and security issues, including batch failure signatures and ease of use. Vitalik raised these questions in a discussion (here) that deserves further exploration.

It is worth noting that this change will affect a security mechanism of Ethereum, tx.origin. More details about this EIP implementation are necessary, but it looks like the behavior of require(tx.origin == msg.sender) will change. This check has always been the most reliable way to make sure that msg.sender is EOA, not a contract. Other methods, such as checking EXTCODESIZE (to check if it is a contract), usually fail and can be circumvented (e.g. by calling the constructor or deploying the code at a predefined address after a transaction). These checks are used to prevent reentry and lightning loan attacks, but are far from ideal, as they also hinder integration with external protocols. After this EIP, even the reliable require(tx.origin == msg.sender) check seems to become obsolete. The protocol must be adapted by removing these checks, because the difference between "EOA" and "Contract" will no longer apply - now there may be relevant code for each address.

The separation between traditional EOA and smart contracts continues to be blurred. This EIP brings Ethereum closer to a design like TON, where every account is essentially executable code. As interactions with protocols become more complex, using programmable logic to improve the end user experience is a natural process of this evolution.

in conclusion

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

• Variable verifier valid stakes up to 2048 ETH, which will significantly change the stake distribution, verifier timeline, and simplify the management of large stake providers by integrating smaller stakes

• Improve the interaction between the execution layer and the consensus layer, and simplify the data exchange between the Eth1 execution block and the beacon chain block. This will greatly simplify deposits, activations, withdrawals and exits, speed up these processes, and lay the foundation for further interaction between the consensus layer and the execution layer

• Support for cheaper BLS signatures and zkSNARK verification directly with new "pair-friendly" BLS12-381 precompilation in smart contracts

• Encourage Rollups to adopt blob transactions by increasing blob transaction thresholds and increasing calldata costs

• Make EOA act as a programmable account, giving it multiple calls, sponsorships, and other advanced features

As you can see, Pectra will have a significant impact on the end user experience of the staking and consensus layer, as well as the execution layer. While we cannot analyze all these changes in detail through code at this stage, as development is still in progress, we will cover these updates in future articles.