zkEVM: Update as per recent review

docs/agglayer/unified-bridge.md

@@ -11,4 +11,4 @@ The bridging mechanism enables token transfers and message-passing between Ether
 
 Each chain holds a single data structure which stores a record of all token withdrawals and messages that originated from that chain. This “exit tree” is an append-only Merkle trie, similar in structure to the Ethereum deposit trie. The latest state of each chain and the unified bridge is represented by the root of this Merkle tree, referred to as the “exit root.”
 
-As cryptographic commitments, exit roots ensure the integrity of the network as a whole.  Refer to the [exit root documentation](../zkEVM/architecture/high-level/smart-contracts/exit-roots.md) for greater detail about the role of exit roots in the system.
+As cryptographic commitments, exit roots ensure the integrity of the network as a whole.  Refer to the [exit root documentation](../zkEVM/architecture/smart-contracts/exit-roots.md) for greater detail about the role of exit roots in the system.

docs/cdk/concepts/admin-upgradeability.md

@@ -1,18 +1,18 @@
 # Admin upgradeability
 
-As L2s work through the [stages of training wheels](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe) to become fully decentralized, chains that opt in to the [AggLayer](../glossary/index.md#agglayer-v1-al1) implement shared security mechanisms with other AggLayer chains including the [Polygon zkEVM](../../zkEVM/architecture/protocol/upgradability.md) to ensure the safety of users.
+As L2s work through the [stages of training wheels](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe) to become fully decentralized, chains that opt in to the [AggLayer](../glossary/index.md#agglayer-v1-al1) implement shared security mechanisms with other AggLayer chains including the [Polygon zkEVM](../../zkEVM/operations/upgradability.md) to ensure the safety of users.
 
 Chains opted into the AggLayer share the following upgradeability controls:
 
-1. The [security council](../../zkEVM/architecture/protocol/security-council.md) ([contract address](https://etherscan.io/address/0x37c58Dfa7BF0A165C5AAEdDf3e2EdB475ac6Dcb6)) that can be used to trigger the [emergency state](../../zkEVM/architecture/protocol/malfunction-resistance/emergency-state.md) which can pause bridge functionality, prevent smart contract upgrades, or stop the [sequencer](./architecture.md#sequencer) from [sequencing batches](./transaction-lifecycle.md#sequenced).
+1. The [security council](../../zkEVM/operations/security-council.md) ([contract address](https://etherscan.io/address/0x37c58Dfa7BF0A165C5AAEdDf3e2EdB475ac6Dcb6)) that can be used to trigger the [emergency state](../../zkEVM/operations/malfunction-resistance/emergency-state.md) which can pause bridge functionality, prevent smart contract upgrades, or stop the [sequencer](./architecture.md#sequencer) from [sequencing batches](./transaction-lifecycle.md#sequenced).
 
-2. The [admin role](../../zkEVM/architecture/protocol/admin-role.md) ([contract address](https://etherscan.io/address/0x242daE44F5d8fb54B198D03a94dA45B5a4413e21)) that can perform upgrades to patch bug fixes or add new features to the system by upgrading smart contracts with a 10-day waiting period (unless [emergency state](../../zkEVM/architecture/protocol/malfunction-resistance/emergency-state.md) is active).
+2. The [admin role](../../zkEVM/operations/admin-role.md) ([contract address](https://etherscan.io/address/0x242daE44F5d8fb54B198D03a94dA45B5a4413e21)) that can perform upgrades to patch bug fixes or add new features to the system by upgrading smart contracts with a 10-day waiting period (unless [emergency state](../../zkEVM/operations/malfunction-resistance/emergency-state.md) is active).
 
 ## Further reading
 
-- [zkEVM protocol upgradability](../../zkEVM/architecture/protocol/upgradability.md).
-- [zkEVM admin role and governance](../../zkEVM/architecture/protocol/admin-role.md).
-- [zkEVM upgrade process](../../zkEVM/architecture/protocol/upgrade-process.md).
-- [zkEVM security council](../../zkEVM/architecture/protocol/security-council.md).
-- [zkEVM emergency state](../../zkEVM/architecture/protocol/malfunction-resistance/emergency-state.md).
+- [zkEVM protocol upgradability](../../zkEVM/operations/upgradability.md).
+- [zkEVM admin role and governance](../../zkEVM/operations/admin-role.md).
+- [zkEVM upgrade process](../../zkEVM/operations/upgrade-process.md).
+- [zkEVM security council](../../zkEVM/operations/security-council.md).
+- [zkEVM emergency state](../../zkEVM/operations/malfunction-resistance/emergency-state.md).
 - [L2Beat - Polygon zkEVM](https://l2beat.com/scaling/projects/polygonzkevm?selectedChart=activity).

docs/cdk/concepts/blocks.md

@@ -61,4 +61,4 @@ In this case, batch `2041736` happens to be the last batch to be sequenced, as d
 
 ## Further reading
 
-- [Blocks in the zkEVM Etrog upgrade](../../zkEVM/architecture/protocol/etrog-upgrade.md/?h=blocks#etrog-blocks).
+- [Blocks in the zkEVM Etrog upgrade](../../zkEVM/releases/etrog-upgrade.md/?h=blocks#etrog-blocks).

docs/zkEVM/how-to/using-foundry.md → docs/tools/dApp-development/common-tools/zkEVM/using-foundry.md

@@ -25,11 +25,11 @@ If you never installed Rust or need an update, visit the website [here](https://
 
 Run the command `forge build` to build the project. The output should look something like this:
 
-![Successful forge build command](../../img/zkEVM/zkv-success-forge-build.png)
+![Successful forge build command](../../../../img/zkEVM/zkv-success-forge-build.png)
 
 Now, test the build with `forge test`
 
-![Testing Forge Build](../../img/zkEVM/zkv-test-forge-build.png)
+![Testing Forge Build](../../../../img/zkEVM/zkv-test-forge-build.png)
 
 You can check out the contents of the newly built project by switching to your IDE. In case of VSCode, just type: ```code .```
 
@@ -126,7 +126,7 @@ In order to deploy on the zkEVM Testnet, populate the `.env` file in the usual w
 
 - Create a `.env.sample` file within the `src` folder
 
-- Populate `.env.sample` file with your `ACCOUNT_PRIVATE_KEY` and the zkEVM Testnet's `RPC URL` found [here](../get-started/quick-start.md). So the `.env.sample` file looks like this:
+- Populate `.env.sample` file with your `ACCOUNT_PRIVATE_KEY` and the zkEVM Testnet's `RPC URL` found [here](../../../../zkEVM/get-started/connect-to-zkEVM.md). So the `.env.sample` file looks like this:
 
     ```json
     RPC_URL="https://rpc.cardona.zkevm-rpc.com"
@@ -177,7 +177,7 @@ In order to deploy on the zkEVM Testnet, populate the `.env` file in the usual w
 
 The above command compiles and deploys the contract to the zkEVM Testnet. The output on the CLI looks like this one below.
 
-![Successful Deploy Sbt.sol](../../img/zkEVM/zkv-success-deploy-sbtdotsol.png)
+![Successful Deploy Sbt.sol](../../../../img/zkEVM/zkv-success-deploy-sbtdotsol.png)
 
 ## Check deployed contract in explorer
 

docs/zkEVM/how-to/using-hardhat.md → docs/tools/dApp-development/common-tools/zkEVM/using-hardhat.md

@@ -7,7 +7,7 @@ This document is a guide on how to deploy a smart contract on the Polygon zkEVM
 
 !!!info
 
-    Before starting with this deployment, please ensure that your wallet is connected to the Polygon zkEVM Testnet. See the demo [here](../get-started/quick-start.md) for details on how to connect your wallet.
+    Before starting with this deployment, please ensure that your wallet is connected to the Polygon zkEVM Testnet. See the demo [here](../../../../zkEVM/get-started/connect-to-zkEVM.md) for details on how to connect your wallet.
 
 - Add the Polygon zkEVM Testnet to your Metamask wallet and get some Testnet ETH from the [Polygon Faucet](https://faucet.polygon.technology).
 
@@ -63,7 +63,7 @@ mv README.md README-tutorial.md
 
     The aim here is to achieve the following outcome:
 
-    ![Figure _ ](../../img/zkEVM/zkv-proj-created-outcome.png)
+    ![Figure _ ](../../../../img/zkEVM/zkv-proj-created-outcome.png)
 
     So then,
 

docs/zkEVM/how-to/verify-contract.md → docs/tools/dApp-development/common-tools/zkEVM/verify-contract.md

@@ -28,7 +28,7 @@ After successfully compiling a smart contract, follow the next steps to verify y
 
     In order to flatten the contract code with Remix, one needs to only right-click on the contract name and select **Flatten** option from the drop-down menu that appears. See the below figure for reference.
 
-    ![Selecting the flatten code option](../../img/zkEVM/flatten-code-remix.png)
+    ![Selecting the flatten code option](../../../../img/zkEVM/flatten-code-remix.png)
 
     After selecting **Flatten**, a new `.sol` file with the suffix `_flatten.sol` is automatically created. Copy the contents of the new `<Original-Name>_flatten.sol` file and paste into the `Enter the Solidity Contract` field in the explorer.
 

docs/zkEVM/how-to/write-contract.md → docs/tools/dApp-development/common-tools/zkEVM/write-contract.md

@@ -37,4 +37,4 @@ With the resulting lines of code, you now have the NFT token contract written in
 
 The below figure depicts the auto-written NFT smart contract code.
 
-![The end-product NFT source code](../../img/zkEVM/zkv-end-product-nft-code.png)
+![The end-product NFT source code](../../../../img/zkEVM/zkv-end-product-nft-code.png)

docs/zkEVM/architecture/protocol/synchronizer-reorg.md

@@ -47,7 +47,7 @@ And, as in the above scenario of sequencer A and B, the synchronizer alerts sequ
 
 The possibility of L2 reorgs arises only in the event of L1 reorgs.
 
-There’s a slight chance for a reorg occurrence in the event of [_forced batches_](../protocol/malfunction-resistance/sequencer-resistance.md), where a user is sequencing a batch.
+There’s a slight chance for a reorg occurrence in the event of [_forced batches_](../../operations/malfunction-resistance/sequencer-resistance.md), where a user is sequencing a batch.
 
 However, the design of forced batches is specifically crafted to mitigate such scenarios.
 

docs/zkEVM/architecture/protocol/transaction-life-cycle/transaction-execution.md

@@ -15,6 +15,6 @@ Users typically interact with trusted L2 state. However, because of specific pro
      - What is the rare case scenario?
         Verification of transactions on L1 can take 1 week in the case when an emergency state is activated or the aggregator does not batch any proofs at all.
 
-     - Additionally, the emergency mode is activated if a sequenced batch is not aggregated in 7 days. Please refer to [this guide](../malfunction-resistance/emergency-state.md) to understand more about the emergency state.
+     - Additionally, the emergency mode is activated if a sequenced batch is not aggregated in 7 days. Please refer to [this guide](../../../operations/malfunction-resistance/emergency-state.md) to understand more about the emergency state.
 
 As a result, users should be mindful of the potential risks associated with high-value transactions, particularly those that cannot be reversed, such as off-ramps, over-the-counter transactions, and alternative bridges.

docs/zkEVM/architecture/proving-system/aggregator-proofs.md

@@ -88,7 +88,7 @@ The main use case is to allow a user to send bridge transactions to withdraw ass
 
 Since every user who sends L2 batch data is, by default, 'untrusted,' the system must ensure that anything sent by any user can be verified.
 
-The _forced batches_ mechanism is elaborated on in the [Malfunction resistance subsection](../../../zkEVM/architecture/protocol/malfunction-resistance/sequencer-resistance.md).
+The _forced batches_ mechanism is elaborated on in the [Malfunction resistance subsection](../../../zkEVM/operations/malfunction-resistance/sequencer-resistance.md).
 
 ## zkCounters
 

docs/zkEVM/architecture/proving-system/json-rpc-to-proof.md

@@ -118,7 +118,7 @@ The figure below depicts the structure of the Etrog upgrade's batches.
 
 ![Figure: Fork-ID 6 - batch approach](../../../img/zkEVM/rpc-batch-approach-forkid6.png)
 
-Read the [Etrog upgrade document](../protocol/etrog-upgrade.md) for further details and how it differs from the Dragonfruit upgrade.
+Read the [Etrog upgrade document](../../releases/etrog-upgrade.md) for further details and how it differs from the Dragonfruit upgrade.
 
 ## Custom zkEVM endpoints
 

docs/zkEVM/architecture/proving-system/processing-l2-blocks.md

@@ -1,4 +1,4 @@
-In this document we discuss the differences between the Dragonfruit upgrade, which comes with the executor fork-ID 5, and the [Etrog upgrade](../protocol/etrog-upgrade.md) associated with fork-ID 6.
+In this document we discuss the differences between the Dragonfruit upgrade, which comes with the executor fork-ID 5, and the [Etrog upgrade](../../releases/etrog-upgrade.md) associated with fork-ID 6.
 
 The key differences between the two Polygon zkEVM upgrades are mainly related to the definition of the L2 block and timestamps.
 

docs/zkEVM/architecture/high-level/smart-contracts/exit-roots.md → docs/zkEVM/architecture/smart-contracts/exit-roots.md

@@ -10,7 +10,7 @@ The L2 bridge contract manages a special Merkle tree called a local exit tree fo
 
 <center>
 
-![Local exit tree for network participant](../../../../img/cdk/high-level-architecture/local-exit-tree.png)
+![Local exit tree for network participant](../../../img/cdk/smart-contracts/local-exit-tree.png)
 
 </center>
 
@@ -29,7 +29,7 @@ The roots of the L2 local exit trees feed into a single exit tree that manages s
 
 <center>
 
-![Exit tree for rollups](../../../../img/cdk/high-level-architecture/exit-tree-for-rollups.png)
+![Exit tree for rollups](../../../img/cdk/smart-contracts/exit-tree-for-rollups.png)
 
 </center>
 
@@ -41,7 +41,7 @@ Every time there is a call to `bridgeAsset()` and `bridgeMessage()` on the bridg
 
 <center>
 
-![L1 local exit tree](../../../../img/cdk/high-level-architecture/l1-ethereum-exit-tree.png)
+![L1 local exit tree](../../../img/cdk/smart-contracts/l1-ethereum-exit-tree.png)
 
 </center>
 
@@ -55,7 +55,7 @@ The GER is the fingerprint of the information stored in all trees, and thus repr
 
 <center>
 
-![Exit tree for rollups](../../../../img/cdk/high-level-architecture/l1-info-tree.png)
+![Exit tree for rollups](../../../img/cdk/smart-contracts/l1-info-tree.png)
 
 </center>
 
@@ -71,7 +71,7 @@ uint8 private constant _LEAF_TYPE_ASSET = 0;
 uint8 private constant _LEAF_TYPE_MESSAGE = 1;
 ```
 
-Data in a leaf contains a Keccak256 hash of the metadata (ABI encoded metadata if any) and the following parameters (matched by publicly available transaction data as seen in the [bridge L1 to L2](../../unified-LxLy/bridging.md#l1-to-l2) documentation):
+Data in a leaf contains a Keccak256 hash of the metadata (ABI encoded metadata if any) and the following parameters (matched by publicly available transaction data as seen in the [bridge L1 to L2](../unified-LxLy/bridging.md#l1-to-l2) documentation):
 
 ```solidity
 _addLeaf(
@@ -111,7 +111,7 @@ The exit roots are modified in two key flows; sequencing and bridging.
 
 The `PolygonZkEVMGlobalExitRootV2` contract manages updates to the exit roots on sequencing. The contract calls `updateExitRoot(...)` on the `GlobalExitRootManager` during the sequencing flow to add an exit leaf to the relevant exit tree. 
 
-![Update exit roots via sequencing flow](../../../../img/cdk/high-level-architecture/update-exit-roots-via-sequencing.png)
+![Update exit roots via sequencing flow](../../../img/cdk/smart-contracts/update-exit-roots-via-sequencing.png)
 
 1. Initiate update: `PolygonZkEVMEtrog` initiates the update process by calling `updateExitRoots` on `PolygonRollupBaseEtrog`.
 2. Retrieve current roots: `PolygonRollupBaseEtrog` retrieves the current local and global exit roots from `PolygonZkEVMGlobalExitRootL2` and `PolygonZkEVMGlobalExitRootV2` respectively.
@@ -128,7 +128,7 @@ The `PolygonZkEVMGlobalExitRootV2` contract manages updates to the exit roots on
 
 When bridging, the global exit root is updated if the [`forceUpdateGlobalExitRoot`](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/v2/PolygonZkEVMBridgeV2.sol#L312) variable is set to `true`.
 
-![Update exit roots via bridging flow](../../../../img/cdk/high-level-architecture/update-exit-roots-via-bridging.png)
+![Update exit roots via bridging flow](../../../img/cdk/smart-contracts/update-exit-roots-via-bridging.png)
 
 1. The user interacts with the `PolygonZkEVMBridgeV2` contract by calling the `bridge()` function.
 2. `PolygonZkEVMBridgeV2` calls `updateLocalExitRoot()` on `PolygonZkEVMGlobalExitRootL2`, which updates the local exit root.

docs/zkEVM/architecture/high-level/smart-contracts/main-contracts.md → docs/zkEVM/architecture/smart-contracts/main-contracts.md

@@ -19,7 +19,7 @@ The following contracts manage consensus mechanisms. They deal with sequencing a
 This contract calls the `onSequenceBatches(...)` function on the `PolygonRollupManager.sol` contract to trigger the verification mechanism after successful sequencing through the `sequenceBatches(...)` call.
 
 <center>
-![Polygon Solidity smart contract consensus contract set](../../../../img/cdk/high-level-architecture/consensus-contracts.png)
+![Polygon Solidity smart contract consensus contract set](../../../img/cdk/smart-contracts/consensus-contracts.png)
 </center>
 
 
@@ -41,7 +41,7 @@ The [PolygonRollupManager.sol](https://github.com/0xPolygonHermez/zkevm-contract
 It is responsible for the verification workflow by supplying updated exit root data to the [PolygonZkEVMGlobalExitRootV2.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/v2/PolygonZkEVMGlobalExitRootV2.sol) contract.
 
 <center>
-![Polygon Solidity smart contract rollup manager](../../../../img/cdk/high-level-architecture/rollup-manager.png){ width=80% }
+![Polygon Solidity smart contract rollup manager](../../../img/cdk/smart-contracts/rollup-manager.png){ width=80% }
 </center>
 
 #### Key functionality
@@ -59,7 +59,7 @@ It is responsible for the verification workflow by supplying updated exit root d
 The [PolygonZkEVMBridgeV2.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/v2/PolygonZkEVMBridgeV2.sol) is the main communication mechanism between the L1 and L2 realms. It manages bridging and claiming of assets and messages across environments.
 
 <center>
-![Polygon Solidity smart contract bridge](../../../../img/cdk/high-level-architecture/bridge.png){ width=80% }
+![Polygon Solidity smart contract bridge](../../../img/cdk/smart-contracts/bridge.png){ width=80% }
 </center>
 
 #### Key functionality
@@ -85,7 +85,7 @@ The [PolygonZkEVMGlobalExitRootV2.sol](https://github.com/0xPolygonHermez/zkevm-
 - Retrieving latest exit roots and leaf values.
 
 <center>
-![Polygon Solidity smart contract exit root L1](../../../../img/cdk/high-level-architecture/l1-exit-root.png){ width=60% }
+![Polygon Solidity smart contract exit root L1](../../../img/cdk/smart-contracts/l1-exit-root.png){ width=60% }
 </center>
 
 ### `PolygonZkEVMGlobalExitRootL2.sol`
@@ -101,5 +101,5 @@ It is a lighter-weight version of the global exit root contract mentioned previo
 - Updates the L2 network and global exit root with the `updateExitRoot(...)` function.
 
 <center>
-![Polygon Solidity smart contract exit root L2](../../../../img/cdk/high-level-architecture/l2-exit-root.png){ width=60% }
+![Polygon Solidity smart contract exit root L2](../../../img/cdk/smart-contracts/l2-exit-root.png){ width=60% }
 </center>

docs/zkEVM/architecture/high-level/smart-contracts/sequencing.md → docs/zkEVM/architecture/smart-contracts/sequencing.md

@@ -13,7 +13,7 @@ This section focuses on the sequencing workflow.
 
 The diagram below shows the sequencing workflow for rollup (non-validium) stacks which calls `sequenceBatches(...)` and `onSequenceBatches(...)`. 
 
-![Polygon Solidity smart contract architecture](../../../../img/cdk/high-level-architecture/sequencing-flow.png)
+![Polygon Solidity smart contract architecture](../../../img/cdk/smart-contracts/sequencing-flow.png)
 
 ## `sequenceBatches()`
 

docs/zkEVM/architecture/high-level/smart-contracts/verification.md → docs/zkEVM/architecture/smart-contracts/verification.md

@@ -13,7 +13,7 @@ This section focuses on the verification workflow.
 
 The sequence diagram below shows the verification workflow for rollup stacks and/or the AggLayer calling the `verifyBatchesTrustedAggregator(...)` function on the rollup manager.
 
-![Polygon Solidity consensus verification flow](../../../../img/cdk/high-level-architecture/verification-flow.png)
+![Polygon Solidity consensus verification flow](../../../img/cdk/smart-contracts/verification-flow.png)
 
 ## `verifyBatchesTrustedAggregator()`
 

docs/zkEVM/get-started/quick-start.md → docs/zkEVM/get-started/connect-to-zkEVM.md

@@ -4,9 +4,6 @@ comments: true
 ---
 -->
 
-!!!caution
-    Check the list of potential risks associated with the use of Polygon zkEVM in the [Disclosures](../get-started/risk-disclosures.md) section.
-
 ## Connect to zkEVM mainnet or testnet
 
 Add a full network configuration to your wallet in one click.