Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Borrow G2Prepared #618

Open
burdges opened this issue Mar 11, 2023 · 2 comments
Open

Borrow G2Prepared #618

burdges opened this issue Mar 11, 2023 · 2 comments

Comments

@burdges
Copy link
Contributor

burdges commented Mar 11, 2023

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 rust-lang/rfcs#3382 helps somehow. I'm most hopeful for the above however.

@Pratyush
Copy link
Member

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
Copy link
Contributor Author

burdges commented Mar 14, 2023

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..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants