Extract curve25519 crate from zk-token-sdk #951
Conversation
|
Think the downstream checks are failing just because the new crate isn't on crates.io yet |
|
Hi, should we merge #946 first before doing this refactor? |
|
When that's merged I will rebase and make sure the relevant changes to the curve25519 dir are ported over |
|
@kevinheavey, I wanted to merge #1495 and #1693 in before this PR, but it seems like those PRs are getting delayed and it would be ideal to get this PR in before agave 2.0 is cut. Do you mind rebasing the PR to test the CI? And let's put this crate under the directory |
kevinheavey
force-pushed
the
zk-token-curve25519
branch
from
7d1652e
to
a8dff80
Compare
There was a problem hiding this comment.
Okay thanks! I think the CI is not too bad. I can reserve the crate to take care of crate-check. Other than that, it appears that downstream tests are the main ones.
Getting rid of the target_os restriction below will take care of some failures, so let's make that change and see what we get with the CI.
|
Sorry for the delay on this 🙏 . All the CI passes, so I will merge it after you rebase. |
kevinheavey
force-pushed
the
zk-token-curve25519
branch
from
95203de
to
568e201
Compare
Problem
As the zk-token-sdk crate itself correctly notes, the code in the curve25519 folder should live in its own crate:
A more pressing motivation for me is that I have code that depends on bpf_loader, which only needs the curve25519 code from zk-token-sdk, and it takes a while to compile the whole zk-token-sdk crate.
Summary of Changes
Extracts
zk-token-sdk/src/curve25519into its own crate and re-exports it for backwards compatibility. Updates code in the monorepo to use the new crate directly.