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

Add preprocessing to challenge API. #193

Open
levs57 opened this issue Aug 5, 2023 · 1 comment
Open

Add preprocessing to challenge API. #193

levs57 opened this issue Aug 5, 2023 · 1 comment
Assignees

Comments

@levs57
Copy link

levs57 commented Aug 5, 2023

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.

@ed255
Copy link
Member

ed255 commented Jun 12, 2024

Hi @levs57 !
I think the biggest challenge for this feature is what you mention about an on-chain verifier; and more generally, any kind of verifier that is not rust native (for example, a circuit verifier). We would lose the opportunity to automatically generate a circuit verifier when such a feature is used.

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!

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