You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/cdk/architecture/cdk-pp-highlevel-arch.md
+2-47Lines changed: 2 additions & 47 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ The figure below depicts a simplified, high level view of the CDK PP chain archi
4
4
5
5
## Transaction flow
6
6
7
-
Here is a step by step flow of transactions starting from when users submit transactions up to when the transactions are settled in L1.
7
+
Here is a step by step flow of transactions starting from when users submit transactions up to when the transactions are settled in L1.
8
8
9
9
1. A user connects to the chain via a CDK Erigon RPC node and submits a transaction.
10
10
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
14
14
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.
15
15
7. The JSON-RPC API checks validity of the certificates against the transaction data in the CDK Erigon RPC node.
16
16
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.
17
-
9. Once the proof is received from the SP1 prover, the JSON-RPC API sends it to L1.
18
-
19
-
20
-
21
-
## Sequential diagram
22
-
23
-
The flow of data is depicted in the squential diagram below.
24
-
25
-
1. User submits a tx to the CDK Erigon RPC node.
26
-
2. The CDK Erigon RPC node sends tx data to the tx-pool man.
27
-
3. The tx-pool man proxies tx data to the CDK Erigon sequencer.
28
-
4. CDK Erigon sequencer executes transactions.
29
-
5. CDK Erigon sequencer syncs tx data with another CDK Erigon RPC node.
30
-
6. AggSender gets batch data from the CDK Erigon sequencer.
31
-
7. AggSender submits certificates to the JSON-RPC API.
32
-
8. JSON-RPC API checks validity of the certificates.
33
-
9. JSON-RPC API requests a proof from SP1 prover.
34
-
10. SP1 prover sends back a proof.
35
-
11. JSON-RPC API sends proof to L1.
36
-
37
-
38
-
39
-
```mermaid
40
-
sequenceDiagram
41
-
participant User
42
-
participant ErigonRPC1 as RPC node 1
43
-
participant tx-pool-man as tx-pool manager
44
-
participant Sequencer as Sequencer node
45
-
participant ErigonRPC2 as RPC node 2
46
-
participant AggSender as AggSender
47
-
participant API as JSON-RPC API
48
-
participant SP1-prover as SP1 prover
49
-
participant L1 as L1
50
-
51
-
User->>ErigonRPC1: submits tx
52
-
ErigonRPC1->>tx-pool-man: sends tx data
53
-
tx-pool-man->>Sequencer: proxies tx data
54
-
Sequencer->>Sequencer: sequences transactions
55
-
Sequencer->>ErigonRPC2: syncs data
56
-
AggSender->>Sequencer: reads batch data
57
-
AggSender->>API: sends certificates
58
-
API->>ErigonRPC2: checks validity
59
-
API->>SP1-prover: requests proof
60
-
SP1-prover->>API: returns proof
61
-
API->>L1: submits proof
62
-
```
17
+
9. Once the proof is received from the SP1 prover, the JSON-RPC API sends it to L1.
Developers can use the CDK stack to build layer 2 chains that are natively connected to the AggLayer (**CDK sovereign chains**).
2
+
3
+
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.
4
+
5
+
## What is a pessimistic proof?
6
+
7
+
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.
8
+
9
+
These proofs enable CDK sovereign chains that interoperate via the [unified bridge](../../zkEVM/architecture/unified-LxLy/index.md) to achieve trustless cross-chain security.
10
+
11
+
Pessimistic proofs ensure that CDK sovereign chains connected to the [AggLayer](../../agglayer/overview.md) interoperate securely, providing a robust mechanism for cross-chain interactions.
12
+
13
+
---
14
+
15
+
## CDK sovereign chain components
16
+
17
+
The architectural components of CDK sovereign chains are detailed in the table below:
Here are brief descriptions of the key CDK components:
32
+
33
+
-**CDK Erigon Node**: A fork of [Erigon](https://github.com/ledgerwatch/erigon), providing:
34
+
- Multiple RPC nodes for transaction submission.
35
+
- A sequencer for executing transactions, and creating blocks and batches.
36
+
-**Contracts**: Smart contracts deployed on L1 to ensure full implementation and functionality:
37
+
-`PolygonRollupManager`
38
+
-`PolygonZkEVMBridgeV2`
39
+
-`PolygonZkEVMGlobalExitRootV2`
40
+
-`FflonkVerifier`
41
+
-`PolygonZkEVMDeployer`
42
+
-`PolygonZkEVMTimelock`
43
+
-**CLI tool**: A command-line tool that simplifies deploying and configuring CDK components.
44
+
-**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.
45
+
-**Transaction pool manager**: Handles storage of user-submitted transactions.
46
+
-**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.
47
+
-**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.
48
+
49
+
The AggSender within the CDK client communicates with the AggLayer node to facilitate proof generation and finalization of transactions.
50
+
51
+
See the high level view of the architecture [here](../architecture/cdk-pp-highlevel-arch.md)
0 commit comments