|
| 1 | +# Rollups vs. Validiums |
| 2 | + |
| 3 | +[Layer 2s](./layer2s.md) can differ in how they interact with Ethereum; more specifically, they often differ in what they do with the transaction data (i.e. the information about transactions that occurred on the L2). They can be broadly categorized into two types: **rollups** and **validiums**. |
| 4 | + |
| 5 | +## Rollups |
| 6 | + |
| 7 | +Rollups use **Ethereum** as a [data availability](https://docs.polygon.technology/cdk/glossary/#data-availability) (DA) layer, meaning they send and store transaction data directly on Ethereum, by providing it inside the parameters of a transaction submitted to a smart contract on the L1. |
| 8 | + |
| 9 | +Using Ethereum to store transaction data is generally considered the most secure option for DA as it leverages Ethereum's security and decentralization. However, this approach is costly, as the L2 must pay Ethereum’s high gas fees to store data on the L1, which typically results in higher gas fees for users. |
| 10 | + |
| 11 | +Within the rollup category, there are further nuances to storing transaction data on Ethereum. Some rollups post serialized transaction data directly, whereas other rollups post state differences instead. Some rollups use [calldata](https://docs.soliditylang.org/en/v0.8.26/types.html#data-location) to store transaction data, while others use more recent Ethereum features such as Blobs, introduced in [EIP-4844](https://www.eip4844.com/). |
| 12 | + |
| 13 | +The CDK provides full flexibility to developers to choose what to do with transaction data, including the ability to build rollups that store data on Ethereum as a rollup like the Polygon zkEVM. |
| 14 | + |
| 15 | +## Validiums |
| 16 | + |
| 17 | +Validiums **do not** store transaction data on Ethereum. Instead, they post ZK proofs called validity proofs to Ethereum that verify the state of the L2 chain. |
| 18 | + |
| 19 | +As the L2 does not pay the high gas fees associated with storing data on Ethereum, this approach is more cost-effective than rollups, meaning gas fees are also lower for users. However, validiums are typically considered less secure than rollups, as they rely on alternative data availability solutions such as a [Data Availability Committee (DAC)](https://docs.polygon.technology/cdk/glossary/#data-availability-committee-dac). |
| 20 | + |
| 21 | +### Alternative DA Solutions |
| 22 | + |
| 23 | +The CDK also supports the integration of alternative DA solutions, with support for networks such as [Avail DA](https://blog.availproject.org/avail-ecosystem-series-polygon-zkevm-validium/), [Celestia](https://polygon.technology/blog/celestias-high-throughput-out-of-the-box-data-availability-layer-to-integrate-with-polygon-cdk), [Near DA](https://pages.near.org/blog/near-da-integrates-with-polygon-cdk-for-developers-building-ethereum-zk-rollups/) and more. |
| 24 | + |
| 25 | +## What's Best for You? |
| 26 | + |
| 27 | +The method you use to store transaction data should be determined by your specific use case. As a general rule of thumb: |
| 28 | + |
| 29 | +- **Rollups** are more suitable for chains that process high-value transactions where security is the top priority, such as DeFi applications; as they are considered more secure with slightly higher fees and limited throughput. |
| 30 | + |
| 31 | +- **Validiums** are more suitable for chains that process a high volume of transactions where low transaction fees are the top priority, such as gaming or social applications; as they are considered more scalable and offer low fees. |
| 32 | + |
| 33 | + |
| 34 | + |
| 35 | +## Technical Comparison |
| 36 | + |
| 37 | +Below is a breakdown of the technical differences between a zkEVM rollup and validium: |
| 38 | + |
| 39 | +| | Rollup | Validium | |
| 40 | +| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |
| 41 | +| **Node type** | [zkEVM node](https://github.com/0xPolygonHermez/zkevm-node) | [Validium node](https://github.com/0xPolygon/cdk-validium-node): zkEVM node with validium extensions | |
| 42 | +| **Data availability** | On-chain via L1 | Off-chain via a local option, or a [DAC](../glossary/index.md#data-availability-committee-dac) + [DA node](https://github.com/0xPolygon/cdk-data-availability) | |
| 43 | +| **Components** | zkEVM components\* | zkEVM components\* + PostgreSQL database + on-chain committees | |
| 44 | +| **Contracts** | [zkEVM smart contracts](https://github.com/0xPolygonHermez/zkevm-contracts) <ul><li>`PolygonZkEVM` (main rollup contract)</li> <li> `PolygonZkEVMBridge`</li> <li>`PolygonZkEVMGlobalExitRoot`</li></ul> | [Validium-specific DAC contract](https://github.com/0xPolygon/cdk-validium-contracts) <ul><li>`CDKDataCommittee.sol`</li><li> `CDKValidium.sol` </li></ul> | |
| 45 | +| **Infrastructure** | Standard infrastructure | Dedicated infrastructure for data availability layer and DACs | |
| 46 | +| **Tx flow** | All transaction data is published on L1 | Validium only publishes the hash of the transaction data to L1. The sequencer sends both the hash and the transaction data to the DAC for verification. Once approved, the hash+signatures are sent to the Consensus L1 contract of the validium protocol. | |
| 47 | +| **Security** | High security due to on-chain data availability and zero-knowledge proofs. | Off-chain data availability can affect security if the sequencer goes offline or if DAC members collude to withhold state data. | |
| 48 | +| **Gas fees** | High, because all transaction data is stored on Ethereum. | Low, because only the hash of the transaction data is stored on Ethereum. | |
| 49 | +| **Proof generation** | Uses Prover to generate proofs of batched transactions for validation. | Uses Prover to generate proofs of batched transactions for validation. | |
| 50 | +| **Final settlement** | Transaction batches and their corresponding proofs are added to the Ethereum state. | The hash of transaction data and its proof are added to the Ethereum state, referred to as the consolidated state. | |
| 51 | + |
| 52 | +<sub><sup>\*</sup>JSON RPC, Pool DB, Sequencer, Etherman, Synchronizer, State DB, Aggregator, Prover</sub> |
0 commit comments