The recent Istanbul hard fork in December affected some important smart contracts deployed on Ethereum mainnet. Thankfully, major projects such as Kyber were prepared and migrated to new contracts before the fork, but many developers are still unaware of the impact the Istanbul hard fork may have on both smart contract development and previously deployed contracts.
In this post, we talk about the recent gas cost changes in Ethereum, their impact, and how developers should deal with them.
Gas on Ethereum
Gas, together with gas price, is the fundamental source of transaction fees on Ethereum. Each instruction in the Ethereum Virtual Machine(EVM) is assigned a gas cost which approximates how much computation effort is needed to execute that instruction.
These low-level instructions, known as opcodes, are assembly-level instructions that are translated from Solidity during compilation.
Istanbul Gas Changes
While gas costs for Ethereum’s opcodes stayed stable for several years, the recent Istanbul hard fork changed gas costs for several opcodes. This has had a significant impact on a number of smart contracts that depended on those opcodes.
The purpose of these gas cost changes was to price Ethereum instructions more accurately. In fact, underpriced operations are a network vulnerability as they make Denial of Service attacks more economically feasible. These attacks occur when the network is overloaded with useless transactions meant to clog the network. Therefore, some operations such as SLOAD, which is used to retrieve variable values, or BALANCE, which is used to check account balance, had their cost increased to reflect their higher computation load.
Gas Change Impact
As operations like SLOAD and BALANCE had their gas cost significantly increased, code that depends on these operations is also affected. Fallback functions are particularly vulnerable as they are often called with a fixed amount of gas.
Fallback functions are most often called when ether is sent to a contract without any specific call. This often happens through a transfer() or send() function which calls a fallback function with a fixed 2300 gas stipend.
SLOAD had its cost increased from 200 to 800 gas, and BALANCE increased from 400 to 700 gas. If the fallback function uses the SLOAD or BALANCE opcodes (for instance to lookup or compare variable values), it may now run out of gas, even though it was working correctly before the change.
Recommendations
- When possible, consider using pull vs push design patterns for payments. The pros and cons of this approach are discussed here.
- Be careful when using transfer() and send(), as these send a fixed amount of gas.
- Perform gas analysis to understand boundary conditions and assumptions
In general, gas accounting is a very nuanced issue. Developers should be aware that future hard forks may continue to tweak the gas costs of various opcodes, so, as much as possible, they should avoid relying on fixed gas costs.
In addition, we recommend performing gas analysis to understand the boundary conditions of your smart contract code. This will also help lay out all gas cost assumptions explicitly, and help you react appropriately when the next hard-fork comes.
About the Author
Kacper is an expert in software modeling and verification. He received a Ph.D in Computer Science from the University of Waterloo for his work on modeling and analysis of software product lines. Before coming to Quantstamp, he worked at MathWorks (maker of MATLAB), Opera, and Samsung.
--
For more Quantstamp news or anything QSP crypto or QSP coin related, check out Quantstamp Reddit and QSP Twitter.
.png)
