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:
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:
Users: They connect to the zkEVM network via an RPC node (e.g., MetaMask) and submit their transactions to the Pool DB.
Pool DB: This database stores the transactions submitted by users, waiting to be included in a batch by the Sequencer.
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.
Synchronizer: This component updates the State DB by fetching data from Ethereum through Etherman.
Etherman: It is a low-level component that handles all interactions with the L1 network and smart contracts.
State DB: This database permanently stores state data (excluding Merkle trees).
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.
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
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:
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.
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.
Last updated
