Skip to content

Commit

Permalink
updated PP and FEP arch formatting
Browse files Browse the repository at this point in the history
  • Loading branch information
@mitchpolygon
mitchpolygon committed Jan 6, 2025
1 parent b3aba60 commit ef5ec65
Show file tree
Hide file tree
Showing 2 changed files with 46 additions and 40 deletions.
26 changes: 15 additions & 11 deletions docs/cdk/architecture/cdk-pp-highlevel-arch.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,16 +2,20 @@ The figure below depicts a simplified, high-level view of the CDK chain architec

![Figure: CDK Architecture](../../img/cdk/CDK-pessimistic-proof-chain.jpg)

## 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:
### Transaction Flow

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.
3. The transaction-pool manager proxies all transaction data to the CDK Erigon sequencer.
4. CDK Erigon sequencer executes transactions, puts the transactions in blocks, and the blocks fill up batches.
5. Any CDK Erigon RPC node syncs transaction data from the CDK Erigon sequencer.
6. AggSender gets batch data from the CDK Erigon sequencer, uses the data to generate certificates, and submits the certificates to the AggLayer RPC.
7. The AggLayer RPC checks the validity of the certificates against the transaction data in the CDK Erigon RPC node.
8. After validating the certificates, the AggLayer RPC 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 AggLayer RPC sends it to L1.
Below is a step-by-step flow of transactions from user submission to settlement on Layer 1 (L1):

1. A user connects to the chain via a **CDK Erigon RPC node** and submits a transaction.
2. The **CDK Erigon RPC node** sends the transaction data to the **transaction-pool manager**.
3. The **transaction-pool manager** proxies all transaction data to the **CDK Erigon sequencer**.
4. The **CDK Erigon sequencer** executes transactions, organizes them into blocks, and batches the blocks for further processing.
5. Any **CDK Erigon RPC node** syncs transaction data from the **CDK Erigon sequencer**.
6. The **AggSender** retrieves batch data from the **CDK Erigon sequencer**, uses this data to generate certificates, and submits the certificates to the **Agglayer RPC**.
7. The **Agglayer RPC** validates the certificates against the transaction data stored in the **CDK Erigon RPC node**.
8. Upon validating the certificates, the **Agglayer RPC** sends a request to the **SP1 prover** to generate a proof, including the necessary data (e.g., certificates).
9. Once the proof is received from the **SP1 prover**, the **Agglayer RPC** submits it to L1 for final settlement.

---
60 changes: 31 additions & 29 deletions docs/cdk/architecture/high-level-views.md
View file
Original file line number Diff line number Diff line change
@@ -1,46 +1,52 @@
The diagram below depicts a simplified architectural layout of the CDK FEP stack and indicates at a high level how components communicate.
The diagram below depicts a simplified architectural layout of the CDK FEP config and indicates at a high level how components communicate.

![High level view of CDK stack](../../img/cdk/cdk-stack.svg)
![High level view of CDK config](../../img/cdk/cdk-stack.svg)

---

### Component interactions

- The CLI tool is the starting point. Developers, or chain administrators in particular, can use the CLI tool to build and configure chains in various modes of operation, such as validiums and rollups.
- Once a chain is configured with the CLI, users can submit transactions through the CDK Erigon RPC node. These transactions are relayed to the `tx-pool manager` before the sequencer selects and executes them.
- The sequencer sequences transactions batches and synchronizes data with the RPC node.
- The sequencer sender reads batch data from the RPC node.
- The aggregator reads batch data from the sequencer data stream.
- The sequencer sender persists data into the L1 smart contract domain for rollup mode and into DAC nodes for validium mode operations.
- The aggregator sends batches to the prover and receives proofs in return. Together with the prover, it aggregates the proofs into batches before submitting the final proofs to the AggLayer or L1, depending on the chosen settlement layer.
- Users interact with the bridge service via the bridge UI or API.
- The AggLayer verifies proofs and interacts with the L1 smart contracts.
- The **CLI tool** is the starting point. Developers, or chain administrators in particular, use the CLI tool to build and configure chains in various modes of operation, such as validiums and rollups.
- Once a chain is configured with the CLI, users can submit transactions through the **CDK Erigon RPC node**. These transactions are relayed to the `tx-pool manager` before the sequencer selects and executes them.
- The **sequencer** sequences transaction batches and synchronizes data with the **RPC node**.
- The **sequencer sender** reads batch data from the RPC node.
- The **aggregator** reads batch data from the sequencer data stream.
- The sequencer sender persists data into the **L1 smart contract domain** for rollup mode and into **DAC nodes** for validium mode operations.
- The aggregator sends batches to the **prover** and receives proofs in return. Together with the prover, it aggregates the proofs into batches before submitting the final proofs to the **Agglayer** or L1, depending on the chosen settlement layer.
- Users interact with the **bridge service** via the **bridge UI** or **API**.
- The Agglayer verifies proofs and interacts with the **L1 smart contracts**.

---

### User data flow

The following diagram is a sequential depiction of the user data flow for the CDK FEP stack in validium mode using a mock prover and having an AggLayer connection.
The following diagram sequentially depicts the user data flow for the CDK FEP config in validium mode using a mock prover and an Agglayer connection.

![High level view of CDK user data flow](../../img/cdk/cdk-user-data-flow.svg)

#### Sequential interactions

1. User sends a transaction to the CDK Erigon RPC node.
2. The CDK Erigon RPC node proxies the data to the CDK Erigon sequencer node and syncs the batch data between the sequencer and the RPC nodes.
1. The user sends a transaction to the **CDK Erigon RPC node**.
2. The **CDK Erigon RPC node** proxies the data to the **CDK Erigon sequencer node** and syncs the batch data between the sequencer and the RPC nodes.
3. The sequencer sequences the transaction batches.
4. The sequencer sender reads batches from the RPC node.
5. In validium mode only, the sequencer sender persists transaction data into the DAC nodes.
6. The sequencer sender sequences the batches into the L1 smart contracts.
7. The aggregator reads batches from the sequencer data stream.
8. The aggregator sends batches to the provers.
9. The aggregator submits the final proof to the AggLayer.
10. The AggLayer submits the final proof to the L1 smart contract domain.
4. The **sequencer sender** reads batches from the RPC node.
5. In validium mode only, the sequencer sender persists transaction data into the **DAC nodes**.
6. The sequencer sender sequences the batches into the **L1 smart contracts**.
7. The **aggregator** reads batches from the sequencer data stream.
8. The aggregator sends batches to the **provers**.
9. The aggregator submits the final proof to the **Agglayer**.
10. The Agglayer submits the final proof to the **L1 smart contract domain**.

---

```mermaid
sequenceDiagram
participant User
participant ErigonRPC as CDK Erigon RPC Node
participant Sequencer as CDK Erigon Sequencer Node
participant SeqSender as Sequence Sender
participant SeqSender as Sequencer Sender
participant Aggregator
participant AggLayer
participant Agglayer
participant DACNodes as DAC Nodes
participant Prover
participant L1 as L1 Smart Contracts
Expand All @@ -54,9 +60,5 @@ sequenceDiagram
Aggregator->>Prover: Send batches to Prover
Prover->>Aggregator: Return proofs
Aggregator->>Aggregator: Aggregate the proofs
Aggregator->>AggLayer: Submit final proof
AggLayer->>L1: Submit final proof to L1 Smart Contract Domain
```

!!! tip
Detailed AggLayer flows will be published soon.
Aggregator->>Agglayer: Submit final proof
Agglayer->>L1: Submit final proof to L1 Smart Contract Domain

0 comments on commit ef5ec65

Please sign in to comment.