Skip to main content

Deployment architecture overview

This section describes the components and design choices in a 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. deployment, providing a high-level reference architecture you can use when designing your own deployment. Detailed production topology and supported tooling for a given deployment can be confirmed with the Lineth team in enterprise engagements.

Deployment components

Required and optional components in the deployment footprint, including how they are versioned or replaced.

Data availability

Where transaction data is stored: on the finalization layer in a rollup, or offchain in a validium.

Finalization layer

Where proofs and state commitments settle: on Ethereum (L1) or Linea Mainnet (L2).

Finality

Application-level finality on the network versus settlement finality on the finalization layer.

Multi-validator consensus

Maru multi-validator QBFT for sequencer fault tolerance and distributed block ordering within the execution path.

High availability

Multi-region setup: validators and RPC across regions, primary and warm-standby finalization, and failure behavior.

Access control

How to restrict RPC access using a single endpoint that authenticates callers and enforces RBAC permissions.

Native interoperability

How two Lineth networks communicate with each other using the Cross Ledger Interoperability Protocol (CLIP).

Key management

Signer roles, the key custody options each role can use, and the controls the operator owns.

tip

If you're still evaluating whether Lineth is the right stack for your use case, see Evaluate Lineth. For protocol-level architecture details, see Protocol Architecture.

Shared components and variants​

All Lineth deployments use the same core components. Internal protocol services stay inside the operator's network. Proofs and state commitments go to a chosen 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..

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. also choose:

  • Key management: Local keys, remote signing through Web3SignerWeb3Signer An open-source, remote signing service that externalizes private key management from nodes. Web3Signer integrates with enterprise-grade key stores and exposes HTTP-based signing APIs so consensus and execution clients can obtain signatures on blocks, attestations, and transactions without directly holding the private keys., or AWS KMS
  • Data availability: On the finalization layer in 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., or offchain in 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.
  • Finalization layer: Ethereum (L1) or Linea Mainnet (L2)
  • Validator model: Single Maru validator, or multi-validator QBFT

Lineth does not recommend a specific set of customizations.

Example architecture​

The following diagram illustrates an example architecture for a private 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. deployment: access control at the edge, a restricted network boundary, and message relayers to other chains. A rollup or public validium uses the same internal services; access and data availability differ.

In this example, transaction data stays on the operator's restricted node set, and is not shown on the diagram. In a rollup, transaction data is posted to the finalization layer. In a public validium, that data stays on the Lineth network and is publicly readable. See Data availability.

For regional placement, failover, and recovery, see High availability.

Example Lineth validium deployment architectureTrusted partners reach access control, which gates the API portal and block explorer inside the Lineth private network. Those tools query near-head and archive RPC nodes, which read onchain system contracts. Internal protocol services including the coordinator, execution services, and core services also interact with those contracts. zk-SNARK proofs leave internal protocol services for the finalization layer. Validium message relayers connect onchain contracts to other enterprise and public blockchains.Trusted partnersAccess controlLineth private networkAccess and toolingAPI portalBlock explorerRPC servicesNear-headRPC nodesArchiveRPC nodesOnchain system contractsMessaging and applicationApplication contractMessage bridge contractsToken contractsToken management contractToken bridge contractsInternal protocol servicesCoordinatorExecution servicesWeb3SignerSequencerCore servicesState managerTracerProverValidium messagerelayerszk-SNARK proofsFinalization and interoperabilityExternal blockchainsEnterprise blockchainPublic blockchainFinalization layerFinalization /message bridge contractToken bridge contract

The example architecture flows as follows:

  1. Clients reach the API portal, block explorer, and RPC. This example gates that path with access control.
  2. Those tools query near-head and archive RPC nodesRPC node A node configured to expose JSON-RPC APIs to applications, users, or internal services, optionally behind load balancers and RBAC. Any node can serve RPC, regardless of its consensus role. Which methods it serves depends on its execution client and enabled plugins: standard Ethereum namespaces are available on any client, while the linea_ namespace requires Linea Besu with the relevant plugins enabled. RPC nodes also differ in how much state history they retain, from current state and recent history by default up to a full archive node., which read chain state from onchain contracts.
  3. The sequencer orders transactions and builds blocks. Multi-validator consensus is a design choice that improves sequencer fault tolerance.
  4. Inside the operator network, the coordinator batches blocks, the tracer produces traces, and the prover generates 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.
  5. Proofs and state commitments leave that network when they are submitted to the finalization contract. This validium example does not post transaction data; a rollup posts it to the finalization layer. See Data availability.
  6. Lineth networks can communicate with each other using native interoperability. This example also shows message relayers to other non-Lineth enterprise or public chains.

See Trust model to understand what each deployment component can do and what participants can verify.

Was this page helpful?