sui
sui copied to clipboard
MystenLabs
Normalize storage_cost and storage_rebate in gas summary
as in https://github.com/MystenLabs/sui/issues/7734
the idea here is to make storage_cost and storage_rebate 0-based.
In the simplest example one would get storage_cost and storage_rebate with the same value and it may be a confusing experience. So we are trying to normalize the values and in the previous simple example report 0 for both.
I had to fix some test and there are tests in rosetta that I am investigating.
In general though it is interesting that if the 3 values computation_cost, storage_cost and storage_rebate are not applied in the proper order one may get an improper amount of gas to apply. In other words if I am trying to find out how much gas I need to provide, I am wondering whether it would be safer to provide computation_cost + storage_cost without regards to rebates. I am not even clear yet if the failing test is relying on storage_cost non normalized...
comments welcome....
The latest updates on your projects. Learn more about Vercel for Git ↗︎
4 Ignored Deployments
| Name | Status | Preview | Comments | Updated |
|---|---|---|---|---|
| explorer | ⬜️ Ignored (Inspect) | Feb 10, 2023 at 11:43PM (UTC) | ||
| explorer-storybook | ⬜️ Ignored (Inspect) | Feb 10, 2023 at 11:43PM (UTC) | ||
| frenemies | ⬜️ Ignored (Inspect) | Feb 10, 2023 at 11:43PM (UTC) | ||
| wallet-adapter | ⬜️ Ignored (Inspect) | Feb 10, 2023 at 11:43PM (UTC) |
![vercel[bot] avatar](https://avatars.githubusercontent.com/in/8329?v=4 "Published by a pub.dev verified publisher"){kind=small}
also to better contextualize what I said in the main comment, this PR adds the normalization just before returning transaction effects in execute_transaction_to_effects. And I am not sure if there are other ways to get effects that may create inconsistencies...
@sblackshear @lxfind talking to Move and wallet/sdk people it seems this feature can get problematic.
Particularly with programmable transactions, but even with regular ones, a user can run out of gas if normalized values are used. Simple example:
programmable transaction
1- execution cost: 100 storage cost: 30 rebate: 20
2- execution cost: 100 storage cost: 20 rebate: 20
3- execution cost: 100 storage cost: 10 rebate: 40
normalized 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 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
so this is likely not happening for now if ever. I'll leave it open for a bit to let people comment if they have any, then I'll close it
it seems storage cost is all computed at the end so the math above is incorrect and we could do this. Keeping it open then... I will investigate why the rosetta test is failing and see if there are issues of some kind with the normalized model