Gas Optimizations #134
Labels
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
Gas Report
Table of Contents
Caching storage variables in memory to save gas
IMPACT
Anytime you are reading from storage more than once, it is cheaper in gas cost to cache the variable in memory: a SLOAD cost 100gas, while MLOAD and MSTORE cost 3 gas.
In particular, in
forloops, when using the length of a storage array as the condition being checked after each loop, caching the array length in memory can yield significant gas savings if the array length is highPROOF OF CONCEPT
Instances include:
Aura.sol
scope:
mint()_totalSupplyis read twice (storage variable read every timetotalSupply()is called)AuraMerkleDrop.sol
scope:
withdrawExpired()daois read twicescope:
claim()auraLockeris read twiceAuraStakingProxy.sol
scope:
applyPendingOwner()pendingOwneris read twicescope:
setApprovals()crvDepositorWrapperis read twicecrewardsis read twicescope:
distribute()keeperis read twicecrvDepositorWrapperis read twicescope:
distributeOther()rewardsis read three timesAuraVestedEscrow.sol
scope:
cancel()adminis read twicescope:
_claim()auraLockeris read three timesClaimFeesHelper.sol
scope:
claimFees()feeDistrois read three timeslastTokenTimesis read twiceBaseRewardPool.sol
scope:
queueNewRewards()periodFinishis read twicescope:
notifyRewardAmount()periodFinishis read twiceBooster.sol
scope:
setFeeInfo()lockRewardsis read four timesrewardFactoryis read twicescope:
addPool()rewardFactoryis read twicescope:
shutdownSystem()poolInfois read (poolInfo.length) times:number of reads depending on
poolInfoas it is in a for loopscope:
_earmarkRewards()treasuryis read three timesplatformFeeis read twicelockRewardsis read twiceBoosterOwner.sol
scope:
acceptOwnership()pendingowneris read twiceCrvDepositor.sol
scope:
lookCurve()incentiveCrvis read twicescope:
depositFor()incentiveCrvis read three timesExtraRewardStashV3.sol
scope:
claimRewards()operatoris read three timesrewardHookis read twicescope:
processStash()operatoris read (1 +tokenList.length) times:number of reads depending on
tokenListas it is in a for loopStashFactoryV2.sol
scope:
CreateStash()v3Implementationis read six timesVirtualBalanceRewardPool.sol
scope:
queueNewRewards()periodFinishis read twiceVoterProxy.sol
scope:
setOperator()operatoris read twicescope:
withdraw()rewardDepositis read three timesscope:
claimCrv()operatoris read twicescope:
claimFees()operatoris read twiceTOOLS USED
Manual Analysis
MITIGATION
cache these storage variables in memory
Calldata instead of memory for RO function parameters
PROBLEM
If a reference type function parameter is read-only, it is cheaper in gas to use calldata instead of memory.
Calldata is a non-modifiable, non-persistent area where function arguments are stored, and behaves mostly like memory.
Try to use calldata as a data location because it will avoid copies and also makes sure that the data cannot be modified.
PROOF OF CONCEPT
Instances include:
BalLiquidityProvider.sol
scope:
provideLiquidity()PoolManagerSecondaryProxy.sol
scope:
setUsedAddress()TOOLS USED
Manual Analysis
MITIGATION
Replace
memorywithcalldataComparisons with zero for unsigned integers
IMPACT
>0is less gas efficient than!= 0if you enable the optimizer at 10k AND you’re in a require statement.Detailed explanation with the opcodes here
PROOF OF CONCEPT
Instances include:
Aura.sol
AuraBalRewardPool.sol
AuraLocker.sol
AuraMerkleDrop.sol
AuraPenaltyForwarder.sol
AuraVestedEscrow.sol
BalLiquidityProvider.sol
ExtraRewardsDistributor.sol
BaseRewardPool.sol
Booster.sol
CrvDepositor.sol
PoolManagerSecondaryProxy.sol
TOOLS USED
Manual Analysis
MITIGATION
Replace
> 0with!= 0Comparison Operators
IMPACT
In the EVM, there is no opcode for
>=or<=.When using greater than or equal, two operations are performed:
>and=.Using strict comparison operators hence saves gas
PROOF OF CONCEPT
Instances include:
AuraLocker.sol
Aura.sol
AuraStakingProxy.sol
AuraVestedEscrow.sol
ClaimFeesHelper.sol
ExtraRewardsDistributor.sol
TOOLS USED
Manual Analysis
MITIGATION
Replace
<=with<, and>=with>. Do not forget to increment/decrement the compared variableexample:
However, if
1is negligible compared to the value of the variable, we can omit the increment.Constructor parameters should be avoided when possible
IMPACT
Constructor parameters are expensive. The contract deployment will be cheaper in gas if they are hard coded instead of using constructor parameters.
PROOF OF CONCEPT
Instances include:
Aura.sol
AuraBalRewardPool.sol
AuraClaimZap.sol
AuraLocker.sol
AuraMerkleDrop.sol
AuraPenaltyForward.sol
AuraStakingProxy.sol
AuraVestedEscrow.sol
BalLiquidityProvider.sol
ClaimFeesHelper.sol
ArbitartorVault.sol
BaseRewardPool.sol
BaseRewardPool4626.sol
Booster.sol
BoosterOwner.sol
ConvexMasterChef.sol
CrvDepositor.sol
DepositToken.sol
DepositToken.sol
PoolManagerProxy.sol
PoolManagerSecondaryProxy.sol
PoolManagerV3.sol
RewardFactory.sol
RewardHook.sol
StashFactoryV2.sol
TokenFactory.sol
VirtualBalanceRewardPool.sol
VoterProxy.sol
TOOLS USED
Manual Analysis
MITIGATION
Hardcode state variables with their initial value instead of writing them during contract deployment with constructor parameters.
Custom Errors
IMPACT
Custom errors from Solidity 0.8.4 are cheaper than revert strings (cheaper deployment cost and runtime cost when the revert condition is met) while providing the same amount of information, as explained here
Custom errors are defined using the error statement
PROOF OF CONCEPT
Instances include:
Aura.sol
AuraBalRewardPool.sol
AuraClaimZap.sol
AuraLocker.sol
AuraMath.sol
AuraMerkleDrop.sol
AuraMinter.sol
AuraPenaltyForward.sol
AuraStakingProxy.sol
AuraVestedEscrow.sol
BalLiquidityProvider.sol
ClaimFeesHelper.sol
CrvDepositorWrapper.sol
ExtraRewardsDistributor.sol
ArbitartorVault.sol
ArbitartorVault.sol
BaseRewardPool4626.sol
Booster.sol
BoosterOwner.sol
cCrv.sol
ConvexMasterChef.sol
CrvDepositor.sol
DepositToken.sol
ExtraRewardStashV3.sol
PoolManagerProxy.sol
PoolManagerSecondaryProxy.sol
PoolManagerV3.sol
RewardFactory.sol
StashFactory.sol
TokenFactory.sol
VirtualBalanceRewardPool.sol
VoterProxy.sol
TOOLS USED
Manual Analysis
MITIGATION
Replace require and revert statements with custom errors.
For instance, in
Aura.sol:Replace
with
and define the custom error in the contract
Default value initialization
IMPACT
If a variable is not set/initialized, it is assumed to have the default value (0, false, 0x0 etc depending on the data type).
Explicitly initializing it with its default value is an anti-pattern and wastes gas.
PROOF OF CONCEPT
Instances include:
AuraBalRewardPool.sol
AuraClaimZap.sol
AuraClaimZap.sol
AuraLocker.sol
AuraMerkleDrop.sol
AuraVestedEscrow.sol
BalLiquidityProvider.sol
ExtraRewardsDistributor.sol
ArbitartorVault.sol
BaseRewardPool.sol
Booster.sol
BoosterOwner.sol
ConvexMasterChef.sol
CrvDepositor.sol
ExtraRewardStashV3.sol
VirtualBalanceRewardPool.sol
VoterProxy.sol
TOOLS USED
Manual Analysis
MITIGATION
Remove explicit initialization for default values.
Event emitting of local variable
PROBLEM
When emitting an event, using a local variable instead of a storage variable saves gas.
PROOF OF CONCEPT
Instances include:
Booster.sol
BoosterOwner.sol
ConvexMasterChef.sol
TOOLS USED
Manual Analysis
MITIGATION
In most instances, the storage variable is read multiple times in the function and it is recommended to cache them into memory, then passing these cached variables in the
emitstatement, as explained in the cache paragraphPrefix increments
IMPACT
Prefix increments are cheaper than postfix increments.
PROOF OF CONCEPT
Instances include:
AuraClaimZap.sol
AuraLocker.sol
AuraVestedEscrow.sol
BalLiquidityProvider.sol
ExtraRewardsDistributor.sol
ArbitartorVault.sol
BaseRewardPool.sol
Booster.sol
BoosterOwner.sol
ExtraRewardStashV3.sol
PoolManagerSecondaryProxy.sol
TOOLS USED
Manual Analysis
MITIGATION
change
variable++to++variable.Require instead of AND
IMPACT
Require statements including conditions with the
&&operator can be broken down in multiple require statements to save gas.PROOF OF CONCEPT
Instances include:
AuraStakingProxy.sol
BalLiquidityProvider.sol
Booster.sol
StashFactoryV2.sol
TOOLS USED
Manual Analysis
MITIGATION
Tight Variable Packing
PROBLEM
Solidity contracts have contiguous 32 bytes (256 bits) slots used in storage.
By arranging the variables, it is possible to minimize the number of slots used within a contract's storage and therefore reduce deployment costs.
address type variables are each of 20 bytes size (way less than 32 bytes). However, they here take up a whole 32 bytes slot (they are contiguous).
As bool type variables are of size 1 byte, there's a slot here that can get saved by moving them closer to an address
PROOF OF CONCEPT
Instances include:
AuraLocker.sol
AuraVestedEscrow.sol
Booster.sol
ExtraRewardStashV3.sol
CrvDepositor.sol
TOOLS USED
Manual Analysis
MITIGATION
Place every
booleanright after anaddressto save one storage slotUnchecked arithmetic
IMPACT
The default "checked" behavior costs more gas when adding/diving/multiplying, because under-the-hood those checks are implemented as a series of opcodes that, prior to performing the actual arithmetic, check for under/overflow and revert if it is detected.
if it can statically be determined there is no possible way for your arithmetic to under/overflow (such as a condition in an if statement), surrounding the arithmetic in an
uncheckedblock will save gasPROOF OF CONCEPT
Instances include:
AuraBalRewardPool.sol
AuraMinter.sol
AuraVestedEscrow.sol
AuraVestedEscrow.sol
CrvDepositor.sol
TOOLS USED
Manual Analysis
MITIGATION
Place the arithmetic operations in an
uncheckedblockUnnecessary library
IMPACT
As of Solidity 0.8.0, arithmetic operations revert on underflow and overflow by default. The use of external libraries to perform additions and subtractions should be avoided as it costs extra gas.
PROOF OF CONCEPT
Most of the contracts in scope use the
addandsubfunctions of theAuraMath.sol.TOOLS USED
Manual Analysis
MITIGATION
Use Solidity native additions and subtractions for uint256 variables
The text was updated successfully, but these errors were encountered: