-
Notifications
You must be signed in to change notification settings - Fork 129
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
Add preprocessing to challenge API. #193
Comments
Hi @levs57 ! We also recently re-architectured halo2 so that it has a clean split between frontend (responsible of offering an API to describe a circuit, compile it and generate a low level plonkish circuit description; and do witness generation) and backend (responsible for setup, proof generation and proof verification). I imagine this black box would be defined in the frontend but would need to be passed to the backend, which will add some complexity in the middleware. So I would say from our part we don't plan to implement this feature. If you'd be interested in implementing this, as a feature that can be disabled, let us know! |
Right now, we have a challenge API, but it does not allow to use black-box operations on it.
For example, if I generate the challenge, I can produce a primitive expression, using Expression::Challenge(challenge), which produces a public constant usable after the phase this challenge is generated in. After this, I can only apply polynomial operations to it.
It is desirable to be able to use any black-box public function and produce a new expression (still "public constant", degree 0, etc) - one particularly important case that comes to mind is hashing the challenge to curve.
It is possible to do - one way is done in my fork here: https://github.com/levs57/halo2 ; though it is a bit lazy as it does some checks runtime - ideally we need a wrapper struct with private field
expr : Expression<F>
, which can only be generated from "public constant" expressions - i.e. from constant, challenges, and other Expression::Postprocess. Currently this is just checked on runtime.I think it is a desirable feature. One particular concern is that it (sort of) breaks on-chain verifier - as it now must somehow know how to compute blackbox functions that we use.
In case of hashing to curve, an optimization is desirable anyways - i.e. reasonably in most cases verifier should just check smth like
(A.x-challenge) < 128; (A.x-challenge) >= 0
, where A is a challenge point - this gives malicious prover an ability to choose point but very limited (out of expected ~64 options), which works in most cases.The text was updated successfully, but these errors were encountered: