From 0 to 1: Understanding Ethereum Shanghai Upgrade

avatar
Foresight News
01-10
This article is machine translated
Show original
The main content of the Shanghai upgrade is to open staking withdrawals and EOF, excluding EIP-4844.

Written by: Shiqi

TL;DR

  • The main content of the Shanghai upgrade is Withdrawal and EOF, EIP-4844 will not be included in the Shanghai upgrade
  • Withdrawal
  • Withdrawal does not need to be initiated actively, it is fully automatic, and withdrawals can be performed for 115,200 Validators every day
  • There are two rules, "Partial Withdrawal" and "Full Withdrawal", which correspond to different conditions. Most withdrawals will be "Partial Withdrawal"
  • "Partial withdrawal" extracts the income of Validators. Due to the two-year pledge, a lot of income has been accumulated on the beacon chain, so the unlocking amount is the largest in the first four days of unlocking; "Full withdrawal ” is the proceeds + pledged 32 ETH taken away at the same time
  • Ideally, it is expected to unlock about 400k ETH on the first day after the upgrade, about 300K on the second day, about 180K on the third day, and about 60K on the fourth day. Most of the unlocked amount in the first four days comes from "partial withdrawals". From the fifth day onwards, since all Validators have basically experienced a withdrawal, most of the node’s income has been withdrawn, so the main source of withdrawals from the fifth day will be "all withdrawals", and this number will be indirectly restricted by the flow coefficient limit
  • To be precise, the flow restriction factor does not limit the number of "full withdrawals" that can be processed every day, but the number of "full withdrawals" that can be met every day. That is to say, if there are a large number of Validators that meet the requirements of If the rule of "all withdrawals" is adopted, it is still possible that a large amount of ETH unstaked far beyond expectations
  • EOF
  • EOF is an upgrade to EVM, which introduces new contract standards and some new opcodes. After the upgrade, EVM will be able to perform version control and run multiple sets of contract rules at the same time
  • With EOF, EVM is no longer limited by the requirement of forward compatibility when iterating, and the difficulty of upgrading becomes lower, which may lead to more frequent upgrades of Ethereum EVM in the future
  • Frequent EVM iterations may lead to higher requirements for EVM-compatible virtual machines, such as zkEVM. To keep up with the version, other EVM-compatible VMs may need to have the ability to automatically convert EOF updates to their own VMs

Learn about Ethereum Shanghai upgrade

What is Shanghai Upgrade

The Shanghai upgrade is the next hard fork of the Ethereum executive layer. It has gone through Constantinople upgrade, Istanbul upgrade, Berlin upgrade, London upgrade, and Paris upgrade (Merge). Each upgrade means that Ethereum has Some major updates, such as EIP-1559 changed the income structure of miners, Merge changed the operating mechanism of Ethereum, and so on.

Beacon chain (beacon chain) - a two-year consensus layer trainee

In December 2020, Ethereum introduced the Beacon chain. Since then, Ethereum has changed from the execution layer and the consensus layer being in charge of one chain to the execution layer consensus layer being in charge of two parallel chains separately, which is also a transformation from PoW to PoS.

After the transformation, the consensus layer is in charge of the Beacon chain, and the execution layer is in charge of the former Ethereum main network, which is the one that everyone usually uses to interact with users on Ethereum. Before the merger of the Beacon chain and the main network, only through The Deposit Contract on the execution layer communicates. In short, the user deposits ETH on the Deposit Contract on the execution layer, and then stores the ETH in the beacon chain, but from then on, the ETH on the beacon chain has no way to return to the execution layer. , the ETH in the Deposit Contract cannot be withdrawn.

Note: Deposit contract, in short Deposit Contract is a smart contract deployed on the ETH main network, it will accept any transaction that contains at least 1 ETH and a valid input data, and the nodes on the beacon chain will listen to this contract, And use the input data in the monitored transaction to establish the corresponding Validator in the beacon chain.

However, the Beacon chain did not debut as soon as it went online. It went through a two-year consensus trainee stage, and it was not officially merged with the Ethereum mainnet until September 2022. The Beacon chain in the middle has been upgraded many times, from the initial Phase 0 , to Altair upgrade , and then to Bellatrix (also known as The Merge), and finally debuted smoothly. Since then, the Beacon chain and the Ethereum main network have been combined to form a new Ethereum , the two communicate through the Engine API.

During the two-year consensus trainee process of the Beacon chain, a lot of ETH has been accumulated on the Beacon chain, which still cannot be withdrawn. When users usually operate on the Ethereum network, they use their own to execute ETH balance on layer. Therefore, the withdrawal function of the beacon chain ETH must be realized, and this Shanghai Upgrade (Shanghai Upgrade) has come.

In fact, the Shanghai upgrade refers to the upgrade of the execution layer. In addition to the Shanghai upgrade, there is also an upgrade of the consensus layer beacon chain, called Capella upgrade. The ETH on the Beacon chain can be withdrawn to the execution layer. It is jointly completed by Shanghai upgrade and Capella upgrade.

The focus of Shanghai's upgrade

The primary goal of the Shanghai upgrade is to implement the withdrawal function of the beacon chain. In addition to the withdrawal of the beacon chain, EOF (EVM Object Format) is also a major upgrade, but precisely because it is so important that it will require more testing time. In order not to delay the implementation of the withdrawal function of the beacon chain, the upgrade of EOF may be delayed , mainly depends on his progress.

EIP-4844 is another important upgrade that has attracted much attention. Since it is of great significance to Ethereum and may also delay the implementation of the withdrawal function of the beacon chain, EIP-4844 has been confirmed to be included in the next Cancun Upgrade (Shanghai Upgrade the next time).

The progress of Shanghai's upgrade

It is estimated that the shadow fork will be carried out in January 2023, and the Shanghai upgrade hard fork will be carried out in March. In addition to the Shanghai Upgrade of the execution layer, this upgrade will also carry out the Capella Upgrade of the consensus layer, and the joint upgrade of the execution layer and the consensus layer will be completed The withdrawal function of the beacon chain, in addition to the pledged ETH withdrawal function on the beacon chain, will also implement EOF and some other small upgrades. It is expected to achieve a total of 9 EIPs. On the other hand, according to the next All Core Developers meeting held on January 5, 2023, it will be decided whether to postpone the implementation of EOP until the fall of 2023, so as not to affect the progress of the withdrawal function implementation. The highly anticipated EIP-4844 will also be implemented in the fall of 2023.

Note: Shadow fork, simply put, shadow fork is a method of stress testing, using the data of the main network to test in a small range of nodes. By running a small number of config-updated nodes to fork the Ethereum network to obtain a shadow fork network, so that the shadow fork can inherit the state and history of the original network without affecting the state of most nodes in the original network. It will not affect the operation of the network before the fork. The advantage of this is that the data volume and transactions of the main network are the most complex, which can help nodes simulate the real situation.

The specific content of the upgrade

withdraw money

Concepts that may be involved

First of all, you need to understand the withdrawal. You need to have a vague idea of what is a Validator, what is ETH 2.0, and what happened to The Merge. If you are familiar with the concepts mentioned below, you can skip it.

If you have no concept, you can also read the Ethereum 2.0 Knowledge base , and you can also make a simple understanding of the status quo: Ethereum is now divided into a consensus layer and an execution layer. The consensus layer has a bunch of wage earners called Validators. (Beacon chain) pledged 32 ETH as a guarantee for their work. With this guarantee, Validators can work for Ethereum and supervise each other in exchange for some income. Currently, the funds used for guarantee and income , Validators cannot be retrieved.

Responsibilities of Validators

Validator has three main responsibilities:

(1) Propose block, which inherits the responsibilities of previous miners, but most of the Validators currently choose to install mev-boost to indirectly implement Proposer builder separation. If you want to know more about MEV and MEV-boost, you can read A&T View: Investment Opportunities in Ethereum Staking Extractable Value

(2) Sign Attestation, which refers to Validator voting to confirm the validity of blocks of other Validator proposals, Attestation is performed once per Epoch, which is a supplement to Responsibility 1

(3) Monitor other Validators for Slashable offenses (monitor for violations). Common violations include Attestaion Violation

Slots and Epoches

Slot and Epoch can be understood as a unit of time, which represents a time interval, a window period, they correspond to the length of a period of time, 12s / slot, 32 Slots = 1 Epoch, 6.4mins / Epoch, so one every 12s slot, one Epoch every 6.4 minutes, and 225 Epochs per day.

Slots and Epochs play an important role in understanding withdrawals, because Validators operate in units of Slots or Epochs, and because of this, withdrawals are also counted in Slots or Epochs.

Image from: https://eth2book.info/altair/part2/building_blocks/aggregator

Usually each Slot will have a Validator randomly selected, and this Validator can propose a block (a Slot will only have one valid block, but each Slot does not necessarily have a block, such as the validator selected in this slot propose block offline). At the same time, all Validators will be divided into many committees (committees), with at least 128 and at most 2048 Validators in each committee. These committees will be independently responsible for attesting each slot, and attesting will randomly select some Validators from each committee as Aggregators , the number of Aggregators in each committee is currently 16, Aggregators are responsible for aggregating the Attestation votes of Validators and broadcasting to the next block proposer. After each Epoch, committees will be dissolved and then reorganized.

Status of the Validator

Validator has several common states. Depending on the state, different withdrawal conditions of Validator will be met. Therefore, it is necessary to know several main states of Validator to correctly understand how withdrawal will happen. Obviously, not all Validators are in the Active state, but only the Validators with the Active and Withdrawable states meet the withdrawal conditions.

1. Deposit

First of all, the 32ETH used to become a Validator must first be deposited into the deposit contract (Deposit Contract) of the main network, and this state will last for about 7 hours before entering the Pending state. After each Validator is successfully created, there will be a corresponding Number (index), this number is monotonically increasing, that is to say, the later you become a Validator, the greater your index

2. Pending

After the Validator completes the deposit, it becomes an official Validator reserve army. It needs to wait for other active (Active) Validators to vote before entering the Pending state. This voting takes place every 4 hours.

After entering the Pending state, the Validator will enter a queue and wait to be fully activated. The number of Validators that can be activated for each Epoch is limited by the "churn limit coefficient (CHURN_LIMIT_QUOTIENT)". The calculation method is

max(MIN_PER_EPOCH_CHURN_LIMIT, n // CHURN_LIMIT_QUOTIENT)

Where MIN_PER_EPOCH_CHURN_LIMIT = 4, n is the number of active validators, CHURN_LIMIT_QUOTIENT = 65536.

Therefore, taking the data on December 29, 2022 as an example, there are currently 492,975 Active Validators in the network, so the current number of new Validators that can be activated per Epoch is 7, based on 225 Epochs per day, the number of new validators that can be activated every day The number of Validators is 1575.

3. Active

A Validator in the Active state can participate in Attestation and propose block (start working) until the Validator's balance drops below 16ETH, voluntarily withdraws or is Slashed.

If any Validators miss Block Proposed or participate in Attestation, this state is called offline (absenteeism). If at least 2 Epochs do not participate in Attestation, the Validator will be deducted. Generally speaking, a Validator must be online at least 50% of the time to obtain positive returns. However, the offline Validator still maintains the Active state. Only when it is slashed (discipline violations) will it be forced to withdraw from the network and at least 1/32 of the balance will be confiscated

4. Exit & Withdrawable

Inactive Validators will be forced to leave the network (Exit) and cannot rejoin. On the other hand, the speed at which Validators leave the network is also strictly limited. In fact, the limitation on the validator activation speed mentioned in the Pending section is actually a limitation on the departure of validators in the entire network. The purpose of this limit is to prevent the instability of the network caused by the rapid change of the number of validators (Validator) . At the same time, on the other hand, it takes about 27 hours for a Validator (Exit status) to withdraw from the network (Exit -> Withdrawable), and it takes an additional 36 days for a Validator who was forced to withdraw due to violations. Change to the Withdrawable state . At present, there are 867 Validators who have voluntarily withdrawn from the Beacon Chain, and 223 Validators who have been withdrawn by Slashed, and they are all currently in the Withdrawable state. If you want to actively exit the network, please refer to Exit your validator | Prysm

The relationship between the number of Validators and the circulation of Ethereum and APR

For details, see: Upgrading Ethereum

N is the number of validators, 225 is the number of Epochs that can be run per day

image source

The growth of APR and N is a negative correlation. There are several reasons for this design. The first is to ensure that APR is a function related to N, which can prevent rational verifiers from decisively withdrawing when the cost is significantly higher than the benefit. At the same time, it can Avoid paying exorbitant costs for security.

On the other hand, making APR and N a negative correlation will encourage Validators to review other people's work results to find ways to get those Validators who behave improperly out of the network.

image source

0x01 Credential and 0x00 Credential

Both 0x01 and 0x00 are proofs received by the Validator during deposits. For withdrawals, you only need to know that only Validators who hold 0x01 Credential can withdraw smoothly, because 0x01 contains the target address of the Validators income , and the vast majority of Validators currently hold 0x00 Credentials, so they need to upgrade to 0x01 Credentials after upgrading in Shanghai. If you want to know how to upgrade to 0x01 Credentials, you can see [Tim’s Twitter](https: https://twitter.com/TimBeiko/status/1600939567523037184). This shift is due to a change in the withdrawal scheme.

How many Validators and ETH are there in the Beacon Chain now?

According to the data of Beaconcha.in, as of December 29, the effectively pledged ETH on the Beacon chain was 15,775,062 ETH ( this data counts the number of ETH used to calculate Stake benefits and penalties), and the number of active validators There are a total of 494,096 verifiers, and the average ETH pledged by each verifier is 33.93 ETH (that is to say, the total number of ETH on the Beacon chain is 16,764,677 ETH). Currently, the Validator address with the highest staking income has 36.9690 ETH, and the staking time exceeds 700 days.

How Withdrawal will be implemented

Withdrawal will be jointly upgraded by the execution layer and the consensus layer. The execution layer mainly assists the consensus layer in the withdrawal process by introducing EIP-4895. Specifically, EIP-4895 completes withdrawals based on the idea of "Push" rather than "Pull", that is, users do not need to initiate a withdrawal request , but will generate a corresponding validator according to the status of Validators in the beacon chain. "Receipt", this receipt contains the details needed to complete the withdrawal, the receipts will enter a withdrawal queue, and a part of the receipt will be executed when each block is packaged, and the number of withdrawal requests that can be executed within a fixed time is determined by strictly limited.

Note: 1) These withdrawal requests will be a "system-level" operation type, which will not be carried out independently or enter the mempool of the user's normal transaction. To compete for block space. Only when the execution client synchronizes through the Engine API will it enter the execution block. Therefore, the withdrawal behavior will not increase the gas of Ethereum or make Ethereum more congested

2) Payload is used to tell the contract the function the user wants to call and the values of the parameters used by this function. System-level operation means that a new payload object `withdrawal` will be defined to distinguish the withdrawal behavior from the user's normal Transaction behavior, instead of defining the withdrawal as a new type of Transactions, this method More complex but easier to test and safer to implement. More about Payload can be seen

What-is-the-use-of-the-payload-field-in-the-ethereum-transaction-reciept
Understanding-data-payloads-in-ethereum-transactions
3) Contents of Capella Upgrade
Capella is a consensus-layer upgrade containing a number of features related to validator withdrawals.

Automatic withdrawals of `withdrawable` validators.
Partial withdrawals sweep for validators with 0x01 withdrawal credentials and balances in excess of `MAX_EFFECTIVE_BALANCE` (32ETH).
Operation to change from `BLS_WITHDRAWAL_PREFIX` (0x00) to `ETH1_ADDRESS_WITHDRAWAL_PREFIX` (0x01) versioned withdrawal credentials to enable withdrawals for a validator.

Withdrawal conditions

Withdrawal is divided into two types. "Partial Withdrawal" and "Fully Withdrawal" correspond to different conditions. There will be no difference in priority between partial withdrawal and full withdrawal, because the withdrawal is fully automatic, that is, Say you just need to meet the prerequisites and wait.

  • Necessary condition: Validator has 0x01 Credential
  • Partial withdrawal conditions: Validator is in Active state, and the balance of Validator is greater than 32ETH
  • All withdrawal conditions: Validator is Withdrawable (this usually means that Validator has exited the network)

How will the withdrawal be carried out

You can directly see https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#has_eth1_withdrawal_credential

When the Validator proposes a block, it will linearly scan all Validators according to the Validator's index, and the first 16 Validators found that meet the Withdrawal condition will form a set and be included in the ExecutionPayload, waiting for the withdrawal to be executed.

In other words, each Epoch will have 512 Validators that can be withdrawn (because one Epoch has 32 Slots, and one Slot is one block), and 115,200 Validators will be withdrawn in one day (one Epoch takes 6.4 minutes, and there are about 225 Epoch), within 5 days all validators of all validators will be traversed.

Ideally, if these 115,200 withdrawals are Partial Withdrawal, then according to the index from low to high, the balance available for withdrawal of the first 115,200 Validators in the index is 3 - 4 ETH (according to the beaconcha data pledge, the earliest Validator balance is about 36.3 ETH, the balance of the 115,200th Validator is about 35 ETH), based on the middle number of 3.5 ETH, the ETH unlocked by the withdrawal function on the first day is about 403,200 ETH (115200 * 3.5). Using the same calculation method, about 2.5 * 115,200 = 288,000 ETH will be unlocked on the second day of the upgrade, and 1.5*115,200 = 172,800 ETH will be unlocked on the third day. On the fourth day, about 0.5*115200 = 57,600 ETH will be unlocked. Since the fifth day, most of the Validators have withdrawn coins, so there will not be as much selling pressure as the previous few days.

Note: The ETH pledge was started in December 2020. At this time, the price of ETH was around $1,000, so most of the ETH that participated in the pledge since then will be at a loss compared with the current price.

Image from: Cryptorank

But in fact, the withdrawal may not always be as smooth as expected, and there will always be some unexpected circumstances that make the actual withdrawal amount higher or lower than the ideal value.

  • Let the unlock amount be lower than the ideal value
  • Not all Validators are 0x01 Credential, and not all Active Validators have 32 ETH. Therefore, some of the Validators do not meet the withdrawal conditions (the reasons are various), and these Validators that do not conform to the rules will be Passed during the traversal. Due to the existence of the Pass mechanism, the Validator is traversal (Sweep). Upper limit, this upper limit is `MAX_VALIDATORS_PER_WITHDRAWALS_SWEEP` = 16384 (2**14)
  • Make the unlock amount higher than ideal
  • There will be an option for Validators to select all withdrawals. Theoretically, if the first 115,200 Validators all choose to withdraw all, then the unlocked amount on the first day is 3,686,400 ETH. However, the prerequisite for all withdrawals is to withdraw from the network, and the number of Validators who can withdraw from the network every day is strictly limited by the "loss limit coefficient". Currently, the maximum number of Validators who can withdraw from the network per day is 1,575.

Possible Effects of Withdrawal

Note: The following are just some questions and my own opinions that I thought of when I was doing it, not investment advice

Q1: Will the unlocked ETH be sold in large quantities in the market?

There is a high probability that it will not. Although a large amount of ETH was unlocked in the first few days of the upgrade, unlocking does not mean that it will be sold. The cost of this group of pledgers who unlock ETH is not low at the current price of ETH. As users who joined the ETH pledge without knowing when the unlock will happen, it is believed that most of them are long ETH (there is no evidence Pure speculation), if there is not enough profit, I personally think that I will not choose to sell ETH, but may choose to re-stake. At the same time, after the withdrawal is opened, the pledged ETH has a clearer unlocking time and unlocking period, which means lower risks, and I believe it will attract more users to participate in the pledge.

Q2: What impact will it have on liquidity staking services?

Taking Lido as an example here, take a guess.

According to the withdrawal process, most of the withdrawals will be through "partial withdrawals". That is to say, for liquid staking service providers, the actual unlocked ETH is only the profit part of the Validator running on the platform. Unless the platform takes the initiative to let the Validator withdraw, but obviously from various perspectives, the platform has no motivation to do so.

Then it will lead to an extreme situation, that is, if stETH can be exchanged into ETH at 1:1 immediately after releasing the pledge, then once a large number of stETH holders apply for exchange, and the total amount exceeds what Lido obtained through ETH withdrawal at that time When the total amount of ETH is reduced, there will be a situation where stETH has no ETH to exchange (because it is actually locked), so even after the unlocking is opened, the 1:1 exchange of stETH and ETH will still need a buffer period, so that the platform has It takes time to release the validator's pledge, and because of this time difference, the pledged derivatives represented by stETH will still be pooled with ETH at an exchange rate slightly lower than 1:1 after the upgrade in Shanghai.

One advantage of delaying withdrawals is that it reduces the panic and risk of a run. In addition, there is another potential benefit, that is, the difficulties encountered by Lido will be encountered by all liquid staking service providers, so the delayed withdrawal of ETH pledge will most likely become a common model for liquid staking service providers. Why is this a good thing? Because one of the moats of stETH is its good liquidity and composability, but there is a concern that after the release of the pledge, the liquidity advantage of stETH disappears because the pledged derivatives can be exchanged for ETH 1:1, but due to A mechanism to delay withdrawals exists, and stETH will still retain its liquidity advantage.

To learn more about withdrawals, please refer to the following information:

  • https://www.youtube.com/watch?v=CcL9RJBljUs
  • https://notes.ethereum.org/@ralexstokes/validator-withdrawals-meta-spec

EOF

Concepts that may be involved

EVM

One of the most important differences between Ethereum and Bitcoin is the addition of smart contracts, and EVM can be understood as an operating system for running smart contracts. Recommended reading: https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy?s=r

Byte code

Usually developers can write smart contracts in a high- level programming language called Solidity, but the smart contracts written by Solidity can be read by humans but not by computers, so they need to be interpreted by the EVM into EVM bytecode and then run by the computer , turning the high-level language (Solidity) that humans can understand into a language (bytecode) that only computers can understand.

In the figure below, the string of unknown hexadecimal codes above is bytecode. They have an obvious feature that they start with 0x. The beginning of 0x will make EVM read the next string as hexadecimal; the following is Contract code written by Solidity before compilation

Picture from: Etherscan randomly found a screenshot of a transaction

opcode operation code

opcode aka operation code, simply speaking, bytecode is usually a series of opcode and its input value. opcode represents some relatively readable operation instructions of the EVM, and these instructions have strict corresponding hexadecimal codes, such as `ADD` corresponds to 0x01. Each opcode needs gas.

Picture from https://ethervm.io/

Stack Machine

EVM is a kind of Stack Machine, which uses LIFO (Last in, First Out) method to read. The simple understanding is that the input value of the EVM opcode will enter the stack, and the stack will be followed. Ethereum theoretically has a maximum of 256 opcodes, and each opcode will pop the top element of the stack and push the result into the stack. To learn more, you can see the in-depth simple out of the stack

Process flow operations

Process flow operations mainly refer to the following opcodes

Image from: https://ethereum.github.io/execution-specs/autoapi/ethereum/dao_fork/vm/instructions/control_flow/index.html

  • Stop: Stop the running of the EVM code
  • PC: Program counter, which is used to specify the field of the currently read bytecode, which will confirm where the next instruction to be executed in the bytecode is, and then jump to the function to be executed through JUMP.
  • JUMP: Change the next instruction to be executed
  • JUMPI: Conditional JUMP
  • JUMPDEST: Destination of JUMP
  • offset: Offset, used to indicate the location of each instruction, in bytes. Bits, bytes, and words are units of computer data storage. Bit is the smallest storage unit , each bit stores a 1-bit binary code , and a byte consists of 8 bits. Words are usually 16, 32 or 64 bits.
  • Bit is the most basic concept. In a computer, since there are only logic 0 and logic 1, many things, actions, and numbers must be expressed as a string of binary codes, such as: 1001 0000 1101 and so on. Each logical 0 or 1 is a bit.
  • A byte is a unit composed of eight bits, that is, 8 bits form a Byte. What is the use of bytes? In computer science, it is used to represent ASCII characters, which is to use bytes to record letters and some symbols. For example, the character A is represented by "0100 0001".
  • Word (Word) represents the binary digits of computer processing instructions or data, and is the unit of computer operations for data storage and data processing. Word sizes tend to be different for 32-bit machines versus 64-bit machines.

Smart contract deployment

To deploy a smart contract, simply send an Ethereum transaction containing the compiled smart contract code without specifying any recipients. At present, because Ethereum includes the compiled smart contract in the transaction, there is no source code, because when Ethereum executes the smart contract, it is faced with bytecode, and it is difficult to verify the correctness of the smart contract before running.

What is EOF

EOF is an upgrade to EVM, which introduces new contract standards and some new opcodes. The traditional EVM bytecode (bytecode) is an unstructured sequence of instructions bytecode. EOF introduces the concept of a container, which implements structured bytecode. The container consists of a header and several sections to structure the bytecode. After the upgrade, the EVM will be able to perform version control and run multiple sets of contract rules at the same time. This EOF upgrade will be realized by 5 EIPs, namely EIP-3540, EIP-3670, EIP-4200, EIP-4750 and EIP-5450. Since EOF is a huge upgrade, it may be delayed in order to ensure that withdrawals can be opened smoothly in January.

For details, see EVM Object Format (EOF)

The meaning of EOF

In short, EOF is a new set of contract rules. The currently running EVM can only run a set of interpretation and validation rules at the same time. This set of rules will apply to all existing contracts, called Legacy contracts. EOF introduces a new set of contract rules and upgrades the EVM interpreter accordingly. After the upgrade, the EVM can run two sets of contract rules in parallel, one set of EOF contracts and one set of Legacy contracts.

With EOF, EVM is no longer limited by the requirement of forward compatibility when iterating, and the difficulty of upgrading becomes lower, which may lead to more frequent upgrades of Ethereum EVM in the future.

Frequent EVM iterations may lead to higher requirements for EVM-compatible virtual machines, such as zkEVM. To keep up with the version, other EVM-compatible VMs may need to have the ability to automatically convert EOF updates to their own VMs.

What does each EIP do?

EIP-3540: EVM Object Format (EOF) v1

In the past, the EVM bytecode deployed on the chain did not have a pre-defined structure, and the code was only verified before being run in the client. This is not only an indirect cost, but also hinders developers from introducing new functions. Or deprecate old functionality. This EIP introduces a container that can be expanded and version controlled for EVM, and declares the format of the EOF contract (as shown in the figure below), based on which the code can be verified when deploying the EOF contract, that is, creation time validation. It means that contracts that do not conform to the EOF format can be prevented from being deployed. This change implements EOF version control, which will help to disable existing EVM instructions or introduce large-scale functions (such as account abstraction) in the future.

The first tangible feature provided by this EIP is the distinction between data and code, which is very helpful for on-chain code validators, which will save their gas consumption

EIP-3670: EOF - Code Validation

EIP-3670 is based on EIP-3540, and its purpose is to ensure that the code of the EOF contract is formatted and valid. For contracts that do not conform to the format, its deployment will be prevented and Legacy bytecode will not be affected.

EIP-4200: EOF - Static relative jumps

EIP-4200 introduces the first EOF-specific opcodes: RJUMP, RJUMPI, and RJUMPV, which encode destinations as signed immediate values. Compilers can use these new JUMP opcodes to optimize the gas cost of deploying and executing JUMP, because they eliminate the runtime required for the existing JUMP and JUMPI opcodes when doing jumpdest analysis. This EIP is a supplement to dynamic jump.

Compared with the traditional JUMP operation, the difference is that operations such as RJUMP do not specify a specific offset position, but specify a relative offset position (from dynamic jumps -> static jumps), because static jumps are often enough

EIP-4750: EOF - Functions

EIP-4750 takes the function of 4200 one step further: by introducing two new opcodes `CALLF` and `RETF`, it implements an alternative solution for the situation that cannot be replaced by RJUMP, RJUMPI and RJUMPV, so as to realize the EOF contract JUMPDEST is no longer needed, thus disabling dynamic jumps.

EIP-5450: EOF - Stack Validation

EIP-5450 adds another validity check to EOF contracts, this time around the stack. This EIP prevents situations where EOF contract deployments may cause stack underflows/overflows (stack underflows / overflows). This way, clients can reduce the number of validity checks they do during execution of EOF contracts.

The background is still that the Ethereum contract is not checked when it is deployed, and only a series of checks are performed when it is running, whether the stack overflows (the upper limit is 1024), whether the gas is enough, and so on. A big improvement of EOF is to make these checks as few as possible during execution, and more checks happen when the contract is deployed.

other minor upgrades

EIP-3651: Warm COINBASE

To understand EIP-3651, you must first understand EIP-2929, because EIP-3651 actually solves a problem caused by EIP-2929.

So what is EIP-2929?

The full name of EIP-2929 is State Assess Lists. To put it simply, EIP-2929 makes some transactions more expensive when they are triggered for the first time (the gas fee varies according to the type of access storage), because the address access of these transactions requires a slave The process from Cold to Warm, after the first trigger, the address will change to Warm state, and Warm state means that it will be cheaper to access the same address in the future, so if the same Opcode needs to be executed multiple times in the same transaction, then It will be cheaper than that, and some accounts are warm by default. EIP-2929 defaulted sending address and receiving address to be warm at that time. In fact, EIP-2929 did not reduce the average gas consumption, and even increased slightly (increased by 0.3% - 0.4%), because the main purpose of EIP-2929 is to increase the cost of DoS attacks, so it is necessary to increase the gas consumption of state access opcode At the same time, in order to balance the Gas used by users to initiate transactions in practice, some frequently used accounts are warmed by default.

EIP-3651 is to make `COINBASE` address also warm by default, `COINBASE` address aka feeRecipient address. This change is mainly to solve the problem that EIP-2929 causes `COINBASE` to be initially in the "Cold" state, which makes the transaction fees involving COINBASE addresses more expensive. The specific modification method is to add the address of COINBASE to the Access List Framework proposed by EIP-2929, so that the address of `COINBASE` is also in the Warm state by default, so that the interaction with the COINBASE address will not consume more than other addresses in the Access list More fees.

The impact of EIP-3651 is that MEV extractors, Block builders and Vailidators will reduce costs in transactions involving COINBASE addresses, because COINBASE is used by a large number of block builders in contional payments. According to William Morriss, after the implementation of EIP-3651 , the approximate cost of interacting with COINBASE Address will be reduced by 26 times. In the past, State access includes accounts needed about 2600 gas, but only 100 after warming.

Note: What is COINBASE Address

COINBASE here refers to the Software used by Block builders to accept new tokens in the network. Block builder usually packs transactions from mempool into blocks and sends them to Validator for sorting, and collects profits from them. In each transaction, multiple interactions with COINBASE Software are required, and the first interaction is usually more expensive, because currently the COINBASE Address needs to be Warm up, and then the interaction fee will slowly decrease as the number of interactions increases, while EIP -3651 Allows COINBASE to be in the Warm up state from the beginning, which will reduce the cost of transferring money to COINBASE

Conditional payments: EIP-1559 makes conditional payments possible. A large number of flashbots use this method, that is, set MaxPriorityFeePerGas to 0, so that Gas Fee will not be charged when the transaction fails. At the same time, these failed transactions are also resistant to censorship, because they fail, and the block builder does not charge Gas and will not save their information. But to use conditional payments, you need to access COINBASE Account

EIP-3855: PUSH0 instruction

Introduce a new opcode to push a value of 0 into the stack. PUSH 0 is a common case in the EVM (11.5% of PUSH* instructions are used to PUSH 0 values into the stack), this EIP will provide a more efficient and cheaper way to do this (now via ` PUSH1 0`, etc.), while providing a unified standard usage for all situations where 0 values need to be put into the Stack

EIP-3860: Limit and meter initcode

This EIP adds a maximum size for ` initcode` and introduces gas metering based on its length. The size limit adds an invariant to the EVM which will make it easier to reason about and propose changes to.

A 2 gas/32 byte cost for `initcode` is introduced to account for the jumpdest-analysis clients must do prior to execution, which previously was not accounted for in the gas schedule.

If there are any factual mistakes in this article, I would be very grateful if you can criticize and correct them. If there are differences of opinion, you are also welcome to discuss. In addition, this article has no investment advice, driven by pure curiosity.

refer to

Source
Disclaimer: The content above is only the author's opinion which does not represent any position of Followin, and is not intended as, and shall not be understood or construed as, investment advice from Followin.
Like
Add to Favorites
Comments
Relevant content