> For the complete documentation index, see [llms.txt](https://docs.lumia.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lumia.org/ecosystem/lumia/architecture.md).

# Architecture

**Who this is for:** developers evaluating Lumia as a deployment target, and issuers who want to understand what's actually underneath the chain before they rely on it. **You should already know:** nothing. This page starts from first principles and ends at Lumia specifics.

### What is a blockchain

A blockchain is a way for mutually distrusting parties to agree on a single, ordered history of state changes without a central authority adjudicating that agreement. Every participant can independently verify that history is correct, and no single party can unilaterally rewrite it. That's the entire problem a blockchain solves: shared, tamper-evident state, agreed on by a group that doesn't have to trust each other individually.

Two things have to be true for that to work. First, someone or something has to decide the order transactions happen in: two conflicting transactions (spending the same funds twice, say) can't both be valid, so an order has to be picked. Second, everyone has to be able to check that the resulting state actually followed from applying those transactions correctly, without redoing all the work a central party did. How a system solves the first problem is what's usually called consensus. How it solves the second is what determines whether "trust the ledger" means "trust an institution" or "trust math."

### What is consensus, and why it matters

Consensus is the mechanism a set of participants uses to agree on that one ordering (which transactions happened, and in what sequence) even when some participants might be offline, slow, or actively lying. A classic blockchain (Bitcoin, pre-Merge Ethereum) solves this with a large, permissionless, economically-incentivized validator or miner set: anyone can join, and the system is designed so that no small coalition can control the outcome without controlling a majority of the network's staked or computed resources.

That design buys strong decentralization, but it's expensive: every participant in that consensus set has to process every transaction, which caps throughput. A large family of newer chains (rollups and validity chains, Layer 2s built on top of a base chain like Ethereum) takes a different approach to the same two problems. Instead of a large validator set re-executing everything, a much smaller set of parties (sometimes just one) proposes the ordering, and correctness is proven mathematically rather than re-checked by majority vote. The base chain underneath doesn't need to trust the L2's operator; it verifies a proof. This trades away validator-set decentralization at the L2 layer in exchange for inheriting the base chain's security for correctness, plus much higher throughput. Understanding which trade a given chain has made, and where it still depends on a smaller, less decentralized set of actors, is the actual question to ask about any L2's architecture.

### Lumia specifics

Lumia is running a **zkEVM**: an Ethereum Virtual Machine-compatible execution environment whose state transitions are proven correct using zero-knowledge cryptography rather than re-executed by a large validator set. See [`/reference/networks`](/run-a-node/network-parameters.md) for mainnet's chain ID and connection details.

Concretely, that means Lumia does not run a traditional consensus protocol with a large validator set voting on blocks. An invalid state transition cannot produce a valid proof, so correctness rests on the math, not on a vote. The trade-off is that liveness (the chain continuing to produce blocks at all) currently depends on the sequencer being up, which is the accepted centralization cost of this architecture family.

Getting a transaction from a user's wallet to final settlement, at a high level: a transaction is submitted, ordered and executed by the sequencer, and included in an L2 block; batches of blocks are committed and their correctness proven; that proof, along with the data needed to reconstruct the batch, is settled against Ethereum L1.

```mermaid
flowchart LR
  W["User wallet"] --> S["Sequencer<br/>orders and executes"]
  S --> B["L2 block"]
  B --> BA["Batch of blocks"]
  BA --> P["Prover<br/>generates validity proof"]
  P --> L1["Ethereum L1<br/>verifies the proof"]
  BA -. "batch data made available" .-> L1
  L1 --> F["Settled"]
```

Three things extend that base picture:

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Chain Features</strong></td><td>Account abstraction (how a user interacts with the chain without managing a raw private key and gas directly) and interoperability (how Lumia connects to other chains).</td><td><a href="https://app.gitbook.com/s/chmhPiVNAafGw48c4oU2/ecosystem/lumia/architecture/chain-features">https://app.gitbook.com/s/chmhPiVNAafGw48c4oU2/ecosystem/lumia/architecture/chain-features</a></td></tr><tr><td><strong>Data Availability</strong></td><td>Where the transaction data behind a proof actually lives, and why that choice matters for security and cost.</td><td><a href="https://app.gitbook.com/s/chmhPiVNAafGw48c4oU2/ecosystem/lumia/architecture/data-availability">https://app.gitbook.com/s/chmhPiVNAafGw48c4oU2/ecosystem/lumia/architecture/data-availability</a></td></tr><tr><td><strong>Lumia's chain framework and settlement</strong></td><td>What Lumia inherits from being built on Polygon's CDK, and what AggLayer membership specifically adds.</td><td><a href="https://app.gitbook.com/s/chmhPiVNAafGw48c4oU2/ecosystem/lumia/architecture/polygon-cdk-and-agglayer/the-lumia-chain-framework-and-settlement">https://app.gitbook.com/s/chmhPiVNAafGw48c4oU2/ecosystem/lumia/architecture/polygon-cdk-and-agglayer/the-lumia-chain-framework-and-settlement</a></td></tr></tbody></table>