The Consumer gas is not constant?

[lucastheo]

I've been studying the Ethereum network through ganache and found some behaviors that I can't explain. I study gas consumption in transactions, I did a first experiment where I repeatedly insert a variable into a list. The variable is of type boolean and the list is an array.

The result (Gas utilizado = Gas consumed; tamanho do Array = Array Size)

I expected a constant result, but there is a wide range of variation. I researched and didn't find a good answer. What would be the reason for the behavior?

Contract: https://github.com/lucastheo/ethereum-gas-study/blob/main/ethereum%20network%20local/contracts/milestone_3/Milestone3Array.sol

[davidmurdoch]

Can you share the code you use to generate the chart?

[lucastheo]

To run the contract I use truffle exec in the file:

https://github.com/lucastheo/ethereum-gas-study/blob/main/ethereum%20network%20local/run/milestone_3/v2_array.js.

The result is a .dat file with a list of the result of truffle runs.

example https://drive.google.com/file/d/193w6Gvgij4XtDDCnGes1z6F-nIh64ku5/view?usp=sharing.

I save the truffle output to a file and capture result.receipt.gasUsed

line 11 https://github.com/lucastheo/ethereum-gas-study/blob/main/data%20analysis/milistone_3/v2__estagios_5_data.py)

For the graph I showed I filter only for the consumption of the "insert element" function.

If you want, I can provide all the data.

Obs: My project is in portuguese, if you have any questions you can talk to me

[lucastheo]

I found out what it was, we have two things.

The first thing is about space allocation, in Ethereum the allocation is by block and a block fits 32 booleans, so when I'm going to allocate an element that takes a position 32n+1(33,65,97,...) Ethereum need to add new block costing more gas than normal (this explains the large peaks on the graph).

The second thing is about the lower dense part of the graph. The reason it happens is because saving a false is cheaper than true.
To explore the behavior I tested it with integers. I've found that saving 0 is cheaper than a positive number and saving a positive number is cheaper than saving a negative.