Ethereum Pectra Hard Fork Introduction

Author: NIC Lin, Medium

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

• EIP-2537: BLS12-381 curve operation precompile
• EIP-2935: Save historical block hash values in State
• EIP-6110: Provide on-chain validator deposits
• EIP-7002: Execution Layer Triggers Exit
• EIP-7251: Add the MAX_EFFECTIVE_BALANCE
• EIP-7549: Move the committee index outside of verification
• EIP-7623: Increase calldata cost
• EIP-7685: General Execution Layer Request
• EIP-7691: Increase blob throughput
• EIP-7702: Set EOA account code
• EIP-7840: Add Blob scheduling in the EL configuration file

Technical protocols related to staking

EIP-6110: BLS12-381 Curve Operations Precompile

Simplify the processing flow for user participation in staking, greatly reducing 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 will execute and parse the event log to determine if anyone has participated in staking, and the users who participate in staking will become validators.

However, the validators of the consensus layer first need to reach consensus on which point in time to deposit, otherwise, some validators will see 5 new deposits, while some validators will only see 3, so 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 a major error in the execution layer and a chain fork, the reference execution layer block (eth1data) will be an execution layer block about 10 hours ago to ensure that when a major error occurs, the consensus layer developers have enough time to react and deal with it, but this also leads to the participation in the staking will not take effect for more than 10 hours at the earliest.

In block △ CL, the 10900000 eth1data records the Block Hash of execution layer block 21683339, which occurred 10 hours ago.

After the implementation of EIP-6110 technical protocol, the user's staking data on the contract will directly become a part of the execution layer. And because the consensus layer blocks themselves will contain execution layer blocks (but not eth1data), consensus validators no longer need to consider the issue of 'confirming that the reference execution layer blocks are the same'. As long as the consensus layer blocks obtain confirmation votes from more than two-thirds of the validators, consensus is reached on the same execution layer blocks that everyone sees. Therefore, after participating in staking, the user can take effect in as fast as about 13 minutes after the execution layer blocks are processed, and the consensus layer client can also remove the original complex logic related to processing staking data.

EIP-7002: Save historical block hash values in State

It can be used to improve the process of validator exit staking or withdrawing staking and income, reducing the risk of validators.

To participate in staking, you need two keys, namely the Validator Key and Withdrawal Credential.

Validator Key is used to validate the work content of validators. Withdrawal Credential is the address to which the pledge and earnings will be withdrawn when the validator exits. Additionally, currently, Validator Key must be used to exit the pledge.

If the Validator Key is lost, the validator work cannot be performed, and the pledge cannot be exited; if the Withdrawal Credential is lost, all deposits and profits will be lost. In addition, some users will use third-party staking services such as Lido. When using these platforms, users need to keep the Withdrawal Credential themselves, while the Validator Key is kept by the service provider to perform validator work on their behalf.

Implementing the EIP-7002 technical protocol, users can use the Withdrawal Credential to call the "Withdraw Contract" (i.e., deployed in the 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) to exit or withdraw the deposit and income (Partial Withdrawal), which can reduce the risks associated with using third-party staking services. If a user participates in staking on their own but loses their Validator Key, they 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 that initiates the request must be the Withdrawal Credential of the validator_pubkey validator.
• When calling the Withdraw contract to initiate a request, you need to attach Gas fee (ETH). The Gas fee will be calculated based on the current withdrawal request quantity. If the quantity of requests is large, the Gas fee will increase.
• If the user's Withdrawal Credential is a contract, they can first go to the Withdraw contract to obtain the current handling fee amount, and then initiate the request and attach the handling fee; but if the Withdrawal Credential is an EOA account, it is not possible to obtain an accurate handling fee, only pre-chain simulation and payment of excess handling fee (not refundable), to ensure that the request initiation will be successful.

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

EIP-7251: increase the MAX_EFFECTIVE_BALANCE

Being able to significantly increase the upper limit of the pledged amount to reduce the number of validators, and validators who have not reached the limit can automatically enjoy the pledged income.

To become a validator by staking, users need to provide an amount of ETH equal to MAX_EFFECTIVE_BALANCE, neither less nor more (currently set at 32 ETH). For example, if a user holds 1024 ETH to stake, they can stake in 32 increments, activate 32 validators, and run 32 validator nodes. The active participation in staking has led to approximately 1 million validators currently and the number continues to increase. This not only makes the state data at the consensus layer larger, but also significantly increases the load on the consensus layer's p2p network, as each Slot (every 12 seconds) requires the continuous transmission and aggregation of tens of thousands of validator signatures in the p2p network layer.

After implementing the EIP-7251 technical protocol, the minimum staking threshold (MIN_ACTIVATION_BALANCE) remains at 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 to earn staking rewards, without the need to withdraw earnings regularly. You can continue staking after accumulating 32 ETH.

Currently, existing validators do not need to withdraw their stakes separately before merging and re-staking together. Instead, they can directly utilize the newly added 'merge deposit contract' on the execution layer (deployed at 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb), and initiate the merge deposit request by calling the contract with the Withdrawal Credential of the validator.

• The parameters of the merge deposit request include source_pubkey and target_pubkey: both keys are validator keys of the validator, and the source validator will be merged into the target validator.
• The Withdrawal Credential initiating the request must be the Withdrawal Credential of the source validator.
• When calling the merger deposit contract to initiate a request, a fee (ETH) will be attached, and the fee will be calculated according to the current number of requests, if the number of requests is large, the fee will increase.
• If the user's Withdrawal Credential is a contract, they can first call the merge deposit contract to obtain the current handling fee amount, and then initiate the request with the handling fee; but if the Withdrawal Credential is an EOA account, it is impossible to obtain an accurate handling fee, so you can only simulate off-chain in advance and pay an extra handling fee (non-refundable) to ensure that the request is successfully executed.

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

EIP-7685: General Execution Layer Request

CL information channel, so that users and staking services can directly send requests to the consensus layer.

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

These requests will have a Request Type to distinguish between different types of requests, and the requests are initiated through different contracts, and finally these requests will be written to 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 are all based on the criteria defined by EIP-7685:

• EIP-6110 Staking Request: Request Type=0, through the Deposit contract

(0x00000000219ab540356cbb839cbe05303d7705fa) initiated the request.

• EIP-7002 Exit Staking Request: Request Type=1, via Withdraw contract

(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) Initiating a request.

• EIP-7251 merging deposit request: Request Type=2, through the Consolidation contract

(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) initiated the request.

Technical protocol to improve user experience

EIP-7702: Setting EOA Account Code

Allow EOA accounts to transform into contract accounts at will, significantly improving the user experience.

There are some shortcomings in the use of EOA accounts, including:

• It is necessary to record and keep the private key or mnemonic phrase, and the threshold for new user registration is high.
• An EOA account can only perform one operation per transaction, for example, if you want to go to Uniswap to exchange USDT for ETH, you must first initiate a transaction to approve USDT, and then you can send another transaction to execute the exchange.
• Unable to refine permission control, such as delegating certain account operations to a third party for operation, users must personally handle every trivial matter and sign and submit each operation for transaction once.
• There is no recovery mechanism, so you can only keep the private key or mnemonic phrase by yourself, and if you lose it, you will never be able to get back the assets of the account.

If it is a smart contract account (such as Safe), all the above issues can be resolved:

• Users can use the private key in the security chip of the mobile phone (or computer) to sign the authorization, no need to remember any private key or mnemonic words, or use email to sign the authorization, or other various authorization methods.
• Multiple operations can be batched together in the same transaction, and the original complex DApp operations can be completed with only one signature authorization and one transaction.
• It is possible to have very detailed permission control, allowing users to authorize third parties to control their own accounts, while specifying "what contracts can interact with", "what operations cannot be performed", "the maximum amount of assets that can be involved in asset transfer", or "the maximum number of operations that cannot exceed per week", etc.
• You can add a recovery mechanism so that when you lose your mnemonic, phone, or email, you can still transfer the assets of your account to a new account through the recovery mechanism.

The EIP-7702 proposal is to give EOA accounts the ability to transform into contract accounts. Users sign the transformation message with the EOA private key, and the signature content includes 'Chain ID', 'contract address after transformation', and 'EOA Nonce value':

• Chain ID: Used to prevent the signature of chain A from being replayed by chain B. However, if the Chain ID is set to 0, it means that you are willing to transform into each chain.
• The contract address you want to become: 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 return to a simple EOA account.
• Nonce value of EOA: used to prevent signature replay. If the Nonce value increases, the original signature will become invalid.

However, there are a few points to note:

1. EOA private key can continue to be used

Even if the user's EOA account becomes a contract, he can still continue to use it in the original EOA account manner. For example, if your EOA account becomes a Safe contract, you can use the Safe interface, follow the Safe transaction process, and 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 that private key.

2. The security of EOA private key remains unchanged.

Even if the user's EOA becomes a MultiSig, 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 has to keep his private key or mnemonic phrase safe, and his account will not become as secure as MultiSig.

3. The EOA account's Storage is not formatted

When an EOA account transforms into a contract and writes data to its Storage, unless the action of explicitly deleting the data is executed, the data written to the Storage will not be formatted due to the EOA account transforming into another contract or canceling the transformation. Therefore, developers should pay attention to not reading the data left by the previous transformed contract in Storage, referring to ERC-7201.

4. The EIP-7702 process does not include initialization

Usually, a general contract account will require an initialization step. During the deployment of the account, the information of the account owner (such as public key or address) is synchronously written to avoid the deployment step being front-run, leading to the loss of account ownership. This is typically done by the Factory contract that deploys the contract account to perform 'deployment + initialization'. However, because EIP-7702 directly changes, rather than deploying the contract to the EOA through a Factory, attackers can copy the user's transformation signature and preemptively send transactions on-chain to transform on behalf of the user, but initialize the account to be controlled by the attacker. Therefore, developers need to pay attention to EIP-7702. Possible preventive measures include checking the signature of the EOA account in the initialization function, so even if it is front-run, the attacker cannot generate the signature of the EOA account to complete the initialization.

5. The wallet needs to guard against changing requests

The wallet needs to do a good job of checking for the user, and stop the request and warn the user when the malicious DApp website asks the user to sign a transformation transaction, otherwise if the user signs a malicious transformation transaction, the assets will be transferred away instantly. Here are some examples of how to transform into a contract:

• Modified Safe Ithaca Account
• Ithaca Account

DApp Technology Protocol

EIP-2537: BLS12-381 Curve Operation Precompiler

Reduce the cost and make it more feasible for BLS curve-based zero-knowledge proof applications.

EIP-2537 adds several new precompile contracts to provide inexpensive BLS curve operations, making it more feasible to develop zero-knowledge proof applications based on BLS curves.

EIP-2935: Save historical block hash values in State

It allows developers or nodes to read the 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, if the Optimismtic Rollup fraud challenge wants to prove that a transaction exists in 1000 previous memory blocks, the challenger can't say it directly.

"Believe me, 1000 blocks of memory really existed before", he had to give evidence, but there was no direct evidence to prove that "1000 previous blocks of memory contained these contents", so he had to prove the transaction in a "chain" of memory blocks, block by block, until it reached 1000 previous blocks, and then prove that the transaction existed in the block.

!

△ Each block points to a parent block, so you can prove any block in history all the way back.

Suppose it is currently a memory block with a number 10000, and the fraud challenge wants to provide proof that the memory block with number 9000 has a transaction X, the challenger needs to start with the hash of the memory block 10000, first prove the hash of the parent memory block 9999 connected to the memory block 10000, and then prove the memory block 9998... Until the memory block 9000, the content of the memory block 9000 is proposed to contain the transaction X.

After EIP-2935, there will be a system contract (deployed on 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC) that will store the hashes of up to 8192 previous memory blocks. Every time a new block of memory is generated, the system contract will automatically update to write the hash of the previous block into the system contract (the hash of the 8192 previous blocks of memory will be rewritten).

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

This also paves the way for a future stateless client: in the future, light nodes will no longer need to store the block headers of all historical memory blocks, but will only need to ask someone else to provide proof using the proof method in the previous fraud challenge example when it is necessary to use the hash of a memory block in the history or the contents of the memory block.

EIP-7623: : Increase calldata cost

Increase the cost of using calldata to publish data to free up enough secure space to increase the Block Gas Limit and Blob count.

With the increasing demand for data release of rollups, after the introduction of blobs in EIP-4844 to allow rollups to put data in a very cheap way, increasing the number of blobs has been an upgrade that the community is looking forward to.

!

△ More and more validators have expressed support for increasing the Block Gas Limit.

However, increasing the Block Gas Limit or the number of blobs will put more pressure on Ethereum's p2p network as the amount of data transacted becomes larger, which will make attackers more efficient unless the cost of publishing data increases.

After the release of the EIP-7623 protocol, the cost of calldata will increase 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'.

If the attacker originally used all of the Block Gas Limit (30M) to put garbage data, the size of the memory block would be about 1.79 MB (30M / 16), compared to an average memory block size of only about 100 KB; and if the Block Gas Limit is increased to 40M, the attacker can generate a memory block of about 2.38 MB in size. When the calldata cost is increased by 2.5 times, the attacker's efficiency will decrease accordingly, becoming a maximum of 0.72MB for 30M and a maximum of 0.95MB for 40M, allowing for a more relaxed increase in Block Gas Limit and Blob quantity. However, this technical protocol also does not want to affect the general users who do not use calldata to publish data, so it will calculate the total Gas usage of the transaction in two ways, and then take the higher one:

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

The real impact will be on smaller rollups, because blobs are fixed size and fixed fees, so small rollups are inefficient to use blobs, and it is more cost-effective to use calldata, but after EIP-7623, the cost of these small rollups will increase by 2.5 times, and they may have to switch to using blobs or find a way to join forces to share a blob.

EIP-7691: Increase Blob Throughput

Increase the number of Blobs to provide more space for data publication to Rollup.

EIP-7691 increases the number of Blobs from "Target: 3 Blob, Upper Limit: 6 Blob" to "Target: 6 Blob, Upper Limit: 9 Blob", providing more space for data publication to Rollup.

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

Other Technical Agreements

EIP-7549: Move committee index out of validation

Adjust the content of validator voting to make it easier for votes to be aggregated and reduce the pressure on the P2P network.

Validators are randomly assigned to a group of committees and pairs for each epoch

In memory block voting, the votes of validators in each committee can be aggregated together, which reduces the number of votes passed in the P2P network, but the validator's votes will contain information about the number of committees that the validator belongs to, which means that the votes of different committees cannot be aggregated, even if they all vote on the same memory block.

EIP-7549 removes the information about '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 Profile

Establish a profile for Blob parameters at the execution layer, saving the execution layer nodes from having to inquire about Blob-related parameters from the consensus layer nodes.

The relevant parameters of Blob are currently stored in the consensus layer nodes, but the execution layer nodes still need these parameters in certain situations (such as RPC eth_feeHistory), so they must all go to the consensus layer nodes for inquiries.

EIP-7840 establishes a profile for Blob-related parameters at the execution layer, and nodes at the execution layer can directly read Blob-related parameters through this profile without querying the consensus layer nodes again.