CDK PP Docs Review Env: DO NOT MERGE!!!

docs/cdk/architecture/cdk-pp-highlevel-arch.md

@@ -4,7 +4,7 @@ The figure below depicts a simplified, high level view of the CDK PP chain archi
 
 ## Transaction flow
 
-Here is a step by step flow of transactions starting from when users submit transactions up to when the transactions are settled in L1. 
+Here is a step by step flow of transactions starting from when users submit transactions up to when the transactions are settled in L1.
 
 1. A user connects to the chain via a CDK Erigon RPC node and submits a transaction.
 2. CDK Erigon RPC node sends the transaction data to the transaction-pool manager.
@@ -14,49 +14,4 @@ Here is a step by step flow of transactions starting from when users submit tran
 6. AggSender gets batch data from the CDK Erigon sequencer, uses the data to generate certificates, and submits the certificates to the JSON-RPC API.
 7. The JSON-RPC API checks validity of the certificates against the transaction data in the CDK Erigon RPC node.
 8. After validating the certificates, the JSON-RPC API sends a request to generate a proof, together with the necessary data (including the certificates), to the SP1 prover. 
-9. Once the proof is received from the SP1 prover, the JSON-RPC API sends it to L1.  
-
-
-
-## Sequential diagram
-
-The flow of data is depicted in the squential diagram below. 
-
-1. User submits a tx to the CDK Erigon RPC node.
-2. The CDK Erigon RPC node sends tx data to the tx-pool man.
-3. The tx-pool man proxies tx data to the CDK Erigon sequencer.
-4. CDK Erigon sequencer executes transactions.
-5. CDK Erigon sequencer syncs tx data with another CDK Erigon RPC node.
-6. AggSender gets batch data from the CDK Erigon sequencer.
-7. AggSender submits certificates to the JSON-RPC API.
-8. JSON-RPC API checks validity of the certificates.
-9. JSON-RPC API requests a proof from SP1 prover.
-10. SP1 prover sends back a proof.
-11. JSON-RPC API sends proof to L1.
-
-
-
-```mermaid
-sequenceDiagram
-    participant User
-    participant ErigonRPC1 as RPC node 1
-    participant tx-pool-man as tx-pool manager
-    participant Sequencer as Sequencer node
-    participant ErigonRPC2 as RPC node 2
-    participant AggSender as AggSender
-    participant API as JSON-RPC API
-    participant SP1-prover as SP1 prover
-    participant L1 as L1
-
-    User->>ErigonRPC1: submits tx
-    ErigonRPC1->>tx-pool-man: sends tx data 
-    tx-pool-man->>Sequencer: proxies tx data
-    Sequencer->>Sequencer: sequences transactions
-    Sequencer->>ErigonRPC2: syncs data
-    AggSender->>Sequencer: reads batch data
-    AggSender->>API: sends certificates
-    API->>ErigonRPC2: checks validity
-    API->>SP1-prover: requests proof
-    SP1-prover->>API: returns proof 
-    API->>L1: submits proof
-```
+9. Once the proof is received from the SP1 prover, the JSON-RPC API sends it to L1.

docs/cdk/getting-started/cli-tool.md

@@ -72,6 +72,10 @@ Options:
 cdk erigon --config /etc/cdk/cdk-node-config.toml --chain genesis.json
 ```
 
+```
+cdk erigon --config /etc/cdk/cdk-node-config.toml --chain genesis.json
+```
+
 ### `cdk versions`
 
 The above command generates all the required configuration files for cdk-erigon on the fly and runs the node.

docs/cdk/releases/pp-intro.components.md

@@ -0,0 +1,51 @@
+Developers can use the CDK stack to build layer 2 chains that are natively connected to the AggLayer (**CDK sovereign chains**).
+
+Out of the box, CDK sovereign chains are built to connect to the AggLayer, and so they rely on a type of ZK-proof called a _pessimistic proof_ to finalize transactions.
+
+## What is a pessimistic proof?
+
+A *pessimistic proof* (PP) is a zero-knowledge proof attesting to the correctness of a chain’s bridge transitions and the collateralization of all withdrawals.
+
+These proofs enable CDK sovereign chains that interoperate via the [unified bridge](../../zkEVM/architecture/unified-LxLy/index.md) to achieve trustless cross-chain security. 
+
+Pessimistic proofs ensure that CDK sovereign chains connected to the [AggLayer](../../agglayer/overview.md) interoperate securely, providing a robust mechanism for cross-chain interactions.
+
+---
+
+## CDK sovereign chain components
+
+The architectural components of CDK sovereign chains are detailed in the table below:
+
+| Component                | CDK Stack                                                    | Notes                                                        |
+| ------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| Node = RPC and sequencer | [cdk-erigon](https://github.com/0xPolygonHermez/cdk-erigon)  | Customizable, commonly:<br/>\- Sequencer = 1 node<br/>\- RPC = multiple nodes |
+| Contracts                | <a href=https://github.com/0xPolygonHermez/zkevm-contracts>zkevm-contracts</a> | Includes L1 contracts for functionality                     |
+| CLI                      | [cdk](https://github.com/0xPolygon/cdk)                      | Included in [CDK](https://github.com/0xPolygon/cdk) repo     |
+| AggSender                | <a href=https://github.com/0xPolygon/cdk>cdk</a>             | A sub-component of the CDK client that sends certificates to the AggLayer node |
+| Tx pool manager          | <a href=https://github.com/0xPolygon/zkevm-pool-manager>zkevm-pool-manager</a> | Manages transaction storage                                  |
+
+---
+
+## Component descriptions
+
+Here are brief descriptions of the key CDK components:
+
+- **CDK Erigon Node**: A fork of [Erigon](https://github.com/ledgerwatch/erigon), providing:
+  - Multiple RPC nodes for transaction submission.
+  - A sequencer for executing transactions, and creating blocks and batches.
+- **Contracts**: Smart contracts deployed on L1 to ensure full implementation and functionality:
+    - `PolygonRollupManager`
+    - `PolygonZkEVMBridgeV2`
+    - `PolygonZkEVMGlobalExitRootV2`
+    - `FflonkVerifier`
+    - `PolygonZkEVMDeployer`
+    - `PolygonZkEVMTimelock`
+- **CLI tool**: A command-line tool that simplifies deploying and configuring CDK components.
+- **AggSender**: A functionality within the CDK client that aggregates necessary data and sends certificates to the AggLayer node for proof generation. It works in conjunction with other sub-components, such as the bridge syncer.
+- **Transaction pool manager**: Handles storage of user-submitted transactions.
+- **Succinct's SP1 prover**: A cryptographic tool that generates ZK-proofs using Rust-based inputs. The prover resides in the AggLayer and is not directly connected to CDK sovereign chains.
+- **AggLayer node**: A critical component of the AggLayer that interfaces between CDK sovereign chains and the SP1 prover. It handles certificate validation and proof requests.
+
+The AggSender within the CDK client communicates with the AggLayer node to facilitate proof generation and finalization of transactions.
+
+See the high level view of the architecture [here](../architecture/cdk-pp-highlevel-arch.md)

docs/index.md

@@ -273,4 +273,4 @@ hide:
 			</div>
 		</div>
 	</section>
-</div>
+</div>