Architecture

LinethLineth (Formerly the Linea Stack) The open-source ZK-rollup stack, codebase, and technical protocol that's the foundation of Linea Mainnet. Operators can deploy this stack to launch their own Ethereum-compatible L2 or L3 networks. architecture supports a configurable protocol that delivers developer-ready L2 and L3 networks, scaling Ethereum by providing an Ethereum-equivalent execution environment.

OperatorsOperator The entity or consortium responsible for deploying, administering, and running the network infrastructure, contracts, keys, access controls, and operational procedures for a network built on Lineth. and network designers configure their stack to shape protocol behavior and trust assumptions, for example, choosing the data availability and finalization layer design.

Transaction lifecycle

Lineth carries a transaction from submission to finalization in four stages:

1. Execute transactions

Transactions enter the mempool through the RPC entrypoint of a node. The sequencerSequencer The set of Linea Besu plugins responsible for ordering, building, and executing blocks in a way that allows the subsequent ZK proof to be made, including the tracer. The sequencer is a plugin set rather than a standalone process; a node that runs it alongside a Maru validator is a sequencer node. validates, orders, and executes them into blocks. Block building runs on a sequencer nodeSequencer node A node that pairs a Maru validator with a Linea Besu execution client running the sequencer plugins. This pairing is what produces canonical blocks: Maru handles consensus, and Linea Besu orders, builds, and executes the block. Some materials use "validator" and "sequencer" interchangeably. Here, the validator is the Maru process, the sequencer is the Linea Besu plugin set, and the sequencer node is the two together.: a Maru validatorMaru validator A Maru consensus client that belongs to the QBFT validator set and proposes and votes on blocks. Each Maru validator requires its own dedicated Linea Besu execution client running the sequencer plugins, which builds the payload Maru then signs and broadcasts. A validator can also drive additional follower execution clients. paired with a Linea BesuLinea Besu A build of the Besu execution client, extended with Lineth plugins such as the sequencer and tracer that add ZK-rollup functionality. Linea Besu is required to propose blocks and to generate traces, so every sequencer node must run it. Nodes that only import blocks or serve standard Ethereum JSON-RPC can run any Ethereum execution client. execution client. It enforces Lineth validity conditions, including a profitability threshold.

2. Batch and trace blocks

The state managerState manager The Lineth component that maintains the network's state representation for proof generation and recovery. It consists of a Besu node with the Shomei plugin and a Shomei node that uses sparse Merkle trees to track state changes block by block, generate Merkle proofs for state transitions, and serve linea_getProof RPC requests. updates the state representation. The tracerTracer The Linea Besu plugin, part of the sequencer, that generates the execution traces the prover needs to create zero-knowledge proofs. The tracer provides trace counts for batch-size calculations and produces conflated trace files as prover input. generates the execution traces for those blocks. The coordinatorCoordinator Lineth's coordination module for batching, proof generation, and finality submission. The coordinator monitors block production, manages conflation deadlines, batches blocks, combines batches into blobs, orchestrates execution, compression, and aggregation proofs, and submits proofs and data to the finalization layer. then groups the blocks into batches. That grouping is conflationConflation The process of combining two or more blocks' worth of transactions into one data set before proof generation. Conflation lets Lineth produce one Merkle tree update and one zero-knowledge proof per batch instead of per block, which makes the proving system more efficient. The coordinator decides where batch boundaries fall, using trace counts from the tracer, and the trace data itself is generated inside the execution client..

3. Generate validity proofs

The proverProver The Lineth component that generates ZK proofs of state transitions, handling proof-generation requests from the coordinator and Linea Besu. The prover produces three types of proofs (execution, compression, and aggregation) and combines them into a zk-SNARK that the finalization layer verifies. Provers may be scaled horizontally to meet throughput requirements. generates execution proofs for the batches. The coordinator combines those batches into blobs, and the prover generates compression proofs.

4. Submit for data availability and finalization

The coordinator submits the data and the proofs to the finalization layerFinalization layer The blockchain where a Lineth deployment submits proofs and state commitments for verification and hard finality. If the finalization layer is Ethereum (an L1), the deployment is an L2. If the finalization layer is Linea (an L2), the deployment is an L3.. The finalization contract validates the zk-SNARKzk-SNARK (Zero-Knowledge Succinct Non-interactive Argument of Knowledge) A type of ZK proof where the prover and verifier don't have to interact. With zk-SNARKs, you can verify 1 transaction or 1 billion transactions in the same amount of time. proofs and records the state roots. After verification and any configured delay, transactions reach settlement finality on the selected finalization layer.

Data availability is the guarantee that the transaction data underlying these proofs remains accessible to the parties who need it to verify or reconstruct historical state. How data availability is provided depends on the deployment model:

• For a rollupRollup A deployment model in which a Lineth network proves state transitions with zk-SNARKs and posts transaction data, state commitments, and proofs to the finalization layer. Anyone who can read that data can reconstruct history while it remains available., the coordinator submits compressed transaction data to the finalization layer as EIP-4844 blobs. The rollup must support the IAcceptEip4844Blobs interface.
• For a validiumValidium A deployment model in which a Lineth network proves state transitions with zk-SNARKs and posts only state commitments and proofs to the finalization layer. A validium can be public or private, depending on who has access to the transaction data. Participants cannot reconstruct the full transaction history from the finalization layer alone., submission is shnarfShnarf A hash commitment recorded on the finalization contract for each data submission. It covers the submitted data, the resulting state root, and the previous shnarf. Finalization proofs are verified against it.-only. Only proofs and state commitments are posted to the finalization layer. The validium must support the IAcceptShnarfData interface. The network may rely on another blockchain or a third-party service, or operators may run nodes specifically for data availability.

Read more about Data commitments (shnarfs).

Components overview

Lineth includes several classes of components, each of which serve part of the transaction lifecycle:

• Nodes accept transactions over JSON-RPC and produce or import blocks. A fully public network provides externally reachable nodes. In other deployment types, node services may be configured to be private or semi-private.

• Internal protocol services stay inside the operator's trusted network boundary.

  • The sequencer orders transactions and builds blocks according to Lineth rules.
  • The state manager maintains a state representation optimized for proof generation and recovery.
  • The tracer generates execution traces required for proof generation.
  • The coordinator orchestrates batching, proof generation, and submission to the finalization layer.
  • The prover generates zk-SNARK proofs for state transitions.

• The canonical bridge moves messages and tokens between the network and the finalization layer. An optional offchain relay, the Postman, can deliver these messages automatically. Anyone can still submit the claim that executes a message.

• Smart contracts execute small programs according to EVM rules. For example, the finalization contract verifies proofs and records state roots on the finalization layer.

note

With further decentralization efforts, components such as the sequencer may be redesigned to be configurable as an external P2P service.

Auxiliary services sit off the submission-to-finalization path:

• The block explorer is an optional operator-facing service for inspection, troubleshooting, and auditing. Linea Mainnet uses Blockscout, an open-source, self-hosted explorer that indexes blocks, transactions, logs, and token data from execution nodes over JSON-RPC or WebSocket. It takes no part in consensus, execution, or finalization, and it can be replaced or omitted without affecting correctness or liveness.

• Web3Signer is an open-source remote signing service. Consensus and execution clients request signatures for blocks, attestations, and transactions over HTTP, while private keys stay in an enterprise-grade key store. Signing is access-controlled and auditable, which simplifies key revocation and rotation. See Key management for how Lineth signer roles use Web3Signer and other custody options.