Everything You Need to Know About the Ethereum Istanbul Hard Fork

The Ethereum Istanbul hard fork is one of the 1.x updates designed to improve UX(user experience) before making the complete shift to Ethereum 2.0. The Berlin/London hard forks scheduled for the future are also part of the Ethereum 1.x updates.

The Ethereum Istanbul hard fork is made up of the following EIP(Ethereum Improvement Proposals), setting the foundation necessary to perform the big functions that Ethereum 1.x is targeting.

• EIP-152: Add Blake2 compression function F precompile
• EIP-1108: Reduce alt_bn128 precompile gas costs
• EIP-1344: Add ChainID opcode
• EIP-1884: Repricing for trie-size-dependent opcodes
• EIP-2028: Calldata gas cost reduction
• EIP-2200: Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change

In this article, we will look at EIP 1884 and focus on how it affected smart contract development.

There are many OPCODEs on the EVM. To run an OPCODE, a certain amount of computing resource is consumed, and each OPCODE uses a different amount of the resource, and therefore has been allocated different gas costs. If the OPCODE’s gas costs do not accurately reflect the amount of computing resources being consumed, this opens the system to the threat of a DoS attack. Furthermore, blocks with multiple undervalued OPCODEs may distort the block gas limit because it takes longer to perform calculations than blocks with the same gas consumption.

On the EVM, there exist OPCODEs that check the State of a block. These OPCODEs take longer and longer to compute as the Ethereum’s State-trie increases in size.

As the amount of information being saved in Ethereum increased, the size of State-trie also increased, and the calculation times of corresponding OPCODEs have naturally increased.

The following OPCODEs demonstrate this phenomenon:

We will look at SLOAD as an example.

The moving average graph(in black) shows that the execution time per gas unit has increased from 23ms to around 145ms.

Hence, EIP 1884 increased the gas costs for such undervalued OPCODEs, and added new OPCODES for situations to review the block’s state without incurring as much gas costs.

• SLOAD gas costs increase from 200 to 800
• BALANCE gas costs increase from 400 to 700
• EXTCODEHASH gas costs increase from 400 to 700
• SELFBALANCE OPCODE added, with gas costs 5

These changes result in some features of already distributed contracts becoming dysfunctional — notably Kyber Network, Gods Unchained, and Aragon. Let’s look at each project’s Solidity code, and how each team has responded to the changes introduced by EIP1884.

Before looking at each team’s Solidity code, let us go over some basic background information about Solidity to help with our understanding.

1. <address>.transfer() and <address>.send() only forward 2,300gas.
   <address>.transfer()/<address>.send() are often used to transfer ether from smart contracts. If the gas limit set upon the generation of the transaction transfers all the remaining gas, this creates the risk of a reentrancy attack. The function only transfers 2,300 gas of the remaining amount, and if an operation’s cost exceeds 2,300 gas, the entire transaction is voided.
2. The fallback function is automatically executed when receiving Ethereum or when the function called is not defined.
   If the fallback function is declared as payable in a smart contract, it is automatically executed when sending Ethereum to that smart contract, and also when a transaction occurs on the smart contract but the function to be executed does not exist.
3. When sending Ethereum between smart contracts, <address>.transfer() is usually used, and this triggers the execution of the fallback function of the smart contract on the receiving end.

As explained, when the fallback function is being executed by the <address>.transfer() function, the total gas executable by the fallback function is capped at 2,300.

Because of this distinct characteristic from other developing environments such as EVM and Solidity, even before EIP 1884, too many operations within the fallback function sometimes resulted in its malfunction.

However, under EIP 1884, there are cases in which previously functional fallback functions cease to do so.

We will look at examples briefly mentioned before — Kyber, Gods Unchained, and Aragon — where functional codes have stopped working.

Kyber Network’s contract had the following fallback function. This function operates as the receiving entity when exchanged Ether with other tokens.

[As-Is]

This function is structured so that the Kyber Reserve smart contract transfers ether with the <address>.transfer() function.(sample TX) This fallback function used to have about 300 gas left over when forwarded 2,300 gas using transfer().

[Issue]

But the second line’s require statement executes SLOAD, causing an additional 600 gas cost after the Ethereum Istanbul Hard Fork, making it unable to complete the fallback function within the 2,300 gas limit. Kyber’s developer has described the issue in this page discussing EIP 1884.

[To-Be]

After the EIP 1884 update, the Kyber team responded by redistributing a new smart contract that had a modified fallback function which does not read stored data.

Gods Unchained’s Capped Vault contract is another contract affected by EIP 1884 in a similar manner to that of Kyber Network. The Capped Vault contract currently functions as the receiving end of Ether when executing the purchase() function, when purchasing the Gods Unchained Rare Pack Four.

If the fallback function is crippled, purchases cannot be made.

The fallback function is written in the following manner:

[Issue]

The require statement’s total() function calls SLOAD and BALANCE once, and SLOAD is called one more time when loading the value of the limit variable, it incurs a total of 1,500 (600+300+600) additional gas expenses. The function used to have 1,342 gas left over, but now it can’t complete its operation within the 2,300 gas limit.

Lastly, we have Aragon’s DepositableDelegateProxy.

One contract is distributed per aragon unit, and this contract serves to forward most function calls to the implementation smart contract.

Here, Aragon has two separate fallback functions for two separate cases.

1. Incoming assets with transfer/send
2. All other cases

The code is as follows:

[As-Is]

If the transfer/send was used, lines 10~12 corresponding to the if statement. Before the Istanbul hard fork, this used 1,759 gas which is not a problem at all.

[Issue]

But the isDepositable() function executes SLOAD, creating an additional 600 gas costs, exceeding the 2,300 cap at 2,359 gas.

[To-Be]

To address this issue, Aragon, after some discussion, still uses SLOAD, but introduced an assembly code that optimizes gas consumption.

Through these examples, we’ve seen that some smart contracts can stop functioning after the Istanbul Hard Fork. Given that the EVM will continue to be updated after Istanbul, and that Ethereum’s State trie’s size will continue to grow, there is the possibility that other OPCODEs, not just SLOAD, will come to incur larger gas costs.

So, the most obvious solution for the individual programmer is to stop using the functions <address>.transfer() and <address>.send(), but even then, there is no way to stop other smart contracts from using them.

Given more and more contracts are designed to interact with other smart contracts — namely De-fi and dex(decentralized exchange), in order to respond to changes in the environment like EIP 1884, it is of utmost importance that fallback functions be designed to create as low a gas cost as possible.

So, the safest way for developing smart contracts is to refrain from executing OPCODEs like SLOAD, which carry the risk of increased gas costs, in the fallback functions.

Sure, there are other ways to limit the gas in transactions, but since <address>.transfer() and <address>.send() are the conventional developing methods, there is always the possibility that other smart contracts will use them.

This article identifies changes in the EVM brought by Ethereum Istanbul Hard Fork and further updates along the road, and their implications regarding existing smart contracts. Especially, we looked at EIP 1884 and went over precautions for developers to take when writing smart contracts. We’ve seen actual examples of several features of smart contracts such as Kyber Network, Gods Unchained and RelayHub have stopped functioning altogether.

It would be helpful to remember that, when distributing a smart contract after this Istanbul update, 1) it is essential that fallback functions be written to create the lowest gas cost possible, and 2) the safest way to achieve this is to not run OPCODEs (such as SLOAD) whose gas costs are likely to increase through future updates.

Also, Kyber Network responded to this change from EIP1884 by modifying the contract so that they could change the target contract Ether transferring target contract. However, we’ll close off by noting that the more fundamental approach is to create a logic that is not dependent on gas costs.

HAECHI AUDIT offers safe smart contract audits and developing services even after the Ethereum Istanbul Hard Fork.

Contact us at audit@haechi.io, and we will be in touch as soon as possible.

Thank you.

https://gist.github.com/ritzdorf/1c6bd72955391e831f8a397d3152b4e0/
https://docs.google.com/drawings/d/1K40GGAcNGjWhe9I0G4AIgGxppgLiL5_gdFcg9lG2YWI/edit
https://blog.kyber.network/istanbul-upgrade-kyber-smart-contract-migration-c8a6bcd84a1b
https://etherscan.io/address/0x9ae49c0d7f8f9ef4b864e004fe86ac8294e20950
https://github.com/ethereum/solidity/issues/610
https://eips.ethereum.org/EIPS/eip-1679
https://eips.ethereum.org/EIPS/eip-1884