# zkNode

### The Core Software for Running a zkEVM Node

zkNode is the essential software required to run a zkEVM node on the Lumia L2 network. It acts as a client that allows network users to synchronize and stay updated with the state of the Lumia L2 zkEVM. The two main factors that influence the L2 state and its finality are the trusted Sequencer and the trusted Aggregator.

#### zkNode Architecture and Transaction Flow

The zkNode architecture follows a modular design, as illustrated in the diagram below:

<figure><img src="/files/bkhpPotAs6jRx80NvTns" alt=""><figcaption><p>Based off PolygonCDK</p></figcaption></figure>

To understand the zkNode architecture, it's crucial to grasp the primary path taken by transactions, starting from when users submit them to the zkEVM network until they are finalized and incorporated into the L1 state.

Lumia L2 zkEVM achieves this through the interaction of several key components:

1. **Users**: They connect to the zkEVM network via an RPC node (e.g., MetaMask) and submit their transactions to the Pool DB.
2. **Pool DB**: This database stores the transactions submitted by users, waiting to be included in a batch by the Sequencer.
3. **Sequencer**: This node fetches transactions from the Pool DB, validates them, and puts valid ones into a batch. It submits the batches to L1 and sequences them for inclusion in the L1 state.
4. **Synchronizer**: This component updates the State DB by fetching data from Ethereum through Etherman.
5. **Etherman**: It is a low-level component that handles all interactions with the L1 network and smart contracts.
6. **State DB**: This database permanently stores state data (excluding Merkle trees).
7. **Aggregator**: This node produces zero-knowledge proofs (ZK-proofs) attesting to the integrity of the Sequencer's proposed state changes. It utilizes the Prover for this purpose.
8. **Prover**: This complex cryptographic tool generates ZK-proofs for hundreds of batches and aggregates them into a single ZK-proof, which is published as the validity proof.

### zkNode Roles and Required Services

&#x20;The zkNode software supports the execution of multiple roles, each requiring different services to function properly. While most services can run on separate instances, the JSON RPC can have multiple instances (all other services must have a single instance).

#### RPC Endpoints (Open to Any User):

* JSON RPC: Can run on separate instances and have multiple instances.
* Synchronizer: Single instance that can run on a separate instance.
* Executor & Merkle Tree: Can run on a separate instance.
* State DB: PostgreSQL that can run on a separate instance.

RPC Endpoints and its relevant documentation can be found below:

* [`zkEVM RPC endpoints`](https://github.com/0xPolygonHermez/zkevm-node/blob/develop/docs/json-rpc-endpoints.md)
* [`zkEVM RPC Custom endpoints documentation`](https://github.com/0xPolygonHermez/zkevm-node/blob/develop/docs/zkEVM-custom-endpoints.md)

#### Trusted Sequencer (Single Entity Role):

* **JSON RPC**: Can run on separate instances and have multiple instances.
* **Sequencer & Synchronizer**: Single instance that needs to run together.
* **Executor & Merkle Tree**: Can run on a separate instance.
* **Pool DB**: PostgreSQL that can run on a separate instance.
* **State DB**: PostgreSQL that can run on a separate instance.

#### Aggregator (Open to Anyone):

* **Synchronizer**: Single instance that can run on a separate instance.
* **Executor & Merkle Tree**: Can run on a separate instance.
* **State DB**: PostgreSQL that can run on a separate instance.&#x20;
* **Aggregator**: Single instance that can run on a separate instance.
* **Prover**: Single instance that can run on a separate instance.
* **Executor**: Single instance that can run on a separate instance.

By understanding the zkNode architecture, transaction flow, and the roles of different components, users can effectively participate in the Lumia L2 zkEVM network and contribute to its smooth operation.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.lumia.org/build/zknode.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.