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 and finalization

Where transaction data is stored and where proofs and state commitments settle on the chosen finalization layer.

Finality design

Application-level finality on the network versus settlement finality on the finalization layer, and the trade-offs between them.

Multi-validator consensus

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

High availability

Multi-region placement of the same components: validators and RPC across regions, primary and warm-standby finalization, and failure behavior.

Access control

Operator-configured RBAC at the access edge for protected RPC, API, and tooling surfaces in restricted deployments.

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:

  • Access control: Public RPC, or RPC and APIs gated by RBACRole-based access control (RBAC) Operator-configured access control for protected Lineth RPC, API, and tooling surfaces. RBAC determines which protected interfaces and data a participant can access, but it is not cryptographic privacy: it doesn't encrypt public-chain data, replace zero-knowledge proof verification, or provide data availability on its own.
  • Data availability: Onchain (for example, EIP-4844 blobs) or offchain in a 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.
  • Finalization layer: L1 (such as Ethereum) or L2 (such as Linea)

Operators own these choices, including compliance design. Lineth does not recommend a specific set of customizations.

Example architecture​

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

In this example, transaction data stays offchain in the operator's private node set, and is not shown on the diagram. In a public deployment, transaction data is posted to the finalization layer. See Data availability and finalization.

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

Example Lineth validium deployment architectureTrusted partners reach RBAC, 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 partnersRBACLineth 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 RBAC; a public deployment can expose RPC without that gate.
  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; RPC nodes 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 layer contracts. This validium example does not post transaction data; a public deployment posts it onchain. See Data availability and finalization.
  6. Interoperability with the finalization layer uses the canonical token bridge and message service. This example also shows validium message relayers to other enterprise or public chains.

See Trust and responsibilities for who operates each component, what it can do, and what participants can verify.

Was this page helpful?