Merge pull request #1344 from o1-labs/volhovm/mina14442-move-to-master

Book revamp/moving RCS: rebase to master

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,55 +27,47 @@
     - [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)
+- [Maller's Optimization](./plonk/maller.md)
+- [Zero-Column Approach to Zero-Knowledge](./plonk/zkpm.md)
 
 # Kimchi
 
 - [Overview](./kimchi/overview.md)
-  - [Arguments](./kimchi/arguments.md)
-    - [Custom gates](./kimchi/gates.md)
-    - [Permutation](./kimchi/permut.md)
-    - [Lookup](./kimchi/lookup.md)
+- [Arguments](./kimchi/arguments.md)
+- [Final Check](./kimchi/final_check.md)
+- [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)
+  - [Keccak](./kimchi/keccak.md)
+
 
 # Pickles & Inductive Proof Systems
 
 - [Overview](./fundamentals/zkbook_ips.md)
 - [Accumulation](./pickles/accumulation.md)
 - [Deferred Computation](./pickles/deferred.md)
-- [Passthough & Me-Only](./pickles/passthrough.md)
 
-# RFCs
 
-- [RFC 0: Alternative zero-knowledge](./plonk/zkpm.md)
-- [RFC 1: Final check](./plonk/final_check.md)
-- [RFC 2: Maller's optimization for kimchi](./plonk/maller_15.md)
-- [RFC 3: Plookup integration in kimchi](./rfcs/3-lookup.md)
-- [RFC 4: Extended lookup tables](./rfcs/extended-lookup-tables.md)
-- [RFC 5: Foreign Field Addition](./rfcs/foreign_field_add.md)
-- [RFC 6: Keccak](./rfcs/keccak.md)
-
-# Specifications
+# Technical Specifications
 
 - [Poseidon hash](./specs/poseidon.md)
 - [Polynomial commitment](./specs/poly-commitment.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/rfcs/extended-lookup-tables.md → book/src/kimchi/extended-lookup-tables.md

@@ -1,6 +1,6 @@
-# RFC: Extended lookup tables
+# Extended lookup tables
 
-This RFC proposes an extension to our use of lookup tables using the PLOOKUP
+This (old) RFC proposes an extension to our use of lookup tables using the PLOOKUP
 multiset inclusion argument, so that values within lookup tables can be chosen
 after the constraint system for a circuit has been fixed.