-
Notifications
You must be signed in to change notification settings - Fork 140
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
New crypto features support #582
Comments
@SupunS @turbolent , I've updated the suggestion above following the new changes in Cadence. A lot of the changes are described in comments since most of it will need to be implemented in Go, and not in Cadence anymore. Please have a look at the comments and let me know if you have any changes.
|
@tarakby Thanks for the update, this looks good. A couple of questions:
|
|
It would be nice if I guess the question is: Do we want to make it impossible to have invalid public keys? Or should it be possible to construct an invalid public key, and then users have to ensure to always check @dete any thoughts? |
I have a preference for option 1, because of an API extension I'm thinking of for when we support BFT measures (verify proof of possession for BLS keys), which works better with option 1. The validation function is not very expensive. But it would be better to avoid re-validation. |
Yeah, I asked if validation is expensive because I was thinking of just setting isValid to the outcome of validation. That way there is no chance of a user forgetting to validate the instance. We could also make Always validating in the constructor and initializing isValid to the outcome of validation, and making it a stored would make it a bit easier to make the type storable, importable, and exportable. |
Just adding that we still need a way to export the |
With import and export here is meant interaction between Cadence and the outside world, e.g. a script argument is imported as a Cadence value, and a value returned from a script is exported from Cadence. Is the The field doesn't need to be exportable if it's only accessed on-chain, e.g. by the staking contract. |
I'm not sure what are the off-chain cases, do you have examples? Btw, the value on-chain must be only accessible for reads not writes (the value should not be settable to |
I don't know about them either, that's why I was asking. I guess it's not important then
Right, we'll make the field |
I'm curious as to why do we need both the So Are there any cases where we need to call |
@SupunS Yes, like I mentioned a little bit further up in the comments, users should only see a |
I had missed this in the last PR (#829), sorry about the confusion! |
Oh, sorry I was under the impression that we expose both. Thanks for the clarification. I can clean it up when doing the changes for adding the |
Issue To Be Solved
Suggest A Solution
This is modified version of the file
crypto.cdc
. Many functions are copied from the original code but I pasted the entire file for a better clarity, as there a few changes here and there. I've added some comments in the code to help understand the changes.This code is a starting point to discuss and improve, I'm open to all suggestions making the APIs easier to use while keeping all the features needed for the epoch switch implementation in Flow protocol.
The text was updated successfully, but these errors were encountered: