> For the complete Linea documentation index, see [llms.txt](/llms.txt). > Agents can fetch this page as Markdown at [https://docs.linea.build/protocol/architecture.md](https://docs.linea.build/protocol/architecture.md). # Architecture [Lineth](/protocol/reference/zero-knowledge-glossary#lineth)**Lineth** (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. [Operators](/protocol/reference/zero-knowledge-glossary#operator)**Operator** 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](/stack/deployment/data-availability-finalization) design. The following represents a possible configuration for a network built on Lineth:  Mainnet example This example configuration represents [Linea Mainnet](/network). While the Lineth [ZK-rollup](/protocol/reference/zero-knowledge-glossary#zero-knowledge-rollup)**Zero-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](#nodes): A fully public network provides externally reachable nodes. In other [deployment types](/stack/evaluate/deployment-models), node services may be configured to be private or semi-private. - [Internal protocol services](#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](#onchain-system-contracts): Versioned onchain contracts, with immutability or upgrade controls depending on deployment. - [Auxiliary services](#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 a consensus client, [Maru](/protocol/reference/repos#maru), which orders blocks and propagates them to peers, and one or more execution clients, which execute transactions and maintain EVM state. Maru communicates with its execution clients over the standard Ethereum [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md). Any node can also expose [JSON-RPC](/protocol/architecture/rpc-services) to serve applications, users, or internal services, either publicly or only within the operator's network. ### Consensus client: Maru [Maru](/protocol/reference/repos#maru) implements [QBFT](/protocol/reference/zero-knowledge-glossary#quorum-byzantine-fault-tolerance-qbft)**Quorum Byzantine Fault Tolerance (QBFT)** The Byzantine-fault-tolerant consensus algorithm that Maru implements to let a set of [Maru validators](/protocol/reference/zero-knowledge-glossary#maru-validator) produce and finalize blocks. A QBFT validator set requires at least `3f+1` validators to tolerate up to `f` faulty validators. consensus and runs on every node, in one of two roles: - **[Maru validator](/protocol/reference/zero-knowledge-glossary#maru-validator)**Maru validator** A Maru node 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.:** Proposes and votes on blocks as part of the QBFT validator set. Maru requests a payload from its dedicated Linea Besu execution client, then signs and broadcasts the resulting block. - **[Maru non-validator](/protocol/reference/zero-knowledge-glossary#maru-non-validator)**Maru non-validator** A Maru node configured with the `qbft` section omitted. It receives blocks from peers and imports them into its execution clients without proposing or voting, and it can drive follower execution clients. Because it never proposes blocks, its execution clients can be any Ethereum execution client.:** Receives blocks from peers and imports them into its execution clients, without proposing or voting. In both roles, Maru manages validator sets, provides P2P block propagation, and exposes API endpoints for monitoring and control. A single Maru node can drive more than one execution client. Alongside the client it uses for block building or import, either role can drive additional [follower execution clients](/protocol/reference/zero-knowledge-glossary#follower-execution-client)**Follower execution client** An execution client that a Maru node drives through its `follower-engine-apis` configuration. A follower execution client imports and executes the blocks Maru gives it, but never proposes them, so it doesn't need sequencer plugins and can be any Ethereum execution client. It doesn't run a Maru of its own, and it may or may not serve JSON-RPC. Both Maru validators and Maru non-validators can drive follower execution clients., configured under [`follower-engine-apis`](/reference/component-configuration/linea-maru-options#maru). A follower execution client doesn't run a Maru of its own. For Maru TOML configuration keys, see the [Maru options](/reference/component-configuration/linea-maru-options). ### 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](/protocol/reference/repos#linea-besu-upstream) is a distribution of [Besu](https://docs.besu-eth.org/) 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 [prover](/protocol/reference/zero-knowledge-glossary#prover)**Prover** 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 manager](/protocol/reference/zero-knowledge-glossary#state-manager)**State 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. Each Maru validator requires a dedicated Linea Besu execution client with [sequencer](/protocol/reference/zero-knowledge-glossary#sequencer)**Sequencer** 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](/protocol/reference/zero-knowledge-glossary#sequencer-node). plugins. A Maru validator paired with such a client is a [sequencer node](/protocol/reference/zero-knowledge-glossary#sequencer-node)**Sequencer 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., and that pairing is what produces canonical blocks. During block building, the sequencer generates [traces](/protocol/reference/zero-knowledge-glossary#tracer)**Tracer** 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. to ensure blocks remain within prover limits. Execution clients that generate prover input traces must also use Linea Besu. Nodes that only import blocks or serve standard Ethereum JSON-RPC can run any Ethereum execution client. This makes the two layers separately configurable, but not symmetrically scalable. Because every validator needs its own Linea Besu, adding validators also means adding execution clients. Follower execution clients can be added independently, without adding more Maru nodes. For the full plugin set and its configuration, see the [Linea Besu plugin reference](/reference/component-configuration/linea-besu-plugin-options). ## Internal protocol services Internal protocol services are required for proof generation and finalization. ### Sequencer The [sequencer](/protocol/architecture/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](/protocol/architecture/coordinator) orchestrates batching, proof generation, and submission to the finalization layer. ### Prover The [prover](/protocol/architecture/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](/protocol/architecture/prover/risc-v-overview) with RISC-V. ### State manager The [state manager](/protocol/architecture/state-manager) maintains a state representation optimized for proof generation and recovery. ### Tracer The [tracer](/protocol/architecture/sequencer/traces-generator) 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-SNARK](/protocol/reference/zero-knowledge-glossary#zk-snark)**zk-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 layer](/protocol/reference/zero-knowledge-glossary#finalization-layer)**Finalization 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](/protocol/architecture/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](https://github.com/blockscout/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](https://docs.web3signer.consensys.io/) 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](/stack/evaluate/deployment-models) 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 validium](/protocol/reference/zero-knowledge-glossary#validium)**Validium** 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](/stack/deployment/data-availability-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](/protocol/architecture/sequencer#transaction-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 validium](/protocol/reference/zero-knowledge-glossary#validium)**Validium** 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 - For the L1-backed transaction path that enforces processing-by-deadline guarantees, see [forced transactions](/protocol/forced-transactions). - See the more about [the transaction lifecycle and finality](/network/overview/transaction-finality) on the Linea public network. ## Next steps - To understand the trust boundaries, and upgrade paths of this stack, see [protocol components](/stack/deployment/core-components). - Review bridge mechanics in the [message service](/protocol/architecture/interoperability/canonical-message-service). - Review cross-chain settlement in the [canonical token bridge](/protocol/architecture/interoperability/canonical-token-bridge). - Understand protocol fees in [predictable pricing](/network/overview/predictable-pricing) and [burn](/network/overview/tokenomics#burning-mechanism).