Normalize storage_cost and storage_rebate in gas summary

[lxfind]

trafficstars

Right now we include both storage_cost and storage_rebate in the gas summary. In many cases they can be identical when we mutate objects. This can be confusing. We could normalize it by making one of them 0. We could do so either at per-object level, or the transaction level.

[dariorussi]

https://github.com/MystenLabs/sui/pull/8101 conversation will follow there

[dariorussi]

It seems this feature can get problematic. Particularly with programmable transactions, but even with regular ones with different gas charging, a user can run out of gas if normalized values are used. Simple example: programmable transaction command 1- execution cost: 100 storage cost: 30 rebate: 20 command 2- execution cost: 100 storage cost: 20 rebate: 20 command 3- execution cost: 100 storage cost: 10 rebate: 40 if normalized, the required cost would be "execution cost: 300 storage cost: 0 rebate: 20" non normalized (current) cost would be "execution cost: 300 storage cost: 60 rebate: 80" Gas to pay - in client code (wallet and more) - is computed as execution_cost + storage_cost so in the normalized case users would have to provide 300 while they would have to provide 360 in the current model. In the normalized case the gas would not be enough to run all the "commands" and the transaction will fail, which is obviously problematic

[dariorussi]

it seems storage cost is all computed at the end so the match above is incorrect and we could do this. Keeping it open

[stefan-mysten]

@dariorussi @lxfind - is this still relevant? If not, let's close this.