Merge pull request 0xPolygon#41 from 0xPolygon/nadim/zkEVM-fix-concepts-structure

zkEVM: fix structure for concepts docs

Author: EmpieichO

docs/zkEVM/architecture/zkprover/intro-stark-recursion.md

@@ -17,7 +17,7 @@ The process that leads to achieving such a State Machine-based system takes a fe
 
 These Polynomial Identities are equations that can be easily tested in order to verify the Prover's claims.
 
-A **Commitment Scheme** is required for facilitating the proving and verification. Henceforth, in the zkProver context, a proof/verification scheme called **PIL-STARK** is used. Check out the documentation [here](../../concepts/commitment-scheme.md) for the Polygon zkEVM's commitment scheme setting.
+A **Commitment Scheme** is required for facilitating the proving and verification. Henceforth, in the zkProver context, a proof/verification scheme called **PIL-STARK** is used. Check out the documentation [here](../../concepts/mfibonacci/commitment-scheme.md) for the Polygon zkEVM's commitment scheme setting.
 
 ## Overall Process
 

docs/zkEVM/architecture/zkprover/intro-storage-sm.md

@@ -18,7 +18,7 @@ The Main SM's instructions, or Storage Actions, are parsed to the Storage SM Exe
 
 The hardware part uses another novel language, called **Polynomial Identity Language** (PIL), which is also developed by the team and especially designed for the zkProver, because almost all state machines express computations in terms of polynomials. State transitions in state machines must satisfy computation-specific polynomial identities.
 
-In order for the Storage SM to carry out Storage Actions, its Executor generates committed and constant polynomials, which are then checked against polynomial identities to prove that computations were correctly executed. See the [Design Approach](../../concepts/mfibonacci.md) section for how this achieved.
+In order for the Storage SM to carry out Storage Actions, its Executor generates committed and constant polynomials, which are then checked against polynomial identities to prove that computations were correctly executed. See the [Design Approach](../../concepts/mfibonacci/mfibonacci.md) section for how this achieved.
 
 ## zkProver's storage
 

docs/zkEVM/architecture/zkprover/proof-generation-phase.md

@@ -2,7 +2,7 @@ This section explains the proof generation phase for all proofs; the zkEVM STARK
 
 ## Proof of the zkEVM STARK
 
-The execution trace has up to this point been built, together with a PIL file describing the ROM of the zkEVM. Given these two, a STARK proof which attests to the correct execution of the zkEVM, can be generated using the PIL-STARK tooling explained [here](../../concepts/pil-stark.md).
+The execution trace has up to this point been built, together with a PIL file describing the ROM of the zkEVM. Given these two, a STARK proof which attests to the correct execution of the zkEVM, can be generated using the PIL-STARK tooling explained [here](../../concepts/mfibonacci/pil-stark.md).
 
 In this step, a blowup factor of 2 is used, so the proof becomes quite big due to a huge amount of polynomials.
 

docs/zkEVM/architecture/zkprover/proving-tools.md

@@ -10,7 +10,7 @@ PIL-STARK proof/verification consists of three components; Setup, Prover, and Ve
 
 - The Verifier receives the **STARK** proof and public values from the Prover, as well as the `starkInfo` and `constRoot` from the Setup phase. The Verifier's output is either an `Accept` if the proof is accepted, or a `Reject` if the proof is rejected.
 
-The full details of the PIL-STARK process are given [here](../../concepts/pil-stark.md), while the following diagram summarizes entire PIL-STARK process.
+The full details of the PIL-STARK process are given [here](../../concepts/mfibonacci/pil-stark.md), while the following diagram summarizes entire PIL-STARK process.
 
 ![PIL-STARK Process](../../../img/zkEVM/01prf-rec-pil-stark.png)
 

docs/zkEVM/concepts/ending-program.md …/generic-state-machine/ending-program.mddocs/zkEVM/concepts/ending-program.md renamed to docs/zkEVM/concepts/generic-state-machine/ending-program.md docs/zkEVM/concepts/ending-program.md renamed to docs/zkEVM/concepts/generic-state-machine/ending-program.md

@@ -30,7 +30,7 @@ $$
 
 The figure below depicts the linear combinations of our state machine as an algebraic processor of sorts.
 
-![The Generic State Machine as an Algebraic Processor](../../img/zkEVM/gen4-sm-alg-processor.png)
+![The Generic State Machine as an Algebraic Processor](../../../img/zkEVM/gen4-sm-alg-processor.png)
 
 The vertical gray box (with the "+" sign) in the above figure denotes addition. It expresses forming linear combinations of some of the columns; $\texttt{FREE}$, $\texttt{A}$, $\texttt{B}$, or $\texttt{CONST}$. Each is either included or excluded from the linear combination depending on whether their corresponding selectors have the value $\mathtt{1}$ or $\mathtt{0}$. An extra register denoted by $\texttt{op}$ acts as a carrier of intermediate of the computation being executed and waiting to be placed in the correct output register (on the right in above figure), depending on the values of $\texttt{setA}$ and $\texttt{setB}$.
 
@@ -142,7 +142,7 @@ Also, **the free inputs may come in the form of another JSON file**, let's name
 
 See below diagram for a concise description of what the Executor does.
 
-![Figure 5: SM Executor in a broader context](../../img/zkEVM/gen5-sm-exec-broader-contxt.png)
+![Figure 5: SM Executor in a broader context](../../../img/zkEVM/gen5-sm-exec-broader-contxt.png)
 
 Although the execution trace is composed of the evaluations of the committed polynomials and the evaluations of the constant polynomials, the two evaluations do not happen simultaneously.
 
@@ -219,4 +219,4 @@ In the big scheme of things, these are Lagrange polynomials emanating from inter
 
 The PIL description of the SM Executor, reading instructions from the zkASM program with four instructions, is depicted in the figure provided below.
 
-![The PIL description for the 4-instruction program](../../img/zkEVM/gen6-pil-4instrct-prog.png)
+![The PIL description for the 4-instruction program](../../../img/zkEVM/gen6-pil-4instrct-prog.png)

docs/zkEVM/concepts/exec-trace-correct.md …eric-state-machine/exec-trace-correct.mddocs/zkEVM/concepts/exec-trace-correct.md renamed to docs/zkEVM/concepts/generic-state-machine/exec-trace-correct.md docs/zkEVM/concepts/exec-trace-correct.md renamed to docs/zkEVM/concepts/generic-state-machine/exec-trace-correct.md

@@ -6,7 +6,7 @@ The idea here is to create a state machine that behaves like a processor of sort
 
 See Figure below, for such a state machine with registries $\texttt{A}$ and $\texttt{B}$, and a state $\big(\texttt{A}^{\texttt{i}},\texttt{B}^{\texttt{i}}\big)$ that changes to another state $\big(\texttt{A}^{\texttt{i+2}},\texttt{B}^{\texttt{i+2}}\big)$ in accordance with two instructions, $\texttt{Instruction}_{\texttt{i}}$ and $\texttt{Instruction}_{\texttt{i+1}}$.
 
-![Figure 1: A typical generic state machine](../../img/zkEVM/gen1-typical-gen-sm.png)
+![Figure 1: A typical generic state machine](../../../img/zkEVM/gen1-typical-gen-sm.png)
 
 The aim with this document is to explain how the machinery used in the mFibonacci SM; to execute computations, produce proofs of correctness of execution, and verify these proofs; can extend to a generic state machine.
 
@@ -20,11 +20,11 @@ Think of our state machine as being composed of two parts; the part that has to
 
 As seen with the mFibonacci SM, the SM executor takes certain inputs together with the description of the SM, in order to produce the execution trace specifically corresponding to these inputs.
 
-![Figure 2: mFibonacci State Machine producing input-specific execution trace](../../img/zkEVM/gen2-mfib-exec-w-inputs.png)
+![Figure 2: mFibonacci State Machine producing input-specific execution trace](../../../img/zkEVM/gen2-mfib-exec-w-inputs.png)
 
 The main difference, in the Generic State Machine case, is the inclusion of a program which stipulates computations to be carried out by the SM executor. These computations could range from a simple addition of two registry values, or moving the value in registry $\texttt{A}$ to registry $\texttt{B}$, to computing some linear combination of several registry values.
 
-![Figure 3: A Generic State Machine producing input- and program-specific execution trace ](../../img/zkEVM/gen3-gen-sm-w-input-instrctn.png)
+![Figure 3: A Generic State Machine producing input- and program-specific execution trace ](../../../img/zkEVM/gen3-gen-sm-w-input-instrctn.png)
 
 So then, instead of programming the SM executor ourselves with a specific set of instructions as we did with the mFibonacci SM, the executor of a Generic SM is programmed to read arbitrary instructions encapsulated in some program (depending on the capacity of the SM or the SM's context of application). As mentioned above, each of these programs is initially written, not in a language like Javascript, but in the zkASM language.
 

docs/zkEVM/concepts/intro-generic-sm.md …eneric-state-machine/intro-generic-sm.mddocs/zkEVM/concepts/intro-generic-sm.md renamed to docs/zkEVM/concepts/generic-state-machine/intro-generic-sm.md docs/zkEVM/concepts/intro-generic-sm.md renamed to docs/zkEVM/concepts/generic-state-machine/intro-generic-sm.md

@@ -171,12 +171,12 @@ $$
 
 Recall that the ROM's polynomial counterpart to the $\texttt{zkPC}$ is the $\texttt{line}$.
 
-![Plookup in the PIL Code for the Generic State Machine](../../img/zkEVM/plookup-generic-sm-pil.png)
+![Plookup in the PIL Code for the Generic State Machine](../../../img/zkEVM/plookup-generic-sm-pil.png)
 
 ### Role in zkEVM
 
 Plookup instructions appear in the PIL codes of state machines in the zkEVM. Plookup is used by some state machines to ensure that certain output values are included in a given lookup table. Plookup is useful when set inclusion must be verified.
 
 The diagram below depicts the extensive role that Plookup plays in the zkProver's secondary state machines.
 
-![Plookup and the zkProver State Machines](../../img/zkEVM/plook-ops-mainSM.png)
+![Plookup and the zkProver State Machines](../../../img/zkEVM/plook-ops-mainSM.png)

docs/zkEVM/concepts/plookup.md …oncepts/generic-state-machine/plookup.mddocs/zkEVM/concepts/plookup.md renamed to docs/zkEVM/concepts/generic-state-machine/plookup.md docs/zkEVM/concepts/plookup.md renamed to docs/zkEVM/concepts/generic-state-machine/plookup.md

@@ -6,7 +6,7 @@ We denote it by $\texttt{zkPC}$ because it is verified in a zero-knowledge manne
 
 The $\texttt{zkPC}$ is therefore a new column of the execution trace and it contains, at each clock, the line in the zkASM program of the instruction being executed.
 
-![Figure 7: A state machine with a Program Counter](../../img/zkEVM/gen7-state-machine-w-zkpc.png)
+![Figure 7: A state machine with a Program Counter](../../../img/zkEVM/gen7-state-machine-w-zkpc.png)
 
 In addition to the $\texttt{JMPZ(addr)}$, an unconditional jump instruction $\texttt{JMP(addr)}$ is allowed in the zkASM program.
 
@@ -107,7 +107,7 @@ So, we query the executor for when the execution trace is at its last but one ro
 
 The assembly program uses labels instead of explicit line numbers, hence conforming to how assembly programs are typically written. Labels are convenient because with them, the assembly compiler can take care of computing actual line numbers. For instance, as in Figure 8 below; $\mathtt{start}$ is line $\mathtt{0}$ and $\mathtt{finalWait}$ is line $\mathtt{5}$.
 
-![Figure 8: Ending a Program with a loop](../../img/zkEVM/gen8-end-prog-w-loop.png)
+![Figure 8: Ending a Program with a loop](../../../img/zkEVM/gen8-end-prog-w-loop.png)
 
 ## Commentary on the execution trace