[RFC] Snark keys management #6341
Conversation
|
|
||
| ### Add a tool for generating keys outside of the build process | ||
|
|
||
| This tool could be an `internal`/`advanced` subcommand of the main executable |
There was a problem hiding this comment.
There is a lot of value in having this as a distinct executable, especially in making sure that most tests/jobs are not dependent on building coda.exe. Is the time/effort cost of splitting it out much higher? Alternatively, do we save effort by adding this command / these features to src/lib/snark_keys/gen_keys/gen_keys.exe instead as it is already focused on snark key generation/management?
There was a problem hiding this comment.
We can build a separate executable that sits at the same layer of the dependency graph as snark_keys does (and library-ise the command so that it can still be exposed from the CLI too), if that would be helpful. I will update the text to add this, and it should be no extra work to do it this way.
I'll note though that the snark keys depend on code quite far up the coda.exe dependency chain, so we'll have to recompile it for each commit, and we likely won't end up saving much time vs using compiling and using coda.exe directly.
rfcs/0039-snark-keys-management.md
Outdated
| zexe repos used when generating the keys | ||
| * the length of the binary data following the header, so that we can validate | ||
| that the file was successfully downloaded in full, where applicable | ||
| * the date when the file's contents were created |
There was a problem hiding this comment.
If we don't include generation date, this (in theory) should be reproducible and I think that's worth it. We're going to want easy reproducibility for the more security-conscious folks and it makes it easy for us to go back to old commits to recover data if needed.
Since we have the commit sha, this can act as a timestamp
There was a problem hiding this comment.
In the medium term, it would be good to have a ls-style tool that lets us list all of the cached keys in different ways, and especially to have list-keys --sort=date so that we could delete out-of-date keys more easily and reliably.
I've updated the rfc to use the date from the current commit, so we have reproducibility and some notion of time, and mentioned these reasons as sub-bullets.
rfcs/0039-snark-keys-management.md
Outdated
| , "supercharged_coinbase_factor": 2 | ||
| , "account_creation_fee": "0.001" } | ||
| , "commits": | ||
| { "coda": "COMMIT_SHA_HERE" |
There was a problem hiding this comment.
Also the marlin/zexe commits should be redundant since they're specified by the submodule checked out at that commit, right?
There was a problem hiding this comment.
the marlin/zexe commits should be redundant
I've removed the zexe commit. Keeping the marlin one because we're using it as an input to the 'identifying hash', and it would be nice if we could compute/check that from the header without needing access to the full git history. I've added a sub-bullet with this justification.
mrmr1993
added
ci-build-me
|
Deploy preview for mina-staging ready! Built with commit a120d7f |
Checklist: