Deployment models
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. supports two deployment models: rollups, in which transaction data is posted to the 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., and validiums, in which only state commitments and proofs are posted to the finalization layer. A validium can be public or private, depending on who can read that network's transaction data.
The following table compares how rollups and validiums address key deployment questions. Choose the model that aligns with your requirements.
| Questions | Rollup | Public validium | Private validium |
|---|---|---|---|
| Where is transaction data stored? | On the finalization layer as EIP-4844 blobs | On the Lineth network's nodes | On a restricted node set in the Lineth network |
| What is posted to the finalization layer? | State commitments, proofs, and transaction data | State commitments and proofs only | State commitments and proofs only |
| Who can reconstruct history? | Anyone with blob data, while it is retained | Anyone who can reach the network's nodes | Authorized participants only |
| What is the network topology and access policy? | Open network and RPC access | Open network and RPC access | Restricted node set and RBAC permissions on RPC |
The following sections provide more details about each model.
Rollups
In a rollup, the coordinatorCoordinator Lineth's coordination module for batching, proof generation, and finality submission. The coordinator monitors block production, manages conflation deadlines, batches blocks, combines batches into blobs, orchestrates execution, compression, and aggregation proofs, and submits proofs and data to the finalization layer. posts transaction data to the finalization layer using EIP-4844 blobs. State commitments, proofs, and transaction data appear on the finalization layer. Anyone who can read that data can reconstruct history while it remains available. RPC access is public, and node membership is not restricted.
Use cases
- Applications that require maximum transparency
- Applications that benefit from onchain data availability
- Applications that prioritize open access over transaction privacy
Security considerations
The following operator choices affect how you secure a rollup:
- Validator topology: If the deployment uses a multi-validator QBFT design, at least 4 Maru validators are required to tolerate one faulty validator.
- Key management: Remote signing backed by a hardware security module (HSM) or key management service (KMS)
Validiums
In a validium, the coordinatorCoordinator Lineth's coordination module for batching, proof generation, and finality submission. The coordinator monitors block production, manages conflation deadlines, batches blocks, combines batches into blobs, orchestrates execution, compression, and aggregation proofs, and submits proofs and data to the finalization layer. submits state commitments and proofs to the finalization layer. Transaction data is not posted there. Typically that data lives on the validium's archive nodesArchive node A full node that retains state at every block from genesis, alongside the blocks and transactions themselves, so it can reconstruct chain state at any past block height. Archive nodes trade minimal latency and modest storage requirements for completeness, supporting auditing, forensics, and analytics..
Public validiums
A public validium makes the Lineth network's data publicly readable. A public L3 that finalizes to Linea Mainnet uses this model: the coordinator submits state commitments and proofs to Linea, and transaction data stays on the L3's nodes because Linea cannot store it as blobs. RPC access is open, so anyone who can reach a node can reconstruct history from the network.
Use cases
- Applications that need the lower finalization cost and faster settlement on Linea Mainnet, while keeping open access
- Applications that do not require transaction data on the finalization layer
Security considerations
The following operator choices affect how you secure a public validium:
- Validator topology: If the deployment uses a multi-validator QBFT design, at least 4 Maru validators are required to tolerate one faulty validator.
- Key management: Remote signing backed by a hardware security module (HSM) or key management service (KMS)
Private validiums
A private validium keeps transaction data in a restricted node set and controls RPC access. Authorized participants who can reach those nodes can reconstruct history. A third party without that access cannot.
A private validium does not make transactions cryptographically private. Anyone authorized to see the offchain data can read the transactions. The zk-SNARK proofs confirm that state transitions are correct; they do not hide that data.
Use cases
- Applications where transaction data should not be public
- Multi-party workflows where participants should not see all transaction details
- Applications that accept the private validium trade-off: state-transition correctness is proven onchain, but reconstructing history requires authorized access to the operator's offchain data
Security considerations
The following operator choices affect how you secure a private validium:
- Validator topology: If the deployment uses a multi-validator QBFT design, at least 4 Maru validators are required to tolerate one faulty validator.
- Access control: RBAC permissions on JSON-RPC, APIs, and tooling
- Key management: Remote signing backed by a hardware security module (HSM) or key management service (KMS)
- Network isolation: Private network topology with controlled peering
For an illustrative topology, see the example private validium architecture.
See also
- Trust model: Trust assumptions for each deployment model, and what participants can verify
- Data availability: Where transaction data is stored in each deployment model