From f6840eca6e103378807f76eccafad583c0a08c29 Mon Sep 17 00:00:00 2001 From: Filippo <110459737+filippoweb3@users.noreply.github.com> Date: Fri, 10 Jan 2025 10:34:33 +0100 Subject: [PATCH] Wiki reorg: Edit Comparisons (#6394) * edits - learn-comparisons as main page - updates sidebar - edit kusama * rm rollup page - move content to main comparison page - structure new page * added table * table edits, new content * interop comparison table * minor edits and link addition * minor addition * Update docs/learn/learn-comparisons.md Co-authored-by: bader y * Update docs/learn/learn-comparisons.md Co-authored-by: bader y * Update docs/learn/learn-comparisons.md Co-authored-by: bader y * Update docs/learn/learn-comparisons.md Co-authored-by: bader y * Update docs/learn/learn-comparisons.md Co-authored-by: bader y * edits * updates comparison * changed eth page name - redirect - sidebar updates * minor fix * edded info - sharding - l2beat * Added Seun's feedback * Marcin's feedback * Benjamin's feedback * minor edits --------- Co-authored-by: bader y --- ...reum-2.md => learn-comparison-ethereum.md} | 10 +- docs/learn/learn-comparison-rollups.md | 153 ---------- docs/learn/learn-comparisons-kusama.md | 10 +- docs/learn/learn-comparisons.md | 279 ++++++++++++++---- polkadot-wiki/docusaurus.config.js | 8 + polkadot-wiki/sidebars.js | 12 +- 6 files changed, 245 insertions(+), 227 deletions(-) rename docs/learn/{learn-comparison-ethereum-2.md => learn-comparison-ethereum.md} (98%) delete mode 100644 docs/learn/learn-comparison-rollups.md 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..5ee24381f193 100644 --- a/docs/learn/learn-comparisons.md +++ b/docs/learn/learn-comparisons.md @@ -1,63 +1,238 @@ --- 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**. In theory, separate entities could assume the role of +sequencing transactions and publishing them. In practice, they are the same machine, but this will +likely change as rollups decentralize more. This mechanism could include thousands of transactions +in a single rollup. + +:::info Layer Two Definition + +Layer two (L2) networks are a key approach to blockchain scalability, off-loading the majority of +computation from layer one (L1) networks. These solutions leverage the security of L1 to create an +additional layer that is faster, reduces fees, and addresses platform-specific challenges. L2 +solutions also focus on utilizing L1 blockspace efficiently and cost-effectively. + +By adopting modular designs and re-using functionality, L2 networks enable the deployment of +scalable rollups for various virtual machine environments, including Ethereum Virtual Machine (EVM), +Solana Virtual Machine (SVM) and [Move-based](https://move-language.github.io/move/) systems. These +rollups settle back to Ethereum, ensuring a robust and secure foundation for diverse blockchain +ecosystems. + +::: + +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 crucial to understand +the difference between non-interactive and interactive methods. + +### Fraud Proofs vs. Validity Proofs + +In the context of rollups, **interactive** and **non-interactive** methods are commonly used to +describe how the validity of transactions or state changes is established between the rollup layer +and the main blockchain (L1). These terms correspond closely to the mechanisms of **fraud proofs** +and **validity proofs**, which are the standard terminology. + +An **interactive method** (associated with fraud proofs) involves a back-and-forth process to +validate transactions. A "prover" submits transaction data or state changes to L1, assuming it is +valid. A challenge mechanism is triggered if a dispute arises, requiring participants to provide +evidence (fraud proofs) to demonstrate invalidity. This process ensures correctness but introduces +latency due to dispute resolution periods, which can vary depending on the implementation. For +example, optimistic rollups often have challenge periods of several hours or even up to seven days. + +A **non-interactive method** (associated with validity proofs) relies on cryptographic mechanisms, +such as SNARKs or STARKs, to validate transactions upfront. These proofs are generated off-chain and +submitted to L1 for verification without requiring dispute resolution. While these methods offer +near-instant finality, in theory, in practice delays are sometimes intentionally introduced as +safeguards. For instance, zkSync rollups may take up to a day to finalize transactions, not due to +technical limitations but as a precautionary measure while the technology matures and secures +high-value assets. + +Below is a comparison of the two mechanisms: + +| **Aspect** | **Fraud Proofs (Interactive)** | **Validity Proofs (Non-Interactive)** | +| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **Mechanism** | Challenge-based system where disputes are resolved interactively. | Cryptographic proofs validate all transactions upfront, eliminating disputes. | +| **Latency** | Time to finality depends on challenge periods. Optimistic rollups often take hours or even days to finalize. Polkadot rollups reduce this to around 30 minutes. | Near-instant finality in theory. In practice, systems like zkSync can take up to a day to finalize, often due to artificial safeguards rather than inherent technical limitations. | +| **Security Basis** | Crypto-economic incentives and participant monitoring ensure validity. | Cryptographic guarantees ensure correctness upfront, reducing the need for external monitoring. | +| **Complexity** | Simpler to implement but requires active monitoring and challenge resolution. | Computationally intensive and complex to build, especially for ZK systems. | +| **Use Cases** | Suitable for applications needing broad compatibility with existing systems and tolerating some latency for finality. | Ideal for high-security applications or scenarios where upfront validation and near-instant finality are critical. | + +Both approaches address different trade-offs between scalability, security, latency, and +implementation complexity. Future innovations may blur the lines between these mechanisms, enabling +hybrid approaches such as non-interactive dispute systems. + +### Zero-knowledge Rollups + +Zero-knowledge rollups (commonly referred to as ZK rollups) are a non-interactive method that +utilizes cryptographic proofs, often in the form of SNARKs, to compute the validity of a particular +set of state changes. While the industry has adopted the term "ZK rollups," it is worth noting that +many implementations do not strictly involve zero-knowledge properties, as the proofs do not +necessarily conceal information. These rollups are better described simply as SNARK-based rollups, +but the term "ZK rollups" remains widely used. + +In contrast to [optimistic rollups](#optimistic-rollups), which rely on fraud proofs and interactive +challenge mechanisms, ZK rollups rely entirely on cryptographic validation, with SNARKs providing +upfront proof of correctness. This approach allows ZK rollups to achieve significantly faster +finalization, as the validity proof ensures that all state transitions are correct without requiring +a challenge period. + +However, ZK rollups face performance challenges due to the computational complexity involved in +proof generation and the difficulty of implementing these proofs in resource-constrained +environments. This complexity also makes achieving Turing completeness more challenging, which can +limit their generalizability in terms of blockspace usage. Despite these challenges, ZK rollups are +becoming increasingly viable for specialized applications. For example, +[Hyperbridge](./learn-bridges.md#bridge-comparison) is a SNARK-based rollup on Polkadot that acts as +a scalable, trustless bridge. It produces a single proof for multiple blockchains, which can be +instantly verified on Polkadot, demonstrating the potential of these rollups in niche use cases. + +### 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. State changes may be disputed, resolved, or included during the challenge +period 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. 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 natively +implemented in Polkadot. [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 entire 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 proves 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 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 data coordination from + parachains into an aggregated, representative state, similar to L2 rollups. +- If optimistic rollups are based on the assumption that all transactions are 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, which + allows 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 types of 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 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. | +| **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. | +| **Governance Upgrades** | Subject to parent chain governance. | Governed by parent L1 network governance. | Forkless upgrades are 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 dispute escalation effects, 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**3 | 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 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 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 +fraud-proof mechanisms and dispute resolution. However, rather than natively executing L2 opcodes, +the EVM interprets the logic of the rollup's virtual machine. + +:::info Opcodes + +An opcode (short for operation code) is the fundamental instruction used by a virtual machine to +perform specific operations. In the context of the EVM, opcodes define low-level commands that +execute computations, manage storage, and interact with smart contracts. Rollups process their +opcodes, which the EVM interprets during dispute resolution and other operations. ::: -## 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. +While optimistic rollups often support EVM-compatible state transitions for seamless integration +with Ethereum and its ecosystem, they are not inherently restricted to EVM logic. Developers could +implement interpretation logic for other virtual machines, such as WASM or custom environments, +enabling optimistic rollups to support diverse computational frameworks. This flexibility expands +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. + +## 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, it uses an 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 (though Polkadot allows smart contract execution through XCM, it is almost impossible to use trustlessly in practice, as only straightforward calls can be passed without read access), and shared staking pools. | Bridging assets and state between rollups. | Cross-chain DeFi, gaming, enterprise blockchain communication. | +| **Prone to Centralization** | Low; while Polkadot's design enforces decentralization, it allows the decentralization of collators but does not mandate it, as there are chains with teams operating all collators. | Optimism does not currently give a choice; sequencers must be centralized. | 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. | It depends on the oracle network security and adoption rate. | + +## Other Comparisons + + diff --git a/polkadot-wiki/docusaurus.config.js b/polkadot-wiki/docusaurus.config.js index d409980933b1..a4b14dfb4f89 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 23d76ec00eb4..8bb985579c57 100644 --- a/polkadot-wiki/sidebars.js +++ b/polkadot-wiki/sidebars.js @@ -760,21 +760,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",