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

Expose functions to update stake in C API #43

Closed
iquerejeta opened this issue Nov 16, 2021 · 4 comments · Fixed by #51
Closed

Expose functions to update stake in C API #43

iquerejeta opened this issue Nov 16, 2021 · 4 comments · Fixed by #51
Assignees

Comments

@iquerejeta
Copy link
Contributor

Currently the stake related to an StmInitializer or StmSigner cannot be updated using the C API. Expose such functions.

@iquerejeta iquerejeta self-assigned this Nov 16, 2021
@abailly-iohk
Copy link
Collaborator

This would be needed by Mithril nodes in order to cope with changes in stake distribution over time. Could alternatively be handled by recreating the data structures from different parameters?

@iquerejeta
Copy link
Contributor Author

The problem of recreating the data structures from the different parameters, is that then the keys are re-generated. What we wanted is to be able to update the parameters of the StmInitializer or StmSigner without having to re-generate the keys.

I'm thinking that it might be of interest to consider a function that takes a seed to generate the StmInitializer or StmSigner. In that way the keys are generated with respect to the seed, but the parameters can be changed.

@abailly-iohk
Copy link
Collaborator

In general, it seems to me it makes sense to be able to pass the keys, do you see any problem with that in general? If we have #44 then it would not be a problem right? Also, I could imagine node operators storing the keys elsewhere, perhaps in a HSM or KMS?

@iquerejeta
Copy link
Contributor Author

I was initially inclined to not make it possible to unlink the key pair from the StmSigner instance. The idea is to minimise the amount of functions we expose to the C API. If we allow too many actions from C, then we are loosing many benefits of rust. But also allowing all these changes increases the chances of shooting yourself in the feet.

However, I'm starting to think that this might be a practical functionality. I'll open a different issue to track that.

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

Successfully merging a pull request may close this issue.

2 participants