Ethereum’s Istanbul Fork — Technical Explanation

A technical summary of the upcoming changes that will be introduced with the Istanbul hard fork on block 9,069,000.

Opcodes

Two new opcodes will be added to the EVM in Istanbul.

If you’re not sure what an opcode is, check out my previous article explaining the Ethereum Virtual Machine.

The new CHAINID opcode introduced at 0x46 pushes the 256-bit value of the current chain ID to the stack. It pops 0 arguments from the stack and has a flat gas cost of 2 gas (G-base). A list of chain IDs is included in EIP 155. For example, on mainnet, the 256-bit equivalent of the number 1 will be pushed to the stack, while on Ropsten the equivalent of the number 3 will be added.

Example use case for the CHAINID opcode (Solidity contract)

Another new opcode introduced at 0x47, called SELFBALANCE, pushes the balance of the current executing contract to the stack. It doesn’t pop any items from the stack and has a flat gas cost of 5 gas (G-low). It’s similar to the BALANCE opcode (which uses 400 gas), except that it doesn’t require any address as input since the address of the current contract will be used (thus saving a lot of gas).

Precompiled contracts

Some mathematical operations don’t have their own opcodes, yet are too expensive or complicated to implement using existing opcodes. In that case, it may be decided to create a so-called “precompiled” contract. These contracts don’t actually contain the code necessary to execute their operations (they don’t contain any code at all), but calls to those contracts will still be interpreted as such. Calls to precompiled contracts will also have a different gas cost compared to regular contract calls.

For example, an EVM call to 0x0000000000000000000000000000000000000002 will be interpreted as the SHA-256 hash function as stated by the EVM protocol. The call will return the result of the hashed input (call arguments). As of right now (pre-Istanbul), there are 8 precompiled contracts, but Istanbul will add a 9th one.

The new precompile at address 0x0000000000000000000000000000000000000009 implements the compression function F used in the BLAKE2 cryptographic hashing algorithm in order to allow interoperability between the EVM and Zcash, as well as introducing more flexible cryptographic hash primitives to the EVM.

Gas Changes

Opcodes

BALANCE (0x31) gas cost will be increased from 400 to 700 gas

EXTCODEHASH (0x3F) gas cost will be increased from 400 to 700 gas

SLOAD (0x54) gas cost will be increased from 200 to 800 gas

Precompiled contracts

ECADD (0x06) gas cost will be decreased from 500 to 150 gas

ECMUL (0x07) gas cost will be decreased from 40k to 6k gas

Pairing check (0x08) gas cost will be changed from 100k + 80k * n gas, to 45k + 34k * n gas, where n is the number of pairings

Input data

The cost for non-zero bytes included in transaction data (G-txdatanonzero) will be reduced from 68 gas per byte to 16 gas per byte.

Storage

Calculation of gas cost for the SSTORE opcode (which lets a contract store data) will become more complicated.

If the previous value of a storage slot equals the provided new value, only the amount of gas used by an SLOAD operation will be used.

If the original value of a storage slot is 0, then it will be changed to a non-zero value. Finally, it will change back to 0 within the same execution and the amount of gas used by the SSTORE operation will be refunded, minus the gas used by the SLOAD operation.

If the original value of a storage slot used to be non-zero value, then it will be changed to a different non-zero value. Finally, it will change back to the original value and the regular storage refund will be applied, minus gas for the SLOAD operation.

If you would like to view the original explanation of the new SSTORE gas cost calculation, feel free to take a look at the original EIP.

References

Talk To Us & Share Your Thoughts