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

Implement Pixel #4

Open
burdges opened this issue May 28, 2019 · 2 comments
Open

Implement Pixel #4

burdges opened this issue May 28, 2019 · 2 comments

Comments

@burdges
Copy link
Collaborator

burdges commented May 28, 2019

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.

@burdges
Copy link
Collaborator Author

burdges commented Jun 4, 2019

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.

@burdges
Copy link
Collaborator Author

burdges commented Jul 11, 2019

It appears Pixel's versifier optimizations differ significantly from BLS, so maybe this fits less well than I initially thought.

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

1 participant