[Solved] Out of gas in state channel?

Protocol Features & Updates State Channels
1

Is it possible a contract call ran in a state channel stop because of not enough gas?

We have a not quite optimized contract which should perform some exhaustive checks recursively and we get cb_b3V0X29mX2dhc0caXYY= as call result which we understand should be an out of gas message, however we used to think there were no gas usage when ran inside a state channel.

Can I make the call to contract static to estimate its gas-usage when it is mean to be run directly in the blockchain?

if not, which is the expected way to perform the estimation?

thanks!
david

2 Likes
2

Yes, it is possible to run out of gas in a state channel contract. State channel contract run with a large but not infinite amount of gas. Also if there is an error in the contract (“not quite optimized” ?) that causes a run-time error this will also manifest as “out of gas”.

Yes, I suggest you use the dry-run functionality where you can (deploy and) run contracts “statically” - protocol/contract_api_usage.md at master · aeternity/protocol · GitHub

1 Like
3

Hi Hans!

Thanks for your answer!!!

Also, I was checking this:

and what I get from the endpoint documentation, it returns a gas_price but no gas_consumption nor estimation… does it?

Thanks!!

4

The dry-run endpoint will return (an array of):

  DryRunResult:
    type: object
    properties:
      type:
        type: string
      result:
        type: string
      reason:
        type: string
      call_obj:
        $ref: '#/definitions/ContractCallObject'

So in the case of a successful call you get a ContractCallObject which among other fields includes:

      gas_used:
        $ref: '#/definitions/UInt64'

This is the gas used by this contract call (it also includes the gas_price, but that is also an input parameter and should be of less interest…)

2 Likes
5

I had miss that, thank you Hans!!!

1 Like
6

I just see that the actual call to perform gas estimation IS callStatic.

7

We estimated the gas consumption and found that our contract gets out of gas in a channel, when gas goes some further 4.1 million units.

Is it possible?

how can we overcome that limit?

8

Hey Dave, there is a purpose for this gas limit: Execution time should thereby be capped, which is in the very interest of the user and also a critical point of a safe smart contract protocol that cannot be DoS’ed. Optimization is the key, so as deconstruction of large operations into multiple smaller ones, if possible. Also the FATE VM should be way more gas effective… Also, recursivity is always expensive. From my brief Erlang studies I have learned though, that you might achieve a more efficient outcome if you use tail recursivity, also known as the “accumulator pattern”: Accumulate the output from function calls and pass it as input into the next call, if you don’t already do so. Don’t let your function be it’s own parameter, so to say, that makes the stack grow and is horribly inefficient.

3 Likes
9

Hi Nikita-fuchs! Thanks for your answer and interest!

We understand execution should be capped in both scenarios in chain and in state-channel.

Nevertheless, in this case, a two-player game, meant to be run in state-channel, we don’t really care about gas consumption, and would like to increase it. Today a reasonable value may be some, but it is a guess and probably tomorrow something different will be required (eg: 640kb should be enough for all). I don’t really want to increase it to googolplex, neither to something indistinguishable to infinite execution, but we are limited to half of our execution, and probably in state-channels a wider option set maybe useful like: asking user for approval, or time-limited execution or whole-contract execution cap… before and until that being discussed, ability to increase it would be good.

Yes, we can optimize or coude (and we will), but it is a not really that bad implementation and we would like to already finish the proof-of-concept.

Thanks also for all the optimization tips!
dave

10

Hi nikita, I understand that there are, like in other blockchain platforms, gas limits per transactions, but not for example a general gas cap in a channel. I’m correct?
This would limit the number of peer interactions to a maximum total gas usage which I see as undesirable and also illogical due to the offchain execution of the smart-channel contracts.
I’m right about this?
Thanks.