Gas Optimizations

[c4-bot-3]

See the markdown file with the details of this report here.

[saxenism]

okayish report. Nothing new.

[c4-sponsor]

saxenism (sponsor) confirmed

[c4-judge]

alex-ppg marked the issue as grade-c

[thenua3bhai]

Hi @alex-ppg Thanks for judging

I request you to please re-evaluate this gas report. I believe this should be marked grade-a. Since it contains total 37 gas findings out of which 16 gas findings are really good and high quality significant gas savers like slot saving, re-factoring findings most of them can not be even found by bot. Most of the findings will save gas even if optimizer turned on. I found these findings by manual review. I usually don't include trivial findings in my report since they are easily found by bot and doesn't save much gas. But I include some trivial findings here since this contest doesn't had bot race so many bot participated and submitted findings in big numbers. Generally judges see those numbers and less number high quality reports got rejected. So I included some findings with less savings but they are still good gas savers and will save gas even when optimizer turned on. Good gas saver are also there which increase the report quality. In terms of gas savings and score my findings weight similar or more than other higher number of bot findings. And this report provides much more good amount of value to the protocol by saving significant gas in their code.

But in terms of scoring this contains 16 L grade-findings and 21 R/NC level findings. All findings are correct and 100% safe to implement. Most of them will save gas even if optimizer is turned on. Specially these L grade ones. Which makes this report score >100 which makes this report eligible for grade-a.

I have summarized significant gas saver findings and listed out L level findings from this report. They are explained in detail in my gas report and their validating reason also.(For full list please check the report).

[G-01] Struct variable can be packed into fewer storage slots by rearranging the order of variables in struct Saves 1 storage slot(Gas Saved ~2000 Gas) == L

[G-02] Remove initializer modifier check from initialize function in L1SharedBridge contract since reentrancyGuardInitializer will do initializer's work also Refactoring by removing unnecessary modifier(Saves ~24000 gas) == L

[G-03] State variables can be packed into fewer storage slots by truncating timestamp holding variables Saves 1 storage slot(Gas Saved ~2000 GAS) == L

[G-04] Using storage instead of memory for taking storage arrays/structs inside loop(Saves 1 Gcoldsload ~2100 Gas Per iteration) == L

[G-05] State variables can be packed into fewer storage slot by reducing their size Saves 1 storage slot(Saves ~2000 Gas) == L

[G-06] Call _saveFacetIfNew(_facet) function outside loop to avoid function call on every iteration, calling it inside loop is redundant wastes gas only Saves 1 function call each iteration(Saves ~200 Gas Per iteration) == L

[G-07] Reduce the size of struct variables and pack them together to save storage slots Saves 1 storage slot (Saves ~2000 Gas) == L

[G-08] Multiple address/ID mappings can be combined into a single mapping of an address/ID to a struct and 2 values packed in struct saves 1 storage slot per mapping key(Saves 1 Slot(~2000 Gas) Per Mapping key) == L

[G-10] Reduce the size of struct variables by truncating timestamp and pack them together to save storage slots Saves 1 storage slot(Saves ~2000 Gas) == L

[G-11] Re-arrange the state variables to pack them into fewer storage slot Save 1 storage slot (Saves ~2000 Gas) == L

[G-12] Multiple accesses of the same mapping/array key/index should be cached (Saves ~520 Gas) == L

[G-14] State variable can be marked constant which never changes or initialized Saves 3 storage slots(Gas Saved ~6300 Gas) == L

[G-17] Avoid updating storage variable with same bool value check before updating Can save 2 SSTORE(Total Saves ~4200 Gas) == L

[G-18] State variables should be cached in stack variables rather than re-reading them from storage Saves 3 SLOAD(Total Gas Saved ~300 Gas) == L

[G-19] Use default value directly instead of reading from deleted state variables Saves 2 SLOAD(~196 Gas) == L

[G-22] Use operator short circuiting around || by switching the order of expressions. memory read first then storage read can save Gcoldsload ~2100 Gas half of the times when memory read is true. == L

Apart from these above 16 L findings my report also have 21 other good findings related to refactoring and other gas savings which are mentioned in my report which can also be considered as R/NC. Most of them will save gas even if optimizer is turned on.(For full list please check the report)

Since 1 L gives 5 score , 1 R gives 2 score and 1 NC gives 1 score in gas reports.

*So Total avg. score of this report = 16*5+ 21* > 100

Which is good score for grade-a comparing with other grade-a reports.

So I request you to please re-evaluate this report and update this to grade-a since based on above score and facts this report should be marked as grade-a.

Thanks

[alex-ppg]

Hey @thenua3bhai, this contest is a special case and the usual guideline I impose has not been applied. I re-evaluated all exhibits you listed, and have the following feedback to share:

• G-01: This is an invalid recommendation as the contract is backward compatible, and the __DEPRECATED variables cannot be restructured as it would break storage compatibility.
• G-02: While I understand the recommendation, the contract is meant to be compatible with the initialization patterns of both the re-entrancy guard and the Initializer dependency. As such, this recommendation is not valid.
• G-03: This only saves gas when the variables are used in tandem. In the context of the Governance contract, the variables are solely assigned once during the constructor together and remain separate in other functions. The gas cost of those functions would increase due to the inherent overhead of unpacking tightly packed variables as well as handling lower-than-256-bit variables at the EVM level.
• G-04: This is indeed an acceptable optimization, even if it may concern a function meant to be invoked off-chain.
• G-05: This is effectively the same as the G-03 recommendation, and is invalid for the same reasons.
• G-06: Based on this comment line, the actual recommended alleviation is incorrect but the overall recommendation is sound.
• G-07: Same as G-03, invalid for the same reasons as well as due to storage backward compatibility.
• G-08: The real-world result of this optimization is debateable as the l2BridgeAddress is used alone multiple times and would increase in gas (as an assignment would require loading the value, combining it with its tight packed value, and then storing it back to the contract).
• G-10: Same as G-03, invalid however due to never concerning storage values. Calldata and arguments are not tight packed.
• G-11: Same as G-03, invalid for the same reasons.
• G-12: This is a valid optimization throughout.
• G-14: This is an invalid recommendation as the contract is meant to be a backward compatible upgrade.
• G-17: While these functions remain unused within the codebase, this is a valid recommendation.
• G-18: This is a valid optimization but a duplicate of G-12
• G-19: This is actually a QA-level flaw in the code rather than an optimization, and has been noted in the contest.
• G-22: A valid and nice optimization.

While your report does contain a few interesting items, there is a lot of duplication present and a lot of the "strongest" ones are invalid or inapplicable. I appreciate the due diligence and will revisit this submission for a potential B grade prior to PJQA's closure, but for now the original ruling remains. Thanks for contributing to the PJQA process!