5 Min Read 
Ethereum is on the eve of its “Istanbul” hard fork. The upgrade is scheduled to occur at Block 9069000, which is expected to be confirmed this weekend. This will be one of many hard forks that will take place before Ethereum’s big transition from proof of work to proof of stake. Many of the changes for this fork are repricings of certain functions for the sake of better network performance and resilience. The upgrade also improves interoperability with other chains, as well as replay protection during chain forks. Below, we’ll go over these updates.
Eleven Ethereum Improvement Proposals (EIPs) were introduced for Istanbul, but only six were approved for implementation:
- EIP-152: A hash function known as Blake2b was added. The addition of Blake2b will make verification of certain data on other Equihash PoW based chains more efficient and cheaper. For example, verifying Zcash block headers on Ethereum is currently slow and expensive. The addition of Blake2b would speed up this process and aid in increasing the interoperability between Ethereum and chains like Zcash. Interoperability, in the context of crypto-assets, enables asset swaps and improves communication between networks. The networks could, in effect, talk to each other and affect each other instead of being siloed off and running in parallel with no knowledge of each other as they do now. This could lead to Zcash being spendable in Ethereum dapps, Zcash improving Ethereum’s privacy, and Zcash and Ethereum holders being able to trade atomically. This update is a step in the direction of these possibilities.
- EIP-1108: This proposal reprices the use of elliptic curve arithmetic. The Ethereum community felt that the costs of doing these operations are currently overpriced. Fast elliptic curve cryptography is an imperative of an increasing number of protocols built on top of Ethereum, some of which are attempting to tackle issues such as privacy and scalability. These protocols include, but are not limited to, the privacy protocols Aztec and Zether, and the scaling protocols, Matter and Rollup.
- EIP-1344: Adds an opcode (operation code) which allows Ethereum smart contracts to identify the current ChainID during a contentious fork and verify the validity of digital signatures based on that ChainID. A ChainID helps the ecosystem determine the blockchain they’re operating on is in fact the chain they intend to operate on. Identifying which chain is which during a contentious fork is crucial to prevent replay attacks. Replay attacks, in the context of crypto forks, happen when a transaction made on one network can be “replayed” on the other side of the fork. During a contentious split of a crypto network two chains are created from the same history and probably have very few differences between them. From one initial asset, two assets are created. An unaware user spending on one chain gives up information, like a signature, that a savvy attacker could use to spend that user’s other asset on the opposite chain. There is an Ethereum smart contract users can call to check the current Chain ID, but Ethereum developers think the contract is complicated enough to cause problems after a hard fork. The proposed opcode is supposed to simplify the identification of the correct chain, preventing replay attacks.
- EIP-1884: Some op-codes are more resource intensive relative to their pricing. This proposal seeks to raise the gas cost of these opcodes to bring their economic costs in line with the actual resources (CPU time, memory, etc.) they consume. Gas is a measure of the cost to execute an operation on the Ethereum Virtual Machine. Imbalances between resources consumed and gas costs cause two problems:
- Attacks on the network are cheaper than they should be; malicious actors can fill blocks with underpriced operations, slowing down block processing.
- As a result of underpriced operations, blocks with equivalent block gas limits process in a much wider range of time than they should. Block gas limits are the maximum amount of gas allowed in a block to determine how many transactions can fit into a block. For example, let’s say we have four transactions where each transaction has a gas limit of 100, 200, 300, and 400. If the block gas limit is 600, then the first three transactions can fit in the block but not the fourth. If we have two blocks of equivalent gas but one is full of underpriced opcodes and the other isn’t, the block with underpriced operations will take longer to process. Even though they are supposed to be equivalent in gas, the actual resources it takes to process these operations are larger than the gas implied. By balancing costs and the actual resources consumed, the variance between processing times can be stabilized to a greater degree.
- EIP-2028: Lowers the gas price of calling on-chain data from 68 gas per byte to 16 gas per byte. This increases the bandwidth of Ethereum by allowing more on-chain data into each block. This proposal could help some layer 2 scaling solutions that need to store data on-chain and be able to call that data cheaply when necessary.
- EIP-2200: Creates a definition of net gas metering changes for the SSTORE (storage of data) opcode, enabling new usages for contract storage, and lowers excessive gas costs where it doesn’t match how most implementations of Ethereum work.
Ethereum in Edge
Our users don’t have to do anything at this time. These changes won’t affect your assets in any way. There doesn’t appear to be any serious disagreement around this hard-fork, but if there is an element in the community that refuses to upgrade and creates a minority network, we’ll make sure to communicate the steps, if any, that would need to be taken to protect your assets.
The next expected hard-fork of Ethereum is tentatively scheduled for June 2020 under the name Berlin, We should see some more gas re-pricings and we might even see a proof of work change. Stay tuned.
