update fixed absolute link issue

Author: EmpieichO

docs/img/zkvm/04l2-batch-chain-acc-hash.png

@@ -66,9 +66,9 @@ A smart contract verifies the validity proofs to ensure that each transition is
 
 To carry out these procedures, zkEVM employs two sorts of participants: **Sequencers** and **Aggregators**. Under this two-layer model: 
 ​
-- [**Sequencers**](/zkevm/zknode/overview.md#sequencers) → propose transaction batches to the network, i.e. they roll-up the transaction requests in batches and add them to the Consensus Contract.
+- **Sequencers** → propose transaction batches to the network, i.e. they roll-up the transaction requests in batches and add them to the Consensus Contract.
 ​
-- [**Aggregators**](/zkevm/zknode/overview.md#aggregators) → check the validity of the transaction batches and provide validity proofs. Any permissionless Aggregator can submit the proof to demonstrate the correctness of the state transition computation.
+- **Aggregators** → check the validity of the transaction batches and provide validity proofs. Any permissionless Aggregator can submit the proof to demonstrate the correctness of the state transition computation.
 
 The  Smart Contract, therefore, makes two calls: one to receive batches from Sequencers, and another to Aggregators, requesting batches to be validated.
 ​
@@ -93,14 +93,14 @@ An Aggregator receives all the transaction information from the Sequencer and se
 - For a given batch or batches, an Aggregator that submits a validity proof first earns the MATIC fee (which is being paid by the Sequencer(s) of the batch(es)).
 - The Aggregators need to indicate their intention to validate transactions. After that, they compete to produce validity proofs based on their own strategy.
 
-## [zkNode](/zkevm/zknode/overview.md)
+## zkNode
 
 zkNode is the software needed to run any zkEVM node. It is a client that the network requires to implement the Synchronization and govern the roles of the participants (Sequencers or Aggregators). Polygon zkEVM participants will choose how they participate:
 
 - As a node to know the state of the network, or
 - As a participant in the process of batch production in any of the two roles: **Sequencer** or **Aggregator**
 
-The zkNode architecture is modular in nature. You can dig deeper into zkNode and its components [here](/zkevm/zknode/overview.md).
+The zkNode architecture is modular in nature. You can dig deeper into zkNode and its components [here](../zknode/zknode-overview.md).
 
 ### Incentivization structure
 
@@ -118,17 +118,17 @@ The two permissionless participants of the zkEVM network are: **Sequencers** and
    - Static Cost: L1 call cost + Server cost (to build a proof)
    - Profitable if: `MATIC fee` > `L1 call` + `Server cost`
 
-## [zkProver](/zkevm/zkProver/overview.md)
+## zkProver
 
 zkEVM employs advanced zero-knowledge technology to create validity proofs. It uses a **zero-knowledge prover (zkProver)**, which is intended to run on any server and is being engineered to be compatible with most consumer hardware. Every **Aggregator** will use this zkProver to validate batches and provide Validity Proofs.
 
 It consists of a **Main State Machine Executor**, a collection of **secondary State Machines** (each with its own executor), a **STARK-proof builder**, and a **SNARK-proof builder**.
 
 ![Skeletal Overview of zkProver](../../img/zkvm/fig4-zkProv-arch.png)
 
-In a nutshell, **the zkEVM expresses state changes in a polynomial form**. As a result, the constraints that each proposed batch must meet are polynomial constraints or polynomial identities. To put it another way, all valid batches must satisfy specific polynomial constraints. Check out the detailed architecture of zkProver [here](/zkevm/zkProver/overview.md).
+In a nutshell, **the zkEVM expresses state changes in a polynomial form**. As a result, the constraints that each proposed batch must meet are polynomial constraints or polynomial identities. To put it another way, all valid batches must satisfy specific polynomial constraints. Check out the detailed architecture of zkProver [here](../zkprover/zkprover-overview.md).
 
-## [zkEVM bridge](/zkevm/protocol/zkevm-bridge.md)
+## zkEVM bridge
 
 The **zkEVM bridge** is a Smart Contract that lets users transfer their assets between two layers, LX and LY. The L1-L2 in zkEVM is a decentralized bridge for secure deposits and withdrawal of assets. It is a combination of two smart contracts, one deployed on one chain and the second on the other.
 
@@ -142,7 +142,7 @@ Verifier is a Smart Contract which is able to verify any ZK-SNARK cryptographic
 
 The Verifier contract is currently deployed on the [Ethereum Mainnet](https://etherscan.io/address/0x4F9A0e7FD2Bf6067db6994CF12E4495Df938E6e9) and [Goerli Testnet](https://goerli.etherscan.io/address/0x8EdA1d8c254a77a57A6A7A1C0262e9A44A7C6D6d).
 
-## [Transaction life cycle](/zkevm/protocol/l2-transaction-cycle-intro.md)
+## Transaction life cycle
 
 Before getting into a transaction flow in L2, users need some funds to perform any L2 transaction. In order to do so, users need to transfer some ether from L1 to L2 through the zkEVM Bridge dApp.
 
@@ -159,7 +159,7 @@ Before getting into a transaction flow in L2, users need some funds to perform a
    - Aggregator will take pending transactions to be verified and build a Proof in order to achieve finality on L1
    - Once the Proof is validated, user's transactions will attain L1 finality (important for withdrawals). This is called the **consolidated state**.
 
-The above process is a summarized version of how transactions are processed in zkEVM. We recommend you to take a look at the complete [transaction life cycle](/zkevm/protocol/l2-transaction-cycle-intro.md) document.
+The above process is a summarized version of how transactions are processed in zkEVM. We recommend you to take a look at the complete [transaction life cycle](../protocol/l2-transaction-cycle-intro.md) document.
 
 ## Design characteristics
 

docs/img/zkvm/fig2-mkl-tree-gen.png

@@ -26,7 +26,7 @@ But if the given **key leads to an existing leaf**, the verifier has to prove th
 
 Suppose the verifier needs to prove that the keys, $K_{\mathbf{x}} = 11010101$ and $K_{\mathbf{z}} = 10101010$ are not set in the SMT depicted in the figure below. 
 
-![Key Not Set Example](/img/zkvm/fig10-key-not-set-eg.png)
+![Key Not Set Example](../../img/zkvm/fig10-key-not-set-eg.png)
 
 #### Case 1: When the key leads to a zero-node
 
@@ -120,7 +120,7 @@ The verifier is provided with the following data;
 
 Consider the SMT given in the below figure.
 
-![Value UPDATE Example](/img/zkvm/fig11-val-update-eg.png)
+![Value UPDATE Example](../../img/zkvm/fig11-val-update-eg.png)
 
 The required **Step 2** of the **UPDATE** operation involves: 
 
@@ -180,7 +180,7 @@ At this stage the verifier checks if this is indeed a zero node;
 2. Then it computes $\mathbf{{\tilde{root}}_{ab0c}} = \mathbf{H_{noleaf}} \big( \mathbf{{\tilde{B}}_{ab0}} \| \mathbf{L_{c}} \big)$. 
 3. And, checks if $\mathbf{{\tilde{root}}_{ab0c}}$ equals $\mathbf{{root}_{ab0c}}$. 
 
-![CREATE Operation - Zero Node](/img/zkvm/fig12-crt-zero-node.png)
+![CREATE Operation - Zero Node](../../img/zkvm/fig12-crt-zero-node.png)
 
 Once the zero-value is checked, the verifier now creates a non-zero leaf with the key-value pair $\big( \mathbf{K_{new}} , \text{HV}_{\mathbf{new}}\big)$.
 
@@ -231,7 +231,7 @@ Suppose a leaf needs to be created to store a new key-value pair $\big({K_{\math
 
 Consider the SMT shown in the below figure.
 
-![CREATE Operation - Non-zero Leaf Node](/img/zkvm/fig13-a-crt-nzleaf-ext.png)
+![CREATE Operation - Non-zero Leaf Node](../../img/zkvm/fig13-a-crt-nzleaf-ext.png)
 
 In this example, navigation using the least-significant key-bits, $\text{kb}_\mathbf{0} = 0$ and $\text{kb}_\mathbf{1} = 1$, leads to an existing leaf $\mathbf{L_{\mathbf{c}}}$. And the key-value pair $(V_\mathbf{\mathbf{c}}, \text{HV}_\mathbf{\mathbf{c}})$ stored at $\mathbf{L_{\mathbf{c}}}$ has the key $K_{\mathbf{c}} = 11010010$.
 
@@ -271,7 +271,7 @@ Suppose a leaf must be created to store a new key-value pair $\big(K_{\mathbf{ne
 
 Consider the SMT shown in the below figure.
 
-![CREATE Operation - Three Branch Extensions](/img/zkvm/fig13-b-crt-nzleaf-xt.png)
+![CREATE Operation - Three Branch Extensions](../../img/zkvm/fig13-b-crt-nzleaf-xt.png)
 
 Navigating the tree by using the least-significant key-bits, $\text{kb}_\mathbf{0} = 0$ and $\text{kb}_\mathbf{1} = 1$, leads to an existing leaf $\mathbf{L_{\mathbf{c}}}$. In this example, suppose the key-value pair $(K_{\mathbf{c}}, \text{HV}_\mathbf{\mathbf{c}})$ stored at $\mathbf{L_{\mathbf{c}}}$ has the key $K_{\mathbf{c}} = 11100110$.
 
@@ -348,7 +348,7 @@ Suppose the data provided includes; the Remaining Key $\tilde{\text{RK}}_{\mathb
 
 With reference to the figure below, navigation leads to the leaf $\mathbf{L_b}$.
 
-![DELETE Operation - Non-Zero Sibling](/img/zkvm/fig14-a-dlt-nz-sib.png)
+![DELETE Operation - Non-Zero Sibling](../../img/zkvm/fig14-a-dlt-nz-sib.png)
 
 Next, perform a Merkle proof to check if the hashed value $\text{HV}_\mathbf{b}$ at $\mathbf{L_b}$ is included in the given root;
 
@@ -375,7 +375,7 @@ Suppose the data provided includes; the Remaining Key $\tilde{\text{RK}}_{\mathb
 
 With reference to the figure below, navigation leads to the leaf $\mathbf{L_c}$.
 
-![Figure 14(/img/zkvm/fig14-b-dlt-z-sib.png): DELETE Operation - Zero Sibling](/img/zkvm/fig14-b-dlt-z-sib.png)
+![Figure 14(../../img/zkvm/fig14-b-dlt-z-sib.png): DELETE Operation - Zero Sibling](../../img/zkvm/fig14-b-dlt-z-sib.png)
 
 The **READ** step in this case is similar to what is seen in the above case. 
 

docs/img/zkvm/gen2-mfib-exec-w-inputs.png

@@ -1,11 +1,11 @@
 
 !!!info
-    In this document, we describe the CIRCOM component of the zkProver. It is one of the four main components of the zkProver, as outlined [here](/zkevm/zkProver/overview.md). These principal components are; the Executor or Main SM, STARK Recursion, CIRCOM, and Rapid SNARK.
+    In this document, we describe the CIRCOM component of the zkProver. It is one of the four main components of the zkProver, as outlined [here](../zkprover/zkprover-overview.md). These principal components are; the Executor or Main SM, STARK Recursion, CIRCOM, and Rapid SNARK.
 
     You may refer to the original [CIRCOM research paper](https://www.techrxiv.org/articles/preprint/CIRCOM_A_Robust_and_Scalable_Language_for_Building_Complex_Zero-Knowledge_Circuits/19374986/1) for more details.
 
 
-As seen in the [zkProver Overview](/zkevm/zkProver/overview.md) document, the output of the STARK Recursion component is STARK proof.
+As seen in the [zkProver Overview](../zkprover/zkprover-overview.md) document, the output of the STARK Recursion component is a STARK proof.
 
 The next step in the zkProver's process of providing validity proof is to **produce the witness similar to the output of the STARK Recursion**.
 
@@ -15,7 +15,7 @@ Although the zkProver is designed as a state machine emulating the EVM, in order
 
 The witness is in turn taken as input to the Rapid SNARK, which is used to generate a SNARK proof published as the validity proof.
 
-![CIRCOM's input and output](/img/zkvm/01circom-witness-zkprover.png)
+![CIRCOM's input and output](../../img/zkvm/01circom-witness-zkprover.png)
 
 In fact, CIRCOM takes a STARK proof as input and produces its corresponding Arithmetic circuit, expressed as the equivalent set of equations called Rank-1 Constraint System (R1CS).
 
@@ -47,7 +47,7 @@ CIRCOM was developed for the very purpose of scaling complex Arithmetic circuits
 
 CIRCOM is a Domain-Specific Language (DSL) used to define Arithmetic circuits, and it has an associated compiler of Arithmetic circuits to their respective Rank-1 Constraint System (or R1CS).
 
-![CIRCOM Overall Context](/img/zkvm/02circom-overall-context.png)
+![CIRCOM Overall Context](../../img/zkvm/02circom-overall-context.png)
 
 ### CIRCOM As A DSL
 
@@ -80,7 +80,7 @@ The CIRCOM language has its own peculiarities. The focus in this subsection is o
 
 Consider as an example, the `Multiplier` circuit with input signals $\texttt{a}$ and $\texttt{b}$, and an output signal $\texttt{c}$ satisfying the constraint $\texttt{a} \times \texttt{b} \texttt{ - c = 0}$.
 
-![A simple Multiplier Arithmetic circuit](/img/zkvm/03circom-simple-arith-circuit.png)
+![A simple Multiplier Arithmetic circuit](../../img/zkvm/03circom-simple-arith-circuit.png)
 
 The figure above depicts a simple `Multiplier` Arithmetic circuit with input wires labeled $\texttt{a}$ and $\texttt{b}$ and an output wire labeled $\texttt{c}$ such that $\texttt{a} \times \texttt{b\ = } \texttt{c}$. The wires are referred to as signals. The constraint related to this Multiplier circuit is: