An overview of the upcoming Istanbul hard fork
The upcoming Ethereum Istanbul hard fork is a major update to the current Ethereum 1.x system. Currently set to be implemented in early October, this update has been delayed a couple of times due to various reasons.
As a major update, there is plenty of criticism on how the Ethereum core dev team are spending too much time and resources on the current 1.x rather than working on the Ethereum 2.0. However, the situation is also fairly straightforward - with Ethereum 2.0 far away from being ready and the current Ethereum blockchain getting full, scalability has become a major bottleneck for Ethereum. Patching the current 1.x system seems like a necessary step at this point.
In this post, we will go through the EIPs accepted into this fork and discuss what they do and any potential issues to watch out for when developing smart contracts.
It is worth pointing out that some major updates like EIP1057(ProgPOW) and EIP1702(EVM upgrade to Web Assembly) will not be included in this particular fork. These are likely to be included in the future Istanbul 2 or Berlin fork.
Confirmed EIPs
There are a total of 6 confirmed EIPs. Here is a summary of what they actually do.
EIP152
Add the Blake2b core hash function F, which is more efficient than SHA3, that will allow for efficient verification of Equihash PoW used in the likes of Zcash.
EIP1108
Reduce gas cost for several elliptic curve cryptography operations like ECADD, ECMUL and pairing check, and this will result in cheaper usage of elliptic curve cryptographic functions, e.g., zk-SNARK.
EIP1344
Add CHAINID opcode. This allows applications to get the current chain ID, which helps identify separate chains after hard forks. Smart contracts can access this info to avoid replay attacks. Applications will need a way to handle change of chain ID in case of a fork.
EIP1884
Increase gas cost for certain opcodes which are becoming resource heavy due to the growth of Ethereum.
SLOAD from 200 to 800.
BALANCE from 400 to 700.
EXTCODEHASH from 400 to 700.
New opcode SELFBALANCE to 5.
Contracts using these opcodes will be affected. This is a potential risk for existing smart contracts on the Ethereum blockchain due to gas increase. We will discuss this particular EIP a bit later.
EIP2028
Reduce gas cost for Calldata (GTXDATANONZERO) from 68 to 16.
This only affects non-zero bytes. Gas cost for zero bytes is unchanged. This will allow more data to fit into one block essentially increasing scalability and helping data-transmission-heavy needs like Layer 2 solutions. However, this also increases network delay due to larger blocks and decreases the cost for attacking the network.
EIP2200
Change how SSTORE gas is charged based on the operations. This will lead to an overall reduction of gas cost for SSTORE in most cases and thus, will not affect current smart contracts too much.
Concerns
Whenever gas cost is increased, there is a huge potential that the update will break existing smart contracts on the Ethereum blockchain. While the majority of these accepted EIPs will not affect existing smart contracts much, EIP1884 is an exception. It increases gas cost for a few opcodes, and as a result, it will make:
- Certain calls more expensive
- Fallback functions which access storage require more than the standard 2300 default gas limit
- Contracts that assume a certain fixed gas cost not work at all.
There has been wide criticism on the Ethereum core devs for not considering backwards compatibility mostly due to not enough time rather than a lack of solutions. Wei Tang from Parity tweeted:
āIām quite concerned about #Ethereum 's #Istanbul hard fork. One of the EIPs, EIP-1884, will break at least a few deployed contracts. This may be a standalone incident, but what worries me is that some participants on last AllCoreDevs seem to classify it as an acceptable behavior.ā
While I do agree with Wei Tang, I wonder if the Ethereum core devs are taking this approach due to the overall criticism about them already spending too much time on 1.x rather than working on Ethereum 2.0.
Regardless, EIP1884 will break smart contracts, so it is a good idea for developers to double check and upgrade their code as needed, especially checking any fallback functions.