Adding zero-knowledge

[Al-Kindi-0]

Addresses #9 .

Based on the recent work. The most noticeable features are:

1. We take into account the degree of the extension field when randomizing.
2. We add randomization of the quotient segment polynomials.
3. We add a random code-word to the DEEP composition polynomial as done in the Aurora paper.
4. In addition to salting the vector commitment, we also salt the Fiat-Shamir as is done in the specification of the BCS transform.

This is ready for full review but I am putting in draft mode as the current solution for generating randomness for zero-knowledge is not clean. More specifically:

1. For salted Merkle trees, should we also use a PRNG?
2. For the PRNG used in the prover, I am not happy with the way it is currently implemented, I am thinking that it should be sort of optional to have it but I couldn't come up with a good way to do that.

There are also some unnecessary allocations but I can remove those once we agree on the general structure.

[Al-Kindi-0]

The handling of the PRNG for zk has been improved and hence I believe that the PR is in a good enough shape for an initial review.

[AVecsi]

What is the status of this PR? Is zero-knowledge implemented? To run an example from the examples folder in zk mode,i added a seed and switched the zk boolean to true, however that just broke the transition degree acutal==expected evaluation.
Am I missing something?

If I switch back the expected degree computation to the old version, self.base * (trace_length - 1) (which I guess I shouldn't) this evaluation passes, but the domain size fails.

The trace length in /air/src/air/mod.rs is half the size of the trance length in /prover/src/domain.rs, if nothing is modified.

[Al-Kindi-0]

@AVecsi , the core non-optimized functionality is implemented though the UX is not the best to be honest.
I pushed a small commit (the last one) which should illustrate how to enable ZK.

[AVecsi]

@Al-Kindi-0 Thanks for the example. I tested the zk implementation a bit and it mostly worked fine. However, I noticed one case where the behavior of the library differs from the non-zk version.

Currently, the implementation simply oversizes everything, including the periodic values, which are zeroed out on the oversized part so that constraint evaluation does not fail with randomized trace witnesses. This works fine when only a single periodic value is used in a constraint. However, if two periodic values (or more) are multiplied during evaluation, the actual constraint evaluation degree becomes lower than expected (for example, reduced by the degree of the divisor when two periodic values are multiplied). As a result, the proof cannot be verified correctly.

[AVecsi]

Also, I am not sure why the change in the function called min_blowup_factor was necessary in https://github.com/facebook/winterfell/blob/cfed59c8d8df2e60f85578e4bbae31d0b0643bc0/air/src/air/transition/degree.rs

In some cases the new implementation caused errors for me as the output set the ce_blowup_factor incorrectly. Reverting back to the original implementation fixed this issue.