Partnered With:

The most noteworthy Ethereum improvement proposals in 2021

Read this article in 10 Minutes

Besides EIP-1559, what proposals are still being discussed in the Ethereum community.

Original title: "2021: The Most Noteworthy Ethereum Improvement Proposal"

Original Source: ETH Chinese Station

< p line="QTN1">

2021 will be the most innovative year for the Ethereum protocol since 2016. The following is the EIP situation worthy of attention this year:

The next hard fork upgrade - "Berlin" will Implement 4 EIPs:

EIP-2929: Gas fees for state access opcodes will increase

EIP-2930: Optional Access List Txs

EIP-2718: Typed Transaction Envelope

EIP-2315: Simple Subroutines

EIP-2929: Increased gas cost required for state access opcodes. Gas fees for storing access opcodes have long been too low, and some malicious transactions that take only 20-80 seconds to execute can now be easily created. This EIP increases the cost of state access by ~3x.

EIP-2930: Optional Access List. About 0.18% of mainnet transactions will be blocked due to EIP-2929. To bridge this gap, this EIP introduces a new type of transaction that specifies the storage slot to be read and pays a 10% upfront fee.

EIP-2718: Contains type transaction envelopes. This EIP specifies a new format for transactions, starting with a "discriminator" that allows clients to interpret different transactions. EIP-2930 will use this EIP first, and then possibly EIP-1559. new format = type || payload.

EIP-2315: Simple subroutine. The last EIP included in the upgrade of the Berlin hard fork: adding support for subroutines. Contracts that want to emulate this functionality have traditionally dealt with both regular stack data and return addresses. This EIP adds a new stack just to track the returned address.

After the Berlin fork, there will be many unstable factors. If the ice age is not extended in the next fork, the fork plan will start in early July. According to the recent AllCoreDev meeting, another fork may appear this summer. There are many candidate EIPs for this hard fork, the most famous of which is EIP-1559.

EIP-1559: Fee Market Changes for Eth1. Gas fee is divided into two parts: base fee (basic fee) and tip (tip). The base fee portion is burned, while the tip is sent to the miner. The basic fee will be dynamically determined by the agreement according to the demand. This avoids some fee spikes and improves the user experience when paying for gas.

(Translator's Note: Here the author inserts the latest status update of EIP-1559 by Tim Beiko, the main promoter of EIP-1559)

Details: https://twitter.com/TimBeiko/status/1349027063903121408

In my opinion, I don't think 1559 is ready to go live right now. The following is a summary of some thoughts I shared on dicord:

Not all clients have 1559 implementations, And none of the clients have a final version;

We haven't resolved the issues raised at the AllCoreDevs meeting ( i.e. test large blocks with large states). It will take weeks at best to achieve this.

1559 will affect many other projects: any project that involves signed transactions, relies on JSON RPC for block/transaction Waiting for the reaction. We still need to talk a lot about these effects.

The Berlin hard fork is about to start. It is not a good choice to drop all the work at hand and implement 1559.

EIP-2982: Phase 0 of Eth2. For the first time since EIP-1011, eth1 and eth2 are assembled in the EIP repository. This EIP is just the start of bringing governance/standardization from eth2 back into eth1. The main changes it brings are: newly issued ETH in eth2.

EIP-? :merge. More optimistically, eth1 -> eth2 is expected to merge in 2021, and the PoW consensus will be removed. However, R&D work will increase significantly in the coming months. This EIP is expected to take place over the next 18 months.

EIP-3102: Binary tree structure. The item EIP will be moved from the current hexadecimal state tree into the binary tree structure. This will make Merkle proofs more efficient. Migration will be potentially resource-intensive, so it's best done before merging.

EIP-2937: SETINDESTRUCTIBLE opcode. This opcode will cause any subsequent SELFDESTRUCTs to act as noops in the current frame. This will help to better demonstrate the reliability of the contract. This is also the first thing to do to support account abstraction.

EIP-2938: Account Abstraction. Allows the contract to be an advanced account that pays transaction fees and initiates transaction execution. This provides a flexible framework for determining the conditions for the validity of arbitrary transactions. Originally proposed in EIP-86, this EIP provides a more concrete path for mainnet rollout.