> For the complete Linea documentation index, see [llms.txt](/llms.txt). > Agents can fetch this page as Markdown at [https://docs.linea.build/stack/deployment/data-availability-finalization.md](https://docs.linea.build/stack/deployment/data-availability-finalization.md). # Data availability and finalization This page compares data availability and finalization designs for a Lineth deployment and their operator consequences. For application-level versus settlement finality, see [Finality design](/stack/deployment/fast-finality). important Understanding the role of [data availability](/protocol/architecture#data-availability) and [finalization](#finality-design-options) in the protocol is essential for deploying and operating a network built on Lineth. The following examples show different combinations of data availability and finalization: - **L2 Private Validium on Ethereum:** Offchain data availability, L1 finalization - **L3 Private Validium on Linea Mainnet:** Offchain data availability, L2 finalization - **L2 Public on Ethereum:** Onchain data availability, L1 finalization - **L3 Public on Linea Mainnet:** Onchain data availability, L2 finalization ## Data availability Lineth enables flexible data retention and disclosure policies depending on deployment requirements. While zk-SNARK proofs ensure the correctness of state transitions, data availability (the accessibility of transaction data from a blockchain network) determines whether the transaction data underlying these proofs remains accessible to parties who need to verify or reconstruct historical state. Data availability is the guarantee that transaction data is accessible when needed. The deployment model determines where and how data is stored. For node roles that support data availability, see [full nodes](/protocol/architecture#full-nodes) and [RPC services](/protocol/architecture/rpc-services). ### Private Validium In a Validium, data availability is typically provided by the Validium’s [archive nodes](/protocol/architecture/rpc-services#archive-nodes) rather than an external data availability solution. If sufficient archive nodes remain available, authorized participants with access to the data can reconstruct and verify transaction history. Because the chain is private, data is not posted to the finalization layer, but is instead retained within the Validium infrastructure under the operational and governance controls of the participating institutions. In this model, assurance of data availability is primarily based on institutional guarantees, node redundancy, and operational SLAs across the consortium of operators. **Data availability:** Offchain in a private node set - Transaction data is stored offchain in a private node set - Only state commitments and proofs are posted to the finalization layer - No onchain data posting (reduces costs but requires trust) - The network cannot be replicated by a third party, so the participant must trust the operator to continue operating the network and providing services to users. **Operator responsibility:** - Deploy and maintain private node set for data storage - Ensure data redundancy and backup procedures - Continue operating the network and providing services to users. If the network needs to be shut down, wind down the network to ensure participants can make exit transactions. ### Public In a public network, transaction data is posted to the finalization layer, allowing third parties to reconstruct the state of the network and submit exit transactions without depending on the operator when the relevant data is available. This allows for maximum transparency and onchain data availability. **Data availability:** Onchain (e.g., on Ethereum via EIP-4844 blobs) - Transaction data is posted to Ethereum as the finalization layer using EIP-4844 blobs - Blob data is available for verification and state recovery during Ethereum's blob retention window - Blobs expire after 4,096 epochs (~18 days), so long-term reconstruction requires independent archival - Maximum transparency and onchain data availability **Operator responsibility:** - Ensure coordinator can post blobs to finalization layer - Monitor blob posting success and gas costs ## Finalization layer The finalization layer is the blockchain where your Lineth deployment submits proofs and state commitments for verification and hard finality. It also determines the layer of your network: - L2: If your finalization layer is an L1 (such as, Ethereum), your network is an L2 - L3: If your finalization layer is an L2 (such as, Linea Mainnet), your network is an L3. **Examples:** - Private network built on Lineth finalizing to Linea Mainnet = L3 (L3 → L2 → L1) - Private network built on Lineth finalizing to Ethereum = L2 (L2 → L1) - Public Linea Mainnet finalizing to Ethereum = L2 (L2 → L1) ### Finalization layer options Enterprise operators typically select between two options for the finalization layer. **Ethereum L1:** - Direct finalization on Ethereum - Higher costs and longer finality times - Direct Ethereum settlement - Suitable for: deployments that require direct Ethereum L1 settlement **Linea Mainnet L2:** - Finalization on Linea Mainnet (which finalizes to Ethereum) - Lower costs and faster finality times - Finality inherits Linea Mainnet's assumptions, which themselves anchor to Ethereum - Suitable for: deployments that can accept L2 finalization #### Operational implications When choosing a finalization layer, consider the following: - Security requirements: L1 finalization provides direct Ethereum settlement; L2 finalization is sufficient for many use cases. - Cost: L2 finalization is cheaper than L1. - Finality design: L2 finalization may be faster than L1. - Contract deployment: You must deploy contracts on your chosen finalization layer. ### Finality design options | Configuration | Description | Summary | Indications | | --- | --- | --- | --- | | **Standalone Lineth – Single validator** | In a single-validator standalone deployment, transaction acceptance is immediate and deterministic under the operator trust model. The single authorized validator produces blocks and executes transactions. Once a block is produced and committed by the validator, transactions in that block are accepted as final by the deployment. No consensus-driven forks or reorganizations are expected by design. | Immediate, deterministic application-level finality with a single trusted validator. | Prioritizes simplicity and low latency. Suitable for private or highly controlled environments where validator trust is explicit. | | **Standalone Lineth – Multiple validators (QBFT)** | In a multivalidator standalone deployment, Lineth uses a Byzantine Fault Tolerant consensus protocol (QBFT) to achieve finality among authorized validators. | A block proposer produces a block for a given height. Validators vote in quorum-based rounds. When a supermajority (≥2/3) of validators commit a block, it is finalized by the validator set. Once finalized, blocks are irreversible under the deployment's QBFT safety assumptions. Finality is typically achieved within seconds. | Provides strong single-slot finality with Byzantine fault tolerance. Suitable for environments requiring distributed trust among multiple validators. | | **Layer 2 Lineth – Single validator** | When deployed as an Ethereum Layer 2 with a single validator (sequencer), Lineth combines fast L2 execution with periodic L1 commitments. | A single authorized validator produces blocks and executes transactions on the L2. Once a block is produced and committed, transactions in that block are accepted as final at the L2 application level under the operator trust model. No consensus-driven forks or reorganizations are expected by design. L2 state is periodically committed to Ethereum Layer 1. When the commitment is finalized, the L2 state receives settlement finality on Ethereum. | Balances fast performance with explicit operator trust and slower Ethereum L1 settlement finality. | | **Layer 2 Lineth – Multiple validators (QBFT)** | When deployed as an Ethereum Layer 2 with multiple validators, Lineth combines Byzantine Fault Tolerant L2 finality with Ethereum Proof-of-Stake finality. | QBFT consensus among authorized validators provides single-slot L2 finality. Ethereum Proof-of-Stake consensus provides settlement finality at regular checkpoints. | Suitable for environments that require fast application-level finality under normal conditions and slower Ethereum settlement finality for global settlement. | ### Smart contract requirements The finalization layer must deploy the following smart contracts: 1. Rollup contract: Stores rollup blocks, monitors state updates, and tracks deposits 2. Verifier contract: Verifies zk-SNARK proofs submitted by your coordinator Together, these contracts allow your coordinator to finalize batches and state. The process is as follows: 1. The [coordinator](/protocol/architecture/coordinator) submits proofs, state commitments, and data-availability payloads to the finalization layer. 2. The rollup contract receives the submission. 3. The rollup contract calls the verifier contract to verify the proof. 4. The verifier contract uses the submitted commitments and data-availability payloads to verify proof validity. 5. If verification succeeds, state is finalized on the finalization layer. important Without the rollup and verifier contracts on your finalization layer, your coordinator cannot finalize batches. These contracts are required for proof verification and state finalization.