Ethereum Pectra Hard Fork Introduction

Author: NIC Lin, Medium

The Pectra hard fork is expected to launch the 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 hash values ​​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 the 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 profile

Staking related technical protocols

EIP-6110: BLS12-381 Curve Operation Precompilation

Simplify the process of users participating in staking, and greatly shorten the waiting time.

The way for users to participate in staking is to deposit 32 ETH on the execution layer and record it by 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 user who participates in the staking becomes a validator.

However, the validators of the consensus layer must first reach a consensus on the time point for the deposit. 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 lead to chain forks, the reference execution layer block (eth1data) will be an execution layer block about 10 hours ago, ensuring that when a major error occurs, the developers of the consensus layer have enough time to react and deal with it. However, this also means that it will take more than 10 hours for participation in staking to take effect.

△ 10900000 eth1data in the CL block, the Block Hash recorded in it is the execution layer block 21683339, which appeared 10 hours before it.

After the EIP-6110 technical protocol is implemented, the user's pledge data 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 the user participates in the pledge, it will take effect as soon as about 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 pledge data.

EIP-7002: Save historical block hash values ​​in State

It can be used to improve the process of validators exiting pledges or withdrawing deposits and income, reducing the risk of validators.

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

The Validator Key is used for the work content of the verifier, and the Withdrawal Credential is used for the address where the deposit and income will be withdrawn when the verifier exits the staking. In addition, the Validator Key must be used to exit the staking.

If the Validator Key is lost, the verifier cannot perform the work and cannot exit the staking; if the Withdrawal Credential is lost, all deposits and income 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 by themselves, and at this time the Validator Key is kept by the service provider and performs the work of the verifier on their behalf.

By implementing 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 exit 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 verifier.

• When calling the Withdraw contract to initiate a request, you need to attach the Gas fee (ETH). The Gas fee will be calculated according to 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, you can first go to the Withdraw contract to obtain the current fee amount, and then initiate the request and attach the fee; but 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 still in the BLS public key format, remember to switch it to the EL address format first.

EIP-7251: Increase the MAX_EFFECTIVE_BALANCE 

It can significantly increase the upper limit of the staking amount to reduce the number of validators, and validators that have not reached the upper limit can automatically enjoy the staking benefits.

Users must provide MAX_EFFECTIVE_BALANCE of ETH to become validators, 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 staking in 32 times, enable 32 validators, and run 32 validator nodes. The active participation of everyone in staking has also led to the current number of about 1 million validators and continues 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 the implementation of 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 get 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 first and then merge them together to re-join the stake. Instead, they can directly use the newly added "deposit merging contract" on the execution layer (deployed at 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb), and the validator's Withdrawal Credential calls the contract to initiate a deposit merging request.

• The parameters of the deposit merging request include source_pubkey and target_pubkey: these two keys are the validator's Validator Key, and the source validator will be merged into the target validator.

• The Withdrawal Credential that initiates the request must be the Withdrawal Credential of the source validator.

• When calling the combined deposit contract to initiate a request, you need to attach a handling fee (ETH). 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, you can first call the combined deposit contract to obtain the current handling fee amount, and then initiate a request and attach the handling fee; but if the Withdrawal Credential is an EOA account, there is no way to obtain the accurate handling fee. You can only simulate it off-chain in advance and pay the excess handling 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: Universal Execution Layer Requests

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, and staking services (such as Lido) can operate in a more decentralized manner. For example, the request to exit the stake mentioned above in EIP-7002, and the request to merge deposits in EIP-7251. Without this technical protocol, Lido users must trust that the Lido node service provider will faithfully execute the exit stake or merge deposit at the consensus layer; with this technical protocol, Lido users can send requests directly through the governance contract on 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 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 all formulate requests based on the standards defined by EIP-7685:

• EIP-6110 adds a pledge request: Request Type=0, initiate a request through the Deposit contract

  (0x00000000219ab540356cbb839cbe05303d7705fa).

• EIP-7002 Request to withdraw pledge: Request Type=1, initiate the request through Withdraw contract

  (0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA).

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

  (0x00431F263cE400f4455c2dCf564e53007Ca4bbBb).

Technical agreement to improve user experience

EIP-7702: Set EOA account code

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

EOA accounts have some shortcomings in use, including:

• It is necessary to record and keep private keys or mnemonics, and the threshold for new users to register and use is high.

• EOA accounts can only perform one operation in one transaction. For example, to exchange USDT for ETH on Uniswap, you must first initiate a transaction to approve USDT, and then 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 for operation. Users must handle every chore personally and sign and send a transaction for each operation.

• There is no recovery mechanism. You can only keep your private key or mnemonic by yourself. If you lose it, you will never get back the account's assets.

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

• Users can use the private key in the security chip of the mobile phone (or computer) to sign and authorize, without having to remember any private key or mnemonic, or use email to sign and authorize, or other various authorization methods.

• Multiple operations can be batched together and executed together in the same transaction. The original complex DApp operations can be completed with only one signature authorization and one transaction.

• There can be very detailed permission control. 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 many assets can be used for asset transfer" or "how many operations can be performed per week".

• A recovery mechanism can be added. When you lose your mnemonic, mobile phone or email, you can transfer the account's 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. Users sign the transformed message with the EOA private key. The signature content includes "Chain ID", "Contract address to be transformed" and "EOA Nonce value":

• Chain ID: Used to prevent the signature of chain A from being taken to chain B for replay. However, if Chain ID is filled with 0, it means that you are willing to transform on every chain.

• Contract address you want to turn into: If you fill in a Safe contract address, your EOA account will become a Safe contract; if you fill in the address (address(0)), it means that you want to cancel the change and turn it back to a simple EOA account.

• EOA Nonce value: used to prevent the signature from being replayed. 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 same way as the original EOA account. His account, for example, assuming that your EOA account becomes a Safe contract, you can use the Safe interface and follow the Safe transaction process, or you can continue to use the original EOA wallet to sign and send transactions. However, this also means that the security of the account is still limited to that private key.

2. Still the security of the EOA private key

Even if the user's EOA becomes a multi-signature, as long as he does not lose the EOA private key, his account security 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. The Storage of the 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, so developers should pay attention to the Storage not to read the data left by the previous transformation contract, you can refer to ERC-7201.

4. The process of EIP-7702 does not include initialization

Generally, contract accounts require an initialization step, and the account owner's information (such as public key or address) is written synchronously when the account is deployed to avoid the deployment step being frontrunned (Frontrun) and causing the account to lose 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 EOA, an attacker can copy the user's transformation signature and preemptively send a transaction to the chain 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 frontrun, the attacker cannot generate the signature of the EOA account to complete the initialization.

5. Wallets should check the change requests

Wallets need to check for users, and block the request and warn users when malicious DApp websites request users to sign a transformed transaction. Otherwise, if users sign malicious transformation transactions, their assets will be transferred instantly. The following are some examples of the implementation of transformation contracts:

• Modified Safe Ithaca Account

• Ithaca Account

DApp Technology Protocol

EIP-2537: BLS12-381 Curve Operation Precompilation

Reduce the cost of zero-knowledge proof applications based on BLS curves and make them more feasible.

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

EIP-2935: Save historical block hash values ​​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 the developer needs to prove the content of a previous memory block, for example, if the fraud challenge of Optimismtic Rollup needs to prove that a transaction exists 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 blocks 1000 years ago contain these contents”, so he must use the memory block “chain” method to prove it one by one until he reaches the memory block 1000 years ago, and then prove that the transaction exists in the memory block.

△ Each block points to a parent block, so any block in history can be proved all the way forward.

Assuming that the current memory block is numbered 10000, and the fraud challenge is to provide 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, and 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 at 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC), whose 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 Optimismtic Rollup fraud challenge, the challenger does not have to prove the previous memory block one by one, but can directly prove that in the current state of the chain of memory block 10000, the value of a certain 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 state of the chain 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 block in history is needed, others can provide proof using the proof method in the previous fraud challenge example.

EIP-7623: Increase calldata cost

Increase the cost of using calldata to publish data to create enough safety space to increase the Block Gas Limit and the number of blobs.

As the demand for Rollup data publishing increases, after Blob was introduced in EIP-4844 to allow Rollup to publish 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 promotion of the community to increase the Block Gas Limit, it reflects the ecosystem's demand for increased resources.

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

However, whether it is raising the Block Gas Limit or the number of Blobs, it will cause 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 all the Block Gas Limit (30M) to store garbage data, the data size of the memory block would be about 1.79 MB (30M / 16), which is only about 100 KB compared to the average memory block size; if the Block Gas Limit is increased 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 efficiency of the attacker will decrease, becoming a maximum of 0.72MB for 30M and 0.95MB for 40M, so that the Block Gas Limit and the number of blobs can be raised 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 fees, 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 unite and share a Blob.

EIP-7691: Increase Blob Throughput

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

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 Rollups.

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 to be solved by this technical protocol.

Other technical protocols

EIP-7549: Move the committee index outside of verification

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

The validators will be randomly assigned to a group of committees (Committees) at each Epoch and vote on

memory blocks. The votes of the validators of each committee can be aggregated together, which can reduce the number of votes transmitted in the p2p network, but the validator's vote will contain the information of "which committee the validator belongs to", which makes the votes of different committees cannot be aggregated together, even if they all vote on 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 node to ask the consensus layer node 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.