8

For ink contracts with weight v2 it requires refTime and proofSize. For this we are first querying(dry run) the transaction method, getting gasRequired from query result and sending it to transaction. For weights v2 query also required gas values which we are getting from api.consts.system.blockWeights['perClass'].operational.maxExtrinsic

This process is failing sometimes with outofgas exception. api.consts.system.blockWeights return plethora of results and it is not clear which value to use.

{
  baseBlock: {
    refTime: 358,523,000
    proofSize: 0
  }
  maxBlock: {
    refTime: 500,000,000,000
    proofSize: 5,242,880
  }
  perClass: {
    normal: {
      baseExtrinsic: {
        refTime: 98,974,000
        proofSize: 0
      }
      maxExtrinsic: {
        refTime: 324,901,026,000
        proofSize: 3,407,872
      }
      maxTotal: {
        refTime: 375,000,000,000
        proofSize: 3,932,160
      }
      reserved: {
        refTime: 0
        proofSize: 0
      }
    }
    operational: {
      baseExtrinsic: {
        refTime: 98,974,000
        proofSize: 0
      }
      maxExtrinsic: {
        refTime: 449,901,026,000
        proofSize: 4,718,592
      }
      maxTotal: {
        refTime: 500,000,000,000
        proofSize: 5,242,880
      }
      reserved: {
        refTime: 125,000,000,000
        proofSize: 1,310,720
      }
    }
    mandatory: {
      baseExtrinsic: {
        refTime: 98,974,000
        proofSize: 0
      }
      maxExtrinsic: null
      maxTotal: null
      reserved: null
    }
  }
}

For us what worked is doubling the gasRequired coming from dry run but this is not a efficient solution.

Is there an official documentation for estimating gas for Weights v2.

3
  • I think this might help you questions link, there is code for gas estimation for Weight v2 of contract transaction
    – go11li
    Feb 7, 2023 at 3:42
  • this is example code
    – go11li
    Feb 7, 2023 at 5:59
  • 1
    The linked question was answered by me and the linked repo code was created by me. I am looking for an official solution. Feb 13, 2023 at 10:18

1 Answer 1

2

The answer which you gave in the link from the comment is correct.

So dry-running it via polkadot-js or some other means. cargo contract {call, instantiate, …} does this by default before submitting the extrinsic.

This process is failing sometimes with outofgas exception.

For us what worked is doubling the gasRequired coming from dry run but this is not a efficient solution.

This could happen when the state that the contract function uses changes between your dry-run to the execution of the extrinsic. Consider e.g. if the contract relies on the block number for some logic. This alone would mean that the contract executes differently. It could even be just a slight derivation that would result in the Gas being different.

Possible solutions are:

  • Redo the dry-run and using that possibly new Gas estimation value.
  • Submit the transaction with something like 1% more Gas than what the dry-run yielded.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.