Closed hdevalence closed 9 months ago
Eventually yes, this seems reasonable. However, zcash_primitives
et al don't yet use the jubjub
crate (it's the next step in the refactor), and I suspect it will be more complicated to try and pull this in beforehand. You're welcome to try though - it might be that the wrappers around redjubjub
to map from jubjub
to zcash_primitives::jubjub
aren't too terrible.
Additionally, we'll be vendoring jubjub
inside our codebase while doing the refactor, so that we can adapt jubjub
's API as necessary while we go (in particular to end up with jubjub
implementing the ff
and group
traits, which themselves will be adapted to more closely match jubjub
's API), which probably means vendoring redjubjub
as well.
Instead of a re-export, we'll just drop the redjubjub
module entirely (#581).
We needed a RedJubjub implementation for use in Zebra (cf https://github.com/ZcashFoundation/zebra/issues/125), so I made a small, mostly self-contained one for that purpose using the new version of the
jubjub
crate. It's not yet on crates.io just because we didn't publish it yet; it's otherwise functionally complete. One nice thing about its API is that unlike the existingredjubjub
implementation, it enforces theBindingSig
/SpendAuthSig
distinction at the type level.I think that it would integrate nicely into
zcash_primitives
, replacingmod redjubjub;
with a re-exportpub use redjubjub_zebra as redjubjub;
, and I would be happy to prepare such a PR, but because it requires propagating type changes throughzcash_primitives
, I wanted to check first rather than doing work that doesn't fit with future plans forlibrustzcash
.This would supersede #179.