GalloDaSballo
commented
2 years ago 4.2k from immutable, rest is probably less than 500 gas
Open code423n4 opened 2 years ago
GalloDaSballo
commented
2 years ago 4.2k from immutable, rest is probably less than 500 gas
Overview
Table of Contents:
0.8.13:> 0is less efficient than!= 0for unsigned integers (with proof)>=is cheaper than>(and<=cheaper than<)require()statements that use&&saves gas<array>.lengthshould not be looked up in every loop of afor-loop++icosts less gas compared toi++ori += 1(same for--ivsi--ori -= 1)abi.encode()is less efficient thanabi.encodePacked()1e3, or even just1000) rather than exponentiation (e.g.10**3)1. Avoid emitting a storage variable when a memory value is available
When they are the same, consider emitting the memory value instead of the storage value:
2. Cheap Contract Deployment Through Clones
There's a way to save a significant amount of gas on deployment using Clones: https://www.youtube.com/watch?v=3Mw-pMmJ7TA .
This is a solution that was adopted, as an example, by Porter Finance. They realized that deploying using clones was 10x cheaper:
Consider applying a similar pattern, here with a
cloneDeterministicmethod to mimic the currentcreate23. Unchecking arithmetics operations that can't underflow/overflow
Solidity version 0.8+ comes with implicit overflow and underflow checks on unsigned integers. When an overflow or an underflow isn't possible (as an example, when a comparison is made before the arithmetic operation), some gas can be saved by using an
uncheckedblock: https://docs.soliditylang.org/en/v0.8.10/control-structures.html#checked-or-unchecked-arithmeticConsider wrapping with an
uncheckedblock here (see@audittags for more details):lending-market/contracts/WETH.sol:
4. Some variables should be immutable
These variables are only set in the constructor and are never edited after that:
Consider marking them as immutable, as it would avoid the expensive storage-writing operation (around 20 000 gas)
5. Reduce the size of error messages (Long revert Strings)
Shortening revert strings to fit in 32 bytes will decrease deployment time gas and will decrease runtime gas when the revert condition is met.
Revert strings that are longer than 32 bytes require at least one additional mstore, along with additional overhead for computing memory offset, etc.
Revert strings > 32 bytes:
Consider shortening the revert strings to fit in 32 bytes.
6. SafeMath is not needed when using Solidity version 0.8+
Solidity version 0.8+ already implements overflow and underflow checks by default. Using the SafeMath library from OpenZeppelin (which is more gas expensive than the 0.8+ overflow checks) is therefore redundant.
Consider using the built-in checks instead of SafeMath and remove SafeMath here:
7. Boolean comparisons
Comparing to a constant (
trueorfalse) is a bit more expensive than directly checking the returned boolean value. Consider usingif(directValue)instead ofif(directValue == true)andif(!directValue)instead ofif(directValue == false)here:8. Bytes constants are more efficient than string constants
From the Solidity doc:
Why do Solidity examples use bytes32 type instead of string?
If data can fit into 32 bytes, then you should use bytes32 datatype rather than bytes or strings as it is cheaper in solidity. Basically, any fixed size variable in solidity is cheaper than variable size. That will save gas on the contract.
Instances of
string constantthat can be replaced bybytes(1..32) constant:9. Pre-Solidity
0.8.13:> 0is less efficient than!= 0for unsigned integers (with proof)Up until Solidity
0.8.13:!= 0costs less gas compared to> 0for unsigned integers inrequirestatements with the optimizer enabled (6 gas)Proof: While it may seem that
> 0is cheaper than!=, this is only true without the optimizer enabled and outside a require statement. If you enable the optimizer AND you're in arequirestatement, this will save gas. You can see this tweet for more proofs: https://twitter.com/gzeon/status/1485428085885640706Consider changing
> 0with!= 0here:Also, please enable the Optimizer.
10.
>=is cheaper than>(and<=cheaper than<)Strict inequalities (
>) are more expensive than non-strict ones (>=). This is due to some supplementary checks (ISZERO, 3 gas). This also holds true between<=and<.Consider replacing strict inequalities with non-strict ones to save some gas here:
11. Splitting
require()statements that use&&saves gasIf you're using the Optimizer at 200, instead of using the
&&operator in a single require statement to check multiple conditions, Consider using multiple require statements with 1 condition per require statement:Please, note that this might not hold true at a higher number of runs for the Optimizer (10k). However, it indeed is true at 200.
12. Using private rather than public for constants saves gas
If needed, the value can be read from the verified contract source code. Savings are due to the compiler not having to create non-payable getter functions for deployment calldata, and not adding another entry to the method ID table
13. Use shift right/left instead of division/multiplication if possible
While the
DIV/MULopcode uses 5 gas, theSHR/SHLopcode only uses 3 gas. Furthermore, beware that Solidity's division operation also includes a division-by-0 prevention which is bypassed using shifting. Eventually, overflow checks are never performed for shift operations as they are done for arithmetic operations. Instead, the result is always truncated.>> 1instead of/ 2>> 2instead of/ 4<< 3instead of* 8Affected code:
14.
<array>.lengthshould not be looked up in every loop of afor-loopReading array length at each iteration of the loop consumes more gas than necessary.
In the best case scenario (length read on a memory variable), caching the array length in the stack saves around 3 gas per iteration. In the worst case scenario (external calls at each iteration), the amount of gas wasted can be massive.
Here, Consider storing the array's length in a variable before the for-loop, and use this new variable instead:
15.
++icosts less gas compared toi++ori += 1(same for--ivsi--ori -= 1)Pre-increments and pre-decrements are cheaper.
For a
uint256 ivariable, the following is true with the Optimizer enabled at 10k:Increment:
i += 1is the most expensive formi++costs 6 gas less thani += 1++icosts 5 gas less thani++(11 gas less thani += 1)Decrement:
i -= 1is the most expensive formi--costs 11 gas less thani -= 1--icosts 5 gas less thani--(16 gas less thani -= 1)Note that post-increments (or post-decrements) return the old value before incrementing or decrementing, hence the name post-increment:
However, pre-increments (or pre-decrements) return the new value:
In the pre-increment case, the compiler has to create a temporary variable (when used) for returning
1instead of2.Affected code:
Consider using pre-increments and pre-decrements where they are relevant (meaning: not where post-increments/decrements logic are relevant).
Notice that this is already applied here:
16. Increments/decrements can be unchecked in for-loops
In Solidity 0.8+, there's a default overflow check on unsigned integers. It's possible to uncheck this in for-loops and save some gas at each iteration, but at the cost of some code readability, as this uncheck cannot be made inline.
ethereum/solidity#10695
Affected code:
The change would be:
The same can be applied with decrements (which should use
breakwheni == 0).The risk of overflow is non-existant for
uint256here.17.
abi.encode()is less efficient thanabi.encodePacked()Changing
abi.encodefunction toabi.encodePackedcan save gas since theabi.encodefunction pads extra null bytes at the end of the call data, which is unnecessary. Also, in general,abi.encodePackedis more gas-efficient (see Solidity-Encode-Gas-Comparison).Consider using
abi.encodePacked()here:Keep in mind that
abi.encodePacked()should not be used with dynamic types when passing the result to a hash function such askeccak256()(see the QA Report)18. It costs more gas to initialize variables with their default value than letting the default value be applied
If a variable is not set/initialized, it is assumed to have the default value (
0foruint,falseforbool,address(0)for address...). Explicitly initializing it with its default value is an anti-pattern and wastes gas.As an example:
for (uint256 i = 0; i < numIterations; ++i) {should be replaced withfor (uint256 i; i < numIterations; ++i) {Affected code:
Consider removing explicit initializations for default values.
19. Upgrade pragma
Using newer compiler versions and the optimizer give gas optimizations. Also, additional safety checks are available for free.
The advantages here are:
Consider upgrading here :
20. Use Custom Errors instead of Revert Strings to save Gas
Solidity 0.8.4 introduced custom errors. They are more gas efficient than revert strings, when it comes to deploy cost as well as runtime cost when the revert condition is met. Use custom errors instead of revert strings for gas savings.
Custom errors from Solidity 0.8.4 are cheaper than revert strings (cheaper deployment cost and runtime cost when the revert condition is met)
Source: https://blog.soliditylang.org/2021/04/21/custom-errors/:
Custom errors are defined using the
errorstatement, which can be used inside and outside of contracts (including interfaces and libraries).Consider replacing all revert strings with custom errors in the solution.