Sorry. I had an answer typed up to this the other day and my battery died before sending. I'll try to recap what I'd written.

Basically, gas costs are hard to predict. I'm not sure how you checked that state of the contract was identical, but keep in mind you are modifying the storage slot for z, and changing a non-zero to a zero is cheaper than changing a non-zero to a non-zero is cheaper than changing a zero to a non-zero. So, that could be part of the difference you are seeing.

So, each opcode can have a different cost, depending on other aspects of the machine state. For example, if there is an access list (not in your case, but in general), the "warmed" state of a storage slot, of an account balance or the bytecode of a target contract will affect the costs of sstore/sload, call, staticcall, balance, etc.

Another aspect is the data in the tx itself; sending 0 bytes in the calldata is cheaper than sending non-zero bytes, so even the name of the signature can change the cost (so a method named foo737() (selector 0x0046b0a9) is cheaper than a method named foo000() (selector 0x9f39047a)).

So, I'm not sure which aspect specifically caused the difference in gas used, but the number of variables that go into that are vast. The number 72000 is also 5 nibbles long (requiring 6 bytes) while 21000 is 4 nibbles long (requiring 4 bytes); I'm not sure if that can impact the cost, but I would think the length of the encoded RLP of the transaction also has an effect.

An obscure optimization technique I've seen to gas golf is mining contract addresses, since calling an address that looks like 0x1234567812345678123456781234567812345678" would be encoded in the contract as PUSH20 0x1234567812345678123456781234567812345678, while an address with a couple GPUs thrown at it could look like 0x0000000000345678123456781234567812345678which would be encoded asPUSH15 0x345678123456781234567812345678`.

Does that help? Comments? This is definitely something I'm sure many people wonder about. :)

Thanks richard very much for the great follow-up. you're the man.

let me give you my opinions. I am already familiar with all the steps you mentioned, while these steps are right by itself, i can't still grasp my head. here is why.

I re-deployed these 2 contracts(https://gist.github.com/novaknole/62a3289f34331c1a08fcb278bbf21417) at sepolia network and they're verified so you can recheck.

main contract address - 0x5134d1e1F2556E0bbdB697cc6bffeF4D02Aa591F
second contract address - 0xEf2002b21ccF93847B2d6A94C227Ba0775919446

Try to run the below code. on the second and first try, their gas used were different, but i don't care about that. From the third try, every single time I run this code, they both print "58308" gas used. So this definitely says one important thing that steps you mentioned are not relevant to my question.

let realCall = await contract.callMain(secondAddress, num);
let waited = await realCall.wait();
console.log(waited.gasUsed.toString(), ' gas used') 

realCall = await contract.callMain(secondAddress, num);
waited = await realCall.wait();
console.log(waited.gasUsed.toString(), ' gas used')

so if the above code(which is run in the same function) prints(i.e requires the same gas), why does the below code produce different gas used ? i.e 58308 gas used(without gaslimit) and 60681 gas used with gas Limit. and it doesn't matter how many times I run, it always results in this difference.

let realCall = await contract.callMain(secondAddress, num);
let waited = await realCall.wait();
console.log(waited.gasUsed.toString(), ' gas used')

realCall = await contract.callMain(secondAddress, num, {gasLimit: 72000});
waited = await realCall.wait();
console.log(waited.gasUsed.toString(), ' gas used')

This got me confused, so I took a look at go-ethereum's gas calculation code and it definitely sums up each gas cost for each opcode and sums it up. how the hell should gas limit have any influence ? there's not a code in go-ethereum that actually decides what gas to use depending on gasLimit.

@ricmoo either this is crazy or I am nuts, there're no other choices :)

I mightn't answer your reply in the next 6-7h (4AM with here), but in the next 30 minutes, I'm here, if not, leave a message and in the morning I will take a look. our timezones are so much different, so I wanted to still add this analysis before I sleep.