Merged ETH Issuance

The Ethereum merger completes the transition of the Ethereum network from proof-of-work to proof-of-stake. The way ETH is issued has changed in the interim. Previously, new ETH issuance came from two sources: the execution layer (i.e. the mainnet) and the consensus layer (i.e. the beacon chain). ETH issuance on the execution layer is now zero since the Ethereum merger.

Execution layer issuance after the merger: Under the upgraded consensus rules, proof-of-work is no longer an effective means of block production. All execution layer activity is packaged into "beacon blocks" ("beacon blocks"), that is, issued and verified by the proof-of-stake verifier. Rewards for validating and publishing "beacon blocks" are calculated separately on the consensus layer.

Post-Merger Consensus Layer Issuance: Consensus Layer ETH issuance continues, just like before the merge, with small rewards for validators who validate and propose blocks. Validator rewards continue to accrue to validator balances managed within the consensus layer. Validator accounts on the Beacon Chain are separate from the accounts we use on the Ethereum mainnet, and withdrawals from validator accounts will not be possible until the planned Shanghai upgrade. After the Shanghai upgrade, users will be able to withdraw their rewards and stake if they wish. This also means that while new ETH is still being issued, it remains 100% locked in the market until the Shanghai upgrade happens.

ethereum key

Here we introduce the "key" of the Ethereum account. Ethereum uses public-private key cryptography to protect user assets. The public key is used as the basis of an Ethereum address - that is, it is visible to the public and serves as a unique identifier. Private keys should only be accessible to the account owner. Private keys are used to "sign" transactions and data so that cryptography can prove that the holder approves certain actions for a particular private key. As Ethereum transitions from Proof of Work to Proof of Stake, users need a new type of key to participate in Proof of Stake by staking ETH and managing validators. The original Ethereum mainnet key is still exactly the same as before, but users who wish to become independent stakers on the beacon chain need a validator key and withdrawal key. After the Shanghai upgrade, withdrawal key is required for pledge withdrawal.

Shanghai upgrade

first level title

We have summarized the four EIPs that will be activated in the Shanghai upgrade:

EIP- 3651 ： Warm COINBASE

Start COINBASE address warm-up

Overview: According to the actual cost of reading the account, the COINBASE address should be warmed up when the transaction starts to execute.

Explain that COINBASE here comes from the concept of Bitcoin, that is, the first transaction in a block is a special transaction called a COINBASE transaction, which was originally designed for miners to package and collect gas tip income for mining. The COINBASE address is preheated (loaded into the system) when the transaction is executed, avoiding the need to re-acquire the COINBASE address information from 0 every time a tip is obtained.

Motivation: COINBASE direct payments are becoming more and more popular. COINBASE payments were adopted because they allow conditional payments, which are beneficial to the network, such as transactions that prevent packaged rollbacks. However, the transaction price with COINBASE is very high. In the interactive list framework introduced by EIP-2929, the COINBASE address is listed as a "cold address", and the information of the COINBASE address must be obtained again for each transaction. Although this gas cost mismatch can motivate other payment methods other than ETH, such as ERC 20, ETH is the main payment method for Ethereum transactions. EIP-3651 is conducive to allowing miners to save gas fees and speed up miner transactions.

EIP-3855, PUSH 0 (0x5f) instruction

Introduce a new instruction that pushes the constant value 0 onto the stack

Overview: Introduces the PUSH 0 ( 0 x 5 f ) instruction, which pushes the constant value 0 onto the stack.

Motivation: Many instructions expect an offset as input, which in many cases is 0 . A good example is the return data parameter of call, which is set to zero if the contract prefers to use RETURNDATA*. This is just one example, but there are many other reasons why a contract would need to push a 0 value. They can do this now with PUSH 1 0 , which costs 3 gas at runtime and is encoded as two bytes, which means a deployment cost of 2 * 200 gas. With the PUSH 0 instruction, there is no need to consume this additional gas deployment cost. Also, from a "wasted" perspective, in existing accounts, 340,557,331 bytes were wasted on push 100 instructions, which means that deploying them consumes 68,111,466,200 bytes gas. The goal of EIP-3855 is to reduce meaningless gas consumption.

EIP- 3860 ，Limit and meter initcode

Limits the maximum size of initcode to 49152 and applies a gas cost of 2 for each 32 byte initcode chunk.

Overview: Extends EIP-170 by introducing a limit on the maximum size of initcode (MAX_INITCODE_SIZE = 2 * MAX_CODE_SIZE = 49152). Also introduce a gas fee of 2 per 32 bytes of initcode chunk to represent the cost of jumpdest-analysis.

Motivation: During contract creation, clients must perform a jumpdest-analysis of initialization code before executing initcode. The work performed scales linearly with the size of the initcode. Based on EIP 170, the initcode size is limited to 24576, and now the maximum initcode size limit is increased to 49152. 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.

EIP-4895 Beacon Chain Introduces Withdrawals as Operational Instructions

Support for validators to withdraw funds from the beacon chain to the EVM through a new "system-level" operation type.

Overview: Introducing a system-level "operation" to support "push" from the beacon chain to EVM withdrawals. After the deployment is complete, the Ethereum beacon chain pledge withdrawal function will be activated.

Motivation: This EIP provides a way for validators on the beacon chain to withdraw funds into the EVM. As a result, the pledged ETH withdrawal operation is implemented, and the implementation method is to introduce a system-level instruction withdrawal based on the information of the beacon chain (consensus layer), unconditionally and directly control the ETH balance of the specified address. The purpose of EIP-4895 is to implement the pledge withdrawal function.

refer to:

refer to:

https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/keys/#withdrawal-key

https://ethereum.org/en/upgrades/merge/issuance/#cl-issuance-post-merge

https://eips.ethereum.org/EIPS/eip- 3651 

https://eips.ethereum.org/EIPS/eip- 3855 

https://eips.ethereum.org/EIPS/eip- 3860 

https://eips.ethereum.org/EIPS/eip- 4895