Exceeded the instruction limit for single message execution

I got

Exceeded the instruction limit for single message execution

when call this code. Is this normal?

const mnemonic = 'unit jelly zone token virus blue parrot pottery stage girl version grief left black foam donkey fatigue silly bitter fox manage note indoor leisure'
const seed = bip39.mnemonicToSeedSync(mnemonic)
1 Like

Is this in the context of an update call or a query call?

Note also that it is probably not a good idea to have this code in a canister as of now, as node provides could have access to your secret.

What CDK are you using?

Can you show more of the code?

1 Like

Thank you for response.
Note that this is just a demo how to create a KeyPair.
I want to make an wallet canister. What is best solution for this now?

I’m using Typescript with azle.
This is all code of a query function in backend canister.
The function cause error is mnemonicToSeedSync .

Query calls have a low instruction limit on purpose because the IC doesn’t charge for them yet.
Azle also adds quite a bit of overhead. Calling a similar function in Motoko or Rust would probably work.

You can change your function to an update call to have a higher instruction limit for a single message execution.

You can always review the current limits on the IC in the docs: Resource limits | Internet Computer.

1 Like

Thank you very much.
Would you mind to suggest any related bip39 stuff in Motoko?

Seem that change query to update is not working.
The error still persist.

Can you try running it inside of init or post upgrade? Currently Azle’s crypto functionality is mostly implemented in JavaScript, and some operations can unfortunately use many many cycles. We hope to address this in the coming months.

You might be able to do this in init or post upgrade, since they have a 200 billion instruction limit.

I am developing a function where user can create their KeyPair.
So that calling this function in init or post upgrade seem not right.

Please note that canister memory, execution and call and response data is not hidden from the node providers. So you should neither generate nor store secret key material in the canister, nor should you transmit secret keys into or out of the canister.

What you can do in your case is to create an asset canister, ie frontend hosted in a canister, which can then generate a key pair client side for the user.