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

Operations over doppio points in Bulletproofs #5

Open
cathieyun opened this issue Apr 8, 2019 · 2 comments
Open

Operations over doppio points in Bulletproofs #5

cathieyun opened this issue Apr 8, 2019 · 2 comments

Comments

@cathieyun
Copy link
Member

cathieyun commented Apr 8, 2019

Implement point operations over doppio points, which are represented as AllocatedPoints. Each operation will take the input AllocatedPoints and the constraint system (if the AllocatedPoint doesn't store a reference to a constraint system?), and allocate new constraints that enforce that the operation is valid. Also it would allocate new variables that represent the result of the operation, and make assignments to the variables.

  • Squaring
  • Multiplication
  • Addition
  • Equality
@hdevalence
Copy link
Contributor

One idea worth looking at is the following.

As far as I know, the JubJub implementation in Sapling has functions (like point addition) that take as parameters the point operands, as well as a &mut constraint system reference.

The upside of taking a &mut constraint system is that it means that all the normal borrowing / ownership logic applies. The downside is that it prevents using things like the ops traits to represent point operations (since they don't allow a context parameter).

We could instead consider using a RefCell or something to hold on to the constraint system reference, so that all of the allocated points have an implicit reference to the constraint system (interior mutability). This might make the API simpler to read, at the cost of moving the borrowing checks to runtime, but that will be insignificant compared to the proving cost, so I think it's a fine tradeoff if it makes the API better.

@Pratyush
Copy link

Pratyush commented May 2, 2019

Note that you can still use ops traits for this by making the Rhs parameter (&mut CS, &Self) instead of just &Self. (I've been toying around with this implementing this idea in https://github.com/scipr-lab/zexe, but haven't yet gotten around to doing it

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

3 participants