[CFRG] Re: Pairing-Friendly Curves: Open Questions Before Draft Update

[Jack Grigg <[e-mail]>]

Hi, Zcash developer here.

On Mon, 15 Dec 2025, 11:36 pm David Waite, <david=
[e-mail]> wrote:

> WRT serialization around BLS-12-381:
>
> - draft-irtf-cfrg-bbs-signatures-09 appendix B.2 duplicates the point
> encoding and decoding, and the algorithm uses this binary representation to
> serialize points as messages in the signature algorithm (with constraints,
> discussed below under the curve selection topic)
>
> - draft-ietf-cose-bls-key-representations-08 references this, and also
> applies a delta to the BBS definition as the prescribed way to represent
> BLS48-581 points in JWK/CWK documents
>
> - draft-irtf-cfrg-bls-signature-06 instead references a historical version
> of a rust crate README.
>
> Also, the document originally referenced by paring-friendly-curves for the
> ZCash work (for its own appendix describing this representation) appears to
> have moved or disappeared - I believe because the above mentioned README.md
> has since been edited.
>

The [ZCashRep] reference taken in July 2017 is indeed outdated because our
BLS12-381 implementation was extracted into its own crate in the many
intervening years. The correct URL is now:

https://github.com/zkcrypto/bls12_381/blob/main/README.md#curve-description

The specification for the serialization format that
draft-irtf-cfrg-bls-signature-06 referenced as [ZCash] (incorrect
capitalization by the way, it should be Zcash in all places) is now here:

https://docs.rs/bls12_381/latest/bls12_381/notes/serialization/index.html

However, I would treat both of these as informative references. For a
normative reference to how Zcash specifies and serializes BLS12-381, you
should reference the Zcash Protocol Specification. The precise reference is:

[Zcash] D.-E. Hopwood, S. Bowe, T. Hornby, and N. Wilcox, "BLS12-381",
Zcash Protocol Specification, Version 2025.6.1 [NU6.1],  Section 5.4.9.2, <
https://zips.z.cash/protocol/protocol.pdf#blspairing>

The URL with anchor is a stable reference to the latest version of that
part of the spec (we take great care to ensure those anchors don't break).

It would be great if we could reference this representation definitively in
> one place, without indicating ZCash as a possibly more authoritative work,
> and ideally without other dependent specs needing to constrain or expand
> upon the format. I don’t think any of the three documents I’ve referenced
> above are ideal though - I think that the serialization should be in this
> document or one split out from it.
>
> My preference as an implementor would be not to split out the point
> representation - or to have pairing-friendly-curves normatively reference
> the document that these were split into. As much as possible we should
> encourage a single serialization for valid points on a particular curve.
>
> I suspect such representations are also useful for documenting and
> leveraging test vectors.
>

FYI in case CFRG was not already aware, we have test vectors here for G1
and G2 compressed and uncompressed encodings (in a concatenated binary
form, but it would be trivial to convert them into a text form):

https://github.com/zkcrypto/bls12_381/tree/main/src/tests


> <snip>
>
> Serialization
>
>    - The current draft allows both compressed and uncompressed encodings,
>    including identity elements. Concerns were raised about interoperability
>    and risks from optional encodings. Should the draft specify a simpler,
>    consistent serialization format for implementers? Should identity points be
>    disallowed or tightly constrained?
>
> My take is that we should have a single encoding function per curve that
> produces fixed-length, compressed, non-identity elements - and a decoding
> function that fails on uncompressed and identity elements.
>
> In the BLS case, that encoding should be a subset of the ZCash-based
> serialization, restricting that “C" is always 1 and “I" is always 0. BBS I
> believe constrains the algorithm to only support compressed points, but
> does not constrain serializing infinity.
>

This matches what we specify in the Zcash Protocol Specification.

We do use the uncompressed encoding when storing the verification keys for
the Sapling Spend and Output circuits (as an optimisation to avoid
additional work when loading them from disk, and because we hash-pin these
static files), but the points at infinity never occur proofs, and for
proofs encoded in transactions (i.e. on the wire) we only use compressed
points.

Cheers,
Jack