You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Prover functions should take a function that returns a field as witness, i.e., all provers should have the following type:
typewitness = unit -> fieldtypeprover =
Pickles.Side_loaded.Verification_key.toption -> (* left side loaded vk *)Pickles.Side_loaded.Proof.toption -> (* left recursively verified proof *)Pickles.Side_loaded.Verification_key.toption -> (* right side loaded vk *)Pickles.Side_loaded.Proof.toption -> (* right recursively verified proof *)witness ->
Pickles.Side_loaded.Proof.t
The point is that all witness handling should be done outside the code defining the circuits, to prevent polluting the mind with thoughts about code that doesn't affect the security of the protocol.
Right now we've mixed the two to an uncomfortable degree. Really we we're supposed to use handlers/requests/responses,
but even that is suboptimal, since you end up defining requests for the sake of making proving easier.
In some sense this is the same as what is proposed above but we allow only one kind of request of the following form
type_ Request.t += Get_witness : fieldRequest.t
Of course, you can make a wrapping library for the circuit that defines a more convenient way of passing in the witnesses.
That helper library would have many of the definitions we would have moved out of the circuits by doing this change.
In the circuits we would use a new function in place of exists:
valnew_exists : ('var, 't) Typ.t -> 'varChecked.t
To assist with figuring out the order of the witnesses, new_exists could get the line number and file name of each place it's used and print it.
The whole interface of the zeko_circuits library should be something like:
Compile_simple.compile should also not provide the circuit with an 'input probably and instead make the circuit
rely on the above-mentioned new_exists exclusively.
Of course in practice we'd replace all of the Pickles types above with our own,
such that we can provide a dummy interface that doesn't use crypto.
The text was updated successfully, but these errors were encountered:
We shouldn't expose the prover functions. We should instead expose the circuits, without any types, and let the user code compile and do everything else.
Recursive proofs like-wise would have to be handled by the user. However, we would have a way of grouping rules into a single "ruleset", such that when compiling circuits, recursive proofs aren't used for the wrong circuit.
Also, exists should take a string, and when providing the witness for the circuit,
it should be such that you should provide a list of fields, along with the "name" for it.
It will be checked that the length and name matches.
Thus, the prover will have no more information, and must still provide everything in the correct order,
but the debuggability is a bit better.
Prover functions should take a function that returns a field as witness, i.e., all provers should have the following type:
The point is that all witness handling should be done outside the code defining the circuits, to prevent polluting the mind with thoughts about code that doesn't affect the security of the protocol.
Right now we've mixed the two to an uncomfortable degree. Really we we're supposed to use handlers/requests/responses,
but even that is suboptimal, since you end up defining requests for the sake of making proving easier.
In some sense this is the same as what is proposed above but we allow only one kind of request of the following form
Of course, you can make a wrapping library for the circuit that defines a more convenient way of passing in the witnesses.
That helper library would have many of the definitions we would have moved out of the circuits by doing this change.
In the circuits we would use a new function in place of
exists
:To assist with figuring out the order of the witnesses,
new_exists
could get the line number and file name of each place it's used and print it.The whole interface of the
zeko_circuits
library should be something like:Compile_simple.compile
should also not provide the circuit with an'input
probably and instead make the circuitrely on the above-mentioned
new_exists
exclusively.Of course in practice we'd replace all of the
Pickles
types above with our own,such that we can provide a dummy interface that doesn't use crypto.
The text was updated successfully, but these errors were encountered: