diff --git a/docs/stack/deployment/access-control.mdx b/docs/stack/deployment/access-control.mdx index 428abca5c6..7b7c9af8df 100644 --- a/docs/stack/deployment/access-control.mdx +++ b/docs/stack/deployment/access-control.mdx @@ -158,5 +158,3 @@ They do not receive a view of private contracts or transaction data. - [Native interoperability](./interoperability.mdx): How two access controlled Lineth networks communicate with each other using the Cross Ledger Interoperability Protocol (CLIP). -- [Privacy and data visibility](../evaluate/validium.mdx): How private validium deployments use offchain - data availability and controlled access. diff --git a/docs/stack/evaluate/compliance.mdx b/docs/stack/evaluate/compliance.mdx index 3addddbec8..f54b0e7a74 100644 --- a/docs/stack/evaluate/compliance.mdx +++ b/docs/stack/evaluate/compliance.mdx @@ -1,82 +1,43 @@ --- title: Compliance description: >- - Protocol evidence operators can use in a compliance program, and what Lineth - does not claim + How to use a Lineth deployment's protocol evidence in your own compliance + program sidebar_position: 1 image: /img/socialCards/compliance.jpg --- import GlossaryTerm from '@theme/GlossaryTerm'; -This page describes what protocol evidence a deployment produces that operators can use in their own compliance -program, and what Lineth does not claim. +This page describes how to use a deployment's protocol evidence in your own +compliance program. +Operators design the program and map its controls to their own obligations. +Lineth does not certify a deployment against a regulatory framework. -This page does **not** include: +For protocol guarantees, operator-controlled surfaces, cryptographic primitives, and assurance evidence, +see [Security and assurance](./security.mdx). -- Mapping to specific regulatory frameworks. -- A certification or attestation that a deployment is compliant. -- Data retention or deletion product features. Operators implement retention and - disclosure against their own policy using the deployment's data availability - and access controls. +## Deployment evidence -## zk-SNARK proofs are not a compliance program - - proofs verify state-transition correctness. They do not by themselves -provide a complete compliance program. A compliance program needs controls, -evidence, retention, disclosure, and ownership that go beyond proof -verification. - -## Protocol evidence a deployment produces - -A Lineth deployment produces the following evidence that operators can use in a -compliance design: +A Lineth deployment produces evidence you can cite in your compliance program: - State commitments posted to the finalization layer -- zk-SNARK proof verification records on the finalization layer +- proof verification records on the finalization layer - Finalization records on the finalization layer - Transaction history retained by the deployment's data availability model -What participants can verify depends on the deployment model. For the trust and -verification boundaries, see -[Trust model](./trust-model.mdx). For where data is -stored and who can see it, see [Privacy and data visibility](./validium.mdx). - -## Operator-owned compliance controls - -Operators are responsible for the controls a compliance program requires. Lineth -provides mechanisms operators can configure, but does not own the program: - -- Access policy: [RBAC](../deployment/access-control.mdx) on RPC endpoints and API surfaces controls - who can read or submit -- Data availability arrangement: operators choose where transaction data is - stored and who can reconstruct it; see - [Data availability and finalization](../deployment/data-availability-finalization.mdx) -- [Key management](../deployment/key-management.mdx): remote signing backed by - HSM or KMS via [Web3Signer](../../protocol/architecture/index.mdx#web3signer) -- Governance and upgrade authority: multisig, governance contract, or timelock - for privileged roles; see [Security and assurance](./security.mdx) -- External integrations: operators connect external compliance, monitoring, and - logging systems to their deployment +What participants can reconstruct or verify from that evidence depends on the +[deployment model](./deployment-models.mdx). +See [Trust model](./trust-model.mdx) for trust and verification boundaries. -## What Lineth does not claim +## Retention and disclosure -- Lineth does not certify a deployment as compliant with any specific - regulation. -- Lineth does not publish a control-to-framework mapping. -- Private validium (offchain data) and - [access control](../deployment/access-control.mdx) (RPC gating) are not - cryptographic private execution or ZK privacy. Do not infer regulatory - compliance from them. -- Lineth does not own data retention or disclosure policy. Operators implement - it. +Operators implement retention and disclosure against their own policy, using the deployment's +[data availability](../deployment/data-availability-finalization.mdx) and +[access control](../deployment/access-control.mdx) configuration. +They connect their own compliance, monitoring, and logging systems to the deployment. -## Where to go next +## See also -| Question | Page | -| ----------------------------------------------------------- | ---------------------------------------------------------------------------------------- | -| What can each component do, and what can participants verify? | [Trust model](./trust-model.mdx) | -| Who can see what data? | [Privacy and data visibility](./validium.mdx) | -| What is protocol versus operator, and what evidence exists? | [Security and assurance](./security.mdx) | -| How is access to RPC and APIs controlled? | [Access control](../deployment/access-control.mdx) | -| How do data availability and finalization choices interact? | [Data availability and finalization](../deployment/data-availability-finalization.mdx) | +- [Security and assurance](./security.mdx): Protocol guarantees and published assurance evidence. +- [Trust model](./trust-model.mdx): What each component can do, and what participants can verify. diff --git a/docs/stack/evaluate/deployment-models.mdx b/docs/stack/evaluate/deployment-models.mdx index e52b1a45fc..65d282aa0a 100644 --- a/docs/stack/evaluate/deployment-models.mdx +++ b/docs/stack/evaluate/deployment-models.mdx @@ -1,103 +1,118 @@ --- title: Deployment models -description: >- - How to compare Lineth public and private validium deployment models and their - trade-offs -sidebar_position: 2 +description: Compare rollups and validiums, and their trade-offs image: /img/socialCards/deployment-models.jpg --- import GlossaryTerm from '@theme/GlossaryTerm'; - supports two deployment models: **public deployments**, such as -[Linea Mainnet](/network), with onchain data availability and open access; and **private validium deployments**, -with offchain data availability and controlled access. + supports two deployment models: **rollups**, in which transaction data is +posted to the finalization layer, 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. -Consider these questions when choosing a deployment model: +The following table compares how rollups and validiums address key deployment questions. +Choose the model that aligns with your requirements. -- [Privacy](validium.mdx) requirements: Should transaction data remain private to authorized participants? -- Regulatory and [compliance](./compliance.mdx) obligations: What controls does your program - require, and who owns them? -- [Data availability](../deployment/data-availability-finalization.mdx) guarantees: How important is onchain data availability for - your participants? -- Network topology: Do you need a private network with controlled membership? -- [Access control](../deployment/access-control.mdx): Do you need role-based access control (RBAC) on RPC endpoints and - APIs? +| Questions | Rollup | Public validium | Private validium | +| --- | --- | --- | --- | +| Where is transaction data stored? | On the finalization layer as [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) blobs | On the Lineth network's nodes | On the Lineth network's nodes | +| 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](../deployment/access-control.mdx) permissions on RPC | -The following table compares how characteristics differ between public deployments and private validium deployments. -Choose the deployment model that aligns with your requirements. +The following sections provide more details about each model. -| 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 layer | 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 | +## Rollups -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. +In a rollup, the coordinator posts +transaction data to the finalization layer using [EIP-4844](https://eips.ethereum.org/EIPS/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 -- Networks requiring maximum transparency +- Applications that require maximum transparency - Applications that benefit from onchain data availability -- Networks that prioritize open access over transaction privacy +- Applications that prioritize open access over transaction privacy ### Security considerations -- Validator topology: if the deployment uses a - [multi-validator QBFT design](../deployment/multi-validator-consensus.mdx), at least 4 - Maru validators are required to tolerate one faulty validator -- [Key management](../deployment/key-management.mdx): remote - signing backed by a hardware security module (HSM) or key management service - (KMS) +The following operator choices affect how you secure a rollup: -## Private validium +- Validator topology: If the deployment uses a + [multi-validator QBFT design](../deployment/multi-validator-consensus.mdx), at least 4 Maru validators + are required to tolerate one faulty validator. +- [Key management](../deployment/key-management.mdx): Remote signing backed by a hardware security + module (HSM) or key management service (KMS) -A private validium keeps transaction data offchain, using proofs -to support state-transition correctness and finalization. -RPC endpoints are protected by [access control](../deployment/access-control.mdx), and node membership is controlled. +## Validiums -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. +In a validium, the coordinator submits state +commitments and proofs to the finalization layer. +Transaction data is not posted there. +Typically that data lives on the validium's archive nodes. -### Use cases +### Public validiums -- 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 +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. -Operators with regulatory or compliance obligations are responsible for -designing their own compliance program. See -[Compliance](./compliance.mdx) for what protocol evidence exists and -what is not claimed. +#### Use cases -### Security considerations +- 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](../deployment/multi-validator-consensus.mdx), at least 4 Maru validators + are required to tolerate one faulty validator. +- [Key management](../deployment/key-management.mdx): 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](../deployment/access-control.mdx). +Authorized participants who can reach those nodes can reconstruct history. +A third party without that access cannot. + +:::warning Private validium is not cryptographic privacy +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](../deployment/multi-validator-consensus.mdx), at least 4 Maru validators + are required to tolerate one faulty validator. +- [Access control](../deployment/access-control.mdx): RBAC permissions on JSON-RPC, APIs, and tooling +- [Key management](../deployment/key-management.mdx): Remote signing backed by a hardware security + module (HSM) or key management service (KMS) +- Network isolation: Private network topology with controlled peering -- Validator topology: at least 4 Maru validators are required for a - [QBFT design](../deployment/multi-validator-consensus.mdx) that tolerates one faulty - validator -- [Access control](../deployment/access-control.mdx): RBAC on RPC endpoints and API portal -- [Key management](../deployment/key-management.mdx): 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](../deployment/index.mdx#example-architecture). ## See also -- [Trust model](./trust-model.mdx): Trust assumptions for each deployment model -- [Privacy and data visibility](./validium.mdx): What a private validium publishes and who can see it +- [Trust model](./trust-model.mdx): Trust assumptions for each deployment model, and what participants can verify - [Data availability and finalization](../deployment/data-availability-finalization.mdx): Where transaction data is stored in each deployment model, and where proofs settle diff --git a/docs/stack/evaluate/index.mdx b/docs/stack/evaluate/index.mdx index 04f7744ef6..9f36a85463 100644 --- a/docs/stack/evaluate/index.mdx +++ b/docs/stack/evaluate/index.mdx @@ -28,12 +28,6 @@ your use case. "Understand what each deployment component can do, what participants can verify, and privileged contract roles.", href: "/stack/evaluate/trust-model", }, - { - text: "Privacy and data visibility", - description: - "Learn what a private validium publishes, keeps offchain, and allows participants to verify.", - href: "/stack/evaluate/validium", - }, { text: "Security and assurance", description: @@ -43,7 +37,7 @@ your use case. { text: "Compliance", description: - "See what protocol evidence a deployment produces, to use in your own compliance program.", + "Use a deployment's protocol evidence in your own compliance program.", href: "/stack/evaluate/compliance", }, ]} diff --git a/docs/stack/evaluate/security.mdx b/docs/stack/evaluate/security.mdx index 5888f3099c..711d66533a 100644 --- a/docs/stack/evaluate/security.mdx +++ b/docs/stack/evaluate/security.mdx @@ -47,13 +47,11 @@ Under the configured deployment model, Lineth provides: - Bridge and message execution gated by verified state commitments. Messages are tied to verified state transitions in the normal protocol path. -For the trust boundaries behind each of these, see -[Trust model](./trust-model.mdx). +For the trust assumptions in a Lineth deployment, see [Trust model](./trust-model.mdx). ## Operator-controlled security surfaces Operators define and operate their own security boundary. -Lineth does not ship a production security operations program. Operators are responsible for: - Infrastructure isolation and network security controls. @@ -139,3 +137,7 @@ conclusions for custom deployments. Organizations evaluating a deployment must assess the applicable software versions, configuration, infrastructure, governance, and operational controls separately. + +## See also + +- [Compliance](./compliance.mdx): How to use protocol evidence in a compliance program. diff --git a/docs/stack/evaluate/validium.mdx b/docs/stack/evaluate/validium.mdx deleted file mode 100644 index ab9dd07a80..0000000000 --- a/docs/stack/evaluate/validium.mdx +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Privacy and data visibility -description: 'Where Lineth deployment data is published, retained, visible, and verifiable' -sidebar_position: 5 -image: /img/socialCards/privacy-and-data-visibility.jpg ---- - -import GlossaryTerm from '@theme/GlossaryTerm'; - -This page describes what a private validium deployment -publishes, retains offchain, makes visible, and allows participants to verify. - -For access policy, see [Access control](../deployment/access-control.mdx). -For regulatory compliance, see [Compliance](./compliance.mdx). - -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. - -## Private 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 - -| Layer | What is published | Who can see it | -| -------------------------------- | ------------------------------------------------------- | ---------------------------------------------------------------------------- | -| Finalization layer | State commitments, zk-SNARK proofs, bridge messages | Anyone reading the finalization layer | -| Operator data availability layer | Transaction data, full ordered history | Participants the operator authorizes, per the deployment's data access model | -| RPC and API surfaces | State and transactions the caller is authorized to view | Callers with [RBAC permissions](../deployment/access-control.mdx) 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](../../protocol/architecture/state-manager.mdx#merkle-trees). - -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 [access control](../deployment/access-control.mdx) and governance rules control. - -## Access control - -A private validium can restrict JSON-RPC access by configuring [access control](../deployment/access-control.mdx). -Clients send requests to a single RPC endpoint that authenticates callers and enforces -RBAC permissions. - -Access control restricts who can call RPC methods. -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](../deployment/data-availability-finalization.mdx#finalization-layer). - -## Architecture - -Private validium deployments include: - -- Consensus layer: [Maru](../../protocol/reference/repos.mdx#maru) with - QBFT consensus (minimum 4 nodes, - see [multi-validator consensus](../deployment/multi-validator-consensus.mdx)) -- Execution layer: - [Linea Besu](../../protocol/reference/repos.mdx#linea-besu-upstream) with - sequencer plugins -- [Coordinator](../../protocol/architecture/coordinator/index.mdx): orchestrates proof - generation and [finalization](../../network/overview/transaction-finality.mdx) -- [Prover](../../protocol/architecture/prover/index.mdx): generates zk-SNARK - proofs -- [State manager](../../protocol/architecture/state-manager.mdx): 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 for a private validium, including data availability, the validator set, and the -finalization layer, are on [Trust model](./trust-model.mdx#trust-assumptions). - -Security features include: - -- Minimum node count: 4 nodes for QBFT fault tolerance -- [Access control](../deployment/access-control.mdx): Role-based permissions on JSON-RPC, APIs, and tooling -- [Key management](../deployment/key-management.mdx): supports - [Web3Signer](../../protocol/architecture/index.mdx#web3signer) remote signing - backed by a hardware security module (HSM) or key management service (KMS) -- Network isolation: private network topology - -## Next steps - -- Learn more about selecting a - [deployment model](./deployment-models.mdx) -- Review [security and assurance](./security.mdx) -- Review [compliance](./compliance.mdx) diff --git a/redirects.json b/redirects.json index 36486266b3..1153544282 100644 --- a/redirects.json +++ b/redirects.json @@ -1482,8 +1482,9 @@ ] }, { - "to": "/stack/evaluate/validium", + "to": "/stack/evaluate/deployment-models#private-validiums", "from": [ + "/stack/evaluate/validium", "/stack/features/validium" ] }, diff --git a/sidebars.js b/sidebars.js index 377796e5c7..53d5261655 100644 --- a/sidebars.js +++ b/sidebars.js @@ -456,11 +456,6 @@ const sidebars = { id: "stack/evaluate/trust-model", label: "Trust model", }, - { - type: "doc", - id: "stack/evaluate/validium", - label: "Privacy and data visibility", - }, { type: "doc", id: "stack/evaluate/security",