Skip to main content

Access control

This page describes operatorOperator The entity or consortium responsible for deploying, administering, and running the network infrastructure, contracts, keys, access controls, and operational procedures for a network built on Lineth.-configured access control for protected 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. RPC, API, and tooling surfaces. For data visibility choices, see Privacy and data visibility.

important

RBAC is not cryptographic privacy. It controls access to protected services and data surfaces, but it does not make public-chain data private, replace zero-knowledge proofs, or provide data availability.

What RBAC controls​

In a Lineth deployment, role-based access control (RBAC) can be used around operator-controlled access surfaces, including:

  • RPC endpoints that expose blockchain data or accept transactions
  • APIs and API portals used to manage or interact with the deployment
  • Explorer and tooling surfaces that show deployment data
  • Participant access to data in deployments where visibility is intentionally restricted

The operator decides which surfaces are exposed, who can use them, and how access is granted for the deployment.

How RBAC fits with private validium​

In a public deployment, transaction data is designed for broad visibility, and public RPC access is designed for broad availability. In a private validiumValidium A deployment model in which a Lineth network proves state transitions with zk-SNARKs but keeps transaction data in a private data availability layer instead of publishing it to the finalization layer. Only state commitments and proofs are posted onchain, so participants without access to the offchain data can't independently reconstruct or verify the full transaction history. deployment, transaction data may be kept offchain, and access to network functionality may be restricted.

RBAC is one part of that controlled-access model. It can help limit access to RPC endpoints, APIs, API portals, and related tooling. It works alongside other deployment choices such as private data availability, network isolation, key management, and operator procedures.

RBAC determines which protected interfaces and data a participant can access. In deployments that use RBAC, the operator defines those access rules and can change them as part of operating the deployment.

Visibility and verification​

Participants can still verify proof validity on the finalization layer. For transactions, blocks, or state they are authorized to access, they may also verify that data against posted state roots using the deployment's available data. RBAC does not change the proof system; it changes which protected data and interfaces a participant can access.

For the broader trust model, see Trust model.

Limitations​

RBAC should be described with these limits:

  • RBAC does not encrypt data or hide data that is published to a public chain or finalization layer.
  • RBAC does not replace private data availability, data-retention, or selective-disclosure design.
  • RBAC does not replace zero-knowledge proof verification, governance, admin-key security, key management, monitoring, or incident response.
  • RBAC does not guarantee that every participant can verify full state or history. Verification depends on the deployment model, available data, and participant access.
  • Privacy: how private validium deployments use offchain data availability and controlled access.
  • Security: how RBAC fits into operational security controls.
  • Deployment models: how access control factors into deployment design.
  • RPC services: how RPC services expose blockchain data and can sit behind access controls.

Was this page helpful?