Why Shanghai upgrade is important. Because in fact, the four stages in the roadmap released by ETH in 15 years: Frontier, Homestead, Metropolis, Tranquility, have gone through 15 upgrades , and they have all been completed in the last Paris upgrade. expected.
A major feature of the roadmap for the new era of ETH2.0 is frequent updates during the eth1.0 phase. Each major update interval is 1~2 years before the test can be launched. In ETH2.0, it seems that there will be a major upgrade every six months.
The Shanghai upgrade is the first upgrade of the six stages of the new roadmap, and the burden on it is self-evident. Just like looking at the eth roadmap four years ago and feeling like a thief, now we look at the new roadmap with this kind of dreamy feeling. How many years will it take before the dream can be reflected in reality?
To put it bluntly, in the foreseeable future, the market will start to stir up speculation immediately, and tokens that can catch up with the concept of this Shanghai upgrade.
- Explaining Starkware in detail: underlying design, Cairo language, team and economic model
- EVM delves into Part 2
- EVM Deep Dive Part 1
So to answer this vulgar question. Our article will be divided into three parts.
1. The new pattern of ETH2.0
2. The specific content of the Shanghai upgrade
3. Shanghai upgrade, potential follow-up impact
The new pattern of ETH2.0, this is an era belonging to MEV
In ETH2.0, the “verifier” has replaced the role of the previous “miner”. MEV revenue has replaced the role of the original GAS fee. Liquid pool, staking pool, and cex staking three types of mining pools have replaced the role of the previous pow mining pool.
1. Validators replace miners
After the merger of the ETH2.0 mainnet, all transactions on the Ethereum network will no longer be verified by energy-intensive “miners”, but by individual and organization “verifiers” who have deposited or pledged a large amount of ETH. Anyone only needs to pledge more than 32ETH to meet the minimum requirements, and the verification node becomes a **”verifier”. **
2. MEV income replaces GAS fees
MEV is a concept that web3.0 practitioners must popularize as soon as possible. We can explain it this way, ETH1.0 is a gas distribution game around pow, while ETH2.0 is an arbitrage gas consumption game around MEV
MEV (Miner Extractable Value), which can be extracted by miners, is also translated as Max Extractable Value, which was first proposed by Phil Daian in the Flash Boys 2.0 paper.
We all know that all actions on the chain exist in the form of “transactions”, and all transactions initiated by users will enter the “mempool” and wait to be packaged by miners. Based on the principle of profit maximization, miners will The order of packaging is determined by the high or low fee, which is the basic condition for the emergence of MEV, and it also gave birth to the emergence of robots on the chain. They use high gas settings (PGA) to preempt transactions in the pool for arbitrage.
Specifically, the currently developed MEV arbitrage mainly falls into three categories: 1. Triangular arbitrage 2. Clip (sandwich attack.) 3. Loan liquidation.
However, the actual arbitrage capture can only achieve about 20% of the theoretical arbitrage at present. The development of arbitrage strategies and the scale of arbitrage in this area will gradually increase with the improvement of eth code, performance enhancement, and market changes.
Such profits that are placed on the ground for nothing are naturally targeted by many people. According to statistics, since 2020, the cumulative amount of MEV captured by the entire network has reached as high as 680 million US dollars. This also led to the rise of a new generation of stars – Flashbot, a tool to help nodes capture MEV. And a host of fancy competitors on the MEV capture track, including but not limited to: KeeperDAO, ArcherDAO, Automata, mistX, BackRunMe
The huge profits generated by MEV have always been trapped in the circle of miners and robots on the chain. It was first used as a kind of gray income of mining pools, which was dubbed by the folks as “bribing node income” and “the smallest 51% attack”.
Arbitrageurs discover arbitrage opportunities, bribe “verifiers”, and manipulate the order of transaction packaging for arbitrage. Here, the spoils sharing process between arbitrageurs and verifiers “is not only a cooperative relationship, but also a game relationship. This article will not expand too much here.
This situation will not change until the London upgrade and Ethereum merger in 2022.
The EIP1559 passed in the London upgrade has greatly changed the income structure of miners
From the previous full gas fee to the burning + tipping model , and the merger of Ethereum also marks its complete change to the POS consensus mechanism, **”Verifiers” replace the original Buddhist “miners”** to participate The value of MEV is divided, and the node network of ETH2.0 has become a more competitive and ecologically rich MEV paradise. This has also greatly increased the number of Flashbot clients, as of now nearly 90% of Ethereum validators are running its MEV-boost client.
Since then, MEV has completely replaced the gas fee as the main income of Ethereum “validators”, and the gas fee is used to burn, resulting in the long-term deflationary expectations of ETH. Based on the current data, due to the introduction of MEV-boost, the income of Ethereum “verifiers” has increased from about 3% to a level close to 10%. Under the premise of ETH deflation, the “node” income is not even lost before the halving, laying the foundation for the stability of the ETH network, and forming a natural barrier with other pos chains.
3. Mining pools in the new era
Although as mentioned above, only more than 30 eth can become a validator in eth2.0, it is still very difficult for individual validators to successfully obtain rewards every two months on average. Especially when it comes to technical activities such as mev-boost that require frequent maintenance, personal verifiers are always stretched. Therefore, except for a very small number of giant whales and lonely braves, joining a mining pool is still the mainstream solution. There are currently three types of mining pools: Liquid pool, staking pool, cex staking
The market shares are as follows:
1. Liquidity mining pool:
The degree of centralization is moderate, and the business model takes Lido, which has a market share of 88.67%, as an example. The mining income pledged in Lido is given in the form of steth. All mining rewards are divided into three parts, 90% to users who pledge ETH, node operators and Lido treasury each share 5%, and the mining pool will also reward users and treasury $Lido mining rewards, user deposit certificate is stETH, because stETH is liquid, so it is called a liquidity pool. Maintaining the liquidity of the stETH-ETH trading pair and the incentive of the $LDO token are the main competitiveness barriers of this type of mining pool.
2. Exchange mining pool
The degree of centralization is relatively high, and the specific distribution plan of mining pool revenue, management fees, and even the source of mortgaged ETH are relatively opaque. The advantage is the strong business endorsement and business team of the exchange.
3. Mining pool
The degree of centralization is extremely low, basically decentralized, and the model is that there is no model. Free mortgage, fair distribution, and relatively transparent management fees.
The disadvantage is that before the Shanghai upgrade, due to the phased limitations of ETH2.0, the currently locked ETH is in jail and cannot be redeemed. It is foreseeable that this type of mining pool will become the main beneficiary after Shanghai’s upgrade.
Based on the above new economic model, validators can generate and collect new ETH (MEV) by staking ETH. These so-called “new ETH” are their rewards for verifying transactions and protecting the network.
But in the current Ethereum, ETH can only be deposited but cannot be withdrawn, and the total value of the pledge is close to 23.5 billion US dollars, all of which are “trapped” on the Ethereum network.
If the unstaking function is not opened as soon as possible, the attractiveness of staking ETH will be greatly reduced , and there will not be so many people entering the Ethereum network in the future. This will undoubtedly have a huge impact on the future development of Ethereum and network security. In the POS world, the mortgage amount of POS is justice, and maintaining the mortgage amount is the first consensus to maintain block security.
And this Shanghai upgrade will provide the ability to unlock the 23.5 billion US dollars of POS pledged ETH locked on the chain, and it will also be accompanied by the integration of many EIPs optimized for GAS.
The specific content of the Shanghai upgrade
It is a pity that EIP-4844, which was very important in the Shanghai upgrade, was finally confirmed to be postponed. It is the first step in ETH sharding, which can greatly reduce the gas cost of eth. Some operations can save gas by a hundred times.
Only nine of the twelve remaining proposals were finally confirmed to be updated. Among them, the eighth specific plan on ETH unlocking is the most important.
1.EIP-3540: EVM Object Format (EOF) v1
EOF optimization
This EIP introduces a reserved format for scalable and versioned containers to the EVM. This reserved format enables code and data separation benefits, making it easy to introduce changes in the future. This change relies on the reserved format introduced by EIP-3541.
Currently, the EVM code deployed on-chain does not contain a reserved format. The code usually needs to be analyzed and verified by JUMPDEST every time before the client runs, which causes additional consumption and does not help the update iteration of the code. The innovations described in this EIP introduce a simple, extensible reservation format with relatively low client and encoding requirements. This reserved format provides the ability to identify and separate the separation of code and data. This separation capability is particularly beneficial for on-chain code validators such as those used by second-layer scaling tools such as Optimism.
2.EIP- 3651: Warm COINBASE
Save the meaningless gas consumption related to ERC20
EIP-3651 was proposed on July 12, 2021 by William Morriss ( wjmelements ). This proposal has been passed and will be included in the Shanghai upgrade. This is a proposal that affects the type of transaction that incentivizes. The COINBASE mentioned in this proposal is not Coinbase, a large exchange, but the name of the software miners use to acquire new coins on the network. This concept originally originated from Bitcoin. The first transaction in a block is called a creation transaction or COINBASE transaction. This is a special transaction for miners to package and collect gas tips for mining. Whether there is a preload before executing the transaction is defined as “warm” or “cold”. In EIP-2929, when the target is not in the accessed_addresses, the cold account access cost (COLD_ACCOUNT_ACCESS_COST) will be charged. At this time, the first transaction is not preloaded (cold), and the gas fee charged will be high, while after preloading (warm) ) transactions, the gas fee will be reduced.
William Morris proposed in the proposal that each new transaction on the platform at this stage must interact with the COINBASE software multiple times. Since the software needs to be “warmed up”, the first gas cost will be higher. As the number of interactions increases, The gas fee will gradually decrease. Williams Morriss proposed in EIP-3651 that COINBASE software can be kept “warm” from the beginning (preloaded), and the address returned by COINBASE (0x41) is included in accessed_addresses, thereby changing the gas of the first transaction inserted by miners Fees, and thus encourage payment methods in ERC20 tokens. The advantage of this proposal is that after the launch of EIP-3651, the transactions packaged by miners can be used for more purposes, and the cost of gas fees will be reduced. At the same time, before the launch of EIP-3651, it is more inclined to use ETH for payment, and after the launch, it will encourage the use of ERC 20 payment methods. Another proposal passed in the Shanghai upgrade, EIP-3855, is also a proposal to reduce meaningless gas consumption. The implementation of both proposals will greatly reduce the cost of Ethereum gas fees.
3.EIP-3670: EOF – Code Validation
EOF optimization
Introduce code verification when creating contracts with EIP-3540. Contracts that reject undefined instructions. In this way, code verification can be introduced when the contract is created. Reject contracts containing truncated PUSH-data or undefined instructions.
4. EIP-3855: Add PUSH0 instruction
It is a proposal to reduce meaningless gas consumption
For the EVM, which is the Ethereum virtual machine (the system that executes the contract code), there are many kinds of instructions designed, but there was no design of push0 before, that is, the operation instruction for pushing the value of 0 into the stack, and this EIP adds PUSH0( 0x5f) instruction, which pushes the constant value 0 onto the stack, which requires 2 gas
When there was no push0 originally, there were some operations that relied on 0 as an offset, such as remote call calls and returns, many parameters were 0. Originally, to operate 0, you could only use the instruction PUSH1 0 (that is, push a number, the number is 0), this operation will consume 3 gas, and then push1 and 0 each occupy a byte storage of the initialization code, resulting in a higher cost of deploying this contract by 2*200gas
The EIP also counts the resulting gas loss: in the existing account, 340,557,331 bytes are wasted on the PUSH1 00 instruction, which means that the deployment loss is 68,111,466,200 gas
5.EIP-3860: Limit and meter initcode
Increase the upper limit of the smart contract system and reduce the gas
Extends EIP-170 by introducing a limit on the maximum size of initcode (MAX_INITCODE_SIZE = 2 * MAX_CODE_SIZE = 49152). The maximum size limit of initcode will be increased from 24576 to 49152, that is, doubled. At the same time, 2 gas fees are introduced for each 32-byte initcode chunk to represent the cost of jumpdest-analysis.
Purpose: During contract creation, the client must perform jumpdest-analysis on initialization code before executing initcode. The work performed scales linearly with the size of the initcode. Based on EIP170, the initcode size is limited to 24576, but now the maximum size limit of initcode is increased to 49152. The original temporary solution is to deploy multiple contracts and then call each other, but obviously cross-contract references are a high gas cost. Obviously, a larger code capacity means that the contract size can be doubled, and contract developers can deploy richer functions. In short, the purpose of EIP-3860 is to support larger Dapps.
6.EIP-4200: EOF – Static relative jumps
Optimize EOF to save gas.
Three new EVM jump instructions (RJUMP, RJUMPI, and RJUMPV) have been introduced that encode a target as a signed immediate value. These are useful in most (but not all) use cases and can keep costs down.
7.EIP-4750: EOF – Functions
Optimize EOF to save gas.
Two new opcodes CALLF and RETF are introduced to call and return from such functions. Additionally, the JUMPF instruction was introduced to perform jumps to functions. Dynamic jump instructions are not allowed.
EIP-4200 introduced static jump instructions, which remove the need for most dynamic jump use cases, but not everything can be solved with them.
This EIP is designed to eliminate the need for and prohibit dynamic jumps because it provides the most important functionality: calling and returning from functions.
Additionally, it is designed to improve analysis opportunities by encoding the number of inputs and outputs for each given function and isolating each function’s stack (i.e. functions cannot read caller/callee stacks).
8.EIP-4895: Beacon chain push withdrawals as operations
The core of this Shanghai upgrade: support for validators to withdraw funds from the beacon chain to the EVM through a new “system-level” operation type
This EIP will introduce a system-level “operation” to support “push” withdrawals from the beacon chain to the EVM. Currently, about 14 million ETH are pledged in the beacon chain. The operation of this withdrawal operation will mean that the pledged withdrawal function of the Ethereum beacon chain will be activated.
Purpose: This EIP provides a way for validators on the beacon chain to withdraw funds into the EVM, thereby realizing the withdrawal operation of pledged ETH. The implementation method is based on the consensus information of the beacon chain, and the system directly controls the ETH balance of the specified address unconditionally. Under this method, there is no gas fee consumption, and there is no need to use gas to prevent dos attacks**. All in all, the purpose of EIP-4895 is to realize the pledge withdrawal function. **
ETH Shanghai Upgrade Unlocking Pledge Scheme
Churn Limit Quotient
According to the latest proposal from the community, validators can make partial withdrawals and full withdrawals, and for security reasons, the withdrawal amount and the withdrawal rate of validators will be limited. The maximum withdrawable amount per Epoch for withdrawal is set to 512. According to the number of existing validators, they can withdraw rewards once in 4 days (total number of validators/(512*225). According to the current validators, nearly 33.9 ETH Based on the average balance of the Ethereum market, the maximum average selling pressure faced by the Ethereum market every day is 230,000 ETH, and the cumulative amount in 4 days is 921,000.
Among them, the withdrawal rate in all withdrawals will be limited. The withdrawal mechanism introduces a “Churn Limit Quotient”. The ETH withdrawal limit is X/ETH per day, where X is the total number of verifiers/65536. Currently Each Epoch can only activate 7 verifiers and is allowed to withdraw, that is, 1575 verifiers per day (225 Epoch). If each verifier holds 32 ETH, the daily outflow of ETH exceeds 50,000 pieces. Of course, the withdrawal rate will also be adjusted according to the total amount of pledged ETH to prevent large outflows of funds and attackers from conducting slashing attacks. Partial withdrawals do not have a specific limit on the number of withdrawals.
It should be noted that the effective pledge balance of the verifier must be above 32 ETH. If it is lower than this amount, the full pledge reward will not be obtained, or the verifier will be expelled from the ranks of the verifier if the balance is less than 16 ETH. Currently, the validator’s undecided withdrawal plan is divided into partial and full deposit withdrawals. Partial withdrawal allows the verifier to withdraw more than 32 ETH, and full withdrawal allows the verifier to withdraw all deposits and exit the pledge.
However, the developer Potuz has recently proposed a new solution that can cancel the withdrawal queue
That is to cancel the logic of all and part of the withdrawal queue in the block. It is recommended to use the validator index to solve this problem. The reason is that each validator on Ethereum will be assigned a number when activated on the beacon chain. Without using the above-mentioned queuing exit, the beacon chain can handle the withdrawal limit according to a block. Number to scan validators, and then process each validator’s withdrawal request in ascending order of the validator’s index number. Currently, developers are researching this solution as an alternative.
9.EIP-5450: EOF – Stack Validation
EOF optimization
Introduce extended verification of code segments to guarantee that no stack underflow occurs during the execution of the verification contract
Current existing EVM implementations perform a large number of validity checks on each executed instruction, such as checking for stack overflow/underflow, whether there is enough gas, etc. This change is intended to minimize the number of such checks required at runtime by verifying at deploy time – when no exceptions occur, and to prevent code from being deployed where it could.
In particular, this extended code verification eliminates the need for EVM stack underflow checks on every executed instruction. It also prevents the deployment of code that can be statically proven to require more than 1024 stack items, but it is still possible to exceed that limit in some cases, so overflow checks cannot be completely eliminated.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
