Michele Orrù
Michele Orrù
I'd rather go with a trait `VariableBaseMSM` that gets implemented as `VariableBaseMSM`, `VariableBaseMSM`, etc.. That'd spare us the conversion to BigInts and back, and seems more ergonomic as the user...
they could implement domain-specific functions or do something like the following I think? ```rust type GG = u64; pub trait VariableBaseMSM: Sized { fn msm_unchecked(bases: &[Self], scalars: &[T]) -> Self;...
Agreed -- but when you have bounded elements they are often *not* as a Field type, so we'd have to come up with something to make the API more ergonomic
whoops, alright sorry about that! Feel free to force-push
@Pratyush sweet, let me know if you need to offload some other tasks before this gets reviewed
In #577, @Pratyush suggests basing `PairingOutput` over `MultiplicativeGroup`. However, this would break some arguments and I'd rather vouch for it being `AdditiveGroup`. For instance. in a sumcheck-based argument for proving...
"email sending facilities" --> in case of errors? Creating a new package `utils` for generic APIs . c8051727ef812fc070c216aafef225d28943df33
Hello! thank you so much, indeed part of the work here was based on PR's that are now merged in arkworks. I think we can update them once ark-group exists....
any news on this? we could at least make it available via a feature flag?
The function for estimating fft's is here: https://github.com/mmaker/zkalc/blob/main/frontend/lib/estimates.js#L153