Merge pull request 0xPolygon#63 from 0xPolygon/km/style_scan

Km/style scan

Author: Nadim Kobeissi

docs/cdk/concepts/dac.md

@@ -3,11 +3,11 @@ Data availability in blockchain technology refers to whether or not transaction
 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.
 
 !!! info "Recommended resource"
-    See Ethereum.org's discussion on [data availability](https://ethereum.org/en/developers/docs/data-availability/).
+    See [Ethereum.org's discussion on data availability](https://ethereum.org/en/developers/docs/data-availability/).
 
-## Data availability committees
+## Data availability committee (DAC)
 
-Polygon's CDK validium has an optional data availability committee (DAC).
+Polygon's CDK validium has an optional DAC.
 
 A DAC is an off-chain network of nodes that implements a data storage layer in a modular chain architecture like CDK. Some advantages are:
 
@@ -24,15 +24,15 @@ The CDK validium DAC is a secure consortium of nodes that ensures off-chain data
 
 ## DAC data flow
 
-![CDK validium DAC dataflow](../../img/cdk/cdk-val-dac-02.png)
+![CDK validium data availability dataflow](../../img/cdk/cdk-val-dac-02.png)
 
 The DAC works together with the sequencer to control the flow of data. The process can be broken down as follows:
 
 1. **Batch formation**: The sequencer collects user transactions and organizes them into batches.
 
 2. **Batch authentication**: Once the batches are assembled, they are authenticated. The sequencer forwards the batch data and its corresponding hash to the DAC.
 
-3. **Data validation and storage**:  The DAC nodes independently validate the batch data. Once validated, the hash is stored in each node's local database for future reference.
+3. **Data validation and storage**: The DAC nodes independently validate the batch data. Once validated, the hash is stored in each node's local database for future reference.
 
 4. **Signature generation**: Each DAC node generates a signature for the batch hash. This serves as an endorsement of the batch's integrity and authenticity.
 

docs/cdk/concepts/index.md

@@ -1,3 +1,3 @@
-This section covers some of the basic concepts needed to understand the CDK setting, which is a platform designed to allow developers to choose between validium and zk-rollup architectures.
+This section explores basic concepts underpinning CDK; a platform designed to allow developers to choose between validium and rollup architectures.
 
-Concepts such as a rollup, a validium and data availability committee (DAC) are defined. Implications of off-chain data availability are briefly discussed.
+The section currently defines concepts such as rollup, validium, and data availability committee (DAC). Some implications of off-chain data availability are mentioned.

docs/cdk/concepts/rollup.md

@@ -3,4 +3,4 @@ Rollups are blockchain layer 2 scaling solutions that speed up the network by *r
 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 on-chain.
 
 !!! 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/quickstart-rollup.md

@@ -1,5 +1,5 @@
 ## Run a CDK rollup locally
 
-The following documentation is a quickstart guide for deploying a CDK rollup on your local machine.
+The following link takes you to a quickstart guide for deploying a CDK rollup on your local machine.
 
 [https://github.com/0xPolygonHermez/zkevm-node/blob/develop/docs/running_local.md](https://github.com/0xPolygonHermez/zkevm-node/blob/develop/docs/running_local.md)

docs/cdk/how-to/index.md

@@ -1,4 +1,4 @@
-This section describes how to manage policies pertaining to data access in the case of a Validium.
+This section describes how to manage policies pertaining to data access in the case of a validium.
 
-Validia store data off-chain, and with this option comes the need to manage both the data and access to the data. This is facilitated through policies that stipulate which addresses can have access to data. Lists of addresses, such as the Allowlist and Denylist, are therefore kept to exclude or include certain addresses to having access.
+Validium architectures store data off-chain, and with this option comes the need to manage both the data and access to the data. This is facilitated through policies that stipulate which addresses can have access to data. Lists of addresses, such as the Allowlist and Denylist, are therefore kept to exclude or include certain addresses to having access.
 

docs/cdk/spec/index.md

@@ -2,6 +2,6 @@ This section gives a comparison between a validium and a zk-rollup.
 
 The main difference is the fact that a validium has a data availability layer whereas a zk-rollup does not. This difference alone is the reason for the substantially reduced gas fees for a validium compared to the zk-rollup.
 
-However, with this off-chain data availability, there is a trade-off between gas fees and security. Unlike in the zk-rollup, where forced batches are activated, the validium suffers from the possibility for the sequencer to go offline or the DAC to collude among themselves to withold state data.
+However, with this off-chain data availability, there is a trade-off between gas fees and security. Unlike in the zk-rollup, where forced batches are activated, the validium suffers from the possibility for the sequencer to go offline or the DAC to collude among themselves to withhold state data.
 
 What remains common between the two architectures is the generation of proofs.