Popular science | Ethereum Istanbul upgrade content interpretation

Author: Pooja Ranjan

Translation: A Jian

Source: Ethereum enthusiasts

What is a network upgrade / hard fork?

The network upgrade is a change to the Ethereum protocol, adding new rules to the existing Ethereum protocol to strengthen the entire system. These new rules were announced in advance in the form of an Ethereum Upgrade Proposal (EIP), in which the proponents will use technical terms to define changes and functions that need to be implemented in the network upgrade.

Network upgrades are both planned and unplanned. Upgrades are also called forks, and are generally new features that add user and protocol development support. Sometimes people use forks to fix vulnerabilities or stop attacks. This is an unplanned fork. To date, 7 hard forks have been implemented on the Ethereum network. The meaning of "hard fork" is that the content of this network upgrade is not completely backward compatible, and may cause some old transactions to fail and / or change the functionality of the deployed contract.

The decentralized nature of the public chain makes network upgrades more difficult than ordinary software upgrades, because this requires collaboration and communication between the entire community and multiple Ethereum client developers, and only then can the upgrade proceed smoothly.

In order for the upgrade to be activated seamlessly on the mainnet, the upgrade content will first be activated and run on the Ethereum test networks such as Rinkeby, Ropsten, Goerli, and Kovan.

What is Istanbul?

Istanbul is the 8th network upgrade of Ethereum. Earlier network upgrades have also been codenamed "Byzantine". The most recent (and last) network upgrade was called "Constantinople."

What is the process of network upgrade?

After the entire community has reached a consensus on what changes should be included in the upgrade, these rule changes will be compiled into multiple Ethereum clients, such as geth, Parity, Besu, and Nethermind. These protocol changes will start to activate in a specific block. After activation, the new features introduced by the upgrade can be used. Nodes that have not been upgraded to the new rules will naturally form a network using the old rules, but this network cannot communicate with the network using the new rules.

What's included in this upgrade?

The content of the Istanbul upgrade is expressed in the form of an Ethereum Upgrade Proposal (EIP). The role of EIP is to describe the standards of the Ethereum platform, including core protocol technical specifications, client APIs, and contract standards.

Because of the growth of the Ethereum community in the past year, this upgrade is the largest of all upgrades (in terms of the number of proposals), and more than 30 EIPs have been proposed to join the fork. After detailed discussions, the six EIPs were eventually deemed suitable and ready to join the upgrade.

EIP 1679: The Istanbul Project

The EIP contains a list of protocol changes that will be added to the Istanbul fork. The EIP also lists all EIPs that were proposed initially.

The EIP included in the Istanbul upgrade has the following features:

  • Reallocate the gas consumption of some opcodes based on the computational overhead and the need to improve resistance to denial of service attacks;
  • Make the performance of Layer-2 scheme based on SNARKs and STARKs better;
  • Enable Ethereum and Zcash to interoperate.
  • Let contracts introduce more creative features.

EIP-152: Add BLAKE2 compression function F pre-compilation function

Added the ability to verify Equihash PoW in the Ethereum contract. This opens up the possibility of relay transactions and atomic swap transactions between Zcash and Ethereum.

EIP-1108: Reduce pre-compiled Gas consumption for alt_bn128 curves

Make zk-SNARKs computations cheaper and allow cheaper extensions and privacy applications to be developed. Examples include Matter labs, Aztec Protocol, Rollup, and Zether.

EIP-1344: ChainID operation code

Add a way for the contract to track its Ethereum chain so that the contract (especially the Layer-2 scheme such as the contract used by the state channel and Plasma) tracks the correct Layer-1 chain, especially during hard forks.

EIP-1884: Repricing Opcodes Related to Merkel Tree Size

Changed the gas consumption of some EVM opcodes to prevent spam transaction attacks and better balance the computational overhead of each block. On the Ethereum network, the amount of Gas consumed by an operation often matches the computational cost of the operation. The EIP increases the consumption of some compute-intensive but currently less gas-consuming opcodes, namely SLOAD, BALANCE, and EXTCODEHASH.

EIP-2028: Reduce Gas Consumption of Transaction Data

Make zk-SNARKs and zk-STARKs applications cheaper by reducing the gas consumption of calling data within a transaction. This also helps the Layer-2 solution increase throughput. Starkware is an example.

EIP-2200: Changing Gas Net Consumption Measurement Method for SSTORE Operation

Change the gas consumption measurement method of EVM data storage operation, so that the contract can introduce some new functions, such as re-entry lock and same-contract multi-send.