A GPCProofConfig which has been checked, bound, and canonicalized
by a call to gpcBindConfig or gpcProve. A bound config
should be deterministic and compatible so that reusing the same
GPCBoundConfig will always result in the same proof and verification
behavior circuit, even if new circuits are added to the family. This
is intended to allow for cases where the config doesn't need to be
transmitted separately along with every proof, but is already known
to the verifier.
In the type system, the only difference from a GPCProofConfig is that
the ciruit identifier is a required field, fixing the choice of circuit.
However, there are other properties which a GPCBoundConfig is expected to
meet after the steps used to generate it:
Checking verifies that the contents of the configuration is valid, and
should be usable to generate proofs (with appropriate inputs).
Binding fills in the circuit identifier in the config and validates
that the config fits within the circuit's parameters. Using a bound
config for future proofs ensures the same circuit is used.
Canonicalizing eliminates optional fields containing default values,
eliminates any unknown fields, and also ensures that object and entry names
iterate in sorted order. This ensures that two configs which behave the
same are also deep equal for easy comparison.
Note that these steps cannot verify anything about future inputs. In
particular the max POD size supported by an auto-selected circuit might
not be sufficient for all inputs. If you need a larger size, you can pick
your circuit explicitly using the circuitIdentifier argument.
A GPCProofConfig which has been checked, bound, and canonicalized by a call to gpcBindConfig or gpcProve. A bound config should be deterministic and compatible so that reusing the same
GPCBoundConfig
will always result in the same proof and verification behavior circuit, even if new circuits are added to the family. This is intended to allow for cases where the config doesn't need to be transmitted separately along with every proof, but is already known to the verifier.In the type system, the only difference from a GPCProofConfig is that the ciruit identifier is a required field, fixing the choice of circuit. However, there are other properties which a
GPCBoundConfig
is expected to meet after the steps used to generate it:Note that these steps cannot verify anything about future inputs. In particular the max POD size supported by an auto-selected circuit might not be sufficient for all inputs. If you need a larger size, you can pick your circuit explicitly using the circuitIdentifier argument.