zkNode overview

Who this is for: operators trying to understand the "zkNode" / validium role in Lumia's architecture before deciding whether to run one. For the actual deployable node most operators run, see RPC node overview and its deployment tutorial.

You should already know: Chain Security, covering the sequencer and zkProvers concepts referenced below.

A naming note: Lumia's engineering material does not use the term "zkNode": it describes the equivalent roles as the sequencer (block production, key-gated, not self-runnable), the prover/executor (proof generation and execution), and RPC replicas (read/verification nodes, permissionless).

Why Lumia isn't a validator network

Lumia Prism is a Polygon CDK validium. There's no consensus protocol and no validator set: exactly one trusted sequencer builds every block, with no voting, no leader election, no quorum. State validity is enforced cryptographically instead of socially: a prover generates a ZK validity proof for each batch, and an L1 verifier contract checks it. An invalid state transition simply cannot produce a valid proof. There's no equivalent role here.

The prover / executor role

The component that actually does proof work runs in two capacities:

• Executor: stateless EVM execution used by the sequencer to close batches.

• Prover: generates the ZK proofs submitted to L1.

It's also only useful to the network if the live sequencer is actually configured to call it, which is an operational integration point with no confirmed self-service path.

What you can actually run yourself

If what you want is a node that syncs Lumia's validium state and verifies it independently (which is what most people mean when they ask about running a "zk node"), that's the RPC node: a permissionless read replica that re-executes and verifies every block itself rather than trusting the sequencer's output. See its deployment tutorial for setup.