Why is the Jubjub base field exposed?

[hdevalence]

Is there a use-case for exposing the base field of Jubjub? From the perspective of a user of the elliptic curve library, the base field of the curve is an implementation detail. From looking through the API it seemed like the only place that it's used in the public API is in functions like from_raw_unchecked for unsafely constructing points, but it's not clear why someone would need to do that.

[daira]

[Edit: this comment is wrong for the current design; it reflects an earlier proposed design.]

If I understand correctly, the base field implementation needs to be exposed because the bls12-381 crate imports jubjub in order to use this implementation for its scalar field (so that we don't end up with two implementations of the same field).

And yes, that's a bit of a hack from the point of view of logical dependencies, but it works. (We don't want a dependency in the reverse direction, because we want to be able to implement RedJubjub without a dependency on BLS12-381.)

[ebfull]

The approach we're taking is to have bls12_381 expose the base field of Jubjub (which is its scalar field). This crate will depend on the bls12_381 crate but with all features disabled, which only exposes the scalar field. I don't remember why this ended up being the way we wanted to do it though.

[str4d]

I don't remember why this ended up being the way we wanted to do it though.

It was because it mapped more closely to the logical dependencies.

Is there a use-case for exposing the base field of Jubjub? [...] From looking through the API it seemed like the only place that it's used in the public API is in functions like from_raw_unchecked for unsafely constructing points, but it's not clear why someone would need to do that.

The main use-case for this was being able to hard-code specific curve points in embedded environments (e.g. the various derived base points used in the Sapling protocol), where even point decompression is costly. However, the ever-increasing const fn API within jubjub might now be sufficient to just generate those constants directly.

[ebfull]

Furthermore, we need to access the base field elements in order to build useful abstractions (circuit stuff, etc.) in Zcash. Thus, there are get_u and get_v methods currently for AffinePoints.

[daira]

Yes, in particular note commitments in Sapling are encoded just as u-coordinates (because a u-coordinate uniquely determines a point in the prime-order subgroup; see Theorem 5.4.4 in the spec).

[hdevalence]

Hmm, so at a high-level is it roughly correct that Sapling requires some gadgets that use Jubjub in particular ways (e.g., to synthesize the witness during proving some statement about the coordinates of Jubjub points), and so the jubjub crate exposes the raw internals so that a downstream crate can implement those gadgets?

[ebfull]

Yup, that's correct.

[ebfull]

Note that this crate and bls12_381 have both been modified (and updated on crates.io) so that the base field of Jubjub is exposed by bls12_381 instead.

[hdevalence]

Hmm, I'm not sure I follow what you mean -- looking at the docs, the base field is still exposed by the jubjub crate, whether it's re-exported from the underlying bls12_381 crate or not.

To clarify, my question wasn't about where it should come from but why it should be there at all, and from the discussion it seems like the answer is because the jubjub crate exposes raw coordinate functionality so that external crates can use it to implement Jubjub gadgets. If that's correct this issue could be closed as answered :)