Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Edits comparisons #6487

Merged
merged 1 commit into from
Jan 10, 2025
Merged

Edits comparisons #6487

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions docs/learn/learn-comparisons.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -172,8 +172,8 @@ be found on [l2beat](https://l2beat.com/scaling/summary).
| **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 the 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). |
| **Interoperability** | Limited interoperability<sup>2</sup>, often restricted to compatible L1s. | Limited interoperability<sup>2</sup>, 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 support state transitions beyond EVM compatibility by interpreting other virtual machine (VM) logic within the EVM environment<sup>1</sup>. | Each parachain can define its unique state transition function (STF), which is compiled to Wasm and validated per Parachain Protocol rules. |
| **Interoperability** | Limited interoperability<sup>1</sup>, often restricted to compatible L1s. | Limited interoperability<sup>1</sup>, 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 support state transitions beyond EVM compatibility by interpreting other virtual machine (VM) logic within the EVM environment<sup>2</sup>. | Each parachain can define its unique state transition function (STF), which is 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 maintenance can be an overhead. |
| **Data Availability** | Data availability requirements posted by the optimistic and ZK rollups are the same. | Data availability requirements posted by the optimistic and ZK rollups are the same. | Built-in data availability with validators ensuring distributed state storage and reconstruction in case of disputes. |
| **Cost Efficiency** | High efficiency but expensive prover computation. | More cost-effective but susceptible to congestion during high usage. | Cost-effective as parachains are independently scalable and not tied to L1 gas fees. |
Expand All @@ -185,7 +185,10 @@ be found on [l2beat](https://l2beat.com/scaling/summary).
| **Shared Security** | Relies on the parent chain's security guarantees, leveraging zk-proofs. | Security shared with the L1 via fraud-proof mechanisms. | Security shared with the Relay Chain via Parachian Protocol. |
| **Sharding** | Only data sharding. Execution sharding does not apply to Ethereum ZK rollups. | Only data sharding. Execution sharding does not apply to Ethereum Optimistic rollups. | Data sharding and execution sharding enabled through the Parachain Protocol, leveraging multiple virtual cores and reserving coretime for rollup operations. |

<sup>1</sup>Optimistic rollups rely on Ethereum's EVM (Ethereum Virtual Machine) for their
<sup>1</sup>There are efforts to allow native interoperability within rollup hubs, e.g., there will
be "better" interoperability within the OP Stack ecosystem than independent L2s.

<sup>2</sup>Optimistic rollups rely on Ethereum's EVM (Ethereum Virtual Machine) for their
fraud-proof mechanisms and dispute resolution. However, rather than natively executing L2 opcodes,
the EVM interprets the logic of the rollup's virtual machine.

Expand All @@ -205,9 +208,6 @@ enabling optimistic rollups to support diverse computational frameworks. This fl
their potential beyond traditional EVM-based boundaries, contrasting with the perception that they
are strictly tied to Ethereum’s computational model.

<sup>2</sup>There are efforts to allow native interoperability within rollup hubs, e.g., rollups
There will be "better" interoperability within the OP Stack ecosystem than independent L2s.

<sup>3</sup>An escape hatch is a method by which users of a rollup can recover digital assets or
program state from a rollup when the operators (sequencers) are offline.

Expand Down
Loading