Author: NIC Lin, Medium

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 the history area in State Block hash value

EIP-6110: Provide on-chain validator deposits

EIP-7002: Execution layer triggers exit

EIP-7251: Add the MAX_EFFECTIVE_BALANCE< /p>

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: In the EL Configuration File Add Blob plan

EIP-6110: BLS12-381 Curve operation precompilation

Simplifies the process of users participating in staking, and greatly shortens 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 executes and parses the event log to determine whether someone participates in the pledge, and then participates in the pledge. The user becomes the verifier.

However, the verifiers of the consensus layer need to reach a consensus on which point in time to deposit, otherwise, they will find that some verifiers see 5 new deposits, while some verifiers only see 3 Therefore, 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 causing chain forks during design, the reference execution layer block (eth1data) will be an execution layer block about 10 hours ago. 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 fact that it will take more than 10 hours to take effect as soon as possible.

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

SecretAfter the EIP-6110 technical agreement, 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 We 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 a 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: Saving historical block hash values ​​in State

Can be used to improve the process for verifiers to exit pledge or withdraw deposits and benefits, and reduce the verifiers' risk.

To participate in the pledge, you need to have 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 pledge 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 the Withdrawal Credential to call the "Withdraw Contract" (i.e., deployed on 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) to exit the stake (Exit) or withdraw deposit and income (Partial Withdrawal) , can reduce the possible risks associated with the use of third-party pledge services. 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.

Stamp the requestThe Withdrawal Credential must be the Withdrawal Credential of the validator_pubkey validator.

Call the Withdraw contract to initiate a request and 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 If it is, there is no way to obtain accurate handling fees. You can only simulate off-chain and pay the excess handling fee (no refund) in advance to ensure that the request will be executed successfully.

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

EIP-7251: Increasing the MAX_EFFECTIVE_BALANCE

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

A user stakes to become a verifier to provide MAX_EFFECTIVE_BALANCE 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 fact that there are currently about 1 million validators and the increase continues. 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 each A 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 number of ETH between 32 and 2048 , you can obtain pledge income, no longer need to withdraw the income regularly, and then continue to pledge it after accumulating 32 ETH.

At present, existing validators do not need to exit the stake first and then merge and re-join the stake. Instead, they can directly use the "merge deposit added to the execution layer.Contract” (deployed at 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb), the verifier's Withdrawal Crendential calls the contract to initiate a request for the merged deposit.

The parameters of the merge 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 initiates 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 For an account, there is no way to obtain accurate handling fees. You can only simulate off-chain and pay the excess handling fee (no refund) in advance 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 format of the EL address.

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.

The user can send requests directly from the execution layer to the consensus layer, and the staking service (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 layer Send 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 memory block of the execution layer, so the consensus layer can directly execute through When the layer memory block obtains this information, there is no need to write individual parsing logic.

EIP-6110, EIP-7002 and EIP-7251 are all based on EIP-7685 Defined criteria to formulate requests:

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

(0x00000000219ab540356cbb839cbe05303d7705fa).

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

(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA).

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

(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb).

EIP-7702: Set up EOA account code

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

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

The private key or mnemonic words need to be recorded and kept, which has a high threshold for new users to register and use.

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

A permission control that cannot be refined, such as handing over certain operations of the account to a third party for operation. The user must personally handle every chore and sign and send each operation. Trading once.

There is no Recovery mechanism, and you can only keep your private key or mnemonic words yourself. 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 the above problems can be solved:

The user can use the security chip of the mobile phone (or computer) For private keys, you 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" and "what operations cannot be performed", "How many assets can only be used when it comes to asset transfers" or "how many operations can not exceed per week" and other restrictions.

New Recovery mechanism can be added, when you lose your assistant words, mobile phone or email, you can also transfer the account's assets to a new account through the Recovery mechanism.

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 A chain The signature is taken to the B-chain 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)), then It means that you want to cancel the change and return to a simple EOA account.

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

But there are a few points to note:

1. The EOA private key can still be used

Even if the user's EOA account becomes a contract, he You can still 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 key

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 All are EOA private key security: he still needs to keep his private key or mnemonic words well, and his account will not become as secure as a multi-sign.

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

When an EOA account turns into a contract and writes data to its storage, unless the action of deleting data is explicitly performed, Otherwise, the data written to Storage will not be formatted because the EOA account transforms into other contracts or cancels the transformation. Therefore, developers should pay attention to Storage and do not 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

General contract accounts require an initialization step, which is written to the account owner's synchronously during the account deployment. Information (such as public keys or addresses) to avoid the loss of account ownership by frontrun. This is usually done by the factory that deploys the contract accountThe contract is used to perform "deployment + initialization", but because EIP-7702 is changed directly, rather than a Factory deploying the contract to EOA, the attacker can copy the user's transformation signature and send the transaction first to the link. Transform the user but initialize the account to an attacker-controlled, 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 users, and block the request when the malicious DApp website requests the user to sign a transformed transaction and Warn the user, otherwise if the user signs a malicious transformation transaction, the assets will be instantly transferred. Here are some examples of transformation contract implementation:

Modified Safe Ithaca Account

Ithaca Account

EIP-2537: BLS12-381 Curve Operational precompilation

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

EIP-2537 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

Let the developer or node read the hash value of past memory blocks directly from the Storage of the system contract ( Block Hash).

If the developer needs to prove the content of a previous memory block, for example, suppose that the fraud challenge of Optimismtic Rollup has a transaction in 1,000 previous memory blocks, the challenger cannot say it directly.

"Please believe that 1000 memory blocks actually existed in this transaction before." He had to provide evidence, but there was no direct evidence to directly prove that "1000 previous memory blocks contain these content", so it must prove a memory block in the form of a memory block "chain" until 1,000 previous memory blocks are reached, and then prove that the transaction exists in the memory block.

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

Suppose that it is currently a memory block numbered 10000, and the fraud challenge is to provide proof that a transaction X exists in a 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 connected to the memory block 10000, then prove the hash value of memory block 9998... until the memory block 9000, and finally propose the memory block 9000. The transaction X is included in the content.

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 case of Optimismtic Rollup fraud challenge, the challenger does not have to slowly prove the previous memory block and one memory block, but can directly prove the current chain status of the memory block 10,000. In this 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 contract hash 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 when If you need to use the hash value or memory block content of a memory block in the history, 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 the demand for data release of Rollup is getting 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 a community. An upgrade expected, like the recent push by the community to raise Block Gas Limit, reflects the ecology’s demand for increasing resources.

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

But no matter whether it is to raise the BThe number of lock Gas Limit or Blobs will put more pressure on the Ethereum's p2p network because the amount of transactions 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 Block Gas Limit (30M) to put junk data, the data size of the memory block was 1.79 MB (30M / 16), compared to the average memory block The size is only about 100 KB; 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:

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 added Gas consumed and Gas consumed by deploying contracts.

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 not count Enter the gas consumed by execution or the gas consumed by deployment contracts. Therefore, for users who are generally "not using 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 the new cost, it will not exceed the gas consumed by the execution, so the average user will not be affected.

The only thing that is really affected will be the small Rollup, because Blobs are fixed size and fixed costs, so small Rollup uses BlobsInefficient, it is relatively cost-effective to use calldata, but after EIP-7623, the cost of these small Rollups will increase by 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 Increase the number of blobs from "Target: 3 Blobs, upper limit: 6 Blobs" to "Target: 6 Blobs, upper limit: 9 Blobs", and add more information to release space for Rollup.

Note: In addition, there are some designs in the Blob fee market that need to be fine-tuned, such as the speed of the fee 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.

EIP-7549: Move the committee index outside of verification

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

Verifieds Each Epoch will be randomly assigned to a group of committees and voted on the memory blocks. The votes of each committee's validators can Aggregate together, which can reduce the number of votes delivered in the p2p network, but the validator's ballot will contain information about "how many committees the verifier belongs to", which will result in the votes of different committees being unable to be aggregated in one. Start, even if they all vote on the same memory block.

EIP-7549 Removes the information "which committee this verifier belongs to" from the voting content, so that the verifiers of different committees can be aggregated together when the voting content is the same, and Steps to reduce the number of votes delivered in the p2p network and reduce the pressure on the p2p network.

EIP-7840: Add a Blob plan to the EL configuration file

Create a setting file for the Blob parameters at the execution layer, eliminating the execution layer nodes to ask the consensus layer nodes Trouble with Blob-related parameters.

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

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