Get access to the Fp12 representation from Gt

[abizjak]

The https://docs.rs/bls12_381/0.7.0/bls12_381/struct.Gt.html has very little functionality exposed at the moment.
It implements the Group trait and a few helpers, however this is not enough for one of the ZK protocols we have.

What would suffice for us is a way to get the underlying Fp12 representation of Gt. For example,

impl AsRef<Fp12> for Gt {
   ...
}

would be perfectly adequate, or any other alternative you would prefer.

Is this something you are open to adding to the library? Without this we cannot upgrade from the old pairing crate that embedded the bls implementation to the recent one.

This is related to #10 although I need less than that.

[str4d]

It implements the Group trait and a few helpers, however this is not enough for one of the ZK protocols we have.

What functionality do you need? I'm generally reluctant to expose the underlying Fp12 representation, as it affects the type safety of this crate (which is something that we specifically had in mind when improving the APIs of this crate over the old pairing crate impl). I'm more inclined to first see whether the functionality you require can be exposed in some other way.

[abizjak]

The only thing we need is that we can serialize the value in a specific way.

        // coefficients in the extension F_6
        let c0_6 = self.c0;
        let c1_6 = self.c1;

        let coeffs = [
            // coefficients of c1_6 in the extension F_2
            c1_6.c2, c1_6.c1, c1_6.c0, // coefficients of c0_6 in the extension F_2
            c0_6.c2, c0_6.c1, c0_6.c0,
        ];
        for p in coeffs.iter() {
            let repr_c1 = FqRepr::from(p.c1);
            let repr_c0 = FqRepr::from(p.c0);
            for d in repr_c1.as_ref().iter() {
                d.serial(out);
            }
            for d in repr_c0.as_ref().iter() {
                d.serial(out);
            }
        }
    }

We could actually work around this and shuffle some other things around I think so we maybe wouldn't have to do this, but we cannot change the protocol we have now without massive migration pain, so we have to stick with the exact format we have at the moment.

[abizjak]

I do sympathize with wanting to have as type-safe API as possible :)

[randombit]

Is there any way to make progress on this? I'm running into the same problem while trying to implement an IBE scheme where we need to hash elements of Gt; any (stable over time) serialization would be fine, no deserialization required.

[abizjak]

@str4d is there any way to make progress on this? Would you accept a PR where this was exposed conditionally based on a feature that is off by default and documented as unstable/unsafe?