You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should implement Pixel because doing so appears fairly straightforward and somewhat orthogonal. I believe the primary hurdle would be abstracting the verification equation, but if done properly then all the underlying optimizations work.
I think EngineBLS could act as both the curve and orientation like now, while some SignatureScheme extension trait provides the verification equation. We'd have BLS<E: EngineBLS> and Pixel<E: EngineBLS> ZSTs that satisfy SignatureScheme.
In this, Pixel's associated type SignatureGroup becomes the cartesian product of both groups, which incidentally makes us more dependent upon our patched version of pairing for batch_normalization.
The text was updated successfully, but these errors were encountered:
I've noticed ZCash's refactor aiming for some general Group trait, but our Pixel::SignatureGroup actually requires both projective and affine forms, and a batch_normalization method. It's not a curve however since it lacks a well defined base field, not sure they'll do that level of granularity.
We should implement Pixel because doing so appears fairly straightforward and somewhat orthogonal. I believe the primary hurdle would be abstracting the verification equation, but if done properly then all the underlying optimizations work.
I think
EngineBLS
could act as both the curve and orientation like now, while someSignatureScheme
extension trait provides the verification equation. We'd haveBLS<E: EngineBLS>
andPixel<E: EngineBLS>
ZSTs that satisfySignatureScheme
.In this,
Pixel
's associated typeSignatureGroup
becomes the cartesian product of both groups, which incidentally makes us more dependent upon our patched version ofpairing
forbatch_normalization
.The text was updated successfully, but these errors were encountered: