Optimizing to Death: The Solidity Gas Optimization Cult

One of the trends that have been emerging in blockchain development circles is gas optimization. Although gas optimization could potentially save thousands of dollars for users or the protocol, most of the “optimizations” that we have been seeing have been, to say the least, useless.

First of all, to understand gas optimization, we need to understand exactly how gas is calculated and spent on the blockchain. Each smart contract when uploaded, is compressed and converted as a low-level byte code that is basically a set of operations that are executed by the node. To perform the operation, there is a fee charged by the network for each operation depending on how computationally expensive it is for the node. The more computations there exist, the more expensive the transaction fee will be. Therefor, the goal of gas optimization is to reduce the amount of operations needed to be performed by a smart contract function to make it cheaper to call on the user or protocol.

For example, avoiding computing hashes off-chain is a great gas optimization technique. For example lets say that there is an immutable data structure, rather than hashing it on-chain using keccack256 , the value can be computed off-chain and then added as as a hash directly on the blockchain. This can reduce gas spent by 80% and therefor allows to a more scalable and cheaper smart contract to use.

Don’t get me wrong, I believe gas optimization is necessary to scale blockchain and introduce it to retail users. The issue lies in techniques that bring near-zero value to the protocol and users, and sometimes even hurt the smart contract code readability and safety.

First of all, not all smart contract functions are meant to be optimized and scalable, these functions need usually to be more safe and auditable. For example a staking smart contract that has an emergency_withdraw function that withdraws all the funds from the smart contract to an admin wallet (not recommending it), this function will be called, in the worst case, 1 or 2 times a year, but it is one of the functions that have the most risk and value attached to it. First of all, the function should be completely clear and simple for auditors, users and developers to understand and avoid any complex tricks that might open a back door to a vulnerability or attack. Second of all, optimizing the function will save a maximum of ~$1 a year in fees. The developer that found the optimization (with an average of around 50 USD/hour salary) in around an hour two, therefor the protocol is paying a developer $100 for saving $1 and making the contract possibly open to vulnerabilities.

This happens more often than not and is being pushed in posts for developers that are practicing optimization in Solidity. Let us avoid being caught in the cult of perfectionism and aiming to build contracts that help build the foundations of a digital world.

Copyright 2023 Georges Chouchani © , All Rights Reserved.