Introduction to Ethereum Pectra Hard Fork

Author: NIC Lin, Medium

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

• EIP-2537: BLS12-381 Curve operation precompilation

• EIP-2935: Save historical block hash value in State

• EIP-6110: Provide on-chain validator deposits

• EIP-7002: Execution layer triggers exit

• EIP-7251: Added 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: Setting up EOA Account Code

• EIP-7840: Adding Blob Plans to EL Configuration Files

Technical agreements related to pledge

EIP-6110: BLS12-381 Curve Operation Precompilation

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

The way users participate in staking is to deposit 32 ETHs on the execution layer and record them by the event log (Event Log). Then the consensus layer performs parsing the event log to determine whether someone participates in the staking, and then the user participating in the staking becomes the verifier.

However, the consensus layer validators first need to reach a consensus on which point in time to deposit. Otherwise, some validators will see 5 new deposits, while some validators only see 3, so the consensus layer validators will find that some validators see 5 new deposits, while some validators will only see 3.We will vote on which execution layer block (eth1data) we want to refer to to to ensure that we see the same execution layer block.

However, in order to avoid major errors in the execution layer causing 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 respond, but this also leads to the fact that they have to wait more than 10 hours to take effect as soon as possible.

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

After the EIP-6110 technical protocol is executed, 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 verifier willWe don’t have to consider the issue of “to confirm that the memory blocks of the execution layer reference are the same”. As long as the consensus layer memory block is voted to confirm by more than two-thirds of the validators, everyone will see the same execution.Layer blocks reach consensus.Therefore, after the user participates in the staking, the execution layer memory block can take effect after the execution layer is completed within 13 minutes at the fastest time, and the consensus layer client can also remove the complex logic that was originally used to process the staking data.

EIP-7002: Save historical block hash value in State

It can be used to improve the process for verifiers to exit pledge or withdraw deposits and benefits, and reduce the risk of verifiers.

Participating in staking requires two keys, namely Validator Key and Withdrawal Credential.

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

If the Validator Key is lost, the verifier work cannot be performed and the staking cannot be withdrawn; if the Withdrawal Credential is lost, all deposits and benefits will be lost.In addition, some users will use third-party staking services such as Lido. When using these platforms, users need to keep Withdrawal Credential by themselves, and at this time, the Validator Key is kept by the service provider and performs the work of the verifier.

Execute the EIP-7002 technical agreement, and users can use Withdrawal Credential to call the “Withdraw Contract” (i.e. deployed on 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) to exit the stake (Exit) or withdraw deposits and income (Partial Withdrawal) and reduce the use of third-party stakes.The risks associated with the service.If the user participates in the pledge by himself but loses the Validator Key, he can also use this to exit the pledge.

• The parameters for initiating the request include validator_pubkey and amount: validator_pubkey is the Validator (Public) Key of the validator, and amount is the number to be collected.

• The Withdrawal Credential that initiated the request must be the Withdrawal Credential of the validator_pubkey validator.

• When calling the Withdraw contract to initiate a request, the Gas fee (ETH) must be attached. The Gas fee will be calculated based on the current number of 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 transaction fee, and then initiate a request and attach the transaction fee; but if Withdrawal Credential is an EOA account, there is no way to obtain accurate results.The handling fee can only be simulated off-chain in advance and the excess handling fee will be paid (no refund) to ensure that the request will be executed successfully.

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

EIP-7251: Added the MAX_EFFECTIVE_BALANCE

It can significantly increase the upper limit of the pledge amount to reduce the number of validators, and verifiers who do not reach the upper limit can automatically enjoy the pledge income.

User stakes to become verifiers to provide MAX_EFFECTIVE_BALANCE with the number of ETH, which cannot be less or more (currently MAX_EFFECTIVE_BALANCE is 32 ETH).If the user holds 1024 ETH to be staked, he can participate in the stake in 32 times, enable 32 validators, and run 32 validator nodes.And the active participation of everyone in staking has also led to the continuous increase of about 1 million validators. This not only makes the state data of the consensus layer larger and more, but the load on the consensus layer p2p network layer is more significant, because eachA Slot (every 12 seconds) has tens of thousands of authenticator signatures to be continuously passed and aggregated in the p2p network layer.

After executing the EIP-7251 technical agreement, the lower limit of pledge (MIN_ACTIVATION_BALANCE) is still 32 ETH, but the upper limit (MAX_EFFECTIVE_BALANCE) will be greatly increased to 2048 ETH. You can pledge any amount of ETH between 32 and 2048, and you can obtain pledge income.You need to withdraw your income regularly and accumulate 32 ETH before continuing to pledge it.

At present, existing verifiers do not need to exit the stake first and then merge together and re-join the stake. Instead, they can directly use the “contract for merged deposit” added on the execution layer (deployed at 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) and are subject to verificationWithdrawal Crendential Go to the call contract to initiate a request for a merged deposit.

• The parameters of the merged deposit request include source_pubkey and target_pubkey: these two keys are Validator Keys of the verifier, and the source verifier will be merged into the target verifier.

• The Withdrawal Credential that initiated the request must be the Withdrawal Credential of the source verifier.

• When calling the merged deposit contract to initiate a request, you must 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 merged deposit contract to obtain the current transaction fee, and then initiate a request and attach the transaction fee; but if Withdrawal Credential is an EOA account, there is no way to obtain itAccurate handling fees can only be simulated off-chain in advance and paid for excess handling fees (no refund) to ensure that the request will be executed successfully.

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

EIP-7685: General Execution Layer Request

Establish a formal EL -> CL information pipeline to facilitate users and pledge services to 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 run in a more decentralized manner.For example, the request for the staking of EIP-7002 mentioned above and the request for the consolidated deposit of EIP-7251.If this technical agreement is not available, Lido users must believe that the Lido node service provider will truly execute the stake or merge deposit at the consensus layer; with this technical agreement, Lido users can directly penetrate the execution layerSend requests through the governance contract.

These requests will have a 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.There is no need to write individual parsing logic.

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

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

  (0x00000000219ab540356cbb839cbe05303d7705fa) initiate the request.

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

  (0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) initiate the request.

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

  (0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) initiates the request.

Technical agreement to improve user experience

EIP-7702: Set up EOA account code

Let the EOA account be transformed into a contract account at will, greatly improving the user experience.

Some shortcomings in use of EOA accounts include:

• Private keys or mnemonic words need to be recorded and kept, which has a high threshold for new users to register and use.

• An EOA account transaction can only perform one operation. For example, if you want to go to Uniswap to exchange USDT to ETH, you must first initiate a transaction to approve USDT, and then you can send another transaction to execute the redemption.

• Unrefined permission control, such as handing over certain operations in the account to a third party for operations, users must personally handle every chore and sign and issue transactions for each operation.

• Without a Recovery mechanism, you can only keep your own private key or mnemonic words, and if you lose it, you will never get the assets in the account again.

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

• Users can sign and authorize with the private key in the security chip of their mobile phone (or computer). They do not need to remember any private keys or mnemonics, or use email to sign and authorize, or other various authorization methods..

• Multiple operations can be Batched together in the same transaction. The original complex DApp operations can be completed with just one signature authorization or one transaction.

• There can be very detailed permission control, and users can authorize third parties to control their own accounts, but at the same time specify “what contract can be interacted with”, “what operations cannot be performed”, “there are only ones involved in asset transfers.How many assets can be used? or “how many operations can not exceed every week” and other restrictions.

• A new Recovery mechanism can be added, and the account’s assets can be transferred to a new account through the Recovery mechanism when you lose your assistant words, mobile phone or email.

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

• Chain ID: Used to prevent the signature of chain A from being taken to chain B and replayed.However, if the Chain ID is filled in 0, it means that you are willing to transform in 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 the blank address (address(0)), it means you want to cancel the change and change it backSimple EOA account.

• Nonce value of EOA: used to prevent signatures from being played back.If the Nonce value increases, the original signature will be invalid.

However, there are a few points to note:

1. The EOA private key can also be used

Even if the user’s EOA account becomes a contract, he can still continue to use it in the original EOA account.His account, for example, if your EOA account becomes a Safe contract, you can use the Safe interface, go through the Safe transaction process, or 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. Still the security of EOA private keys

Even if the user’s EOA becomes a multi-signature, as long as he does not throw away 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 words well, heThe account will not become as secure as multiple signs.

3. The storage of the EOA account will not be formatted

When an EOA account transforms into a contract and writes data to its Storage, unless the action of deleting data is explicitly performed, the data written to the Storage will not be transformed into another contract or cancelled because the EOA account transforms into a contract or transforms into a cancelled contract unless the action of deleting data is explicitly performed.Format, so developers should pay attention to Storage. Do not read the data left by previous transformation contracts. You can refer to ERC-7201.

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

Generally, contract accounts require an initialization step, which synchronizes the account owner’s information (such as public key or address) when deploying the account, to avoid the deployment step being taken off (frontrun) and loses account ownership..This is usually performed by the Factory contract that deploys the contract account to perform “deployment + initialization”, but because EIP-7702 is changed directly, rather than a Factory deploys the contract to the EOA, the attacker can copy the user’sTransform and sign and send transactions first to the link to transform the user but initialize the account to be controlled by the attacker, so developers need to pay attention to EIP-7702.Possible prevention methods such as checking the signature of the EOA account within the initialization function, so that even if it is taken off, the attacker will not be able to generate the signature of the EOA account to complete the initialization.

5. The wallet needs to check for changes

The wallet needs to check for the user, stop the request and warn the user when the malicious DApp website requests the user to sign a transformation transaction. Otherwise, if the user signs a malicious transformation transaction, the asset will be instantly transferred.Here are some examples of transformation contract implementation:

• Modified Safe Ithaca Account

• Ithaca Account

DApp Technical Agreement

EIP-2537: BLS12-381 Curve Operation Precompilation

Making the cost of zero-knowledge proof application based on BLS curves more feasible.

EIP-2537 has added several precompiled contracts (Precompiles) to provide cheap BLS curve operations, so it will be more feasible to develop zero-knowledge proof applications based on BLS curves.

EIP-2935: Save historical block hash value in State

Allows developers or nodes to read the hash value 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, suppose that Optimismtic Rollup’s fraud challenge has to prove that there is a transaction in 1,000 previous memory blocks, the challenger cannot say it directly.

“Please believe that this transaction actually existed in 1000 memory blocks before.” He had to provide evidence, but there was no direct evidence to directly prove that “1000 previous memory blocks contain these contents”, so he had to use it asThe memory block “chain” method is to prove a memory block one memory block forward until 1,000 previous memory blocks are reached, and then prove that the transaction exists in the memory block.

△ Each block will point to a parent block, so you can prove any block in history all the way forward.

Assuming that it is currently a memory block numbered 10000, and the fraud challenge needs to provide a proof that a transaction X exists in a memory block numbered 9000, the challenger needs to start with the hash value of 10000 memory block first proves that the memory block is 10000.The hash value of the connected parent memory block 9999, and then prove the memory block 9998… until the memory block 9000, and finally the content of the memory block 9000 contains the transaction X.

After EIP-2935, there will be a system contract (deployed in 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC), and its storage will store up to 8192 hash values ​​of previous memory blocks.Whenever a new memory block is generated, the system contract will be automatically updated and the hash value of the previous memory block is written into the system contract (the hash value of 8192 previous memory blocks will be copied).

In this way, in the example of Optimismtic Rollup fraud challenge, the challenger does not have to slowly prove it to the previous memory block and a memory block, but can directly prove that the current chain state of the memory block 10,000 is a certain system contract.The value of a Storage (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 one step is to prove the hash value of memory block 1808 (= 10000 – 8192), and then prove that memory block 1808 is in the current chain state, in the system contracthash value of memory block 1000.

This also paves the way for the future stateless client: future light nodes no longer need to store all the memory blocks in history, but use a certain part of the history when it is necessary to use it.When the hash value or memory block content of a memory block, please ask others to 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 divert enough security space to increase the number of Block Gas Limit and Blobs.

As Rollup’s data release demand becomes higher and higher, after introducing blobs in EIP-4844 to allow Rollup to place data in a very cheap way, increasing the number of blobs has always been an upgrade that the community expects.Or, like the recent push by the community to raise Block Gas Limit, it reflects the need for ecology to increase resources.

△ More and more validators say they support raising Block Gas Limit.

However, whether it is to increase the number of Block Gas Limit or Blobs, it will put more pressure on the Ethereum’s p2p network because the transaction volume becomes larger, which will increase the efficiency of the attacker’s attack unless the data will be published.Costs are 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 Block Gas Limit (30M) to put junk data, the data size of the memory block was 1.79 MB (30M / 16), which was only about 100 KB compared to the average memory block size;If 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 to 2.5 times, the attacker’s efficiency will decrease, becoming 30M maximum 0.72MB and 40M maximum 0.95MB, so you can increase the number of Block Gas Limit and Blobs with more confidence.However, this technical agreement does not want to affect ordinary users who “do not use calldata to publish data”, so it will calculate the total Gas usage of transactions in two ways and then take a higher one:

1. The original trading Gas usage calculation method is calculated with the old calldata cost: that is, the calldata is calculated in the form of “Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas”, and the transaction execution is consumed.Gas and Gas consumed by deploying contracts.

2. Simply calculate the amount of calldata Gas, but it is calculated with a new cost: that is, calculate calldata in the form of “Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas”, but does not count the gas consumed by executionOr the Gas consumed by deploying the contract. Therefore, for users who generally “not use calldata to publish data” (for example, go to Uniswap to redeem), the main Gas consumption is the execution part, even if calldata is calculated at a new cost.The Gas consumed by the execution will not exceed, so the average user will not be affected.

The one that is really affected will be the small Rollup, because Blobs are fixed in size and fixed costs, so small Rollup is inefficient in using Blobs, and it is more cost-effective to use calldata. However, after EIP-7623, the cost of these small Rollups will be equal.Improve 2.5 times, 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 increase more space for publishing data to Rollup.

EIP-7691 raises the number of blobs from “Target: 3 Blobs, upper limit: 6 Blobs” to “Target: 6 Blobs, upper limit: 9 Blobs”, adding more space for publishing information to Rollup.

Note: In addition, there are some designs in the Blob fee market that need to be fine-tuned, such as the speed of commission adjustment is not immediate and the minimum fee limit is too low, but this is not in the problem that this technical agreement needs to solve.

Other technical agreements

EIP-7549: Move the committee index outside of verification

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

Verifiers will be randomly assigned to a group of committees and

Memory block voting, the ballots of each committee’s validators can be aggregated together, which can reduce the number of votes passed in the p2p network, but the ballots of the verifier will include “how many committees the verifier belongs to”The information that caused the votes of different committees to be unable to be aggregated even if they all voted on the same memory block.

EIP-7549 Removes the information of “which committee this verifier belongs to” from the voting content, so that the verifiers of different committees can be aggregated together with the same voting content, further reducing the votes in the p2p networkThe number of transmissions is reduced to the pressure of the p2p network.

EIP-7840: Adding a Blob Plan in an EL Configuration File

Establish a setting file for the Blob parameters at the execution layer, eliminating the trouble of the execution layer node asking for the Blob-related parameters of the consensus layer node.

Blob related parameters are currently stored in consensus layer nodes, but execution layer nodes still need these parameters (such as RPC eth_feeHistory), so they must be asked from consensus layer nodes.

EIP-7840 establishes a setting file for Blob-related parameters at the execution layer. The execution layer nodes can directly read Blob-related parameters through this setting file, and there is no need to ask the consensus layer node.