Skip to main content
How it works

Protocol components

This page defines the Linea protocol components. Each component has a clear operational responsibility and deployment footprint. Use this page as the canonical reference for:

  • What must be operated as part of the protocol
  • How protocol-critical elements are versioned and replaced

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, the Linea protocol 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