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: public deployments, such as Linea Mainnet, with onchain data availability and open access; and private validium deployments, with offchain data availability and controlled access.
Consider these questions when choosing a deployment model:
- Privacy requirements: Should transaction data remain private to authorized participants?
- Regulatory and compliance obligations: What controls does your program require, and who owns them?
- Data availability guarantees: How important is onchain data availability for your participants?
- Network topology: Do you need a private network with controlled membership?
- Access control: Do you need role-based access control (RBAC) on RPC endpoints and APIs?
The following table compares how characteristics differ between public deployments and private validium deployments. Choose the deployment model that aligns with your requirements.
| Characteristic | Public deployments | Private validium |
|---|---|---|
| Data availability | Transaction data is posted onchain via EIP-4844 blobs | Transaction data can be stored offchain in a private node set |
| Access control | Public RPC endpoint | RPC endpoints protected by RBAC |
| What 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. | State commitments, proofs, and transaction data | State commitments and proofs; transaction details stay offchain |
| Who can reconstruct history | Anyone with the blob data, while it is retained | Participants the operator authorizes through DA access and RBAC |
| Network topology | Open access | Controlled node membership |
The following sections provide more details about use cases and security considerations for each model.
Public deployments
Public deployments such as Linea Mainnet are open networks with onchain data availability. Transaction data is posted as EIP-4844 blobs, so state commitments, proofs, and transaction data all appear on the finalization layer. Anyone with the blob data can reconstruct history while those blobs are retained. RPC access is public, and node membership is not restricted.
Use cases
- Networks requiring maximum transparency
- Applications that benefit from onchain data availability
- Networks that prioritize open access over transaction privacy
Security considerations
- 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: whether to implement RBAC on RPC endpoints
- Key management: remote signing backed by a hardware security module (HSM) or key management service (KMS)
Private validium
A private validium keeps transaction data offchain, using 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 to support state-transition correctness and finalization. RPC endpoints are protected by access control, and node membership is controlled.
Whether this model suits a regulated environment depends on the operator's own compliance, privacy, and access-control design; Lineth does not certify a deployment as compliant.
Use cases
- Workflows where transaction data should not be public
- Multi-party workflows where participants should not see all transaction details
- Operators who accept the validium trade-off: state-transition correctness is proven onchain, but data reconstruction without the operator depends on the deployment's data availability arrangement
Operators with regulatory or compliance obligations are responsible for designing their own compliance program. See Compliance for what protocol evidence exists and what is not claimed.
Security considerations
- Validator topology: at least 4 Maru validators are required for a QBFT design that tolerates one faulty validator
- Access control: RBAC on RPC endpoints and API portal
- Key management: remote signing backed by a hardware security module (HSM) or key management service (KMS)
- Network isolation: private network topology with controlled peering
See also
- Trust and responsibilities: Trust assumptions and guarantees for each deployment model
- Privacy and data visibility: What a private validium publishes and who can see it
- Data availability and finalization: Where transaction data is stored in each deployment model, and where proofs settle