Lumia - The RWA Chain
  • What is Lumia Chain?
  • Polygon
    • CDK
    • AggLayer
    • Miden
    • Passport
  • ⛓️Lumia
    • Architecture
    • Roadmap
    • LUMIA Token
      • Token Swap Guide (UI)
      • Token Swap Guide (SmartContract)
    • 普通话 - LUMIA 代币
    • rwaUSD
    • HyperNodes
    • zkProvers
      • zkProver Network (zkN) via Gevolut
    • Sequencer
      • Decentralised Sequencer Network (DCN)
    • Data Availability
      • Validium
      • Volition (Enhanced Validium)
      • What is Avail DA?
        • How does AvailDA Scale?
        • Benefits of AvailDA
      • Lumia DA - Lightclient Nodes
    • Lumia Stream
      • Node Owned Liquidity
      • Liquidity Restaking
    • Interoperability
      • Polygon AggLayer
      • HyperLane
    • KYC
    • Chain & Account Abstraction with Intents
      • Particle Connect on Lumia
    • Real World Assets (RWA) on Lumia
  • 🛠️Build
    • Introduction
      • Accounts and Wallets
      • Setup Metamask with Lumia Chain
      • Bridge to/ from Lumia L2
      • Setup FoxWallet with Lumia Chain
    • Explorers
    • Build Environment
      • RPC
        • RPC Guide
      • Add Lumia Network to MetaMask
      • Testnet Tokens
    • SmartContracts
      • Deployment
        • Hardhat
        • Truffle
      • Verify
        • Hardhat
        • Truffle
      • Interact
      • Relay
      • Web3 Functions
    • On-Chain KYC
    • Oracles
      • API3
      • Supra
      • Commodity Prices
    • Indexers
      • Indexing with TheGraph
      • Indexing with Goldsky
    • zkNode
      • Run Local Validium Node
      • Run an RPC
        • JSON RPC Endpoints
      • Gas Fees
    • DA Lightclient
    • CDK Repos
    • rwaUSD
      • rwaUSD: Overcollateralizing
      • rwaUSD: Bridging
    • FAQs
Powered by GitBook
On this page
  • The Core Software for Running a zkEVM Node
  • zkNode Roles and Required Services

Was this helpful?

  1. Build

zkNode

PreviousIndexing with GoldskyNextRun Local Validium Node

Last updated 1 year ago

Was this helpful?

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:

  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

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.

🛠️
zkEVM RPC endpoints
zkEVM RPC Custom endpoints documentation
Based off PolygonCDK