Borrow G2Prepared

[burdges]

Afaik we do not have &G2Prepared: Into<G2Prepared> sensibly, so every invocation requires duplicating the G2Prepared, like 16kb or more.

    fn multi_miller_loop(
        a: impl IntoIterator<Item = impl Into<Self::G1Prepared>>,
        b: impl IntoIterator<Item = impl Into<Self::G2Prepared>>,
    ) -> MillerLoopOutput<Self>;

You'll notice zcash abandoned the generics in the equally messy old interface. You'd still avoid the preparation time by cloning the G2Prepareds, but we never modify G2Prepared so idiomatic rust would allow borrows here.

Could we borrow but retain the Into somehow? I suspect maybe..

    fn multi_miller_loop(
        a: impl IntoIterator<Item = impl Into<impl Borrow<Self::G1Prepared>>>,
        b: impl IntoIterator<Item = impl Into<impl Borrow<Self::G2Prepared>>>,
    ) -> MillerLoopOutput<Self>;

It's possible rustc winds up confused by the multiple trait layers here, under some uses, not sure.

As an aside, rustc won't let associated types remove the impl Borrow flexibility and Into<Cow<..>> breaks oddly. It's also plausible https://github.com/rust-lang/rfcs/pull/3382 helps somehow. I'm most hopeful for the above however.

[Pratyush]

Hm another thing I realized is that the current API means that multi_miller_loop must accept items all of the same concrete type, which means I can't do something like E::multi_miller_loop([a, b], [c, d_prepared])

[burdges]

Into is purely a convenience, so if you've manually prepared d_prepared then you can manually prepare the c.

It's hard to share d_prepared between verifications anyways right now. We'll need const traits to be stabilized for code like https://github.com/w3f/ring-vrf/blob/master/nugget_bls/src/lib.rs#L184-L190 really. I started a simple crate for polymorphic lazy_statics but then decided it's not worth the effort if const traits land 1-2 years.

Anyways, I think someone news to arkworks could explore if the impl Into<impl Borrow<_>> interface breaks any other crates. It'll likely work..