From 7645354dc99b31231ab56f140077ff1a693dd9b0 Mon Sep 17 00:00:00 2001 From: Filippo <110459737+filippoweb3@users.noreply.github.com> Date: Fri, 10 Jan 2025 10:49:38 +0100 Subject: [PATCH] edits comparisons (#6487) --- docs/learn/learn-comparisons.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/learn/learn-comparisons.md b/docs/learn/learn-comparisons.md index 5ee24381f19..07ccae79f5c 100644 --- a/docs/learn/learn-comparisons.md +++ b/docs/learn/learn-comparisons.md @@ -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 interoperability2, often restricted to compatible L1s. | Limited interoperability2, 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 environment1. | Each parachain can define its unique state transition function (STF), which is compiled to Wasm and validated per Parachain Protocol rules. | +| **Interoperability** | Limited interoperability1, often restricted to compatible L1s. | Limited interoperability1, 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 environment2. | 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. | @@ -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. | -1Optimistic rollups rely on Ethereum's EVM (Ethereum Virtual Machine) for their +1There are efforts to allow native interoperability within rollup hubs, e.g., there will +be "better" interoperability within the OP Stack ecosystem than independent L2s. + +2Optimistic 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. @@ -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. -2There 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. - 3An 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.