Merge pull request #49 from 0xPolygon/nadim/fixes

Do reorg requested by Grace + fixes site-wide

docs/cdk/concepts/dac.md

@@ -1,4 +1,4 @@
-Data availability in blockchain technology refers to whether or not transaction data is available on-chain or off-chain. 
+Data availability in blockchain technology refers to whether or not transaction data is available on-chain or off-chain.
 
 If data is available on-chain, then each node has to store every piece of data related to every transaction. This can be costly for node operators as hardware and storage requirements are high. Moving data off-chain streamlines node architecture and operations.
 
@@ -14,13 +14,13 @@ A DAC is an off-chain network of nodes that implements a data storage layer in a
 - **Lower transaction fees**: Reduced computational requirements lead to lower fees and faster finality on the main network.
 - **Privacy and security**: The DAC stores secure and private transaction data.
 - **Trustless**: Data owners do not have to trust the blockchain operator.
-- **Scalable**: Decoupling data storage from the main chain supports more scalable networks. 
+- **Scalable**: Decoupling data storage from the main chain supports more scalable networks.
 
 DACs store the data required to reconstruct the state of the blockchain and make that data accessible so that, if the main blockchain network goes down, users can still access their assets and data.
 
 Setting up a DAC can be costly and therefore DACs mostly support Enterprise use cases which require cheap and fast transactions with a private and secure data layer.
 
-The CDK validium DAC is a secure consortium of nodes that ensures off-chain data access. 
+The CDK validium DAC is a secure consortium of nodes that ensures off-chain data access.
 
 ## DAC data flow
 
@@ -40,4 +40,4 @@ The DAC works together with the sequencer to control the flow of data. The proce
 
 6. **Verification on Ethereum**: A designated smart contract on Ethereum verifies the submitted signatures against a list of valid DAC members and confirms that sufficient approval has been provided for the batch hash.
 
-7. **Final settlement with zero-knowledge proof**: The aggregator prepares a proof for the batch via the prover and submits it to Ethereum. This proof confirms the validity of the batch's transactions without revealing their details. The chain state updates on Ethereum.
+7. **Final settlement with zero-knowledge proof**: The aggregator prepares a proof for the batch via the prover and submits it to Ethereum. This proof confirms the validity of the batch's transactions without revealing their details. The chain state updates on Ethereum.

docs/cdk/concepts/index.md

@@ -0,0 +1 @@
+Welcome to Concepts

docs/cdk/concepts/rollup.md

@@ -1,6 +1,6 @@
-Rollups are blockchain layer 2 scaling solutions that speed up the network by *rolling up* multiple transactions into batches which are eventually committed to the layer 1. 
+Rollups are blockchain layer 2 scaling solutions that speed up the network by *rolling up* multiple transactions into batches which are eventually committed to the layer 1.
 
 CDK provides zkEVM rollup solutions.
 
 !!! info "Recommended resource"
-    See Ethereum.org's detailed [description of zero-knowledge rollups](https://ethereum.org/en/developers/docs/scaling/zk-rollups/).
+    See Ethereum.org's detailed [description of zero-knowledge rollups](https://ethereum.org/en/developers/docs/scaling/zk-rollups/).

docs/cdk/concepts/validium.md

@@ -1,4 +1,4 @@
-Validiums are blockchain scaling solutions that do not store transaction data. 
+Validiums are blockchain scaling solutions that do not store transaction data.
 
 !!! info "Recommended resource"
-    See Ethereum.org's detailed [description of validiums](https://ethereum.org/en/developers/docs/scaling/validium/).
+    See Ethereum.org's detailed [description of validiums](https://ethereum.org/en/developers/docs/scaling/validium/).

docs/cdk/get-started/deploy-rollup.md

@@ -4,4 +4,3 @@
 ## Deploy a CDK rollup locally
 
 The [zkEVM deployment quickstart documentation](../../zkEVM/get-started/deploy-zkevm/index.md) shows you how to deploy a zkEVM rollup on your local machine.
-

docs/cdk/get-started/deploy-validium.md

@@ -7,17 +7,16 @@ Follow the steps below to deploy a CDK validium instance.
 
 First, deploy the relevant contracts.
 
-Follow the steps in the [CDK validium contracts repository's README</ins>](https://github.com/0xPolygon/cdk-validium-contracts).
+Follow the steps in the [CDK validium contracts repository's README](https://github.com/0xPolygon/cdk-validium-contracts).
 
 ## 2. Run the CDK validium node
 
-Next, set up and run the CDK validium node. 
+Next, set up and run the CDK validium node.
 
 Follow the instructions in the [CDK validium node repository's README](https://github.com/0xPolygon/cdk-validium-node).
 
-
 ## 3. Run the data availability (DA) node (optional step)
 
-Finally, once the CDK validium node is operational, set up and run the data availability node. 
+Finally, once the CDK validium node is operational, set up and run the data availability node.
 
-Check for instructions here: [<ins>CDK DA Node GitHub running instructions</ins>](https://github.com/0xPolygon/cdk-data-availability/blob/main/docs/running.md).
+Check for instructions here: [CDK DA Node GitHub running instructions](https://github.com/0xPolygon/cdk-data-availability/blob/main/docs/running.md).

docs/cdk/welcome.md → docs/cdk/get-started/index.md

@@ -5,16 +5,16 @@ This section documents the two most popular deployments currently supported by C
 - Validium
 - Rollup
 
-Users select a chain architecture specific to their needs from a set of supported, open source options. Alternatively, users can select custom components for specific requirements. 
+Users select a chain architecture specific to their needs from a set of supported, open source options. Alternatively, users can select custom components for specific requirements.
 
 !!! important "Why are there zkEVM docs in the CDK section?"
      Several of the docs point to zkEVM specific deployment documentation because the rollup flavor of CDK uses zkEVM deployment defaults.
 
 The diagram below shows the two supported configuration options for data availability (DA), rollup or validium. Rollups post transaction data from the CDK directly onto Ethereum whereas validiums only post the transaction hash.
 
-![CDK architecture choices](../img/cdk/cdk-architecture.png)
+![CDK architecture choices](../../img/cdk/cdk-architecture.png)
 
-Check out the [data availability docs](concepts/dac.md) for more information.
+Check out the [data availability docs](../concepts/dac.md) for more information.
 
 !!! important
     The documentation describes standard deployments. You can edit the configuration files to implement your own custom set ups.

docs/cdk/get-started/quickstart-validium.md

@@ -26,6 +26,7 @@ cd zkValidium-quickstart
 ```
 
 Create the `.env` file by copying the example:
+
 ```bash
 cp .env.example .env
 ```
@@ -93,6 +94,7 @@ zkevm-bridge-service             /bin/sh -c /app/zkevm-brid ...   Up
                                                                                  0.0.0.0:9090->9090/tcp,:::9090->9090/tcp                     
 zkevm-bridge-ui                  /bin/sh /app/scripts/deploy.sh   Up             0.0.0.0:8088->80/tcp,:::8088->80/tcp 
 ```
+
 </details>
 
 2.3.1 If a service isn't running (i.e. it is in `Exit 1` state), investigate further using the logs:
@@ -123,7 +125,7 @@ sudo make restart
 
 ## 3. Test validium
 
-3.1 Verify the block explorer is running by navigating to [localhost:4001](http://localhost:4001/). 
+3.1 Verify the block explorer is running by navigating to [localhost:4001](http://localhost:4001/).
 
 You should see a page similar to this:
 
@@ -135,8 +137,8 @@ You should see a page similar to this:
 
 4.1 Follow MetaMask's instructions on [how to set up a network manually](https://support.metamask.io/hc/en-us/articles/360043227612-How-to-add-a-custom-network-RPC).
 
-- Set the chain ID to **1001**. 
-- The currency symbol can be anything but we will use **POL** by default. 
+- Set the chain ID to **1001**.
+- The currency symbol can be anything but we will use **POL** by default.
 - The RPC node and block explorer containers can be found at ports **8123** and **4001**, respectively.
 
 <div align="center">
@@ -191,7 +193,7 @@ CDK has a native bridge with UI that allows you to transfer funds between the L1
 
 5.1.2 Switch to the L1 network and you will see the previously imported account with ~999 POL on the L1 chain.
 
-5.1.3 Verify the bridge UI by navigating to [localhost:8088](http://localhost:8088/). 
+5.1.3 Verify the bridge UI by navigating to [localhost:8088](http://localhost:8088/).
 
 5.1.4 Click on **Connect a wallet > MetaMask**.
 
@@ -205,7 +207,7 @@ CDK has a native bridge with UI that allows you to transfer funds between the L1
   <img src="/img/cdk/cdk-bridge-connected.png" alt="bridge" width="90%" height="30%" />
 </div>
 
-5.1.6 Enter the amount (e.g. 5) to bridge and click **Continue**, you will see the **Confirm Bridge** page. 
+5.1.6 Enter the amount (e.g. 5) to bridge and click **Continue**, you will see the **Confirm Bridge** page.
 
 5.1.7 Click **Bridge** and approve the transaction on the MetaMask pop-up:
 
@@ -221,7 +223,7 @@ CDK has a native bridge with UI that allows you to transfer funds between the L1
 
 ### 5.2 L2 to L1
 
-5.2.1 Switch network on MetaMask to your validium chain and navigate back to [localhost:8088](http://localhost:8088/). 
+5.2.1 Switch network on MetaMask to your validium chain and navigate back to [localhost:8088](http://localhost:8088/).
 
 5.2.2 You should see both the updated L1 and L2 balances:
 
@@ -244,4 +246,4 @@ The L2->L1 bridging is slightly different than L1->L2 and you will see the **Act
 
 <div align="center">
   <img src="/img/cdk/cdk-bridge-l2-to-l1-completed.png" alt="bridge" width="90%" height="30%" />
-</div>
+</div>

docs/cdk/how-to/index.md

@@ -0,0 +1 @@
+This introduction to the how to section is being written.

docs/cdk/how-to/manage-allowlists.md → docs/cdk/how-to/manage-policies.md

@@ -5,7 +5,7 @@ Managing allowlists, denylists, and ACLs is done with policies.
 
 ## Policy overview
 
-A **policy** is a set of rules that govern what actions are allowed or denied in the transaction pool. 
+A **policy** is a set of rules that govern what actions are allowed or denied in the transaction pool.
 
 - **Fine-grained control**: Developers can specify policies at a granular level, allowing or denying specific actions for specific addresses.
 - **Dynamic updates**: Policies and ACLs can be updated on-the-fly without requiring a node restart.
@@ -21,7 +21,7 @@ Currently, there are two defined policies:
 - **SendTx**: governs whether an address may send transactions to the pool.
 - **Deploy**: governs whether an address may deploy a contract.
 
-The CDK validium node offers policy management features that include allowlisting[^1], denylisting[^2], and access control lists (ACLs)[^3]. These features are beneficial for validium-based app-chains that require fine-grained control over transaction pools. 
+The CDK validium node offers policy management features that include allowlisting[^1], denylisting[^2], and access control lists (ACLs)[^3]. These features are beneficial for validium-based app-chains that require fine-grained control over transaction pools.
 
 ### Code definitions
 
@@ -83,7 +83,6 @@ docker exec -it cdk-validium-aggregator /app/cdk-validium-node policy describe -
 docker exec -it cdk-validium-aggregator /app/cdk-validium-node policy describe
 ```
 
-
 [^1]: **Allowlisting**: The process of explicitly allowing addresses to perform certain actions.
 [^2]: **Denylisting**: The process of explicitly denying addresses from performing certain actions.
-[^3]: **ACL (access control list)**: A list of addresses that are exceptions to a given policy.
+[^3]: **ACL (access control list)**: A list of addresses that are exceptions to a given policy.

docs/cdk/index.md

@@ -1 +1 @@
-TODO: marketing copy and frontend design
+TODO: marketing copy and frontend design

docs/cdk/spec/index.md

@@ -0,0 +1 @@
+This introduction to the specification section is being written.

docs/cdk/specification/validium-vs-rollup.md → docs/cdk/spec/validium-vs-rollup.md

@@ -11,10 +11,10 @@ Polygon CDK running in validium mode inherits the core functionalities of a zkEV
 | **Components**           | zkEVM components\*                                        | zkEVM components\* + PostgreSQL database + on-chain committees                   |
 | **Contracts** | [zkEVM smart contracts](https://github.com/0xPolygonHermez/zkevm-contracts)  <ul><li>`PolygonZkEVM` (main rollup contract)</li> <li> `PolygonZkEVMBridge`</li> <li>`PolygonZkEVMGlobalExitRoot`</li></ul>  | [Validium-specific DAC contract](https://github.com/0xPolygon/cdk-validium-contracts) <ul><li>`CDKDataCommittee.sol`</li><li> `CDKValidium.sol` </li></ul> |
 | **Infrastructure** | Standard infrastructure                                     | Dedicated infrastructure for data availability layer and DACs                      |
-| **Tx flow** | All transaction data is published on L1 | Validium only publishes the hash of the transaction data to L1. The sequencer sends both the hash and the transaction data to the DAC for verification. Once approved, the hash+signatures are sent to the Consensus L1 contract of the validium protocol. 
+| **Tx flow** | All transaction data is published on L1 | Validium only publishes the hash of the transaction data to L1. The sequencer sends both the hash and the transaction data to the DAC for verification. Once approved, the hash+signatures are sent to the Consensus L1 contract of the validium protocol.
 | **Security** | High security due to on-chain data availability and zero-knowledge proofs. |Off-chain data availability can affect security if the sequencer goes offline or if DAC members collude to withhold state data. |
 | **Gas fees** | High, because all transaction data is stored on Ethereum. | Low, because only the hash of the transaction data is stored on Ethereum. |
 | **Proof generation** | Uses Prover to generate proofs of batched transactions for validation. | Uses Prover to generate proofs of batched transactions for validation. |
 | **Final settlement** | Transaction batches and their corresponding proofs are added to the Ethereum state. | The hash of transaction data and its proof are added to the Ethereum state, referred to as the consolidated state. |
 
-<sub><sup>*</sup>JSON RPC, Pool DB, Sequencer, Etherman, Synchronizer, State DB, Aggregator, Prover</sub>
+<sub><sup>*</sup>JSON RPC, Pool DB, Sequencer, Etherman, Synchronizer, State DB, Aggregator, Prover</sub>

docs/index.md

@@ -6,48 +6,47 @@ hide:
 
 The Polygon Wiki is the source of truth for Polygon, providing comprehensive documentation, community resources, and guides for enthusiasts and developers interested in learning about or building on Polygon.
 
-## Place Holder 
+## Place Holder
 
 Content will follow here
 
 <div class="section-nav">
 
-	<div class="section-nav-item" style="background-image:url(/img/section-nav/technology.png)">
-		<a href="zkEVM"><h2>zkEVM</h2></a>
-		<p>Learn about the technology behind the project.</p>
-	</div>
+ <div class="section-nav-item" style="background-image:url(/img/section-nav/technology.png)">
+  <a href="zkEVM"><h2>zkEVM</h2></a>
+  <p>Learn about the technology behind the project.</p>
+ </div>
 
-	<div class="section-nav-item" style="background-image:url(/img/section-nav/miden.png)">
-		<a href="miden"><h2>Miden</h2></a>
-		<p>Learn about the technology behind the project.</p>
-	</div>
+ <div class="section-nav-item" style="background-image:url(/img/section-nav/miden.png)">
+  <a href="miden"><h2>Miden</h2></a>
+  <p>Learn about the technology behind the project.</p>
+ </div>
 
-	<div class="section-nav-item" style="background-image:url(/img/section-nav/pos.png)">
-		<a href="pos"><h2>PoS</h2></a>
-		<p>Learn about the technology behind the project.</p>
-	</div>
+ <div class="section-nav-item" style="background-image:url(/img/section-nav/pos.png)">
+  <a href="pos"><h2>PoS</h2></a>
+  <p>Learn about the technology behind the project.</p>
+ </div>
 
-	<div class="section-nav-item" style="background-image:url(/img/section-nav/cdk.png)">
-		<a href="cdk"><h2>CDK</h2></a>
-		<p>Learn about the technology behind the project.</p>
-	</div>
+ <div class="section-nav-item" style="background-image:url(/img/section-nav/cdk.png)">
+  <a href="cdk"><h2>CDK</h2></a>
+  <p>Learn about the technology behind the project.</p>
+ </div>
 
 </div>
 
-## Place holder 
+## Place holder
 
-Other tyoe of content will go here. 
+Other tyoe of content will go here.
 
 <div class="section-nav">
 
-	<div class="section-nav-item" style="background-image:url(/img/section-nav/tools.png)">
-		<a href="tools"><h2>Tools</h2></a>
-		<p>Learn about the technology behind the project.</p>
-	</div>
+ <div class="section-nav-item" style="background-image:url(/img/section-nav/tools.png)">
+  <a href="tools"><h2>Tools</h2></a>
+  <p>Learn about the technology behind the project.</p>
+ </div>
 
-	<div class="section-nav-item" style="background-image:url(/img/section-nav/tutorials.png)">
-		<a href="tutorials"><h2>Tutorials</h2></a>
-		<p>Learn about the technology behind the project.</p>
-	</div>
+ <div class="section-nav-item" style="background-image:url(/img/section-nav/tutorials.png)">
+  <a href="tutorials"><h2>Tutorials</h2></a>
+  <p>Learn about the technology behind the project.</p>
+ </div>
 </div>
-

docs/learn/index.md

@@ -4,4 +4,4 @@ hide:
 	- toc
 ---
 
-TODO: learn section
+TODO: learn section

docs/miden/get-started/index.md

@@ -0,0 +1 @@
+This documentation section is under development.

docs/miden/index.md

@@ -1 +1 @@
-# Marketing html page
+Marketing html page

docs/pos/api/index.md

@@ -1 +1 @@
-This section is meant to be auto-generated soon.
+This section is meant to be auto-generated soon.

docs/pos/architecture/bor/index.md

@@ -57,4 +57,4 @@ Bor features a mechanism to relay specific events from the Ethereum chain to Bor
 2. Heimdall monitoring these events and proposing state changes through `StateReceiver.sol`.
 3. Bor committing these state changes at the start of every sprint, ensuring synchronization with the Ethereum chain's state.
 
-This state sync process is a crucial aspect of maintaining consistency between the Ethereum and Bor chains, ensuring that relevant state changes on Ethereum are reflected in Bor's state.
+This state sync process is a crucial aspect of maintaining consistency between the Ethereum and Bor chains, ensuring that relevant state changes on Ethereum are reflected in Bor's state.

docs/pos/architecture/bor/snapshots.md

@@ -2,7 +2,7 @@ When setting up a new sentry, validator, or full node server, it is recommended
 
 !!! tip
 
-    For the latest snapshot, please visit [<ins>Polygon Chains Snapshots</ins>](https://snapshot.polygon.technology/).
+    For the latest snapshot, please visit [Polygon Chains Snapshots](https://snapshot.polygon.technology/).
 
 ## Client Snapshots
 

docs/pos/concepts/index.md

@@ -1 +1 @@
-This introductory page is currently being written. In the meantime, please review documentation existing under this section, which, in all likelihood, is also in a relatively early editorial state.
+This introductory page is currently being written. In the meantime, please review documentation existing under this section, which, in all likelihood, is also in a relatively early editorial state.

docs/pos/concepts/tokens/index.md

@@ -1 +1 @@
-This introductory page is currently being written. In the meantime, please review documentation existing under this section, which, in all likelihood, is also in a relatively early editorial state.
+This introductory page is currently being written. In the meantime, please review documentation existing under this section, which, in all likelihood, is also in a relatively early editorial state.