Skip to content

Commit

Permalink
edits comparisons
Browse files Browse the repository at this point in the history
  • Loading branch information
@filippoweb3
filippoweb3 committed Jan 10, 2025
1 parent f6840ec commit 2386c92
Showing 1 changed file with 6 additions and 6 deletions.
12 changes: 6 additions & 6 deletions docs/learn/learn-comparisons.md
View file
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

0 comments on commit 2386c92

Please sign in to comment.