Skip to main content

Deployment components

This page describes the Lineth (formerly the Linea Stack) components. It identifies which components an operator must or may run, and describes how they are versioned or replaced. For what each component does internally, see the Protocol architecture.

Core protocol components​

The following components are required.

Replaceability: Versioned via protocol upgrade.

  • Maru: Consensus layer client
  • Linea Besu: Execution layer client
  • Sequencer: Orders transactions and builds blocks
  • Coordinator: Orchestrates batching, proof generation, and submissions
  • Prover: Generates zero-knowledge proofs of state transitions
  • State manager: Maintains a state representation for proof generation
  • Tracer: Generates execution traces required for proofs

Onchain system contracts​

The following smart contracts or alternatives that offer parity are required.

Replaceability: Versioned via redeployment.

  • AddressFilter contract
  • Canonical token bridge
  • Finalization verifier
  • LineaRollup message bridge contract
  • Token bridge contracts

Data availability​

In addition to concrete components, Lineth depends on correctness-critical requirements, which may be satisfied by different implementations depending on the deployment model.

Purpose

  • Ensure transaction data and state transitions remain accessible
  • Enable reconstruction and verification of historical state

Correctness requirement

  • Without data availability, the protocol cannot be independently verified
  • Loss of data availability breaks state reconstructability

Example implementations

  • Linea Public Mainnet deployment: EIP-4844 blobs on Ethereum
  • Private Validium deployments: Operator-provided or outsourced data availability infrastructure

Trust model

  • Data availability is within the trust boundary
  • Responsibility for data availability implementation depends on deployment model

See more on data availability considerations.

Auxiliary services​

Auxiliary services are not required for protocol correctness. They are typically optional and replaceable.

Common examples include:

Special cases

  • Web3Signer: remote signing with integration with a large number of Key Management Solutions (KMS):
    • Not required for correctness
    • In trust boundary (signing path)
    • Not replaceable: currently, Web3Signer is integral
    • Optional

Was this page helpful?