diff --git a/docs/stack/deployment/core-components.mdx b/docs/stack/deployment/core-components.mdx index 7221b193d5..d286cf82ac 100644 --- a/docs/stack/deployment/core-components.mdx +++ b/docs/stack/deployment/core-components.mdx @@ -51,32 +51,6 @@ The following [smart contracts](../../protocol/architecture/smart-contracts.mdx) - `LineaRollup` message bridge contract - Token bridge contracts -## Data availability - -In addition to concrete components, Lineth depends on correctness-critical requirements, which may be satisfied by different implementations depending on the [deployment model](../evaluate/deployment-models.mdx). - -**Purpose** - -- Ensure transaction data and state transitions remain accessible -- Enable reconstruction and verification of historical state - -**Correctness requirement** - -- Without data availability, the protocol cannot be independently verified -- Loss of data availability breaks state reconstructability - -**Example implementations** - -- **Linea Public Mainnet deployment:** EIP-4844 blobs on Ethereum -- **Private Validium deployments:** Operator-provided or outsourced data availability infrastructure - -**Trust model** - -- Data availability is within the trust boundary -- Responsibility for data availability implementation depends on deployment model - -See more on [data availability considerations](./data-availability-finalization.mdx). - ## Auxiliary services Auxiliary services are **not required for protocol correctness**. They are typically **optional** diff --git a/docs/stack/deployment/data-availability-finalization.mdx b/docs/stack/deployment/data-availability-finalization.mdx index 7cfc2c4167..6dde5989da 100644 --- a/docs/stack/deployment/data-availability-finalization.mdx +++ b/docs/stack/deployment/data-availability-finalization.mdx @@ -65,7 +65,7 @@ redundancy, and operational SLAs across the consortium of operators. - 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 +### Public deployments 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 diff --git a/docs/stack/evaluate/deployment-models.mdx b/docs/stack/evaluate/deployment-models.mdx index 3c4586ee0f..12fd6e0fda 100644 --- a/docs/stack/evaluate/deployment-models.mdx +++ b/docs/stack/evaluate/deployment-models.mdx @@ -9,56 +9,41 @@ image: /img/socialCards/deployment-models.jpg import GlossaryTerm from '@theme/GlossaryTerm'; -This page describes the deployment models and the trade-offs -they create for access, data availability, and finalization. Related evaluation -paths include [Trust and responsibilities](./trust-model.mdx) and -[Privacy and data visibility](./validium.mdx). + 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. -## Customization factors +Consider these questions when choosing a deployment model: -An operator can customize the following in a Lineth deployment: - -- Access control: who may access the mempool, ledger, and transaction data -- Data availability: how transaction data is stored and who can reconstruct it -- Finalization speed: block size and configuration affect soft finality speed -- Finalization layer: whether you finalize on Ethereum or Linea affects security assumptions and - hard finality speed -- Transaction ordering: operators can apply custom ordering rulesets - -Operators own these choices. Lineth does not recommend a specific set of customizations. - -## Two primary models - -Lineth supports two primary deployment models: - -- [Public deployments](#public), such as Linea Mainnet, with onchain data availability -- [Private validium deployments](#private-validium), with offchain data availability and controlled - access - -When configuring a deployment, consider: - -- Privacy requirements: should transaction data remain private to authorized - participants? -- Regulatory and [compliance](./compliance.mdx) obligations: what controls does your program +- [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 guarantees: how important is onchain data availability for +- [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: do you need [RBAC](../deployment/rbac.mdx) on RPC endpoints and +- Network topology: Do you need a private network with controlled membership? +- [Access control](../deployment/rbac.mdx): Do you need role-based access control (RBAC) on RPC endpoints and APIs? -## Public +The following table compares how characteristics differ between public deployments and private validium deployments. +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 | -Public deployments such as Linea Mainnet are fully public networks with onchain -data availability. +The following sections provide more details about use cases and security considerations for each model. -### Characteristics +## Public deployments -- Data availability: transaction data is posted onchain via EIP-4844 blobs -- Public access: public RPC endpoint -- Transparency: all transactions are visible on the finalization layer -- Finalization: state commitments, proofs, and data are posted to the - finalization layer +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. +RPC access is public, and node membership is not restricted. ### Use cases @@ -79,29 +64,14 @@ data availability. ## Private validium -A private validium keeps transaction data offchain while using zk-SNARK proofs -to support state-transition correctness and finalization. Whether this model +A private validium keeps transaction data offchain, using proofs +to support state-transition correctness and finalization. +RPC endpoints are protected by [RBAC](../deployment/rbac.mdx), and node membership is controlled. + +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. -### Characteristics - -- Data availability: transaction data can be stored offchain in a private node - set -- Data visibility: transaction details are not posted to the finalization layer; - what participants can see depends on the deployment's data availability and - [RBAC](../deployment/rbac.mdx) configuration -- Access control: RPC endpoints protected by [RBAC](../deployment/rbac.mdx); only - authorized participants can view data they are scoped to -- [Finalization](../../network/overview/transaction-finality.mdx): state - commitments and proofs are posted to the finalization layer -- Network topology: private network with controlled node membership - -In private validium deployments, participant visibility depends on RBAC settings -and data availability access. Some participants may verify only the data they -are authorized to access. For the trust trade-off, see -[Trust and responsibilities](./trust-model.mdx). - ### Use cases - Workflows where transaction data should not be public @@ -127,7 +97,9 @@ what is not claimed. (KMS) - Network isolation: private network topology with controlled peering -## Next steps +## See also -Also consider the design decisions required to determine the -[finality mechanism](../deployment/data-availability-finalization.mdx#finality-design-options). +- [Trust and responsibilities](./trust-model.mdx): Trust assumptions and guarantees for each deployment model +- [Privacy and data visibility](./validium.mdx): What a private validium publishes and who can see it +- [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 f2f72465b5..5980fcbf86 100644 --- a/docs/stack/evaluate/index.mdx +++ b/docs/stack/evaluate/index.mdx @@ -31,7 +31,7 @@ your use case. { text: "Privacy and data visibility", description: - "Learn what a deployment publishes, keeps offchain, makes visible, and allows participants to verify.", + "Learn what a private validium publishes, keeps offchain, and allows participants to verify.", href: "/stack/evaluate/validium", }, { diff --git a/docs/stack/evaluate/trust-model.mdx b/docs/stack/evaluate/trust-model.mdx index 916e1d7029..18906fa99c 100644 --- a/docs/stack/evaluate/trust-model.mdx +++ b/docs/stack/evaluate/trust-model.mdx @@ -52,11 +52,11 @@ For the full list of roles, see [LineaRollup contracts reference](/network/build ## Trust assumptions per deployment model -| Trust dimension | Public rollup on Ethereum | Private validium on Ethereum | Private validium on Linea Mainnet | +| Trust dimension | Public deployment on Ethereum | Private validium on Ethereum | Private validium on Linea Mainnet | | --- | --- | --- | --- | | Data availability provided by | Ethereum (EIP-4844 blobs) | Operator-run archive nodes or DA committee | Operator-run archive nodes or DA committee | | Finalization layer | Ethereum | Ethereum | Linea Mainnet (which itself anchors to Ethereum) | -| Bridge trust to the finalization layer | Canonical bridge: ZK proofs, plus admin and upgrade authority for pauses, verifier configuration, and contract upgrades | Same as rollup | Canonical bridge to Linea Mainnet (proofs plus admin and upgrade authority), plus Linea Mainnet's own bridge and governance assumptions | +| Bridge trust to the finalization layer | Canonical bridge: ZK proofs, plus admin and upgrade authority for pauses, verifier configuration, and contract upgrades | Same as public deployment | Canonical bridge to Linea Mainnet (proofs plus admin and upgrade authority), plus Linea Mainnet's own bridge and governance assumptions | | Inherited trust assumptions | Ethereum L1 finality, plus the deployment's sequencer, prover, admin key, verifier configuration, and upgrade-authority assumptions | Ethereum L1 finality, plus the deployment's sequencer, prover, admin key, verifier, upgrade, and DA assumptions | Ethereum L1 + Linea Mainnet finality, plus Linea Mainnet sequencer, prover, Security Council, admin key, verifier, upgrade, and bridge assumptions | | State reconstruction without operator | Yes, while L1 blob data is available; long-term reconstruction requires independent archival of EIP-4844 blob data | No, depends on operator-run DA and the deployment's data access model | No, depends on operator-run DA and the deployment's data access model | @@ -77,14 +77,14 @@ A private validium on Linea Mainnet The set of guarantees a participant can verify *without* trusting the operator depends on the deployment model. -**Public rollup on Ethereum** +### Public deployment on Ethereum - Proof validity and state-transition correctness, by reading the verifier contract on L1. A valid proof means the operator cannot finalize an invalid state transition through the normal proof path. - Full transaction history while L1 blobs are retained, by reading L1 blobs and reconstructing L2 state. After EIP-4844 blob expiry, long-term reconstruction depends on independent archival of blob data. - Bridge events and message status, on L1. - Contract role assignments and admin actions, on L1. -**Private validium on Ethereum** +### Private validium on Ethereum - Proof validity and state-transition correctness, by reading the verifier contract on L1. A valid proof means the operator cannot finalize an invalid state transition through the normal proof path. - That a state transition was proved, even if its transaction contents are private. @@ -93,7 +93,7 @@ The set of guarantees a participant can verify *without* trusting the operator d - Their own observed state, by running a node or using an authorized interface where the deployment grants access. - They cannot reconstruct full state or history without the required operator DA access. This is the validium trade-off, and [RBAC](../deployment/rbac.mdx) settings may further limit which data each participant can observe. -**Private validium on Linea Mainnet** +### Private validium on Linea - Proof validity and state-transition correctness, by reading the verifier contract on Linea Mainnet. A valid proof means the operator cannot finalize an invalid state transition through the normal proof path. - Same validium and [RBAC](../deployment/rbac.mdx) caveats as private validium on Ethereum, but proofs are verified on Linea Mainnet (which is itself proved to Ethereum). diff --git a/docs/stack/evaluate/validium.mdx b/docs/stack/evaluate/validium.mdx index f5e297c782..97f2bcdb7a 100644 --- a/docs/stack/evaluate/validium.mdx +++ b/docs/stack/evaluate/validium.mdx @@ -7,7 +7,7 @@ image: /img/socialCards/privacy-and-data-visibility.jpg import GlossaryTerm from '@theme/GlossaryTerm'; -This page describes what a deployment +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/rbac.mdx). @@ -17,7 +17,7 @@ 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 +## 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.