Feat/g16 enormous fs hint #405
Conversation
|
quick remark; maybe add a panic for now in |
| @@ -576,3 +576,19 @@ func (system *r1cs) negateLinExp(l compiled.LinearExpression) compiled.LinearExp | |||
| func (system *r1cs) Compiler() frontend.Compiler { | |||
| return system | |||
| } | |||
|
|
|||
| func (system *r1cs) Commit(v ...frontend.Variable) (frontend.Variable, error) { | |||
|
|
|||
There was a problem hiding this comment.
need to ensure we do it only once? since it uses a singleton (system.CommitmentInfo). But ... technically we could have (if needed) a list of []CommitmentInfo right?
There was a problem hiding this comment.
It's definitely ideal for different subcircuits to be able to get different commitments. Maybe something like
func Commit(uid []byte, v ...frontend.Variable) (frontend.Variable, error)that could be called multiple times.
I think it's worth trying but would involve even more modifying-a-hint-after-it's-created type shenanigans. I'll create an issue and once I'm a bit more secure that my current hint hacks are okay, I'll take a stab at it.
But in the meantime I agree there should be an error if Commit is called more than once.
There was a problem hiding this comment.
Of course if the hint hacks started to get out of hand, we could open the can of worms that is giving the commitments their own solving and scheduling mechanisms.
I do remember though that you said @ThomasPiellard had an idea regarding generalizing hints. Perhaps the cleanest way is to implement that first ( "that" = an abstraction that both hints and commitments embody that takes care of scheduling and solving), then build the commitments on top of that cleanly; no hints, no hacks, no duplication of logic.
| } | ||
|
|
||
| func bsb22CommitmentComputePlaceholder(*big.Int, []*big.Int, []*big.Int) error { | ||
| return fmt.Errorf("placeholder function: to be replaced by commitment computation") |
There was a problem hiding this comment.
why is this just a placeholder? Would be nice to have a default impl, so that calling R1CS.Solve on a R1CS with commitment info actually works?
There was a problem hiding this comment.
(that is, without depending on Groth16)
There was a problem hiding this comment.
The problem is that since the hint computes the commitment, it requires the Commitment Key, created during setup. But the hint is created in compilation time, when the Commitment Key is not yet available.
The only way out of this that I can think of is to instead randomize the Commitment Key during compilation. But that would break modularity by making setup-type tasks bleed into compilation, and also bring a big code-generated curve switch-case into the compilation codebase, which as I understand currently doesn't have any.
There was a problem hiding this comment.
well, what I'm saying is that, technically, the frontend should build a constraint system, that's solvable as is, without going to the next step (proof systems).
So why not just put a hint that do a sha256 or something deterministic with the inputs, without a "key"?
There was a problem hiding this comment.
Sha256 is only possible for public variables to which the verifier has direct answer. For private variables we will need that Pedersen commitment whose basis comes from the verifying key. Unfortunately this spaghetti quality, that weakens the modular frontend/backend separation is inherent to the scheme, and actually the reason why it works (i.e. soundness depends on it.)
frontend/compiled/commitment.go
Outdated
| for _, inI := range publicCommitted { | ||
| inIBytes := inI.Bytes() | ||
| slack := fieldByteLen - len(inIBytes) | ||
| buf.Write(make([]byte, slack)) |
There was a problem hiding this comment.
in the case of many public commited values, would probably be beneficial to allocate an empty []byte of len fieldByteLen before the loop, and write slack[:slackIdx] here
There was a problem hiding this comment.
Pushed something in that spirit!
No description provided.