Skip to content

Commit

Permalink
minor edits and link addition
Browse files Browse the repository at this point in the history
  • Loading branch information
@filippoweb3
filippoweb3 committed Dec 9, 2024
1 parent 380017c commit 835602d
Showing 1 changed file with 21 additions and 20 deletions.
41 changes: 21 additions & 20 deletions docs/learn/learn-comparisons.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -143,29 +143,30 @@ for that parablock are [slashed](./learn-offenses.md) if it is found to be bad.

### Rollup Comparison Table

| **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 the relay chain's consensus mechanism. |
| **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. | Shared security is native, leveraging Polkadot's validator set and erasure coding for data availability. Strong Byzantine fault tolerance. No optimistic assumption, rollup data are checked all the time. Secondary checks and an escalation process give strong security guarantees and minimize chance of malicious block finalization. |
| **Scalability** | High, but limited by computational expense and challenges in building generalized ZK circuits. | High, with better parallelization, but constrained by gas limitations in parent chains like Ethereum. | Inherently scalable through native sharding and parachains operating in parallel. Pipelining and scheduling increase throughput and scalability for the single rollup. |
| **Decentralization** | Risk of centralization in sequencer roles and ZK proof computation. | Sequencer centralization concerns, as validators are known and fewer in number. | Collator set decentralization is critical; fully centralized collators reduce the benefits, making parachains similar to other rollup technologies. |
| **Interoperability** | Limited to networks with compatible smart contract support. | Limited interoperability, often confined to the parent blockchain ecosystem. | Native interoperability through XCM and XCMP protocols, allowing seamless communication between parachains. |
| **Development Complexity** | Difficult to implement and optimize due to the complexity of ZK proof systems. | Simpler to implement but requires careful fraud-proof logic. | Moderate; any runtime compiled to Wasm is valid, simplifying parachain development. |
| **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. |
| **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 (e.g., Ethereum). | Governed by the parent chain. | Protocol upgrades through forkless changes, enhancing adaptability. |
| **Fraud/Validity Proofs** | Non-interactive validity proofs. | Fraud proofs requiring active challenges during the dispute window. | Interactive approval protocols to resolve parachain block disputes. |
| **Applications** | Ideal for high-security use cases like financial transactions and identity. | Best for general-purpose decentralized apps with moderate security requirements. | Supports diverse applications, including DeFi, gaming, and governance, thanks to Turing-complete parachains. |
| **Escape Hatch** | No native escape hatch—requires zk circuits to correctly release funds. | Can include an escape hatch to withdraw funds during sequencer failure or network issues. | Funds can become trapped if parachain collator or communication fails; no native escape mechanism exists at the protocol level. |
| **Permissioning** | Sequencers are usually permissioned but can become permissionless with careful setup. | Sequencers are usually permissioned but can include mechanisms for broader validator inclusion. | Parachains can have permissioned or permissionless collator sets, providing flexibility in design. |

An 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.
| **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 the relay chain's consensus mechanism. |
| **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. | Shared security is native, leveraging Polkadot's validator set and erasure coding for data availability. Strong Byzantine fault tolerance. No optimistic assumption, rollup data are checked all the time. Secondary checks and an escalation process give strong security guarantees and minimize chance of malicious block finalization. |
| **Scalability** | Limited by computational expense and challenges in building generalized ZK circuits. | Constrained by gas limitations in parent chains like Ethereum. | Inherently scalable through native 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. |
| **Decentralization** | Risk of centralization in sequencer roles and ZK proof computation. | Sequencer centralization concerns, as validators are known and fewer in number. | Collator set decentralization is critical; fully centralized collators reduce the benefits, making parachains similar to other rollup technologies. |
| **Interoperability** | Limited to networks with compatible smart contract support. | 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. |
| **Development Complexity** | Difficult to implement and optimize due to the complexity of ZK proof systems. | Simpler to implement but requires careful fraud-proof logic. | Moderate; any runtime compiled to Wasm is valid, simplifying parachain development. |
| **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 (e.g., Ethereum). | Subject to parent chain governance | Protocol upgrades through forkless changes, enhancing adaptability. Each parachain can be a fully fledged blockchain with own governance. |
| **Fraud/Validity Proofs** | Non-interactive validity proofs. | Fraud proofs requiring interactive method during the dispute window. | Interactive approval protocols to resolve parachain block disputes. |
| **Applications** | Ideal for high-security use cases like financial transactions and identity. | Best for general-purpose decentralized apps with moderate security requirements. | Flexible. Supports diverse applications, including DeFi, gaming, and governance, thanks to Turing-complete parachains. |
| **Escape Hatch**<sup>1</sup> | No native escape hatch—requires zk circuits to correctly release funds. | Can include an escape hatch to withdraw funds during sequencer failure or network issues. | Funds can become trapped if parachain collator or communication fails; no native escape mechanism exists at the protocol level. |
| **Permissioning** | Sequencers are usually permissioned but can become permissionless with careful setup. | Sequencers are usually permissioned but can include mechanisms for broader validator inclusion. | Parachains can have permissioned or permissionless collator sets, providing flexibility in design. |

<sup>1</sup>An 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.<br/><br/>

## Interoperability Comparison

In this section we explore the main differences in interoperability between Polkadot, Optimism
Superchain Ecosystem and Chainlink CCIP.
In this section we explore the main differences in interoperability between Polkadot,
[Optimism Superchain Ecosystem](https://docs.optimism.io/stack/explainer) and
[Chainlink CCIP](https://chain.link/cross-chain).

| Feature | Polkadot XCM | Optimism Superchain Interoperability | Chainlink CCIP |
| --------------------------- | -------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
Expand Down

0 comments on commit 835602d

Please sign in to comment.