2021 will be the most innovative year for the Ethereum protocol since 2016. The following is the EIP situation that deserves attention this year:
The next hard fork upgrade-“Berlin” will implement 4 EIPs:
➤EIP-2929: The gas cost for state access opcodes will increase
➤EIP-2930: Optional Access List Txs
➤EIP-2718: Typed Transaction Envelope
➤EIP-2315: Simple Subroutines
EIP-2929: The gas cost for state access opcodes has increased. The gas fee for storing and accessing opcodes has been too low for a long time, and some malicious transactions that can be executed in only 20-80 seconds can now be easily created. This EIP increases the cost of state access by approximately 3 times.
EIP-2930: Optional access list. About 0.18% of mainnet transactions will be blocked by EIP-2929. To make up for this crack, this EIP introduces a new type of transaction, which can specify the storage slot to be read, and then pay a 10% off prepayment.
EIP-2718: Contains types of transaction envelopes. This EIP specifies a new format for transactions. It starts with a “discriminator” (discriminator) that allows clients to interpret different transactions. EIP-2930 will use this EIP first, then EIP-1559. New format=type||payload.
EIP-2315: Simple subroutine. It was included in the last EIP of the Berlin hard fork upgrade: adding support for subroutines. Traditionally, contracts that want to simulate this function need to process regular stack data and return addresses at the same time. This EIP adds a new stack, which is only used 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 conference, there may be another fork this summer. There are many EIP candidates for this hard fork, the most famous of which is EIP-1559.
EIP-1559: Eth1 fee market changes. Gas fee is divided into two parts: base fee (basic fee) and tip (tip). The basic fee will be destroyed, and the tip will be sent to the miner. The basic cost will be dynamically determined by the agreement based on demand. This can avoid some cost peaks and improve the user experience when paying for gas.
(Translator’s Note: The author here inserts the latest status update of EIP-1559 by Tim Beiko, the main promoter of EIP-1559)
(Tim) In my opinion, I don’t think 1559 is ready to go live now. Here is a summary of some of the ideas I shared on dicord:
1. Not all clients have the implementation of 1559, and no client has the final version;
2. We haven’t solved the problem raised in the AllCoreDevs conference (that is, test large blocks with large states). It will take several weeks to achieve this at the fastest.
3.1559 will affect many other projects: any project involving signed transactions relies on JSON RPC’s response to blocks/transactions, etc. We still need to discuss these effects extensively.
4. The Berlin hard fork is about to start. And putting aside all the work at hand to promote 1559 is not a good choice.
EIP-2982: Phase 0 of Eth2. Since EIP-1011, eth1 and eth2 have been assembled in the EIP repository for the first time. This EIP is only the beginning of reintroducing the governance/standardization of eth2 into eth1. The main changes it brings are: adding ETH to eth2.
EIP-?: merge. More optimistic is that eth1->eth2 is expected to merge in 2021 and the PoW consensus will be removed. However, in the next few months, research and development work will increase significantly. It is estimated that the EIP will be carried out in the next 18 months.
EIP-3102: Binary tree structure. The EIP will be transferred from the current hexadecimal state tree to the binary tree structure. This will make Merkel prove more efficient. Migration may take up a lot of resources, so it is best to do it before the merger.
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. Allow the contract to become a premium account for paying transaction fees and initiating transaction execution. This provides a flexible framework for determining the conditions for the validity of any transaction. Initially proposed in EIP-86, the EIP provides a more specific path to be implemented on the main network.
EIP-?: EVM384. Although this is not an official EIP, it is moving in this direction. The proposal proposes to increase the local 384-bit arithmetic operator (and possibly other widths) to support the effective implementation of the new encryption system in the EVM.
EVM384 (content). With the rapid innovation of modern encryption systems, EVM384 provides a framework for Ethereum to support these systems without the need to provide hard forks and pre-compilation for each encryption system. On the contrary, anyone can implement it as an EVM contract.
EIP-2537: BLS12-381 pre-compiled. With EVM384, whether the proposal is still needed is still to be discussed. Although EVM384 is a better long-term solution, BLS is an advanced proposal in the Ethereum ecosystem (in view of eth2) and is worth pre-compilation locally.
Bulk transactions. There are many EIPs that aim to replace meta-transactions with L1 primitives. It is expected that significant progress will be made in this area this year. Such EIPs are:
➤EIP-2711: Sponsored, expiring and batch txs
➤EIP-2733: Transaction Package
➤EIP-2803: Expensive transaction
➤EIP-3074: Sponsored Tx Precompile
EIP-2464: eth/65: Transaction broadcast and retrieval. By broadcasting transaction hashes to most peer nodes instead of broadcasting complete transactions, the proposal greatly reduces the bandwidth used by the eth1 client. Geth plans to stop supporting <eth/65 sometime this year.
2021 will bring many changes to the Ethereum protocol, far beyond my list. The Eth2 and Stateless Ethereum teams will have their own plans this year.
