Skip to main content

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 design.

The following represents a possible configuration for a network built on Lineth:

Lineth architecture diagram showing validator and full nodes, RPC services, internal protocol services, and finalization to Ethereum. This section details those components shown in this image and how they define the protocol's behavior and guarantees: Components overview, Nodes, Consensus client Maru, Execution clients, Linea Besu, RPC nodes, Internal protocol services, Sequencer, Coordinator, Prover, State manager, Tracer, Onchain system contracts, Auxiliary services, Block explorer, Web3Signer, Data availability, Transaction lifecycle, Next steps
Mainnet example

This example configuration represents Linea Mainnet. While the Lineth ZK-rollupZero-knowledge rollup An L2 scaling solution that uses a zero-knowledge proof as its validity proof to post data back to Ethereum. As compared to optimistic rollups, this validity proof allows for a more secure trust assumption and removes the need for a challenge period. protocol is agnostic to the finalization layer (it's unopinionated on where proofs are written), this configuration finalizes transactions by submitting proofs to Ethereum Mainnet and temporarily making data available there.

Components overview​

Lineth is comprised of several broad classes of components:

  • Nodes: 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: Operator-run services for proof generation and finalization (sequencer, coordinator, prover, state manager, and tracer). Traffic between them stays inside the operator's trusted network boundary.
  • Smart contracts: Versioned onchain contracts, with immutability or upgrade controls depending on deployment.
  • Auxiliary services:
    • Block explorer: While this is optional, explorer data simplifies transaction building, auditing, and troubleshooting.
    • Web3Signer: Secure signing service ensuring that nodes may sign without revealing keys.

Nodes​

Every Lineth node runs two clients: an execution client, which executes transactions and maintains EVM state, and the consensus client, Maru, which orders blocks and propagates them to peers. The two communicate over the standard Ethereum Engine API.

Any node can also expose JSON-RPC to serve applications, users, or internal services, either publicly or only within the operator's network.

Consensus client: Maru​

Maru implements QBFTQuorum Byzantine Fault Tolerance (QBFT) The Byzantine-fault-tolerant consensus algorithm that Maru implements to let a validator set produce and finalize blocks, tolerating faulty validators in a 3f+1 validator set. consensus and runs on every node, in one of two roles:

  • Validator: Proposes and votes on blocks as part of the QBFT validator set. Maru requests a payload from its execution client, then signs and broadcasts the resulting block.
  • Follower: Receives blocks from peers and passes them to its execution client for execution, without voting.

In both roles, Maru manages validator sets, provides P2P block propagation, and exposes API endpoints for monitoring and control.

Execution client: Linea Besu​

Any Ethereum execution client that implements the Engine API can serve as a Lineth execution client and integrate with Maru, including Linea Besu, Besu, Geth, Erigon, and Nethermind. This promotes client diversity and compatibility with existing Ethereum node tooling and infrastructure.

Linea Besu is a distribution of Besu that bundles several Lineth-specific plugins with preset startup profiles. These plugins implement the protocol functions that a standard Ethereum client doesn't provide: trace generation for 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., Lineth block-building rules, 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. integration, and the linea_ RPC namespace.

The sequencerSequencer The component of the Lineth execution client responsible for ordering, building, and executing blocks in a way that allows the subsequent ZK proof to be made. It's implemented as a set of plugins extending Linea Besu, including the tracer. There's typically one sequencer per network. and trace generationTracer 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. depend on those plugins, so those roles require Linea Besu. Nodes that follow the chain or serve standard Ethereum JSON-RPC can run any execution client. For the full plugin set and its configuration, see the Linea Besu plugin reference.

Internal protocol services​

Internal protocol services are required for proof generation and finalization.

Sequencer​

The sequencer orders transactions and builds blocks according to Lineth rules. Typically deployed as a protected internal service.

note

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

Coordinator​

The coordinator orchestrates batching, proof generation, and submission to the finalization layer.

Prover​

The prover generates zk-SNARK proofs for state transitions. Provers may be scaled horizontally to meet throughput requirements. The Lineth proving architecture is also evolving toward guest-program-based proof generation with RISC-V.

State manager​

The state manager maintains a state representation optimized for proof generation and recovery.

Tracer​

The tracer generates execution traces required for proof generation.

Onchain system contracts​

Smart contracts execute small programs according to EVM rules. Once deployed, they are immutable unless they are explicitly designed with upgradeability or administrative controls.

Lineth includes system contracts deployed in two locations:

  • On the finalization layer: The finalization contract validates 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 finalized state roots. This contract must be deployed on 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..

  • On the deployed network itself: Application-specific contracts are deployed on the network instance to enable token issuance, workflow automation, and other network-specific functionality.

  • On both layers: Bridge contracts are deployed on both the destination chain and the deployed network to enable cross-chain token transfers and message passing.

For more information about the system contracts, see Smart contracts.

Auxiliary services​

Block explorer​

The block explorer is an optional, operator-facing service used for inspection, troubleshooting, and auditing. Linea Mainnet uses Blockscout, an open-source, self-hosted explorer that indexes chain data from execution nodes and presents it via a web interface.

The explorer connects to the network via JSON-RPC or WebSocket, continuously indexes blocks, transactions, logs, and token data, and stores this information in a relational database. It allows operators to inspect blocks and transactions, review contract activity, track bridge operations, and monitor network health.

Block explorers are not required for network operation and do not participate in consensus, execution, or finalization. They can be deployed, replaced, or omitted without affecting correctness or liveliness.

Web3Signer​

Web3Signer is an open-source, remote signing service that externalizes private key management from the nodes themselves. Web3Signer integrates with enterprise-grade key stores, exposing HTTP‑based signing APIs that allow consensus and execution clients to obtain signatures on blocks, attestations, and transactions without directly holding the private keys.

Web3Signer ensures that signing operations are access‑controlled, and auditable rather than embedded in each node. This tooling simplifies key revocation and rotation workflows, and ensures that private keys never leave the secure boundary of the key store.

Data availability​

Data availability is crucial in preserving and providing access to transaction data required to reconstruct the state of the network. While zk-SNARK proofs ensure the correctness of state transitions, data availability is the guarantee that the transaction data underlying these proofs remains accessible to anyone who wants to verify or reconstruct the historical state.

Data availability by deployment

How data availability is handled depends on the deployment model of the network. The network may rely on another blockchain or third-party service to provide data availability, or operators may run nodes specifically for data availability.

  • Private validiumValidium A deployment model in which a Lineth network proves state transitions with zk-SNARKs but keeps transaction data in a private data availability layer instead of publishing it to the finalization layer. Only state commitments and proofs are posted onchain, so participants without access to the offchain data can't independently reconstruct or verify the full transaction history.: Data stored offchain with private node set; no onchain data posting
  • Public deployment: Data posted to finalization layer using EIP-4844 blobs

See Data availability and finalization for more information.

Transaction lifecycle​

These architectural components support transactions from submission to finalization.

  1. Submission: Transactions enter the mempool via the RPC entrypoint of a node.
  2. Block building: The sequencer validates, orders, and executes transactions into blocks, enforcing Lineth validity conditions including a profitability threshold.
  3. State tracking: The state manager updates the state representation; the tracer generates traces.
  4. Conflation: The coordinator groups blocks into batches.
  5. Proof and blob generation: The prover generates execution proofs for batches and the coordinator combines batches into blobs; the prover generates compression proofs.
  6. Data submission: Lineth contracts define three data-submission models:
    • Compressed data submitted as EIP-4844 blobs. Supported by the coordinator. Requires the rollup to support the IAcceptEip4844Blobs interface.
    • Compressed data submitted as calldata. The current coordinator does not provide a calldata submitter. Requires the rollup to support the IAcceptCalldataBlobs interface.
    • Shnarf-only submission for private validiumValidium A deployment model in which a Lineth network proves state transitions with zk-SNARKs but keeps transaction data in a private data availability layer instead of publishing it to the finalization layer. Only state commitments and proofs are posted onchain, so participants without access to the offchain data can't independently reconstruct or verify the full transaction history. deployments, without publishing the compressed batch data to the finalization layer. Supported by the coordinator. Requires the validium to support the IAcceptShnarfData interface.
  7. Finalization: The coordinator submits proofs to the finalization layer; after verification and any configured delay, transactions reach hard finality on the selected finalization layer.
info

Next steps​

Was this page helpful?