Prettify sections more

book/src/SUMMARY.md

@@ -12,7 +12,7 @@
   - [Multiplying polynomials](./fundamentals/zkbook_multiplying_polynomials.md)
   - [Fast Fourier transform](./fundamentals/zkbook_fft.md)
 
-# Cryptographic tools
+# Cryptographic Tools
 
 - [Commitments](./fundamentals/zkbook_commitment.md)
 - [Polynomial commitments](./plonk/polynomial_commitments.md)
@@ -27,26 +27,20 @@
     - [Half Gate](./fundamentals/zkbook_2pc/halfgate.md)
     - [Full Description](./fundamentals/zkbook_2pc/fulldesc.md)
     - [Fixed-Key-AES Hashes](./fundamentals/zkbook_2pc/fkaes.md)
-
   - [Oblivious Transfer](./fundamentals/zkbook_2pc/ot.md)
     - [Base OT](./fundamentals/zkbook_2pc/baseot.md)
     - [OT Extension](./fundamentals/zkbook_2pc/ote.md)
-
   - [Full Protocol](./fundamentals/zkbook_2pc/2pc.md)
-
-# Proof systems
-
-- [Overview](./fundamentals/proof_systems.md)
-- [zk-SNARKs](./fundamentals/zkbook_plonk.md)
-- [Custom constraints](./fundamentals/custom_constraints.md)
+- [Proof Systems](./fundamentals/proof_systems.md)
+  - [zk-SNARKs](./fundamentals/zkbook_plonk.md)
 
 # Background on PLONK
 
 - [Overview](./plonk/overview.md)
-- [Glossary](./plonk/glossary.md)
+  - [Glossary](./plonk/glossary.md)
 - [Domain](./plonk/domain.md)
-- [Lagrange basis in multiplicative subgroups](./plonk/lagrange.md)
-- [Non-interaction with fiat-shamir](./plonk/fiat_shamir.md)
+- [Lagrange Basis in Multiplicative Subgroups](./plonk/lagrange.md)
+- [Non-Interactivity via Fiat-Shamir](./plonk/fiat_shamir.md)
 - [Plookup](./plonk/plookup.md)
 - [Maller's Optimization](./plonk/maller.md)
 - [Zero-Column Approach to Zero-Knowledge](./plonk/zkpm.md)
@@ -59,6 +53,7 @@
 - [Maller's Optimization for Kimchi](./kimchi/maller_15.md)
 - [Lookup Tables](./kimchi/lookup.md)
   - [Extended Lookup Tables](./kimchi/extended-lookup-tables.md)
+- [Custom Constraints](./kimchi/custom_constraints.md)
 - [Custom Gates](./kimchi/gates.md)
   - [Foreign Field Addition](./kimchi/foreign_field_add.md)
   - [Foreign Field Multiplication](./kimchi/foreign_field_mul.md)

book/src/fundamentals/proof_systems.md

@@ -1,31 +1,29 @@
-# Overview
+# Proof Systems Design Overview
 
 Many modern proof systems (and I think all that are in use) are constructed according to the  following recipe.
 
 1. You start out with a class of computations.
 
 2. You devise a way to *arithmetize* those computations. That is, to express your computation as a statement about polynomials.
-   
+
    More specifically, you describe what is often called an "algebraic interactive oracle proof" (AIOP) that encodes your computation. An AIOP is a protocol describing an interaction between a prover and a verifier, in which the prover sends the verifier some "polynomial oracles" (basically a black box function that given a point evaluates a polynomial at that point), the verifier sends the prover random challenges, and at the end, the verifier queries the prover's polynomials at points of its choosing and makes a decision as to whether it has been satisfied by the proof.
 
 3. An AIOP is an imagined interaction between parties. It is an abstract description of the protocol that will be "compiled" into a SNARK. There are several "non-realistic" aspects about it. One is that the prover sends the verifier black-box polynomials that the verifier can evaluate. These polynomials have degree comparable to the size of the computation being verified. If we implemented these "polynomial oracles" by having the prover really send the $O(n)$ size polynomials (say by sending all their coefficients), then we would not have a zk-SNARK at all, since the verifier would have to read this linearly sized polynomial so we would  lose succinctness, and the polynomials would not be black-box functions, so we may lose zero-knowledge.
-   
+
    Instead, when we concretely instantiate the AIOP, we have the prover send constant-sized, hiding *polynomial commitments*. Then, in the phase of the AIOP where the verifier queries the polynomials, the prover sends an *opening proof* for the polynomial commitments which the verifier can check, thus simulating the activity of evaluating the prover's polynomials on your own.
-   
+
    So this is the next step of making a SNARK: instantiating the AIOP with a polynomial commitment scheme of one's choosing. There are several choices here and these affect the properties of the SNARK you are constructing, as the SNARK will inherit efficiency and setup properties of the polynomial commitment scheme used.
 
-4. An AIOP describes an interactive protocol between the verifier and the prover. In reality, typically, we also want our proofs to be non-interactive. 
-   
+4. An AIOP describes an interactive protocol between the verifier and the prover. In reality, typically, we also want our proofs to be non-interactive.
+
    This is accomplished by what is called the [Fiat--Shamir transformation](). The basic idea is this: all that the verifier is doing is sampling random values to send to the prover. Instead, to generate a "random" value, the prover simulates the verifier by hashing its messages. The resulting hash is used as the "random" challenge.
-   
+
    At this point we have a fully non-interactive proof. Let's review our steps.
-   
+
    1. Start with a computation.
-   
+
    2. Translate the computation into a statement about polynomials and design a corresponding AIOP.
-
-   3. Compile the AIOP into an interactive protocol by having the prover send hiding polynomial commitments instead of polynomial oracles.
-
-   4. Get rid of the verifier-interaction by replacing it with a hash function. I.e., apply the Fiat--Shamir transform.
 
+   3. Compile the AIOP into an interactive protocol by having the prover send hiding polynomial commitments instead of polynomial oracles.
 
+   4. Get rid of the verifier-interaction by replacing it with a hash function. I.e., apply the Fiat--Shamir transform.

book/src/fundamentals/custom_constraints.md → book/src/kimchi/custom_constraints.md

@@ -20,7 +20,7 @@ Then, given such a circuit, PLONK lets you produce proofs for the statement
 
 ## Specifying a constraint
 
-Mathematically speaking, a constraint is a multivariate polynomial over the variables $v_{\mathsf{Curr},0}, \dots, v_{\mathsf{Curr}, W+A-1}, v_{\mathsf{Next}, 0}, \dots, v_{\mathsf{Next}, W+A-1}$. In other words, there is one variable corresponding to the value of each column in the "current row" and one variable correspond to the value of each column in the "next row".
+Mathematically speaking, a constraint is a multivariate polynomial over the variables $c_{\mathsf{Curr},i}, \dots, v_{\mathsf{Curr}, W+A-1}, v_{\mathsf{Next}, 0}, \dots, v_{\mathsf{Next}, W+A-1}$. In other words, there is one variable corresponding to the value of each column in the "current row" and one variable correspond to the value of each column in the "next row".
 
 In Rust, $v_{r, i}$ is written `E::cell(Column::Witness(i), r)`. So, for example, the variable $v_{\mathsf{Next}, 3}$ is written
 `E::cell(Column::Witness(3), CurrOrNext::Next)`.

book/src/plonk/fiat_shamir.md

@@ -1,4 +1,4 @@
-# non-interaction with fiat-shamir
+# Non-Interactivity via Fiat-Shamir
 
 So far we've talked about an interactive protocol between a prover and a verifier.
 The zero-knowledge proof was also in the honest verifier zero-knowedlge (HVZK) model, which is problematic.
@@ -15,7 +15,7 @@ This is important as our technique to transform an interactive protocol to a non
 The whole idea is to replace the verifier by a random oracle, which in practice is a hash function.
 Note that by doing this, we remove potential leaks that can happen when the verifier acts dishonestly.
 
-Initially the Fiat-Shamir transformation was only applied to sigma protocols, named after the greek letter $\Sigma$ due to its shape resembling the direction of messages (prover sends a commit to a verifier, verifier sends a challenge to a prover, prover sends the final proof to a verifier). 
+Initially the Fiat-Shamir transformation was only applied to sigma protocols, named after the greek letter $\Sigma$ due to its shape resembling the direction of messages (prover sends a commit to a verifier, verifier sends a challenge to a prover, prover sends the final proof to a verifier).
 A $Z$ would have made more sense but here we are.
 
 ## Generalization of Fiat-Shamir
@@ -27,6 +27,6 @@ This is simple: every verifier move can be replaced by a hash of the transcript
 
 While we use a hash function for that, a different construction called the [duplex construction](https://keccak.team/sponge_duplex.html) is particularly useful in such situations as they allow to continuously absorb the transcript and produce challenges, while automatically authenticating the fact that they produced a challenge.
 
-[Merlin](https://merlin.cool/) is a standardization of such a construction using the [Strobe protocol framework](https://strobe.sourceforge.io/) (a framework to make use of a duplex construction). 
-Note that the more recent [Xoodyak](https://keccak.team/xoodyak.html) (part of NIST's lightweight competition) could have been used for this as well. 
+[Merlin](https://merlin.cool/) is a standardization of such a construction using the [Strobe protocol framework](https://strobe.sourceforge.io/) (a framework to make use of a duplex construction).
+Note that the more recent [Xoodyak](https://keccak.team/xoodyak.html) (part of NIST's lightweight competition) could have been used for this as well.
 Note also that Mina uses none of these standards, instead it simply uses Poseidon (see section on poseidon).

book/src/plonk/glossary.md

@@ -1,9 +1,9 @@
 # Glossary
 
-* size = number of rows
-* columns = number of variables per rows
-* cell = a pair (row, column)
-* witness = the values assigned in all the cells
-* gate = polynomials that act on the variables in a row
-* selector vector = a vector of values 1 or 0 (not true for constant vector I think) that toggles gates and variables in a row
-* gadget = a series of contiguous rows with some specific gates set (via selector vectors)
+* Size: number of rows
+* Columns: number of variables per rows
+* Cell: a pair (row, column)
+* Witness: the values assigned in all the cells
+* Gate: polynomials that act on the variables in a row
+* Selector vector: a vector of values 1 or 0 (not true for constant vector I think) that toggles gates and variables in a row
+* Gadget: a series of contiguous rows with some specific gates set (via selector vectors)