Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store ECDSA and Schnorr keys in a static variable to avoid repeated mgmt canister calls #965

Open
dantol29 opened this issue Sep 2, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@dantol29
Copy link
Contributor

dantol29 commented Sep 2, 2024

BASIC_BITCOIN example

It takes approximately ~9 seconds to get public key, as well as a decent amount of gas is spent.
Is there a reason why we have to call schnorr_public_key or ecdsa_public_key each time a user wants to get an address? If not then storing public keys in a static variable would maintain state across different calls to the canister and save lots of time and gas.
I understand that this is just an example, but perhaps this optimization would show some devs how to reduce cycle burn rate.

Something like:

thread_local! {
    /* flexible */ static SCHNORR: RefCell<Option<SchnorrPublicKey>> = RefCell::default();
}
@dantol29 dantol29 added the enhancement New feature or request label Sep 2, 2024
Copy link
Contributor

github-actions bot commented Oct 3, 2024

This issue is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale label Oct 3, 2024
@altkdf
Copy link
Contributor

altkdf commented Oct 14, 2024

It is indeed reasonable to cache the public key in a variable instead of repeatedly making calls to the management canister. We will try to address this soon, but feel free to open a PR yourself if you like.

@github-actions github-actions bot removed the stale label Oct 15, 2024
@dantol29
Copy link
Contributor Author

It is indeed reasonable to cache the public key in a variable instead of repeatedly making calls to the management canister. We will try to address this soon, but feel free to open a PR yourself if you like.

Gonna open PR soon! Thank you for the answer!

@dantol29
Copy link
Contributor Author

Opened the PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants