code-423n4 / 2022-07-swivel-findings

0 stars 1 forks source link

Gas Optimizations #109

Open code423n4 opened 2 years ago

code423n4 commented 2 years ago

Use of 2**256 - 1 When 2**255 Should Be Used

Context: Swivel.sol#L549

Description: Infinity can also be represented via `2**255, it's hex representation is 0x8000000000000000000000000000000000000000000000000000000000000000 while 2**256 - 1 is 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff. Then main difference is and where the gas savings come from is, zeros are cheaper than non-zero values in hex representation.

Recommendation: Use 2**255 instead of 2**256 - 1 to save gas on deployment.

Use of The memory Keyword When storage Should Be Used

Context: MarketPlace.sol#L91, MarketPlace.sol#L132, MarketPlace.sol#L216, MarketPlace.sol#L228, MarketPlace.sol#L248, MarketPlace.sol#L266, MarketPlace.sol#L284

Description: When copying a state struct in memory, there are as many SLOADs and MSTOREs as there are fields. 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.

Recommendation: Use the storage keyword instead of the memory keyword in these situations.

Same State Variable Read More Than Once

Context: VaultTracker.sol#L49-L77 (maturityRate), VaultTracker.sol#L82-L109 (maturityRate), VaultTracker.sol#L113-L139 (maturityRate), VaultTracker.sol#L152-L203 (maturityRate), VaultTracker.sol#L208-L239 (maturityRate), ZcToken.sol#L43-L48 (maturity, redeemer, protocol), ZcToken.sol#L52-L57 (maturity, redeemer, protocol), ZcToken.sol#L70-L75 (maturity, redeemer, protocol), ZcToken.sol#L79-L84 (maturity, redeemer, protocol), ZcToken.sol#L88-L93 (maturity, redeemer, protocol), ZcToken.sol#L98-L119 (maturity, redeemer, protocol), ZcToken.sol#L124-L137 (maturity, redeemer, protocol)

Description: Functions that read state variables more than once can cache it into a local variable for repeated reads saving gas by converting expensive SLOADs into much cheaper MLOADs.

Recommendation: It's best to cach the state variables into memory when read more than once.

State Variables That Can Be Set To Immutable

Context: Swivel.sol#L33

Description: Solidity 0.6.5 introduced immutable as a major feature. It allows setting contract-level variables at construction time which gets stored in code rather than storage. Each call to it reads from storage, using a sload costing 2100 gas cold or 100 gas warm. Setting it to immutable will have each storage read of the state variable to be replaced by the instruction push32 value, where value is set during contract construction time and this costs only 3 gas.

Recommendation: Set the state variable to immutable

Setting The Constructor To Payable

Context: All Contracts

Description: You can cut out 10 opcodes in the creation-time EVM bytecode if you declare a constructor payable. Making the constructor payable eliminates the need for an initial check of msg.value == 0 and saves 21 gas on deployment with no security risks.

Recommendation: Set the constructor to payable.

Function Ordering via Method ID

Context: All Contracts

Description: Contracts most called functions could simply save gas by function ordering via Method ID. Calling a function at runtime will be cheaper if the function is positioned earlier in the order (has a relatively lower Method ID) because 22 gas are added to the cost of a function for every position that came before it. The caller can save on gas if you prioritize most called functions. One could use This tool to help find alternative function names with lower Method IDs while keeping the original name intact.

Recommendation: Find a lower method ID name for the most called functions for example mostCalled() vs. mostCalled_41q() is cheaper by 44 gas.

robrobbins commented 2 years ago

some dupas or wontfixes