Merge pull request 0xPolygon#511 from 0xPolygon/sc-verifications-1

forgotten updates after review

Author: kmurphypolygon

docs/img/cdk/high-level-architecture/update-exit-roots-via-bridging.png

@@ -16,14 +16,14 @@ The diagram below is a full and detailed topological overview of the entire Poly
 - Exit root trees: Append-only sparse Merkle trees which record the current and historical state of the system. 
 - CDK and zkEVM nodes containing:
     - JSON RPC client: Exposes the read/write interfaces for interacting with a node/chain.
-    - Pool database: The pool database records transaction requests coming in from the JSON RPC client and sends them to the sequencer.
-    - State database: The state database responds to read requests from the JSON RPC client.
-    - Sequencer: Does the complex job of carefully sequencing transactions as they come in before sending them to the aggregator for batching. See the discussion on [sequencers](../../architecture/index.md#sequencer) for more information.
-    - Aggregator: Used for aggregating transaction batches to send to the prover. See the discussion on [aggregators](../../architecture/index.md#aggregator) for more information.
-    - Synchronizer: This component ensures a synchronized state between the node's systems and the L1 outside-world via the Etherman component and the state database. 
-    - Etherman component: The Etherman helps the synchronizer maintain a synchronized state with L1 by communicating with the L1 Ethereum chain via smart contract functions.
-- Bridge service component: Provides an API to perform bridge claims, i.e. asset and message transfers between L1/L2 and L2/L2.
-- Prover component: System for calculating zero-knowledge proofs on transaction batches.
+    - Pool database: Records transaction requests coming in from the JSON RPC client and passes them to the sequencer.
+    - State database: Responds to read requests from the JSON RPC client.
+    - Sequencer: Does the complex job of fetching transactions and carefully sequencing them before sending them to the aggregator for batching. See the discussion on [sequencers](../../architecture/index.md#sequencer) for more information.
+    - Aggregator: Aggregates transaction batches to send to the prover. See the discussion on [aggregators](../../architecture/index.md#aggregator) for more information.
+    - Synchronizer: Ensures a synchronized state between the node's systems and the L1 outside-world via the Etherman component and the state database. 
+    - Etherman: Helps the synchronizer maintain a synchronized state with L1 by communicating with the L1 Ethereum chain via smart contract functions.
+- Unified bridge service: Provides an API to perform bridge claims, i.e. asset and message transfers between L1/L2 and L2/L2.
+- Prover: System for calculating zero-knowledge proofs on transaction batches.
 
 ## What to expect
 

docs/img/learn/innovation-and-design.svg

@@ -2,6 +2,10 @@ Abstract contract required to preserve the storage slots from previous versions.
 
 ## Functions
 
+None.
+
+## Variables
+
 ### `lastRollupExitRoot`
 
 Rollup root, contains all exit roots of all rollups.

docs/zkEVM/architecture/high-level/overview.md

@@ -1,4 +1,4 @@
-The unified bridge transfers assets and messages between networks (L1, L2) by calling bridge and claim functions on the [PolygonZkEVMBridgeV2.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/v2/PolygonZkEVMBridgeV2.sol) contract which can act as an upgradeable proxy via the library imports.
+The unified bridge transfers assets and messages between networks (L1, L2) by calling bridge and claim functions on the [PolygonZkEVMBridgeV2.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/main/contracts/v2/PolygonZkEVMBridgeV2.sol) contract whose deployment address is an [upgradeable proxy](https://etherscan.io/address/0x2a3DD3EB832aF982ec71669E178424b10Dca2EDe#code). Interaction with the actual contract happens via the proxy.
 
 This contract is deployed on L1 and there is also one deployed on every L2 network. It communicates closely with an exit root manager contract specific to L1 or L2.
 

docs/zkEVM/architecture/high-level/smart-contracts/api/lib/PolygonZkEVMGlobalExitRootBaseStorage.md

@@ -4,46 +4,6 @@ The Merkle root of an exit tree is known as the exit tree root, and it is the fi
 
 The global exit tree root of the L1 info tree is, therefore, the source of truth for the whole network. 
 
-## Updating system state
-
-The system uses a set of [exit tree roots](exit-roots.md) to manage system state. Leaves of the trees point to transaction data such as detailed above.
-
-Adding a new leaf to the tree triggers an update to the exit tree root which then propagates to an update on the global exit tree root.
-
-Using Merkle tree exit roots in this way, referenced by the bridge contracts and accessible to the `PolygonRollupManager` contract with getters, the bridge contract triggers data synchronization across L1 and L2, including at the sequencer and state db level.
-
-The use of two distinct global exit root manager contracts for L1 and L2, as well as separate logic for the sequencing flow and the bridge contract, allows for extensive network interoperability. Meanwhile, all asset transfers can be validated by any L1 and L2 node due to the accessibility of state data.
-
-The exit roots are modified in two key flows; sequencing and bridging.
-
-### Sequencing flow
-
-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)
-
-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.
-3. Compute new exit root: `PolygonRollupBaseEtrog` computes the new exit root based on the retrieved local and global exit roots.
-4. Update local exit root: `PolygonRollupBaseEtrog` updates the local exit root in `PolygonZkEVMGlobalExitRootL2`.
-5. Update global exit root: `PolygonRollupBaseEtrog` updates the global exit root in `PolygonZkEVMGlobalExitRootV2`.
-6. Verify updated exit root: `PolygonRollupBaseEtrog` calls `getRollupExitRoot` on `PolygonRollupManager` to verify the updated exit root.
-
-!!! tip "L1 or L2 update"
-    - If `msg.sender` is the bridge contract, the L1 local exit root is updated.
-    - If `msg.sender` is the rollup manager, the L2 local exit root is updated.
-
-### Bridging flow
-
-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)
-
-1. The user interacts with the `PolygonZkEVMBridgeV2` contract by calling the `bridge()` and `claim()` functions.
-2. For both bridge() and claim():
-    `PolygonZkEVMBridgeV2` calls `updateLocalExitRoot()` on `PolygonZkEVMGlobalExitRootL2`, which updates the local exit root.
-3. If `forceUpdateGlobalExitRoot` is set to true, `PolygonZkEVMBridgeV2` calls `updateGlobalExitRoot()` on `PolygonZkEVMGlobalExitRootV2`, which updates the global exit root.
-
 ## Rollup local exit trees
 
 The L2 bridge contract manages a special Merkle tree called a local exit tree for each network that participates in bridging and claiming which is updated by the [PolygonZkEVMGlobalExitRootL2.sol](https://github.com/0xPolygonHermez/zkevm-contracts/blob/feature/etrog/contracts/PolygonZkEVMGlobalExitRootL2.sol) contract.
@@ -134,3 +94,42 @@ _addLeaf(
     - `address destinationAddress`: Address that receives the bridged asset in the destination network.
     - `uint256 leafAmount`: Amount of tokens/ether to bridge.
     - `bytes32 keccak256(metadata)`: Hash of the metadata. This metadata contains information about assets transferred or the message payload.
+
+## Updating system state
+
+The system uses a set of [exit tree roots](exit-roots.md) to manage system state. Leaves of the trees point to transaction data such as detailed above.
+
+Adding a new leaf to the tree triggers an update to the exit tree root which then propagates to an update on the global exit tree root.
+
+Using Merkle tree exit roots in this way, referenced by the bridge contracts and accessible to the `PolygonRollupManager` contract with getters, the bridge contract triggers data synchronization across L1 and L2, including at the sequencer and state db level.
+
+The use of two distinct global exit root manager contracts for L1 and L2, as well as separate logic for the sequencing flow and the bridge contract, allows for extensive network interoperability. Meanwhile, all asset transfers can be validated by any L1 and L2 node due to the accessibility of state data.
+
+The exit roots are modified in two key flows; sequencing and bridging.
+
+### Sequencing flow
+
+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)
+
+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.
+3. Compute new exit root: `PolygonRollupBaseEtrog` computes the new exit root based on the retrieved local and global exit roots.
+4. Update local exit root: `PolygonRollupBaseEtrog` updates the local exit root in `PolygonZkEVMGlobalExitRootL2`.
+5. Update global exit root: `PolygonRollupBaseEtrog` updates the global exit root in `PolygonZkEVMGlobalExitRootV2`.
+6. Verify updated exit root: `PolygonRollupBaseEtrog` calls `getRollupExitRoot` on `PolygonRollupManager` to verify the updated exit root.
+
+!!! tip "L1 or L2 update"
+    - If `msg.sender` is the bridge contract, the L1 local exit root is updated.
+    - If `msg.sender` is the rollup manager, the L2 local exit root is updated.
+
+### Bridging flow
+
+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)
+
+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.
+3. If `forceUpdateGlobalExitRoot` is set to true, `PolygonZkEVMBridgeV2` calls `updateGlobalExitRoot()` on `PolygonZkEVMGlobalExitRootV2`, which updates the global exit root.

docs/zkEVM/architecture/high-level/smart-contracts/bridging.md

@@ -77,7 +77,7 @@ It is a lighter-weight version of the global exit root contract mentioned previo
 
 #### Key functionality
 
-- Stores every global exit root in the `globalExitRootMap`. The root of this map is the timestamp.
+- Stores every global exit root in the `globalExitRootMap` where keys are global exit roots and values are timestamps.
 - Updates the `lastRollupExitRoot` on any bridge call.
 - Updates the L2 network and global exit root with the `updateExitRoot(...)` function.