With this approach, we don't need `Target::PublicInput`; any routable `Target` can be marked as a public input via `register_public_input`. The circuit itself hashes these targets, and routes the hash output to the first four wires of a `PublicInputGate`, which is placed at an arbitrary location in the circuit.
All gates have direct access to the purported hash of public inputs. We could think of them as accessing `PI_hash_i(x)` (as in Plonk), but these are now (four) constant functions, so they effectively have direct access to the hash itself.
`PublicInputGate` checks that its first four wires match this purported public input hash. The other gates ignore the hash.
Resolves#64.
* Tree of scopes
This is an extension of the context concept.
Earlier I was planning to store a simple stack of contexts, but I ended up storing the whole history, in a tree structure. This gives us more control over the output, i.e. we can print the gate count of a parent scope before those of its child scopes, which seems more user-friendly.
Sample gate count output:
[2021-07-19T18:09:24Z INFO plonky2::circuit_builder] 27829 gates to root
[2021-07-19T18:09:24Z INFO plonky2::circuit_builder] | 2373 gates to evaluate the vanishing polynomial at our challenge point, zeta.
[2021-07-19T18:09:24Z INFO plonky2::circuit_builder] | | 1284 gates to evaluate gate constraints
[2021-07-19T18:09:24Z INFO plonky2::circuit_builder] | 25312 gates to verify FRI proof
[2021-07-19T18:09:24Z INFO plonky2::circuit_builder] | | 650 gates to verify 0'th FRI query
[2021-07-19T18:09:24Z INFO plonky2::circuit_builder] | | | 96 gates to check FRI initial proof
[2021-07-19T18:09:24Z INFO plonky2::circuit_builder] | | | 65 gates to compute x from its index
[2021-07-19T18:09:24Z INFO plonky2::circuit_builder] | | | 233 gates to combine initial oracles
...
Sample copy constraint failure:
Error: Copy constraint 'root > verify FRI proof > verify 0'th FRI query > check FRI initial proof > verify 0'th initial Merkle proof > check Merkle root: 0-th hash element' between wire 12 of gate #2550 [...] and wire 0 of gate #0 [...] is not satisfied. Got values of 6861386743364621393 and 0 respectively.
* No min
* info -> debug
* Move to its own file
* Make ZK optional
* Remove rate from FriConfig
Seems redundant, and we've had some tests break due to the two fields not matching.
* zero_knowledge: false in bench
- Configure FRI with a list of arities that's more appropriate for a 2^14 instance. The previous config resulted in a huge final polynomial.
- Log the blinding factors, and other logging tweaks.
As in plonky1. The semantics of virtual targets in plonky1 were rather weird, but I think it's somewhat better here, since we already separate `generate_copy` and `assert_equal` methods. Users now make more of an explicit choice -- they can use a `VirtualTarget` for the witness generation only using `generate_copy`, or they can involve it in copy constraints.
- `self.gates` -> `self.gate_instances`
- Some tests were using a single binary FRI reduction, which doesn't provide enough succinctness for our blinding scheme to work. This caused `blinding_counts` to continue until it overflowed.
