diff --git a/docs/learn/learn-comparison-ethereum-2.md b/docs/learn/learn-comparison-ethereum.md similarity index 98% rename from docs/learn/learn-comparison-ethereum-2.md rename to docs/learn/learn-comparison-ethereum.md index b0ca94178ff6..6a24c170e4b7 100644 --- a/docs/learn/learn-comparison-ethereum-2.md +++ b/docs/learn/learn-comparison-ethereum.md @@ -1,10 +1,10 @@ --- -id: learn-comparisons-ethereum-2 +id: learn-comparisons-ethereum title: Polkadot vs. Ethereum sidebar_label: Ethereum description: Comparison between Polkadot and Ethereum. keywords: [ethereum, Ethereum, proof of stake, sharding] -slug: ../learn-comparisons-ethereum-2 +slug: ../learn-comparisons-ethereum --- Both protocols are blockchains at their core but serve fundamentally different roles in how they are @@ -32,8 +32,8 @@ Both protocols have fundamentally different goals: - Ethereum is a general-purpose blockchain based on the Ethereum Virtual Machine (EVM). Ethereum is not specialized nor optimized for any particular application. Instead, its primary focus is the Ethereum Virtual Machine for executing smart contracts. Ethereum achieves scalability via - [**rollups**](./learn-comparisons-rollups) are secondary protocols that utilize Ethereum as a - settlement layer. + [**rollups**](./learn-comparisons#rollup-comparison) are secondary protocols that utilize Ethereum + as a settlement layer. - Polkadot is a multi-chain protocol that provides shared security and secure interoperability for each of its **parachains**. Each parachain (also called an "appchain" in this context) is @@ -82,7 +82,7 @@ validation to occur on the protocol level without needing a layer two solution. :::info Rollup vs. Parachain Comparison For a more in-depth comparison of parachains versus rollups, take a look at the -[rollup comparison page](./learn-comparison-rollups.md) +[rollup comparison page](./learn-comparisons.md#rollup-comparison). ::: diff --git a/docs/learn/learn-comparison-rollups.md b/docs/learn/learn-comparison-rollups.md deleted file mode 100644 index c72912a0af38..000000000000 --- a/docs/learn/learn-comparison-rollups.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -id: learn-comparisons-rollups -title: Layer Two and Rollups -sidebar_label: Layer Two and Rollups -description: Comparison between various Rollup and L2 Protocols. -keywords: [rollups, polkadot, scalability, shared, security, parachain, ethereum] -slug: ../learn-comparisons-rollups ---- - -:::note - -This comparison covers general information regarding two widely used rollup mechanisms that are used -to scale (usually EVM-based) blockchains and compares and contrasts how Polkadot achieves -scalability. - -::: - -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 -fees, and solves other platform-specific issues. In many cases, L2 solutions focus on utilizing -block space on a particular blockchain efficiently and cost-effectively. - -**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 -single rollup. - -Polkadot implements this functionality at the native level (i.e. without using L2 scaling -solutions), allowing for shared security and scalability of the relay chain and respective -parachains. Shared security is a concept that has similar goals to EVM-based optimistic and -zero-knowledge rollups. Still, instead of being implemented as a secondary layer, Polkadot -guarantees native security and scalability for each of its parachains 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. - -## Optimistic Rollups - -Optimistic rollups are an interactive scaling method for L1 blockchains. They assume -_optimistically_ that every proposed transaction is valid by default. - -In the case of mitigating potentially invalid transactions, optimistic rollups introduce a -_challenge period_ during which participants may challenge a suspect rollup. A fraud-proving scheme -is in place to allow for several _fraud proofs_ to be submitted. Those proofs could make the rollup -valid or invalid. During the challenge period, state changes may be disputed, resolved, or included -if no challenge is presented (and the required proofs are in place). - -While optimistic rollups provide scalability, they have both benefits and drawbacks to their -approach: - -**Benefits:** - -- They are not limited by the type of state change - any state change can be included, meaning - existing apps do not have to account for it. -- They can be parallelized for scalability. -- A substantial amount of data can fit within a single rollup - ([in the case of Ethereum, for example](https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/#scaling-ethereum-with-optimistic-rollups), - tens of thousands of transactions in a single state transition). - -**Drawbacks:** - -- Transaction censorship and centralization are of concern, where sequencers/L2 nodes can be - compromised. -- Challenge periods could take a substantial amount of time to pass, increasing time for the rollup - to finalize onto the L1 network. -- Due to their generalist nature of including any state change for their parent network, optimistic - rollups can run into gas limitations or cause network congestion in the case of Ethereum. - -Optimistic rollups are often used in the Ethereum ecosystem. Examples of optimistic EVM-based rollup -solutions include: - -- [Optimism](https://www.optimism.io/) -- [Arbitrum](https://bridge.arbitrum.io/) -- [Unipig](https://unipig.exchange/welcome) - -## Zero-knowledge Rollups - -Zero-knowledge rollups (often called ZK rollups) are a non-interactive method that utilizes -zero-knowledge proofs to compute the validity of a particular set of state changes. Whereas -optimistic rollups relied on fraud proofs, ZK rollups rely on cryptographic validation in the form -of ZK proofs. - -Zero-knowledge rollups are significantly faster in finalization, as the cryptographic validity proof -handles the nuance of ensuring a rollup is valid. However, the ZK rollups often suffer from -performance due to their complexity and difficult implementation into resource-constrained -environments. Because Turing completeness is also challenging to achieve due to this computational -overhead, their ability to be generalized (in terms of blockspace) is reduced. However, they have a -promising future in solving some of the problems of optimistic rollups and addressing secure -scalability. - -**Benefits:** - -- They only require a small amount of data availability. Often, the proof is enough to ensure - validity. -- They can be proven trustlessly. -- Because the proof is immediately available, finality is also instantaneous. -- They have a promising future overall, as they have not reached maturity yet. - -**Drawbacks:** - -- They suffer from the same problems that other L2 solutions have regarding the centralization of L2 - operators. -- They are computationally expensive, and ZK circuits are difficult to implement. -- The potential for congestion is still a factor, as the amount of data could still be problematic. - -## Polkadot - Native Shared Security - -Whereas rollups are considered solutions for L2 protocols, Polkadot include this functionality -natively through its [Parachains Protocol](./learn-parachains-protocol.md). The Parachains Protocol, -which is how Polkadot handles network's **sharding** is meant to accomplish the combined goals of -providing security, scalability, and availability. - -It enables parachains to verify their collective state and communicate with one another. Parachains -have similarities to aspects of optimistic and ZK rollups, which are reflected in how Polkadot -handles the validity and availability of the parachain state. [Collators](./learn-collator.md), a -key part of Polkadot architecture, are in principle similar to sequencers, as collators pass data -with a proof-of-validity (PoV) function for liveness and communication with the relay chain. - -Each shard, or parachain, is equipped with a unique state transition function (STF). This function -ensures that communication to the relay chain remains valid. Each STF, called runtime, is written in -[Wasm](https://wiki.polkadot.network/docs/learn-wasm). Any state transition function is valid if it -compiles to Wasm and abides by the Parachains Protocol. - -Each STF runs a validity proof. The proof ([the Approval Protocol](./learn-parachains-protocol.md)) -is interactive, unlike ZK rollups, which are non-interactive. Additionally, unlike ZK rollups, there -are no difficulties in creating parachains with Turing-complete logic. Each parachain is also a -full-fledged state machine (usually in the form of a blockchain). Similarly to optimistic rollups, -the Parachain Protocol also has cases where disputes and resolutions of potentially harmful para -blocks (blocks representing the parachain) can take place, in which case the validators that vouched -for that parablock are [slashed](./learn-offenses.md) if it is found to be bad. - -**Benefits:** - -- Protocol level sharding, shared security, and interoperability. -- Each shard has a low barrier of entry in terms of development, as anything that compiles to Wasm - is a valid target. -- Fast Finality (usually under a minute on Polkadot). -- Data availability is built-in through validators and mechanisms like - [erasure coding](./learn-parachains-protocol.md#erasure-codes). -- No L2 implies less of a risk of incurring centralization issues for sequencers or other L2 - operators. - -**Drawbacks:** - -- Execution of code in Wasm could be a performance bottleneck, as it is slower than making native - calls. -- The relay chain sets a - [hard limit](https://paritytech.github.io/polkadot/book/protocol-overview.html?highlight=10#protocol-overview) - on the size and weights of the PoV (Proof of Validity) blocks which contain the parachain state - transition data. - -Despite these drawbacks, Polkadot remains upgradable through forkless upgrades, which allows the -protocol to be easily upgradable to stay in line with future technological advances. diff --git a/docs/learn/learn-comparisons-kusama.md b/docs/learn/learn-comparisons-kusama.md index f2285d0c3647..b43cd7f8776c 100644 --- a/docs/learn/learn-comparisons-kusama.md +++ b/docs/learn/learn-comparisons-kusama.md @@ -77,14 +77,6 @@ perform under those upgrades. Ultimately, Kusama and Polkadot will live on as independent, standalone networks with their own communities, their own governance, and their own complementary use cases, though they will continue -to maintain a close relationship, with many teams likely deploying applications to both networks. In -the future, we’re also likely to see Kusama bridged to Polkadot for cross-network interoperability. +to maintain a close relationship, with many teams likely deploying applications to both networks. Web3 Foundation remains committed to both networks going forward, providing crucial support and guidance to teams building for the ecosystem. - -## Explore more - -- [About Kusama](https://kusama.network) -- [The Kusama Wiki](https://guide.kusama.network) -- [Kusama on Polkadot-JS Apps](https://kusama.dotapps.io) -- [Polkadot and Kusama: What's the difference?](https://support.polkadot.network/support/solutions/articles/65000182146-kusama-and-polkadot-what-s-the-difference-) diff --git a/docs/learn/learn-comparisons.md b/docs/learn/learn-comparisons.md index 0c6740ade007..60be89524c0e 100644 --- a/docs/learn/learn-comparisons.md +++ b/docs/learn/learn-comparisons.md @@ -1,63 +1,212 @@ --- id: learn-comparisons title: Polkadot Comparisons -sidebar_label: Other Comparisons -description: Comparison between Polkadot and ETH 1.0 and BSC. -keywords: [comparisons, polkadot, blockchain] +sidebar_label: Comparisons +description: Comparison between Polkadot and other Networks. +keywords: + [ + comparisons, + Polkadot, + blockchain, + rollups, + polkadot, + scalability, + shared, + security, + parachain, + ethereum, + ] slug: ../learn-comparisons --- -Polkadot is a blockchain protocol that is innovating in the web3 space. +import DocCardList from '@theme/DocCardList'; -:::info In-depth Comparisons for multi-chain ecosystems +## Rollup Comparison -See the in-depth comparisons for [Ethereum 2.0](./learn-comparison-ethereum-2.md), -[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 +single rollup. + +:::info Layer Two Definition + +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 +fees, and solves other platform-specific issues. In many cases, L2 solutions focus on utilizing L1 +blockspace efficiently and cost-effectively. ::: -## Ethereum 1.x - -[Ethereum](https://ethereum.org) is a smart contract blockchain that allows for general computation -to be deployed on-chain and operated across the p2p network. Ethereum 1.x refers to the current -Ethereum release and the immediately planned future upgrades. - -The difference between Ethereum 1.x and Polkadot is quite large. Ethereum is a single chain that -allows developers to extend its functionality through the deployment of blobs of code onto the chain -(called smart contracts). Polkadot, as described in the whitepaper, is a fully extensible and -scalable blockchain network that provides security and interoperability through shared state. - -In practical terms, this means that the layer of abstraction between these two projects is -remarkably different for developers. In Ethereum, developers write smart contracts that all execute -on a single virtual machine, called the Ethereum Virtual Machine (EVM). In Polkadot, however, -developers write their logic into individual blockchains, where the interface is part of the state -transition function of the blockchain itself. Polkadot will also support smart contract blockchains -for Wasm and EVM to provide compatibility with existing contracts, but will not have smart contract -functionality on its core chain, the relay chain. - -As such, Polkadot is a possible augmentation and scaling method for Ethereum 1.x, rather than -competition. - -## Binance Smart Chain - -[Binance Chain](https://www.binance.com) is a Proof of Stake Authority (PoSA) blockchain used to -exchange digital assets on Binance DEX. Binance Smart Chain is an EVM-compatible smart contract -chain bridged to Binance Chain. Together, they form the Binance Dual Chain System. Binance Smart -Chain is also a Proof of Stake Authority chain and allows users to create smart contracts and dapps. - -Both chains are built with Cosmos SDK and therefore are a part of the -[Cosmos](learn-comparisons-cosmos.md) ecosystem. Due to specifics of the Cosmos architecture, -interoperability of Binance Smart Chain is based on bridges. This means all validators of both -chains are also bridge operators, therefore the security of the system relies on trusting -validators. At the moment, there are 21 Binance Smart Chain validator nodes. - -Polkadot has an entirely different purpose, as it was built to connect and secure unique -blockchains. It is a protocol on which single blockchains (such as Binance Smart Chain) could be -built and benefit from shared security, interoperability and scalability. Interoperability within -Polkadot is based on pooled security on Polkadot, and the security of the entire Polkadot network, -and has much stronger economic security. - -Scalability based on bridges relies on each bridged chain finding its own set of validators, -therefore duplicate resources are required. Scalability on Polkadot is based on the security of the -relay chain, and as the number of validators in the active set on Polkadot are increased, more -parachains can be supported. +In this section we explore the main differences in rollup technology between: + +- Zero-knowledge rollups, +- Optimistic rollups, and +- Polkadot rollups (i.e. parachains). + +Before diving into the differences between these rollup technologies, it is important to understand +the difference between non-interactive and interactive methods. + +### Non-interactive vs. Interactive Rollup Methods + +In the context of rollups, **interactive** and **non-interactive** methods refer to how the validity +of transactions or state changes is established between the rollup layer and the main blockchain +(L1). + +A non-interactive method relies on cryptographic proofs to validate transactions or state changes +without requiring dispute resolution or interactive challenges. A prominent example is +zero-knowledge proving mechanisms that operate off-chain, such as a zk-SNARK or zk-STARK. These +protocols prove that the transactions in a batch satisfy the rules of the protocol. These proofs are +submitted to the L1 chain and verified without needing further interaction. + +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 +that a transaction is invalid. This can require multiple steps, with both the challenger and +defender submitting data to the L1 chain. + +Here below, the key differences between interactive and non-interactive methods. + +| **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. | +| **Security Basis** | Crypto-economic incentives and monitoring by participants ensure validity. | Cryptographic proofs ensure correctness of all transactions upfront. | +| **Complexity** | Simpler to implement but requires monitoring. | Computationally intensive and harder to build. | +| **Use Cases** | Broad compatibility with existing applications. | Best for high-security applications where instant finality is critical. | + +Both approaches serve different needs and trade-offs, depending on the balance between scalability, +security, latency, and flexibility required. + +### Zero-knowledge Rollups + +Zero-knowledge rollups (often called ZK rollups) are a _non-interactive_ method that utilizes +zero-knowledge proofs to compute the validity of a particular set of state changes. Whereas +[optimistic rollups](#optimistic-rollups) rely on fraud proofs, ZK rollups rely on cryptographic +validation in the form of ZK proofs. + +Zero-knowledge rollups are significantly faster in finalization, as the cryptographic validity proof +handles the nuance of ensuring a rollup is valid. However, the ZK rollups often suffer from a +performance perspective due to the complexity involved in proof generation and difficult +implementation into resource-constrained environments. Because Turing completeness is also +challenging to achieve due to this computational overhead, their ability to be generalized (in terms +of blockspace) is reduced. However, the generation of zk proofs is becoming useful in niche +applications. For example, [Hyperbridge](./learn-bridges.md#bridge-comparison) is a ZK rollup on +Polkadot that serves as a scalable trustless bridge producing a single zk proof for multiple +blockchains that can be instantly verified on Polkadot. + +### Optimistic Rollups + +Optimistic rollups are an interactive scaling method for L1 blockchains. They assume +_optimistically_ that every proposed transaction is valid by default. + +In the case of mitigating potentially invalid transactions, optimistic rollups introduce a +_challenge period_ during which participants may challenge a suspect rollup. A fraud-proving scheme +can be in place to allow for several _fraud proofs_ to be submitted. Those proofs could make the +rollup valid or invalid. During the challenge period, state changes may be disputed, resolved, or +included if no challenge is presented (and the required proofs are in place). + +Optimistic rollups are often used in the Ethereum ecosystem. [Optimism](https://www.optimism.io/) +and [Arbitrium](https://bridge.arbitrum.io/) are an example of optimistic EVM-based rollups. + +### Polkadot Rollups + +Polkadot Rollups work similarly to optimistic rollups. They are an interactive method with fraud +proof mechanism. Very much like optimistic rollups and zk rollups are secured by Ethereum, Polkadot +rollups are secured by the Polkadot Relay Chain. The checking and fraud proof mechanics are +implemented on Polkadot, natively. [collators](./learn-collator.md), are in principle similar to +sequencers, as they pass data with a proof-of-validity (PoV) function for liveness and communication +with the Relay Chain. + +Additionally, Polkadot operates as a _stateless client_ of its rollups, meaning the Relay Chain does +not maintain the full state of each parachain. Instead, it verifies state transitions using PoV +blocks submitted by collators. This is analogous to _block witnesses_ in the Ethereum ecosystem, +which prove transaction validity without requiring full state storage. This design ensures +scalability by delegating state maintenance to rollups while enabling secure validation through +cryptographic proofs. + +Polkadot rollups have the following main differences compared to optimistic rollups: + +- Polkadot rollups can be fully-fledged state machine (usually in the form of a blockchain) with own + logic, governance mechanism, etc. +- Polkadot implements rollup functionality at the native level (i.e. without using L2 scaling + 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 + function ensures that communication to the relay chain remains valid. Each STF, called runtime, is + compiled to [Wasm](https://wiki.polkadot.network/docs/learn-wasm). Any STF is valid if it compiles + to Wasm and abides by the Parachains Protocol. +- If optimistc rollups are based on the assumption that all transactions a valid, **Polkadot rollups + are "cynical" and always check the validity of transactions using a subset of the validators**. In + case of disputes, an escalation effect involving more validators is triggered and dispute + resolution will end with the malicious actor being [slashed](./learn-offenses.md). +- Polkadot has multiple virtual cores that are made possible thanks to the Parachain Protocol + allowing execution sharding. Rollups access Polkadot by reserving time on those cores via + [coretime](./learn-agile-coretime.md). + +A more detailed comparison of Polkadot rollups with optimistic and zk rollups can be found in the +comparison table below. + +### Rollup Comparison Table + +Here below there is a comparison table summarizing the main differences between Polkadot, ZK, and +Optimistic rollups. An in-depth comparison between different optimistic and ZK rollups can be found +on [l2beat](https://l2beat.com/scaling/summary). + +| **Feature** | **ZK Rollups** | **Optimistic Rollups** | **Polkadot Parachains/Rollups** | +| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **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. | +| **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 environment1. | 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. | +| **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. | +| **Governance Upgrades** | Subject to parent chain governance. | Governed by parent L1 network governance. | Forkless upgrades supported through Polkadot’s native governance mechanisms. | +| **Fraud/Validity Proofs** | Non-interactive validity proofs, ensuring correctness off-chain. | Fraud proofs requiring active challenges during the dispute window. | Continuous validity checks by validators with escalation effects for disputes, ending in slashing malicious actors. | +| **Applications** | Ideal for high-security use cases like financial transactions and privacy-preserving applications. | Suitable for general-purpose dApps with moderate security needs. | Fully-fledged state machines capable of defining governance, logic, and custom runtime environments, ideal for diverse blockchain apps. | +| **Escape Hatch**2 | No built-in escape hatch; relies on zk circuits functioning correctly. | Can include an escape hatch to withdraw funds if sequencers fail. | No native escape mechanism; funds could be trapped if parachain collators fail. | +| **Permissioning** | Typically relies on permissioned sequencers. | Sequencers can be permissioned or partially permissionless. | Parachains support both permissioned and permissionless collator sets, providing flexibility for private or public use cases. | +| **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 is not applicable to Ethereum ZK rollups. | Only data sharding. Execution sharding is not applicable 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 +operations and fraud-proof mechanisms. This means they can only execute EVM-compatible state +transitions, as any disputed transaction must be validated on Ethereum L1 by re-executing it within +the EVM. While this ensures seamless integration with Ethereum and supports its ecosystem of +applications, it limits optimistic rollups to EVM-based logic, restricting their ability to support +diverse computational frameworks like WASM or custom environments. This dependency defines their +functionality and places a boundary on their flexibility compared to other blockchain systems like +Polkadot. + +2An escape hatch is method by which users of a rollup can recover digital assets or +program state from a rollup when the operators (sequencers) are offline. + +## Interoperability Comparison + +In this section we explore the main differences in interoperability between Polkadot, +[Optimism Superchain Ecosystem](https://docs.optimism.io/stack/explainer) and +[Chainlink CCIP (Cross-chain Interoperability Protocol)](https://chain.link/cross-chain). + +| Feature | Polkadot XCM | Optimism Superchain Interoperability | Chainlink CCIP | +| --------------------------- | -------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | +| **Architecture** | Direct communication between parachains within the Polkadot ecosystem using a unified relay chain. | Cross-rollup interoperability built on Ethereum, extending rollups’ compatibility. | Universal standard enabling cross-chain communication for any blockchain network. | +| **Scope** | Limited to parachains and relay chains in the Polkadot/Kusama ecosystem. | Focused on rollups in Ethereum Layer 2 (e.g., Optimism, Base). | Blockchain-agnostic, supporting public and private chains. | +| **Consensus Dependency** | Relies on Polkadot's shared relay chain consensus. | Depends on Ethereum Layer 1 for security and sequencer trust within Superchain rollups. | Independent of any specific chain’s consensus, uses oracle network for secure messaging. | +| **Interoperability Model** | Messages are trustlessly passed between parachains using XCMP and HRMP channels. | Rollups communicate through the Superchain’s sequencer infrastructure. | Relies on Chainlink decentralized oracles to transmit data securely across chains. | +| **Scalability** | High scalability within the ecosystem; limited by relay chain capacity. | Limited by Ethereum throughput and Superchain architecture. | Scalable; offloads cross-chain messaging to oracle networks. | +| **Security Model** | Secured by Polkadot's relay validators and stake. | Secured by Ethereum’s base layer and rollup-specific fraud or validity proofs. | Security ensured by Chainlink oracles and cryptographic proofs. | +| **Ease of Integration** | Requires Substrate-based parachains and compliance with Polkadot protocols. | Requires rollups to align with Optimism’s OP stack architecture. | Blockchain-agnostic, integrates with any chain using CCIP libraries. | +| **Interoperability Speed** | Near-instant, as Polkadot’s shared relay chain validates interactions. | Relatively slower due to dependency on Layer 1 Ethereum finality and rollup delays. | Fast, as it relies on Chainlink oracle nodes for data transmission. | +| **Use Cases** | Native token transfers, contract execution, shared staking pools. | Bridging assets and state between rollups. | Cross-chain DeFi, gaming, enterprise blockchain communication. | +| **Prone to Centralization** | Low; Polkadot's design enforces decentralization. | Medium; rollup sequencers could centralize without proper safeguards. | Medium; depends on the decentralization level of Chainlink's oracle network. | +| **Current Deployment** | Actively deployed in Polkadot and Kusama ecosystems. | Early stage; foundational elements are live, expanding with OP stack rollups. | Widely adopted across multiple chains in both testnet and mainnet. | +| **Key Strengths** | Seamless, low-latency native communication within the ecosystem. | Interoperability focused on Ethereum scalability and Layer 2 adoption. | Universal, chain-agnostic standard with flexible use cases. | +| **Limitations** | Limited to Polkadot-compatible parachains. | Restricted to Ethereum and rollups using OP stack. | Depends on oracle network security and adoption rate. | + +## Other Comparisons + + diff --git a/polkadot-wiki/docusaurus.config.js b/polkadot-wiki/docusaurus.config.js index 44bebe7a4aa5..9db9a51ee8f6 100644 --- a/polkadot-wiki/docusaurus.config.js +++ b/polkadot-wiki/docusaurus.config.js @@ -220,6 +220,14 @@ module.exports = { to: '/docs/learn-system-chains', from: ['/docs/learn-bridge-hub'] }, + { + to: '/docs/learn-comparisons', + from: ['/docs/learn-comparison-rollup'] + }, + { + to: '/docs/learn-comparisons-ethereum', + from: ['/docs/learn-comparisons-ethereum-2'] + }, ], createRedirects: function (existingPath) { if (existingPath.startsWith("/docs/")) { diff --git a/polkadot-wiki/sidebars.js b/polkadot-wiki/sidebars.js index 92b0a5a6b8c6..513287d36bb4 100644 --- a/polkadot-wiki/sidebars.js +++ b/polkadot-wiki/sidebars.js @@ -746,21 +746,17 @@ module.exports = { }, { type: "category", - label: "Polkadot Comparisons", + label: "Comparisons", description: "Comparison between Polkadot and other Networks. ", link: { - type: 'generated-index', - title: "Polkadot Comparisons", - description: "Comparison between Polkadot and other Networks. ", - slug: '/learn-comparisons-index', + type: 'doc', + id: "learn/learn-comparisons", }, items: [ 'learn/learn-comparisons-kusama', - 'learn/learn-comparisons-ethereum-2', + 'learn/learn-comparisons-ethereum', 'learn/learn-comparisons-cosmos', 'learn/learn-comparisons-avalanche', - 'learn/learn-comparisons', - 'learn/learn-comparisons-rollups' ], }, "learn/learn-video-tutorials",