Wiki reorg: Edit Comparisons #6394
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- move content to main comparison page - structure new page
|
@mmagician I am making a comparison in the wiki between ZK, Optimistic, and Polkadot rollups. I know you are working on ZK rollups and I would like to ask if you can provide a review on the content of this PR 🙏 |
filippoweb3
added
A1 - In Progress
Co-authored-by: bader y <ibnbassem@gmail.com>
Co-authored-by: bader y <ibnbassem@gmail.com>
Co-authored-by: bader y <ibnbassem@gmail.com>
Co-authored-by: bader y <ibnbassem@gmail.com>
Co-authored-by: bader y <ibnbassem@gmail.com>
- redirect - sidebar updates
- sharding - l2beat
seunlanlege
reviewed
Dec 19, 2024
seunlanlege
reviewed
Dec 19, 2024
seunlanlege
reviewed
Dec 19, 2024
seunlanlege
reviewed
Dec 19, 2024
seunlanlege
reviewed
Dec 19, 2024
mmagician
suggested changes
Dec 20, 2024
| [Cosmos](./learn-comparisons-cosmos.md) and [Avalanche](./learn-comparisons-avalanche.md). | ||
| **Rollups** are an L2 scaling solution. At the most basic level, a rollup L2 solution is responsible | ||
| for "rolling up" transactions by batching them before publishing them to the L1 chain, usually | ||
| through a network of **sequencers**. This mechanism could include thousands of transactions in a |
There was a problem hiding this comment.
The sequencer's role is not necessarily publishing the Txs to the L1. In theory the role of sequencing Txs and publishing could be assumed by separate entities.
In practice today they're probably the same machine, but this is likely to change as rollups decentralize more.
|
|
||
| Layer two (L2) networks are popular as being the way forward for blockchain scalability by | ||
| off-loading the majority of computation from layer one (L1) networks. L2 solutions utilize the L1 | ||
| network's security and functionality to build an additional layer that is often faster, reduces |
There was a problem hiding this comment.
Functionality is not re-used.
One could launch an EVM or SVM or Move rollups that settle to Ethereum.
|
|
||
| An interactive method involves a back-and-forth process between parties to validate transactions. A | ||
| prominent example is the usage of fraud proofs, as used in optimistic rollups. If a dispute arises, | ||
| a challenge mechanism is triggered, where a "prover" submits evidence (fraud proof) to demonstrate |
There was a problem hiding this comment.
I don't know if these are already deployed in prod, or just being worked on now, but it's possible to have non-interactive dispute mechanisms.
I'd frame this section differently, as fraud proofs vs. validity proofs, which is the standard terminology.
| | **Aspect** | **Interactive** | **Non-Interactive** | | ||
| | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- | | ||
| | **Mechanism** | Back-and-forth dispute resolution. | One-time proof submission and verification. | | ||
| | **Latency** | Different time to finality depending on the technology, and mostly related to challenge periods. For instance, optimistic rollups can take a few hours while Polkadot rollups around 30 minutes. | Near-instant finality in theory. In practice ZK rollups can take hours to finalize. ZKsync for instance takes a whole day. | |
There was a problem hiding this comment.
The delay in validity rollup finality is not related to the technology used.
The delay is introduced artificially as "training wheels" - since this is still new tech and millions of $$ are secured there, they allow for some time for good old humans to intervene in case the social layer notices something being off, e.g. a ZK proof system having been broken.
| Both approaches serve different needs and trade-offs, depending on the balance between scalability, | ||
| security, latency, and flexibility required. | ||
|
|
||
| ### Zero-knowledge Rollups |
There was a problem hiding this comment.
If you really want to be picky, best to avoid the misleading term "ZK", since there is actually no zkSNARKs involved. These are just SNARKs.
But yeah the industry has kind of gotten used to calling them zk rollups
| solutions), allowing for shared security and scalability for each rollup through the | ||
| [Parachains Protocol](./learn-parachains-protocol.md). Polkadot handles the coordination of data | ||
| from parachains into an aggregated, representative state, somewhat similar to L2 rollups. | ||
| - Each shard, or parachain, can be equipped with a unique state transition function (STF). This |
There was a problem hiding this comment.
Each L2 can also have its own STF - as outlined above they can run different VMs (implies different STF)
| | **Finality** | Near-instant finality. Because the proof is immediately available, finality is also instantaneous. | Delayed finality (a week) due to fraud-proof mechanisms. | Fast finality (under 1 minute) via relay chain consensus. | | ||
| | **Security Model** | Relies on cryptographic validity proofs, ensuring high security and no reliance on game-theoretic assumptions. | Relies on economic incentives and a challenge period to catch fraud. Optimistic assumption makes it less secure than ZK Rollups. | "Cynical" model, where every transaction is checked by a subset of validators, with escalation and slashing in case of disputes. | | ||
| | **Scalability** | Limited scalability as they are a single state machine and are only as scalable as the prover machine and computation requirement. Many zk-rollups disable cryptographic precompiles on mainnet as a result of the immense computational requirement for them. | High, with parallelization, but limited by gas costs on L1 chains like Ethereum. | Inherently scalable through native execution sharding and parachains operating in parallel. [Pipelining](./learn-async-backing.md) and [core scheduling](./learn-agile-coretime.md) increase throughput and scalability for the single rollup. Execution sharding is enabled by multiple virtual cores using [coretime](./learn-agile-coretime.md). | | ||
| | **Decentralization** | Centralization risks for sequencers and zk proof computation. | Sequencer centralization risks; fewer validators can lead to potential censorship. | Collator decentralization is critical to ensure parachains remain trustless and independent. | |
There was a problem hiding this comment.
Sequencer centralization risks are common problems to all rollups polkadot or not
| | **Security Model** | Relies on cryptographic validity proofs, ensuring high security and no reliance on game-theoretic assumptions. | Relies on economic incentives and a challenge period to catch fraud. Optimistic assumption makes it less secure than ZK Rollups. | "Cynical" model, where every transaction is checked by a subset of validators, with escalation and slashing in case of disputes. | | ||
| | **Scalability** | Limited scalability as they are a single state machine and are only as scalable as the prover machine and computation requirement. Many zk-rollups disable cryptographic precompiles on mainnet as a result of the immense computational requirement for them. | High, with parallelization, but limited by gas costs on L1 chains like Ethereum. | Inherently scalable through native execution sharding and parachains operating in parallel. [Pipelining](./learn-async-backing.md) and [core scheduling](./learn-agile-coretime.md) increase throughput and scalability for the single rollup. Execution sharding is enabled by multiple virtual cores using [coretime](./learn-agile-coretime.md). | | ||
| | **Decentralization** | Centralization risks for sequencers and zk proof computation. | Sequencer centralization risks; fewer validators can lead to potential censorship. | Collator decentralization is critical to ensure parachains remain trustless and independent. | | ||
| | **Interoperability** | Limited interoperability, often restricted to compatible L1s. | Limited interoperability, often confined to the parent blockchain ecosystem. See the [comparison about interoperability](#interoperability-comparison) for more information. | Native interoperability through [XCM](./learn-xcm.md), allowing seamless communication between parachains having different logic. [Trustless bridges](./learn-bridges.md) can connect Polkadot to other blockchains. | |
There was a problem hiding this comment.
Teams are working on native interoperability within rollup hubs, e.g. rollups within the OP Stack ecosystem will have "better" interop than independent L2s.
How exactly it's going to work is TBD, but at least being worked on by multiple teams
| | **Scalability** | Limited scalability as they are a single state machine and are only as scalable as the prover machine and computation requirement. Many zk-rollups disable cryptographic precompiles on mainnet as a result of the immense computational requirement for them. | High, with parallelization, but limited by gas costs on L1 chains like Ethereum. | Inherently scalable through native execution sharding and parachains operating in parallel. [Pipelining](./learn-async-backing.md) and [core scheduling](./learn-agile-coretime.md) increase throughput and scalability for the single rollup. Execution sharding is enabled by multiple virtual cores using [coretime](./learn-agile-coretime.md). | | ||
| | **Decentralization** | Centralization risks for sequencers and zk proof computation. | Sequencer centralization risks; fewer validators can lead to potential censorship. | Collator decentralization is critical to ensure parachains remain trustless and independent. | | ||
| | **Interoperability** | Limited interoperability, often restricted to compatible L1s. | Limited interoperability, often confined to the parent blockchain ecosystem. See the [comparison about interoperability](#interoperability-comparison) for more information. | Native interoperability through [XCM](./learn-xcm.md), allowing seamless communication between parachains having different logic. [Trustless bridges](./learn-bridges.md) can connect Polkadot to other blockchains. | | ||
| | **State Transition Logic** | General-purpose but constrained by zk-circuit implementation complexity. | Can only support EVM state transitions with assumptions of optimistic validity since they have to be checked in the EVM environment<sup>1</sup>. | Each parachain can define its unique state transition function (STF), compiled to Wasm and validated per Parachain Protocol rules. | |
There was a problem hiding this comment.
Not true, optimistic rollups' opcodes aren't natively checked by the L1. Instead, the individual opcodes of the L2 are interpreted by the EVM.
One could equally implement the interpretation logic of other VMs aside from the EVM.
| | **Interoperability** | Limited interoperability, often restricted to compatible L1s. | Limited interoperability, often confined to the parent blockchain ecosystem. See the [comparison about interoperability](#interoperability-comparison) for more information. | Native interoperability through [XCM](./learn-xcm.md), allowing seamless communication between parachains having different logic. [Trustless bridges](./learn-bridges.md) can connect Polkadot to other blockchains. | | ||
| | **State Transition Logic** | General-purpose but constrained by zk-circuit implementation complexity. | Can only support EVM state transitions with assumptions of optimistic validity since they have to be checked in the EVM environment<sup>1</sup>. | Each parachain can define its unique state transition function (STF), compiled to Wasm and validated per Parachain Protocol rules. | | ||
| | **Development Complexity** | Complex due to the mathematics of zero-knowledge proofs. | Moderate complexity, requiring fraud-proof implementation. | Moderate to high complexity; parachain runtimes must be written in Wasm-compatible languages but can define custom logic and governance. Parachain maintainance can be an overhead. | | ||
| | **Data Availability** | Requires posting minimal data proofs to L1. | Posts complete data on-chain during challenge periods, increasing cost. | Built-in data availability with validators ensuring distributed state storage and reconstruction in case of disputes. | |
There was a problem hiding this comment.
Data availability requirements posted by the optimistic and ZK rollups is precisely the same.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Major reorg to the comparisons section.