Gas Optimizations #336
Labels
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
Table of Contents:
AuraLocker.emergencyWithdraw(): Use of thememorykeyword whenstorageshould be usedBooster: Tighly pack storage variablesCrvDepositor: Tighly pack storage variablesExtraRewardStashV3: Tighly pack storage variables> 0is less efficient than!= 0for unsigned integers (with proof)>=is cheaper than>(and<=cheaper than<)CrvDepositor.sol#setFees(): Tautology on "_lockIncentive >= 0" which is always true as_lockIncentiveis uint256require()statements that use&&saves gasboolfor storage incurs overhead++icosts less gas compared toi++ori += 1calldatainstead ofmemoryCheap Contract Deployment Through Clones
Here, contract deployments are made:
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:
I suggest applying a similar pattern.
Help the optimizer by saving a storage variable's reference instead of repeatedly fetching it
To help the optimizer, declare a
storagetype variable and use it instead of repeatedly fetching the reference in a map or an array.The effect can be quite significant.
As an example, instead of repeatedly calling
someMap[someIndex], save its reference like this:SomeStruct storage someStruct = someMap[someIndex]and use it.Affected code (check the
@audittags):AuraLocker.emergencyWithdraw(): Use of thememorykeyword whenstorageshould be usedWhen copying a state struct in memory, there are as many SLOADs and MSTOREs as there are slots. When reading the whole struct multiple times is not needed, it's better to actually only read the relevant field(s). When only some of the fields are read several times, these particular values should be cached instead of the whole state struct.
Here L355, the
storagekeyword should be used instead ofmemory(see@audittags):Caching storage values in memory
The code can be optimized by minimising the number of SLOADs.
SLOADs are expensive (100 gas after the 1st one) compared to MLOADs/MSTOREs (3 gas each). Storage values read multiple times should instead be cached in memory the first time (costing 1 SLOAD) and then read from this cache to avoid multiple SLOADs.
See the
@audittags for details about the multiple SLOADs where a cached value should be used instead ofSLOAD 2and above:Not using SafeMath can save gas on arithmetics operations that can't underflow/overflow
When an overflow or an underflow isn't possible (as an example, when a comparison is made before the arithmetic operation), SafeMath isn't necessary (see
@audittags):SafeMath is not needed when using Solidity version 0.8.11
Solidity version 0.8.11 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.
I suggest using the built-in checks instead of SafeMath and remove SafeMath here:
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-arithmeticI suggest wrapping with an
uncheckedblock here (see@audittags for more details):Booster: Tighly pack storage variablesHere, the storage variables can be tightly packed from:
to
Which would save 1 storage slot.
CrvDepositor: Tighly pack storage variablesFrom:
to:
Which would save 1 storage slot.
ExtraRewardStashV3: Tighly pack storage variablesFrom:
to:
Which would save 1 storage slot.
Boolean comparisons
Comparing to a constant (
trueorfalse) is a bit more expensive than directly checking the returned boolean value.I suggest using
if(directValue)instead ofif(directValue == true)andif(!directValue)instead ofif(directValue == false)here:> 0is less efficient than!= 0for unsigned integers (with proof)!= 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 at 10k AND you're in arequirestatement, this will save gas. You can see this tweet for more proofs: https://twitter.com/gzeon/status/1485428085885640706I suggest changing
> 0with!= 0here:Also, please enable the Optimizer.
>=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:
CrvDepositor.sol#setFees(): Tautology on "_lockIncentive >= 0" which is always true as_lockIncentiveis uint256As a variable of type
uintwill always be>= 0, such a check isn't necessary.Consider deleting the
>= 0check L75: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, I suggest using multiple require statements with 1 condition per require statement:Using
boolfor storage incurs overheadBooleans are more expensive than uint256 or any type that takes up a full word because each write operation emits an extra SLOAD to first read the slot's contents, replace the bits taken up by the boolean, and then write back. This is the compiler's defense against contract upgrades and pointer aliasing, and it cannot be disabled.
Shift Right instead of Dividing by 2
A division by 2 can be calculated by shifting one to the right.
While the
DIVopcode uses 5 gas, theSHRopcode only uses 3 gas. Furthermore, Solidity's division operation also includes a division-by-0 prevention which is bypassed using shifting.I suggest replacing
/ 2with>> 1here:An array's length should be cached to save gas in for-loops
Reading 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, I suggest storing the array's length in a variable before the for-loop, and use this new variable instead:
++icosts less gas compared toi++ori += 1++icosts less gas compared toi++ori += 1for unsigned integer, as pre-increment is cheaper (about 5 gas per iteration). This statement is true even with the optimizer enabled.The same is also true for
i--.i++incrementsiand returns the initial value ofi. Which means:But
++ireturns the actual incremented value:In the first case, the compiler has to create a temporary variable (when used) for returning
1instead of2Affected code:
Consider using
++iinstead ofi++to increment the value of an uint variable. The same holds true with decrements (--ivsi--)Increments/Decrements can be unchecked
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 code would go from:
to:
The risk of overflow is inexistant for
uint256here.Please, notice that in
convex-platform/contracts/, the syntax used is already unchecked, as the Solidity version used is 0.6.12, which doesn't implement a default overflow check. Only contracts undercontracts/are concerned.Use
calldatainstead ofmemoryWhen arguments are read-only on external functions, the data location should be
calldata:No need to explicitly initialize variables with default values
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:
I suggest removing explicit initializations for default values.
Upgrade pragma to at least 0.8.4
Using newer compiler versions and the optimizer give gas optimizations. Also, additional safety checks are available for free.
The advantages here are:
Consider upgrading pragma to at least 0.8.4 for contracts in
convex-platform/contracts(ideally 0.8.11 for consistency), as they use Solidity 0.6.12.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:
I suggest shortening the revert strings to fit in 32 bytes.
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).I suggest replacing all revert strings with custom errors in
/contracts.The text was updated successfully, but these errors were encountered: