Ethereum Pectra Hard Fork Introduction

The Pectra hard fork is expected to start mainnet deployment in March 2025. The Pectra upgrade includes 11 technical protocols (EIPs).

Original article: Introduction to Ethereum Pectra Hard Fork

Author: NIC Lin

Compiled by: imToken

Cover: Photo by Shubham Dhage on Unsplash

The Pectra hard fork is expected to launch mainnet deployment in March 2025. The Pectra upgrade includes 11 technical protocols (EIPs), which are:

• EIP-2537: BLS12-381 curve operation precompilation
• EIP-2935: Save historical block hashes in State
• EIP-6110: Provide on-chain validator deposits
• EIP-7002: Execution layer triggered exit
• EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
• EIP-7549: Move committee index outside of validation
• EIP-7623: Increase calldata cost
• EIP-7685: Generic Execution Layer Request
• EIP-7691: Increase Blob throughput
• EIP-7702: Set EOA account code
• EIP-7840: Add Blob plan to EL configuration file

Technical agreements related to pledge

EIP-6110: BLS12-381 curve operation precompilation

Simplify the process for users to participate in staking and significantly shorten the waiting time.

The way for users to participate in staking is to deposit 32 ETH on the execution layer and record it in the event log. Then the consensus layer executes and parses the event log to determine whether anyone has participated in the staking, and then the users who participate in the staking become validators.

However, the validators at the consensus layer first need to reach a consensus on the time point at which the deposit was made. Otherwise, some validators will see 5 new deposits, while some validators will only see 3. Therefore, the consensus layer validators will vote on which execution layer block (eth1data) to refer to to ensure that everyone sees the same execution layer block.

However, in order to avoid major errors in the execution layer that could lead to chain forks, the reference execution layer block (eth1data) was an execution layer block from about 10 hours ago, ensuring that when major errors occur, the consensus layer developers have enough time to respond. However, this also means that participation in staking will take at least 10 hours to take effect.

After executing the EIP-6110 technical protocol, the user's pledge information on the contract will directly become part of the execution layer. Because the consensus layer block itself will contain the execution layer block (but not eth1data), the consensus layer validators no longer need to consider the issue of "confirming that the reference execution layer memory block is the same". As long as the consensus layer memory block is voted and confirmed by more than two-thirds of the validators, everyone will reach a consensus that they are seeing the same execution layer block. Therefore, after users participate in staking, the pledge will take effect in as little as 13 minutes after the execution layer memory block is processed, and the consensus layer client can also remove the complex logic originally used to process the staking data.

EIP-7002: Save historical block hashes in State

It can be used to improve the process of validators exiting staking or withdrawing deposits and earnings, and reduce the risks of validators.
Participating in staking requires two keys, namely Validator Key and Withdrawal Credential.
The Validator Key is used for the work content of the validator, and the Withdrawal Credential is used for the address where the deposit and income will be withdrawn when the validator exits the staking. In addition, the Validator Key operation is currently required to exit the staking.
If you lose your Validator Key, you will not be able to perform validator work and will not be able to withdraw from staking; if you lose your Withdrawal Credential, you will lose all your deposits and earnings. In addition, some users will use third-party staking services such as Lido. When using these platforms, users need to keep the Withdrawal Credential by themselves, while the Validator Key is kept by the service provider and performs the work of the validator on their behalf.
By executing the EIP-7002 technical protocol, users can use the Withdrawal Credential to call the "Withdraw Contract" (deployed at 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) to exit staking (Exit) or withdraw deposits and earnings (Partial Withdrawal), which can reduce the risks associated with using third-party staking services. If a user participates in staking on his own but loses the Validator Key, he can also use this to withdraw from staking.

• The parameters of the request include validator_pubkey and amount: validator_pubkey is the validator's Validator (Public) Key, and amount is the amount to be withdrawn.
• The Withdrawal Credential used to initiate the request must be the Withdrawal Credential of the validator_pubkey verifier.
• When calling the Withdraw contract to initiate a request, a Gas fee (ETH) must be attached. The Gas fee will be calculated based on the current number of withdrawal requests. If the number of requests is large, the Gas fee will increase.
• If the user's Withdrawal Credential is a contract, then you can first go to the Withdraw contract to obtain the current fee amount, and then initiate a request and attach the fee; but if the Withdrawal Credential is an EOA account, there is no way to obtain the accurate fee, and you can only simulate it off-chain in advance and pay the excess fee (which will not be refunded) to ensure that the request will be successfully executed.

Note: If your Withdrawal Credential is still in the BLS public key format, remember to switch it to the EL address format first.

EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

The upper limit of the staking amount can be significantly increased to reduce the number of validators, and validators who have not reached the upper limit can automatically enjoy the staking income.

To become a validator, users must provide MAX_EFFECTIVE_BALANCE amount of ETH, no less and no more (currently MAX_EFFECTIVE_BALANCE is 32 ETH). If a user holds 1024 ETH to stake, he can participate in the stake in 32 times, enable 32 validators, and run 32 validator nodes. Everyone's active participation in staking has also led to the current number of validators being around 1 million and continuing to increase. In addition to making the state data of the consensus layer larger and more, the load on the consensus layer p2p network layer is more significant, because each slot (every 12 seconds) has tens of thousands of validators' signatures that need to be continuously transmitted and aggregated in the p2p network layer.
After executing the EIP-7251 technical protocol, the staking lower limit (MIN_ACTIVATION_BALANCE) will still be 32 ETH, but the upper limit (MAX_EFFECTIVE_BALANCE) will be significantly increased to 2048 ETH. You can stake any amount of ETH between 32 and 2048, and you can obtain staking income. You no longer need to withdraw income regularly. You can continue to stake new ETH after accumulating 32 ETH.
Currently, existing validators do not need to withdraw their stakes and then merge them back together to stake. Instead, they can directly use the newly added "deposit merging contract" on the execution layer (deployed at 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb), and use the validator's Withdrawal Crendential to call the contract to initiate a deposit merging request.

• The parameters of the merge deposit request include source_pubkey and target_pubkey: these two keys are the validator keys of the validator, and the source validator will be merged into the target validator.
• The Withdrawal Credential used to initiate the request must be the Withdrawal Credential of the source verifier.
• When calling the merged deposit contract to initiate a request, a handling fee (ETH) must be attached. The handling fee will be calculated based on the current number of requests. If the number of requests is large, the handling fee will increase.
• If the user's Withdrawal Credential is a contract, then the combined deposit contract can be called first to obtain the current fee amount, and then the request can be initiated and the fee can be attached. However, if the Withdrawal Credential is an EOA account, there is no way to obtain the accurate fee. You can only simulate it off-chain in advance and pay the excess fee (which will not be refunded) to ensure that the request will be successfully executed.

Note: If your Withdrawal Credential is in BLS public key format, you need to switch it to EL address format first.

EIP-7685: Generic Execution Layer Request

Establish a formal EL -> CL information pipeline so that users and staking services can send requests directly to the consensus layer.

Users can send requests directly from the execution layer to the consensus layer, allowing staking services (such as Lido) to operate in a more decentralized manner. For example, the previously mentioned EIP-7002 request to exit staking, and the EIP-7251 request to merge deposits. Without this technical protocol, Lido users would have to trust that the Lido node service provider would faithfully execute the exit of pledge or the merging of deposits at the consensus layer; with this technical protocol, Lido users can send requests directly through the governance contract at the execution layer.

These requests will have Request Type to distinguish different types of requests, and initiate requests through different contracts. Finally, these requests will be written into the execution layer memory block, so the consensus layer can directly obtain this information through the execution layer memory block without having to write individual parsing logic.

EIP-6110, EIP-7002, and EIP-7251 all formulate requests based on the standards defined by EIP-7685:

• EIP-6110 adds staking request: Request Type=0, and initiates the request through the Deposit contract (0x00000000219ab540356cbb839cbe05303d7705fa).
• EIP-7002 staking withdrawal request: Request Type=1, initiate the request through the Withdraw contract (0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA).
• EIP-7251 merged deposit request: Request Type=2, initiate the request through the Consolidation contract (0x00431F263cE400f4455c2dCf564e53007Ca4bbBb).

Technical agreement to improve user experience

EIP-7702: Set EOA account code

Allow EOA accounts to be transformed into contract accounts at will, greatly improving the user experience.

There are some disadvantages in using EOA accounts, including:

• The private key or mnemonic phrase needs to be recorded and kept, and the threshold for new users to register and use it is high.
• An EOA account can only perform one operation per transaction. For example, if you want to exchange USDT for ETH on Uniswap, you must first initiate a transaction to approve USDT before you can send another transaction to perform the exchange.
• It is impossible to control permissions in detail, such as handing over certain operations of the account to a third party. Users must handle every chore personally and sign and send a transaction for each operation.
• There is no recovery mechanism, so you can only keep your private key or mnemonic phrase by yourself. If you lose it, you will never get your assets back.

If it is a smart contract account (such as Safe), the above problems can be solved:

• Users can use the private key in the security chip of their mobile phone (or computer) to sign and authorize, without having to remember any private key or mnemonic phrase, or sign and authorize via email, or use a variety of other authorization methods.
• Multiple operations can be batched together and executed together in the same transaction. The previously complex DApp operations can be completed with only one signature authorization and one transaction.
• There can be very detailed permission control, and users can authorize a third party to control their own accounts, but at the same time specify restrictions such as "what contracts can be interacted with", "what operations cannot be performed", "how much assets can be used for asset transfers", or "how many operations can be performed per week".
• A recovery mechanism can be added, so that when you lose your mnemonic phrase, mobile phone, or email, you can transfer your account assets to a new account through the recovery mechanism.

The EIP-7702 proposal is to give EOA accounts the ability to transform into contract accounts. The user signs the transformed message with the EOA private key. The signature content includes "Chain ID", "transformed contract address" and "EOA Nonce value":

• Chain ID: used to prevent the signature of chain A from being taken to chain B for replay. However, if the Chain ID is filled with 0, it means that you are willing to transform on every chain.
• Contract address you want to change to: If you fill in a Safe contract address, your EOA account will become a Safe contract; if you fill in a blank address (address(0)), it means you want to cancel the change and change back to a simple EOA account.
• Nonce value of EOA: used to prevent the signature from being replayed. If the Nonce value increases, the original signature will become invalid.

There are a few things to note though:

1. EOA private key can still be used

Even if a user's EOA account becomes a contract, he can still continue to use it in the same way as the original EOA account. For example, if your EOA account becomes a Safe contract, you can use the Safe interface and follow the Safe transaction process, or you can continue to sign and send transactions with the original EOA wallet. However, this also means that the security of the account is still limited to the private key.

2. Still the security of EOA private key

Even if the user's EOA becomes a multi-signature, as long as he does not lose the EOA private key, the security of his account will always be the security of the EOA private key: he still needs to keep his private key or mnemonic phrase well, and his account will not become as secure as a multi-signature.

3. Storage of EOA account will not be formatted

When an EOA account is transformed into a contract and writes data to its Storage, unless the data is explicitly deleted, the data written to the Storage will not be formatted because the EOA account is transformed into another contract or the transformation is canceled. Therefore, developers should pay attention to the Storage not to read the data left by the previous transformation contract. Please refer to ERC-7201.

4. The EIP-7702 process does not include initialization

Generally, contract accounts require an initialization step to synchronously write the account owner's information (such as public key or address) when the account is deployed to avoid the deployment step being front-run and causing loss of account ownership. This is usually performed by the Factory contract that deploys the contract account to perform "deployment + initialization", but because EIP-7702 is a direct change, rather than a Factory deploying the contract to the EOA, an attacker can copy the user's transformation signature and send the transaction to the chain first to transform the user but initialize the account to be controllable by the attacker, so developers need to pay attention to EIP-7702. Possible prevention methods include checking the signature of the EOA account in the initialization function, so that even if it is preempted, the attacker will not be able to generate the signature of the EOA account to complete the initialization.

5. Wallets should check change requests

The wallet needs to do a good job of screening for users. When a malicious DApp website requests users to sign a transformed transaction, the request should be blocked and the user should be warned. Otherwise, if the user signs a malicious transformed transaction, the assets will be transferred away instantly. Here are some examples of how to implement the transformation contract:

• Modified Safe Ithaca Account
• Ithaca Account

DApp Technical Protocol

EIP-2537: BLS12-381 curve operation precompilation

This will reduce the cost of zero-knowledge proof applications based on the BLS curve and make them more feasible.

EIP-2537 adds several precompiled contracts (Precompile) to provide cheap BLS curve operations, making it more feasible to develop zero-knowledge proof applications based on the BLS curve.

EIP-2935: Save historical block hashes in State

Allow developers or nodes to read the hash value (Block Hash) of past memory blocks directly from the storage of the system contract.

If a developer needs to prove the contents of a previous memory block, for example, in an Optimistic Rollup fraud challenge, it is necessary to prove that a certain transaction existed in 1,000 previous memory blocks. The challenger cannot say it directly.

"Please believe me that this transaction really existed 1000 memory blocks ago." He must provide evidence, but there is no direct evidence to directly prove that "the memory block 1000 years ago contains these contents." Therefore, he must use the memory block "chain" method to prove it one memory block at a time until he reaches the memory block 1000 years ago, and then prove that the transaction exists in that memory block.

Assume that the current memory block is numbered 10000, and the fraud challenge requires proof that a certain transaction X exists in the memory block numbered 9000. The challenger needs to start from the hash value of memory block 10000, first prove the hash value of the parent memory block 9999 to which memory block 10000 is connected, then prove memory block 9998... until memory block 9000, and finally propose that the content of memory block 9000 contains the transaction X.

After EIP-2935, there will be a system contract (deployed in

0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC), its Storage will store the hash values ​​of up to 8192 previous memory blocks. Whenever a new memory block is generated, the system contract will automatically update and write the hash value of the previous memory block into the system contract (the hash values ​​of 8192 previous memory blocks will be overwritten).

In this way, in the example of the Optimistic Rollup fraud challenge, the challenger does not have to prove it one memory block at a time, but can directly prove that in the current state of the chain of memory block 10000, the value of a Storage of the system contract (corresponding to memory block 9000) is the hash value of memory block 9000. If the range exceeds 8192, such as memory block 1000, then at most there is one more step, first proving the hash value of memory block 1808 (= 10000 – 8192), and then proving the hash value of memory block 1000 in the system contract in the current chain state of memory block 1808.

This also paves the way for future stateless clients: future light nodes will no longer need to store all the block headers in history. Instead, when the hash value or content of a certain memory block in history is needed, they can ask others to provide proof using the proof method in the previous fraud challenge example.

EIP-7623: Increase calldata cost

Increase the cost of publishing data using calldata to create enough safety margin to increase the Block Gas Limit and Blob number.

As the demand for Rollup data release increases, after Blob was introduced in EIP-4844 to allow Rollup to release data in a very cheap way, increasing the number of Blobs has always been an upgrade that the community has been looking forward to. Or, like the recent community push to increase the Block Gas Limit, it reflects the ecosystem's demand for increased resources.

However, whether the Block Gas Limit or the number of blobs is increased, it will put more pressure on Ethereum's p2p network because the amount of transaction data becomes larger, which will increase the efficiency of attackers' attacks, unless the cost of publishing data is also increased.

After the release of the EIP-7623 protocol, the cost of calldata will be increased by 2.5 times from the original "Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas" to "Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas".

Originally, if the attacker used the entire Block Gas Limit (30M) to store garbage data, the data size of the memory block would be about 1.79 MB (30M / 16), compared to the average memory block size of only about 100 KB; and if the Block Gas Limit is raised to 40M, the attacker can generate a memory block of about 2.38 MB. When the calldata cost is increased by 2.5 times, the attacker's efficiency will decrease to a maximum of 0.72MB for 30M and 0.95MB for 40M. This way, the Block Gas Limit and Blob number can be increased with greater confidence. However, this technical protocol does not want to affect ordinary users who "do not use calldata to publish data", so it will calculate the total gas usage of the transaction in two ways and take the higher one:

1. The original transaction gas usage calculation method is combined with the old calldata cost: that is, the calldata is calculated as "Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas", and the Gas consumed by transaction execution and the Gas consumed by deploying the contract are added.
2. Simply calculate the calldata Gas usage, but use the new cost: that is, calculate calldata as "Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas", but do not include the Gas consumed by execution or the Gas consumed by deploying the contract. Therefore, for users who "do not use calldata to publish data" (such as exchanging on Uniswap), the main Gas consumption is in the execution part. Even if calldata is calculated at the new cost, it will not exceed the Gas consumed by execution, so general users will not be affected.

The ones that will be really affected are the small-scale Rollups, because Blobs are of fixed size and fixed cost, so it is inefficient for small Rollups to use Blobs, and it is more cost-effective to use calldata. However, after EIP-7623, the cost of these small Rollups will increase by 2.5 times, so they may have to switch to using Blobs or find ways to join together to share a Blob.

EIP-7691: Increase Blob throughput

Increase the number of blobs to add more space for data publishing to Rollup.

EIP-7691 increases the number of blobs from "target: 3 blobs, upper limit: 6 blobs" to "target: 6 blobs, upper limit: 9 blobs", adding more space for data publishing to Rollup.

Note: In addition, there are some designs in the Blob fee market that need to be fine-tuned, such as the fee adjustment speed is not immediate enough and the fee floor is too low, but this is not the problem that this technical protocol aims to solve.

Other technical agreements

EIP-7549: Move the committee index outside of validation

Adjust the content of validator voting to make it easier to aggregate votes and reduce the pressure on the p2p network.

Validators will be randomly assigned to a group of committees at each Epoch and

For memory block voting, the votes of the validators of each committee can be aggregated together, which can reduce the number of votes transmitted in the p2p network. However, the validator's ballot will contain information about "which committee the validator belongs to", which means that the votes of different committees cannot be aggregated together, even if they all vote for the same memory block.

EIP-7549 removes the information of "which committee the validator belongs to" from the voting content, so that validators from different committees can be aggregated together when the voting content is the same, further reducing the number of votes transmitted in the p2p network and reducing the pressure on the p2p network.

EIP-7840: Add Blob plan to EL configuration file

Create a configuration file for Blob parameters at the execution layer, saving the trouble of the execution layer nodes asking the consensus layer nodes for Blob-related parameters.

Blob related parameters are currently stored in the consensus layer nodes, but the execution layer nodes still need these parameters in some cases (such as RPC eth_feeHistory), so they must ask the consensus layer nodes.

EIP-7840 creates a configuration file for Blob-related parameters at the execution layer. Execution layer nodes can directly read Blob-related parameters through this configuration file without having to ask the consensus layer nodes.

Disclaimer: As a blockchain information platform, the articles published on this site only represent the personal views of the authors and guests and have nothing to do with the position of Web3Caff. The information in the article is for reference only and does not constitute any investment advice or offer. Please comply with the relevant laws and regulations of your country or region.