Skip to main content

Privacy and data visibility

This page describes what a Lineth (formerly the Linea Stack) deployment publishes, retains offchain, makes visible, and allows participants to verify.

For access policy, see Access control. For regulatory compliance, see Compliance.

This page does not cover cryptographic private execution or private state. Lineth does not publish a shipped capability for onchain ZK privacy; do not infer it from validium or RBAC.

Validium data flow​

In validium mode, the Lineth deployment proves state transitions using zk-SNARKs while retaining transaction data within a private data availability layer. After blocks are produced by the Sequencer, they are aggregated and batched, and a zk-SNARK proof attesting to the resulting state transition is generated and submitted to the finalization layer.

State commitments and proofs are posted onchain. Transaction data is not.

Data visibility by layer​

LayerWhat is publishedWho can see it
Finalization layerState commitments, zk-SNARK proofs, bridge messagesAnyone reading the finalization layer
Operator data availability layerTransaction data, full ordered historyParticipants the operator authorizes, per the deployment's data access model
RPC and API surfacesState and transactions the caller is authorized to viewCallers with RBAC permissions for the relevant endpoint

Offchain data availability changes where transaction data lives. It does not by itself make transactions cryptographically private. A participant with access to the offchain data can read it; a participant without access cannot.

Offchain data availability​

Transaction data is stored offchain in a private node set, so only state commitments and zk-SNARK proofs go onchain. With the relevant data, a participant can verify their own state against the onchain commitments using Merkle proofs.

Unlike a public network, a validium does not give every participant a full view of all transactions or their ordering. Reconstruction or independent verification of full history requires access to the offchain data, which the deployment's RBAC and governance rules control.

Access control​

RBAC controls access to network functionality:

  • RPC endpoints: access controlled by API keys and permissions
  • API portal: institution-level access controls
  • Transaction visibility: participants see only transactions they are authorized to view

RBAC is an access policy. It controls who can call an endpoint or view data the deployment exposes. It is not a cryptographic privacy mechanism and does not hide data from the operator or from participants who already hold the data.

Finalization layer options​

A private validium can finalize on:

  • Ethereum L1: direct finalization on Ethereum, with higher costs and longer finality times
  • Linea Mainnet: finalization on Linea Mainnet, with lower costs and faster finality

See a comparison of finalization layer options.

Architecture​

Private validium deployments include:

  • Consensus layer: Maru with Quorum-Based Byzantine Fault Tolerance (QBFT) consensus (minimum 4 nodes, see multi-validator consensus)
  • Execution layer: Linea Besu with sequencer plugins
  • Coordinator: orchestrates proof generation and finalization
  • Prover: generates zk-SNARK proofs
  • State manager: maintains state for proof generation
  • Private RPC nodes: RBAC-protected RPC endpoints
  • API portal: controlled access to network functionality
  • Data availability: private node set for data storage

Trust and security​

Trust assumptions​

Private validium requires trust in:

  • Data availability providers: they must make data available when needed
  • Validator set: must follow consensus protocol (QBFT provides fault tolerance with 3f+1 validators)
  • Finalization layer: the deployment inherits the finality assumptions of the selected finalization layer

For the full trust-boundary and failure-mode treatment, see Trust and responsibilities.

Security features​

  • Minimum node count: 4 nodes for QBFT fault tolerance
  • Access controls: RBAC on RPC and API endpoints
  • Key management: supports Web3Signer remote signing backed by a hardware security module (HSM) or key management service (KMS)
  • Network isolation: private network topology

Data availability​

Where deployments use a private node set for data storage, participants must trust that data availability providers will make data available when needed, or operate under a consortium model that gives them direct access to the data required for verification and recovery.

Next steps​

Was this page helpful?