Use Local Memory Type Variable Instead of Global Storage Type Variable in Event to Save Gas

[HighBe]

Hi, we recently have conducted a systematic study about Solidity event usage, evolution, and impact, and we are attempting to build a tool to improve the practice of Solidity event use based on our findings. We have tried our prototype tool on some of the most popular GitHub Solidity repositories, and for your repository, we find a potential optimization of gas consumption arisen from event use.

The point is that when we use emit operation to store the value of a certain variable, local memory type variable would be preferable to global storage type (state) variable if they hold the same value. The reason is that an extra SLOAD operation would be needed to access the variable if it is storage type, and the SLOAD operation costs 800 gas.

For your repository, we find that the following event use can be improved:

• 0x07f7ecb66d788ab01dc93b9b71a88401de7d0f2e.sol
  function name: AdjustBetAmounts
  event name:  BetLimitChanged
  variable:    betLimit->amount

    function AdjustBetAmounts(uint256 amount) 
    onlyOwner()
    public
    {
        betLimit = amount;
        
        emit BetLimitChanged(betLimit);
    }

  function name: AdjustDifficulty
  event name:  DifficultyChanged
  variable:    difficulty->amount

    function AdjustDifficulty(uint256 amount) 
    onlyOwner()
    public
    {
        difficulty = amount;
        
        emit DifficultyChanged(difficulty);
    }

• 0x7d09edb07d23acb532a82be3da5c17d9d85806b4.sol
  function name: AdjustBetAmounts
  event name:  BetLimitChanged
  variable:    betLimit->amount

    function AdjustBetAmounts(uint256 amount) 
    onlyOwner()
    public
    {
        betLimit = amount;
        
        emit BetLimitChanged(betLimit);
    }

  function name: AdjustDifficulty
  event name:  DifficultyChanged
  variable:    difficulty->amount

    function AdjustDifficulty(uint256 amount) 
    onlyOwner()
    public
    {
        difficulty = amount;
        
        emit DifficultyChanged(difficulty);
    }

Do you find our results useful? Your reply and invaluable suggestions would be greatly appreciated, and are vital for improving our tool. Thanks a lot for your time!

[Gernot Salzer]

Thanks for the pointer to your work. It will be definitely interesting once we turn our attention on improving the benchmarks. Are you aware of tools that intend to detect such and similar possibilities of reduced gas consumption? Otherwise, your observation could be of interest to the developers of the Solidity compiler. However, their topmost priority is probably the correctness of the compiler, as any security problem outweighs the benefits of such optimizations.

[Gernot Salzer]

Have you checked recent Solidity versions and the use of storage/memory modifiers? Wouldn't it be sufficient to declare the parameter to be memory?

[HighBe]

Have you checked recent Solidity versions and the use of storage/memory modifiers? Wouldn't it be sufficient to declare the parameter to be memory?

We really appreciate your response. To our knowledge, we are not aware of tools that can do such and similar optimization of gas consumption. According to our analysis, such optimizations should not bring side effects such as security vulnerabilities. With regards to the Solidity version, we check the lastest one and find that state variables are not allowed to be typed as memory (same as before). Thanks a lot for your comment, we are constantly improving our prototype and also considering whether such (and similar) gas optimizations can be intergeated into the compiler optimization process.