code-423n4 / 2022-02-nested-findings

0 stars 0 forks source link

Gas Optimizations #8

Open code423n4 opened 2 years ago

code423n4 commented 2 years ago

https://github.com/code-423n4/2022-02-nested/blob/main/contracts/FeeSplitter.sol (#L191, #L149, #L166)

  1. In sendFeesWithRoyalties, releaseTokens, releaseTokensNoETH function, add check amount!=0
require(amount!=0, "Incorrect amount");

https://github.com/code-423n4/2022-02-nested/blob/main/contracts/NestedRecords.sol#L76

  1. In updateHoldingAmount function, under the while loop, use return instead of break
if (tokens[tokenIndex] == _token) {
                    ...
                    return;
                }

https://github.com/code-423n4/2022-02-nested/blob/main/contracts/NestedFactory.sol#L317

  1. No need to check require(batchLength != 0, "NF: INVALID_ORDERS"); as this is already checked in all the calling functions like create, _processInputOrders

https://github.com/code-423n4/2022-02-nested/blob/main/contracts/NestedFactory.sol#L445

  1. The condition if (_amountToSpend > amounts[1]) is not required as the parent condition is already checking for require(amounts[1] <= _amountToSpend, "NestedFactory::_safeSubmitOrder: Overspent");
adrien-supizet commented 2 years ago
  1. I'm not sure about the benefits of this one. To discuss
  2. This does not achieve what we want
  3. disputed, those are not the same checks
  4. confirmed
harleythedogC4 commented 2 years ago

My personal judgments:

  1. "add check amount!=0". I don't see why this is a gas-optimization, and there is no explanation why this is a good idea. Invalid.
  2. "use return instead of break". I disagree with the sponsor, return seems to do the same thing as break in this scenario. Valid and small optimization.
  3. "No need to check require(batchLength != 0, "NF: INVALID_ORDERS");". Agree with sponsor, these are different checks. Invalid.
  4. "The condition if (_amountToSpend > amounts[1]) is not required". Valid and small optimization.
harleythedogC4 commented 2 years ago

Now, here is the methodology I used for calculating a score for each gas report. I first assigned each submission to be either small-optimization (1 point), medium-optimization (5 points) or large-optimization (10 points), depending on how useful the optimization is. The score of a gas report is the sum of these points, divided by the maximum number of points achieved by a gas report. This maximum number was 10 points, achieved by #67.

The number of points achieved by this report is 2 points. Thus the final score of this gas report is (2/10)*100 = 20.