From a0f302db4a9f663f50debda5490f9ce756abcc43 Mon Sep 17 00:00:00 2001 From: Alexandra Carrillo Date: Thu, 17 Sep 2026 16:33:25 -0700 Subject: [PATCH 1/4] Edit pass: Lineth Stack evaluation docs --- docs/stack/deployment/access-control.mdx | 2 - docs/stack/evaluate/compliance.mdx | 83 +++++----------- docs/stack/evaluate/deployment-models.mdx | 83 +++++++++++----- docs/stack/evaluate/index.mdx | 8 +- docs/stack/evaluate/security.mdx | 8 +- docs/stack/evaluate/validium.mdx | 115 ---------------------- redirects.json | 3 +- sidebars.js | 5 - 8 files changed, 86 insertions(+), 221 deletions(-) delete mode 100644 docs/stack/evaluate/validium.mdx diff --git a/docs/stack/deployment/access-control.mdx b/docs/stack/deployment/access-control.mdx index e157d352b8..3df6ead4a6 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. - [Lineth-to-Lineth interoperability](./interoperability.mdx): How two Lineth networks communicate with each other, and how an access controlled destination authorizes calls. -- [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 41fde33dfa..282918636c 100644 --- a/docs/stack/evaluate/deployment-models.mdx +++ b/docs/stack/evaluate/deployment-models.mdx @@ -15,7 +15,7 @@ with offchain data availability and controlled access. Consider these questions when choosing a deployment model: -- [Privacy](validium.mdx) requirements: Should transaction data remain private to authorized participants? +- Privacy 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 @@ -35,7 +35,7 @@ Choose the deployment model that aligns with your requirements. | 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. +The following sections provide more details about each model. ## Public deployments @@ -53,51 +53,80 @@ RPC access is public, and node membership is not restricted. ### Security considerations -- Validator topology: if the deployment uses a +The following operator choices affect how you secure a public deployment: + +- Validator topology: If the deployment uses a [multi-validator QBFT design](../deployment/distributed-sequencing.mdx), at least 4 - Maru validators are required to tolerate one faulty validator -- [Key management](../deployment/key-management.mdx): remote + 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 validium -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. +A private validium keeps transaction data offchain in a data availability layer, and proves state +transitions using zk-SNARK proofs. +After the sequencer produces blocks, the +coordinator batches them and requests a proof. +The prover generates a zk-SNARK proof of the resulting state transition. +The coordinator submits that proof to the finalization layer. +Only state commitments and proofs are posted onchain. + +A private validium can [restrict access to JSON-RPC](../deployment/access-control.mdx) and control +node membership. + +For an illustrative topology, see the +[example validium architecture](../deployment/index.mdx#example-architecture). + +Operators with regulatory or compliance obligations are responsible for +designing their own [compliance](compliance.mdx) program. + +### Data visibility -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. +The following table outlines what is published and who can see it on each layer: the finalization layer, +the private node set for data storage (data availability layer), and RPC and API surfaces. + +| Layer | What is published | Who can see it | +| --- | --- | --- | +| Finalization layer | State commitments, zk-SNARK proofs, bridge messages | Anyone reading the finalization layer | +| Data availability layer | Transaction data, full ordered history | Participants the operator authorizes to read the offchain data | +| 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 | + +:::warning Private validium is not cryptographic privacy + +A private validium's offchain data availability 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. + +::: + +To learn what participants can verify from the published proofs and authorized offchain data, see +[Trust model](./trust-model.mdx#what-participants-can-verify). ### 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](./compliance.mdx) for what protocol evidence exists and -what is not claimed. +- Workflows that accept the validium trade-off: state-transition correctness is + proven onchain, but reconstructing history requires access to the operator's + [offchain data](../deployment/data-availability-finalization.mdx#private-validium) ### Security considerations -- Validator topology: at least 4 Maru validators are required for a - [QBFT design](../deployment/distributed-sequencing.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 +The following operator choices affect how you secure a private validium: + +- Validator topology: If the deployment uses a + [multi-validator QBFT design](../deployment/distributed-sequencing.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 +- Network isolation: Private network topology with controlled peering ## 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 3f28cccecd..9188c7e731 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 ab70015c0d..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/distributed-sequencing.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 ca81e16627..7fe04460e6 100644 --- a/redirects.json +++ b/redirects.json @@ -1473,8 +1473,9 @@ ] }, { - "to": "/stack/evaluate/validium", + "to": "/stack/evaluate/deployment-models#private-validium", "from": [ + "/stack/evaluate/validium", "/stack/features/validium" ] }, diff --git a/sidebars.js b/sidebars.js index e99a62d181..6732cd543b 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", From 72a4f0bfa64b250f3d53e3a9ab320890929bd612 Mon Sep 17 00:00:00 2001 From: Alexandra Carrillo Date: Tue, 29 Sep 2026 17:10:02 -0700 Subject: [PATCH 2/4] split validium into public and private --- docs/stack/evaluate/deployment-models.mdx | 140 ++++++++++------------ 1 file changed, 65 insertions(+), 75 deletions(-) diff --git a/docs/stack/evaluate/deployment-models.mdx b/docs/stack/evaluate/deployment-models.mdx index 282918636c..979e55002b 100644 --- a/docs/stack/evaluate/deployment-models.mdx +++ b/docs/stack/evaluate/deployment-models.mdx @@ -1,130 +1,120 @@ --- title: Deployment models -description: >- - How to compare Lineth public and private validium deployment models and their - trade-offs -sidebar_position: 2 +description: Compare public deployments 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: **public deployments (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: -- Privacy requirements: Should transaction data remain private to authorized participants? +- Privacy requirements: Should transaction data remain visible only 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? +- [Data availability](../deployment/data-availability-finalization.mdx) guarantees: Do participants + need to be able to reconstruct history from the finalization layer? - 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? +- [Access control](../deployment/access-control.mdx): 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. +The following table compares how characteristics differ between public deployments and validiums. 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 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 | +| Characteristic | Public deployment (rollup) | Public validium | Private validium | +| --- | --- | --- | --- | +| Transaction data | Posted to the finalization layer via EIP-4844 blobs | Stored by the Lineth network's nodes | Stored by 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 | +| Access and topology | Open RPC access | Open RPC access | Restricted node set and RBAC permissions on RPC | +| Who can reconstruct history | Anyone with blob data, while it is retained | Anyone who can reach the network's nodes | Authorized participants only | The following sections provide more details about each model. -## Public deployments +## Public deployments (rollups) -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 public deployment, or rollup, the coordinator posts +transaction data to the finalization layer (for example, using +[EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) blobs on Ethereum). +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 The following operator choices affect how you secure a public deployment: - Validator topology: If the deployment uses a - [multi-validator QBFT design](../deployment/distributed-sequencing.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) + [multi-validator QBFT design](../deployment/distributed-sequencing.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 validium +## Validiums -A private validium keeps transaction data offchain in a data availability layer, and proves state -transitions using zk-SNARK proofs. -After the sequencer produces blocks, the -coordinator batches them and requests a proof. -The prover generates a zk-SNARK proof of the resulting state transition. -The coordinator submits that proof to the finalization layer. -Only state commitments and proofs are posted onchain. +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. -A private validium can [restrict access to JSON-RPC](../deployment/access-control.mdx) and control -node membership. +### Public validiums -For an illustrative topology, see the -[example validium architecture](../deployment/index.mdx#example-architecture). +A public validium makes the Lineth network's data publicly readable. +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](compliance.mdx) program. +#### Use cases -### Data visibility +- Applications that need the lower finalization cost on Linea Mainnet, while keeping open access +- Applications that do not require transaction data on the finalization layer -The following table outlines what is published and who can see it on each layer: the finalization layer, -the private node set for data storage (data availability layer), and RPC and API surfaces. +#### Security considerations -| Layer | What is published | Who can see it | -| --- | --- | --- | -| Finalization layer | State commitments, zk-SNARK proofs, bridge messages | Anyone reading the finalization layer | -| Data availability layer | Transaction data, full ordered history | Participants the operator authorizes to read the offchain data | -| 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 | +The following operator choices affect how you secure a public validium: -:::warning Private validium is not cryptographic privacy +- Validator topology: If the deployment uses a + [multi-validator QBFT design](../deployment/distributed-sequencing.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's offchain data availability 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. +### 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. -To learn what participants can verify from the published proofs and authorized offchain data, see -[Trust model](./trust-model.mdx#what-participants-can-verify). +#### Use cases -### 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 -- Workflows where transaction data should not be public -- Multi-party workflows where participants should not see all transaction - details -- Workflows that accept the validium trade-off: state-transition correctness is - proven onchain, but reconstructing history requires access to the operator's - [offchain data](../deployment/data-availability-finalization.mdx#private-validium) - -### Security considerations +#### 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/distributed-sequencing.mdx), at least 4 Maru validators are - required to tolerate one faulty validator. + [multi-validator QBFT design](../deployment/distributed-sequencing.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) +- [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, and what participants can verify From f0ce1639315231b34649700725549a7d170e4361 Mon Sep 17 00:00:00 2001 From: Alexandra Carrillo Date: Wed, 30 Sep 2026 12:44:20 -0700 Subject: [PATCH 3/4] address comments --- docs/stack/evaluate/deployment-models.mdx | 24 ++++++++++++++--------- redirects.json | 2 +- 2 files changed, 16 insertions(+), 10 deletions(-) diff --git a/docs/stack/evaluate/deployment-models.mdx b/docs/stack/evaluate/deployment-models.mdx index 979e55002b..6d3df4b9d5 100644 --- a/docs/stack/evaluate/deployment-models.mdx +++ b/docs/stack/evaluate/deployment-models.mdx @@ -1,14 +1,14 @@ --- title: Deployment models -description: Compare public deployments and validiums, and their trade-offs +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 (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. + 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: @@ -22,10 +22,10 @@ Consider these questions when choosing a deployment model: - [Access control](../deployment/access-control.mdx): Do you need role-based access control (RBAC) on RPC endpoints and APIs? -The following table compares how characteristics differ between public deployments and validiums. +The following table compares how characteristics differ between rollups and validiums. Choose the deployment model that aligns with your requirements. -| Characteristic | Public deployment (rollup) | Public validium | Private validium | +| Characteristic | Rollup | Public validium | Private validium | | --- | --- | --- | --- | | Transaction data | Posted to the finalization layer via EIP-4844 blobs | Stored by the Lineth network's nodes | Stored by 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 | @@ -34,9 +34,9 @@ Choose the deployment model that aligns with your requirements. The following sections provide more details about each model. -## Public deployments (rollups) +## Rollups -In a public deployment, or rollup, the coordinator posts +In a rollup, the coordinator posts transaction data to the finalization layer (for example, using [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) blobs on Ethereum). State commitments, proofs, and transaction data appear on the finalization layer. @@ -51,7 +51,7 @@ RPC access is public, and node membership is not restricted. ### Security considerations -The following operator choices affect how you secure a public deployment: +The following operator choices affect how you secure a rollup: - Validator topology: If the deployment uses a [multi-validator QBFT design](../deployment/distributed-sequencing.mdx), at least 4 Maru validators @@ -93,6 +93,12 @@ A private validium keeps transaction data in a restricted node set and 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 diff --git a/redirects.json b/redirects.json index 7fe04460e6..f808fc3237 100644 --- a/redirects.json +++ b/redirects.json @@ -1473,7 +1473,7 @@ ] }, { - "to": "/stack/evaluate/deployment-models#private-validium", + "to": "/stack/evaluate/deployment-models#private-validiums", "from": [ "/stack/evaluate/validium", "/stack/features/validium" From 1f077e2946b9a77129b20b2c9523671a8cedd0f7 Mon Sep 17 00:00:00 2001 From: Alexandra Carrillo Date: Fri, 2 Oct 2026 16:56:39 -0700 Subject: [PATCH 4/4] address comments --- docs/stack/evaluate/deployment-models.mdx | 32 ++++++++--------------- 1 file changed, 11 insertions(+), 21 deletions(-) diff --git a/docs/stack/evaluate/deployment-models.mdx b/docs/stack/evaluate/deployment-models.mdx index f7bd13ae82..65d282aa0a 100644 --- a/docs/stack/evaluate/deployment-models.mdx +++ b/docs/stack/evaluate/deployment-models.mdx @@ -11,34 +11,22 @@ posted to the finalization layercoordinator posts -transaction data to the finalization layer (for example, using -[EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) blobs on Ethereum). +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. @@ -69,11 +57,13 @@ Typically that data lives on the validium's ar ### Public validiums 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. #### Use cases -- Applications that need the lower finalization cost on Linea Mainnet, while keeping open access +- 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