Deterministic gas usage

[ilblackdragon]

It's critical that functions take predictable amount of gas when callbacks are involved. It's also important for frontends, so they don't just always attach 300Tg to every transaction.

Currently there are both contract state and blockchain state that can affect that amount of gas spent on a callback.

I want to open discussion how we can round costs up in such a way that they are deterministic independent of blockchain state. And what are good practices to mitigate contract state changes (also if there are ways to round things up to reduce variance there, like round up number of bytes written to closest 32 or whatever).

[abacabadabacaba]

Rounding any values will not make us any closer to guaranteeing predictable gas usage. In general, it would be very difficult to guarantee that running a specific Rust/AS/WASM code will not use more that a specific amount of gas. Also, this approach makes it much more difficult to change gas prices in the future.

I prefer a different approach: some sort of primitive (such as an event queue) that can record a call back without running any contract code. The price for this can be paid up front, so the operation itself is guaranteed to succeed. If all callbacks use this kind of approach, we can change gas costs without restrictions (currently we can't increase gas costs because this may break contracts with hardcoded gas amounts). Also, contract development would be easier because there would be no need to think about how much gas to pass to a call and how much to leave for a callback.

[bowenwang1996]

@abacabadabacaba how do you make sure that the callback "is guaranteed to succeed"? For example, what happens when the callback consumes more gas than what is allowed?

[abacabadabacaba]

@bowenwang1996 My idea is to make it possible to arrange the call result to be just recorded in storage. This doesn't run any code, so gas usage is predictable (and can be paid up front). It should also be possible to run a callback function in addition to recording the result in storage. If the callback function runs out of gas, the storage entry will remain, so someone may send a transaction to call the contract (supplying enough gas) which will retry the callback.

[bowenwang1996]

I see, but my understanding is that @ilblackdragon's concern is more about the callback running out of gas due to change in contract state, not so much about whether the call result is stored.