Interpretation: Ethereum Istanbul upgrade content
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from
Ethereum enthusiasts (ID: ethfans)
Ethereum enthusiasts (ID: ethfans)
, Author: Pooja Ranjan, translation: A Jian, reprinted by Odaily with authorization.
first level title
A 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 are announced in advance in the form of Ethereum Upgrade Proposals (EIPs), in which proposers define in technical terms the changes and features that need to be implemented in network upgrades.
Network upgrades are both planned and unplanned. An upgrade is also called a fork, and is generally a new feature that is supported by users and protocol development. Sometimes people also use forks to fix bugs or stop attacks. This is an unplanned fork. To date, seven hard forks have been implemented on the Ethereum network. The meaning of "hard fork" is that the content contained in this network upgrade is not fully backward compatible, and may invalidate some old transactions and/or change the function of deployed contracts.
In order to seamlessly activate the upgrade on the mainnet, the upgrade content will first be activated and run on the Ethereum test network such as Rinkeby, Ropsten, Goerli and Kovan.
first level title
Istanbul (Istanbul) is the eighth network upgrade of Ethereum. Previous network upgrades have had codenames such as "Byzantium." The latest (and last) network upgrade is called "Constantinople".
first level title
What does the network upgrade process look like?
first level title
What is included in this upgrade?
The content of the Istanbul upgrade is expressed in the form of the Ethereum Upgrade Proposal (EIP). The role of EIP is to describe the standards of the Ethereum platform, including core protocol technical descriptions, client APIs, and contract standards.
This EIP contains a list of protocol changes that will be incorporated into the Istanbul fork. This EIP also lists all EIPs that were originally proposed.
Redistribute the gas consumption of some opcodes according to the calculation overhead and the need to improve the resistance to denial of service attacks;
Improve the performance of Layer-2 schemes based on SNARKs and STARKs;
Make Ethereum and Zcash interoperable.
Redistribute the gas consumption of some opcodes according to the calculation overhead and the need to improve the resistance to denial of service attacks;
Improve the performance of Layer-2 schemes based on SNARKs and STARKs;
Allowing contracts to introduce more creative functionality.
secondary title
Added the ability to verify Equihash PoW inside Ethereum contracts. This opens up the possibility of relaying transactions and atomic swaps between Zcash and Ethereum.
secondary title
Make zk-SNARKs calculations cheaper, allowing cheaper scaling and privacy applications to be developed. Examples include Matter labs, Aztec Protocol, Rollup, and Zether.
secondary title
Add a way for contracts to track their own Ethereum chain, so that contracts (especially those used by Layer-2 solutions such as state channels and Plasma) track the correct Layer-1 chain, especially during hard forks.
secondary title
Changed the gas consumption of some EVM opcodes to prevent transaction spam 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 overhead required for this operation. This EIP increases the consumption of some opcodes that are computationally intensive but currently less gas-intensive, namely SLOAD, BALANCE, and EXTCODEHASH.
secondary title
EIP-2028: Reduce transaction data Gas consumption
