Add marlin repo sha to snark key identity

[nholland94]

We hit a bug in a testnet recently where the snark keys change from underneath the network in s3, causing nodes which were restarted by kubernetes to download different snark keys and end up in an incompatible state where they cannot verify proofs from the network. As a fix to this problem, I'm not adding the marlin repo sha to the snark key's s3 storage key so that any updates to the marlin repo (which would make incompatible keys) will create a different keypair in s3, avoiding the problem in the future.

2 notes about these changes:

1. I'm not totally sure I didn't miss somewhere in the CI process where we calculate the expected s3 keypair storage key from outside of the ocaml process. If you have details about how the s3 keypair upload from CI works, please double check I didn't miss anything.
2. It's possible we may be able to get rid of the hard coded _v2 in the keypair name now that the marlin repo sha is in there. I didn't do that for now, but if that's the case, I can make that change.

[mrmr1993]

This adds a transitive dependency to everything above this library on universe. I can't think of any easy fix for it, but we should try to come up with one ASAP, or push forward with moving these things out of the build process altogether.

[nholland94]

It's not ideal, but if we change the zexe interface so that we thread the marlin repo sha down to it instead of baking it in at that layer, we could hack around this. It's not a great solution imo, but it would fix rebuilding zexe_backend every single build, which seems worth it.

[nholland94]

I may be able to do a hack where I depend on the source tree of the marlin repo in external and generate a file internally to zexe_backend that contains the sha for it. If I do it right, it will only trigger a rebuild when the marlin repo changes, but we'll see if I can get dune to play nice like that. I'll test it out some before I merge this.

[lk86]

I've been working on caching these keys in the docker image before even building the main daemon (and ran into issues because the v2 keys aren't static), a tool in the marlin repo for consistently doing that would be nice and is probably the better place to standardize. Does this also help avoid the universe dependency?

[lk86]

To add some clarity on what we do in CI:

The build artifact job runs make build_or_download_pv_keys followed by ./scripts/publish-pvkeys.sh to push them to s3, neither of these jobs explicitly references the file name. Anything you store in /tmp/coda_cache_dir during build_or_download_pv_keys ends up in s3 under snark-keys.o1test.net

[mrmr1993]

I've been working on caching these keys in the docker image before even building the main daemon (and ran into issues because the v2 keys aren't static), a tool in the marlin repo for consistently doing that would be nice and is probably the better place to standardize.

@lk86 any changes to the snark code will require new keys, so sticking them in the docker image only works until the constraint system next changes. The real fix for this would be to move key generation out of the coda.exe build entirely and manage them separately.

[netlify]

Deploy preview for mina-staging ready!

Built with commit a1b60c3

https://deploy-preview-6208--mina-staging.netlify.app

[nholland94]

The real fix for this would be to move key generation out of the coda.exe build entirely and manage them separately.

I think we should start moving towards this soon. This seems like the best solution. The docker solution is not great since the keypairs can change too frequently (and they are pretty big), and having the daemon generate it is messy.

[nholland94]

@mrmr1993 I managed to remove the new zexe dependency on (universe). Would you mind doing a quick re-review of the new implementation?