Merge branch 'main' of https://github.com/0xPolygon/polygon-docs into km/tools_section_2

Author: kmurphypolygon

docs/zkEVM/bridge-to-zkevm.md

@@ -4,12 +4,11 @@
 
 Users can deposit assets from Ethereum and transact off-chain on Polygon zkEVM. For moving assets across chains (L1 ↔ zkEVM), you will need to use the zkEVM Bridge. The bridge interface is available for both Mainnet Beta and Testnet in the [Polygon Wallet Suite](https://wallet.polygon.technology/zkEVM/bridge).
 
-<!-- Also, bridging can be done with the help of [MaticJS](/docs/develop/ethereum-polygon/matic-js/zkevm/initialize-zkevm/) SDK. -->
 
 The next video is a guide on how to bridge tokens from L1 to the zkEVM Testnet. The same video applies to the zkEVM Mainnet.
 
 <video loop width="100%" height="100%" controls="true" >
-  <source type="video/mp4" src="../img/zkEVM/zkevmwallettestnet.mp4"></source>
+  <source type="video/mp4" src="../../img/zkvm/zkevmwallettestnet.mp4"></source>
   <p>Your browser does not support the video element.</p>
 </video>
 

docs/zkEVM/protocol/flow-of-assets.md

@@ -40,6 +40,6 @@ Consider now the case where a user commits to bridging some assets from L2 to L1
 
     For example, the interaction between the Consensus Contract and the Sequencer is omitted in the figure.
 
-    For a more wholistic view of the interaction between the Consensus Contract and the Sequencer, the reader is referred to earlier subsections of this documentation, specifically on the [<ins>Consensus Contract</ins>](/zkevm/architecture.md#consensus-contract).
+    For a more wholistic view of the interaction between the Consensus Contract and the Sequencer, the reader is referred to earlier subsections of this documentation, specifically on the [<ins>Consensus Contract</ins>](../architecture/index.md).
 
 ![A end-to-end flow of assets between L1 and L2](../../img/zkEVM/06pzb-complete-asset-flow-l1-l2.png)

docs/zkEVM/protocol/submit-transaction.md

@@ -1,4 +1,3 @@
-
 !!!info
     This document series describes in detail the various forms and stages that L2 users' transactions go through, from the time they are created in users' wallets to the time they are finally verified with indisputable evidence on L1.
 

docs/zkEVM/protocol/transaction-batching.md

@@ -2,6 +2,7 @@
 !!!info
     This document is a continuation in the series of articles explaining the [<ins>Transaction Life Cycle</ins>](submit-transaction.md) inside Polygon zkEVM.
 
+
 The **Trusted Sequencer** must batch the transactions using the following `BatchData` struct specified in the `PolygonZkEVM.sol` contract:
 
 ```

docs/zkEVM/specifications/evm-differences.md

@@ -5,11 +5,9 @@ This document provides a comprehensive list of differences between the Ethereum
 
     Note that the following differences have no impact on the developer experience with the zkEVM as compared to the EVM. Gas optimization techniques, interacting with libraries like Web3.js and Ethers.js, and deploying contracts works seamlessly on the zkEVM without any overhead.
 
-    To start deploying your own smart contracts on the zKEVM, check out the [<ins>deployment guide</ins>](/zkevm/develop.md).
-
 ## Opcodes
 
-This section lists out the changes we have done with Opcodes in zKEVM as compared to the EVM.
+This section lists the changes we have done with Opcodes in zKEVM as compared to the EVM.
 
 - **SELFDESTRUCT** &rarr; removed and replaced by **SENDALL**.
 

docs/zkEVM/specifications/pil/configuration-files.md

@@ -4,7 +4,7 @@ In order for PIL to securely enable modularity, especially in complex settings s
 
 ## Dependency Inclusion Feature
 
-Let's consider a scenario. If the PIL code of Secondary SMs reflects unique properties such as the maximum length (for example, the length $\mathtt{2^{10}}$ of the Multiplier SM as seen in the first line of [the `multiplier.pil` code](/zkevm/PIL/pil-compile.md)), such properties can easily become magic numbers which attackers could use as distinguishers of which computation is running at a given point in time.
+Let's consider a scenario. If the PIL code of Secondary SMs reflects unique properties such as the maximum length (for example, the length $\mathtt{2^{10}}$ of the Multiplier SM as seen in the first line of [the `multiplier.pil` code](compiling-using-pilcom.md)), such properties can easily become magic numbers which attackers could use as distinguishers of which computation is running at a given point in time.
 
 This is where the **dependency inclusion feature** comes in.
 

docs/zkEVM/specifications/pil/cyclicity-in-pil.md

@@ -2,7 +2,7 @@ This document describes how to introduce cyclicity to execution traces in Polyno
 
 In order to synchronize the execution trace of a given program with the subgroup $G$ of the multiplicative group $\mathbb{F}^*$, over which interpolation is performed, an extra constant polynomial (or precompiled column) is added to the trace. 
 
-An explanation of what this group $G = \langle g \rangle$ is, and why it is naturally a cyclic group, was discussed in the [Basic Concepts](/zkevm/zkProver/mfibonacci-example.md) section of the zkProver.
+An explanation of what this group $G = \langle g \rangle$ is, and why it is naturally a cyclic group, was discussed in the [Basic Concepts](../../concepts/mfibonacci-example.md) section of the zkProver.
 
 ## Non-cyclic SM Example
 

docs/zkEVM/specifications/pil/generating-proofs.md

@@ -89,4 +89,4 @@ async function execute() {
 
 If the output of the `starkVerify` function is `true`, the proof is valid. Otherwise, the verifier should invalidate the proof sent by the prover.
 
-A `pil-stark` DIY guide is given [here](/zkevm/zkProver/pil-stark-demo.md).
+A `pil-stark` DIY guide is given [here](../../concepts/pil-stark-demo.md).

docs/zkEVM/specifications/pil/inclusion-arguments.md

@@ -217,11 +217,11 @@ $$
 \texttt{a}\ \text{ is } \textbf{contained in }\ \texttt{b}\ \text{ if for all }\ i ∈ [n],\ \text{ there exists a }\ j ∈ [m]\ \text{ such that }\ a_i = b_j.
 $$
 
-In other words, if one thinks of $\texttt{a}$ and $\texttt{b}$ as multisets and reduce them to sets (by removing the multiplicity), then $\texttt{a}$ is contained in $\texttt{b}$ if $\texttt{a}$ is a subset of $\texttt{b}$. See [this document](/zkevm/zkProver/intro-generic-sm.md) for more details on multisets and Plookup.
+In other words, if one thinks of $\texttt{a}$ and $\texttt{b}$ as multisets and reduce them to sets (by removing the multiplicity), then $\texttt{a}$ is contained in $\texttt{b}$ if $\texttt{a}$ is a subset of $\texttt{b}$. See [this document](../../concepts/intro-generic-sm.md) for more details on multisets and Plookup.
 
 A protocol $(\mathcal{P},\mathcal{V})$ is an **inclusion argument** if the protocol can be used by $\mathcal{P}$ to prove to $\mathcal{V}$ that one vector is contained in another vector. 
 
-In the PIL context, the implemented inclusion argument is the same as the $\text{Plookup}$ method provided in [[GW20](https://eprint.iacr.org/2020/315.pdf)], also discussed [here](/zkevm/zkProver/intro-generic-sm.md). Other "alternative" method exists such as the $\text{PlonkUp}$ described in [[PFM+22](https://eprint.iacr.org/2022/086.pdf)].
+In the PIL context, the implemented inclusion argument is the same as the $\text{Plookup}$ method provided in [[GW20](https://eprint.iacr.org/2020/315.pdf)], also discussed [here](../../concepts/intro-generic-sm.md). Other "alternative" method exists such as the $\text{PlonkUp}$ described in [[PFM+22](https://eprint.iacr.org/2022/086.pdf)].
 
 An inclusion argument is invoked in PIL with the "$\texttt{in}$" keyword.