Layer 2 (L2)

Rollups execute transactions off-chain and post compressed data (or proofs) back to the main chain. This is the dominant L2 scaling paradigm.

• Optimistic Rollups: Assume transactions are valid, using a fraud-proof challenge period (e.g., Arbitrum, Optimism).
• ZK-Rollups: Use zero-knowledge proofs (validity proofs) to cryptographically verify correctness instantly (e.g., zkSync, Starknet).

Essential infrastructure for moving assets and data between L1 and L2, or between different L2s. They come with distinct security models:

• Trustless Bridges: Rely on cryptographic proofs (e.g., light clients).
• Trusted Bridges: Rely on a multisig or federation of external validators. Bridge security is a critical risk vector, as seen in exploits like the Wormhole and Ronin bridge hacks.

An L2 architecture that assumes transactions are valid by default (optimistically) and only executes computation via a fraud proof if a challenge is raised. Transactions are batched and a cryptographic commitment (the state root) is posted to the L1.

• Key Mechanism: Uses a challenge period (typically 7 days) where anyone can dispute invalid state transitions.
• Examples: Arbitrum One, Optimism.
• Trade-off: Higher capital efficiency for users but delayed finality due to the challenge window.

An L2 architecture that bundles transactions and uses zero-knowledge proofs (specifically ZK-SNARKs or ZK-STARKs) to validate them off-chain. A single, succinct validity proof is submitted to the L1, guaranteeing correctness.

• Key Mechanism: Provides cryptographic security inherited from the L1 with no need for a challenge period.
• Examples: zkSync Era, Starknet, Polygon zkEVM.
• Trade-off: Offers near-instant finality but requires more complex, computationally intensive proof generation.

A scaling solution similar to ZK-Rollups where validity is proven with zero-knowledge proofs, but data is kept off-chain instead of being posted to the L1. This relies on a separate Data Availability Committee or cryptographic techniques for data integrity.

• Key Mechanism: Maximizes throughput and minimizes L1 fees by not publishing transaction data on-chain.
• Examples: Immutable X, Sorare.
• Trade-off: Higher scalability but introduces a data availability trust assumption outside the L1.

A payment channel L2 technique where participants lock funds in a smart contract on the L1, then conduct numerous fast, low-cost transactions off-chain by exchanging signed messages. The final net balance is settled on-chain.

• Key Mechanism: Enables instant finality and near-zero fees for participants within the channel.
• Examples: The Bitcoin Lightning Network, Ethereum's Connext for generalized state.
• Use Case: Ideal for high-frequency, bidirectional micropayments between known parties.

A framework for creating hierarchical sidechains (child chains) that periodically commit block hashes to the L1. It relies on fraud proofs and allows users to withdraw funds via a challenge process if the operator is malicious.

• Key Mechanism: Uses MapReduce-style data trees to minimize on-chain data. Security depends on users monitoring the chain.
• Historical Context: Pioneered scaling research but largely superseded by rollups due to data availability and mass exit challenges.
• Example: OMG Network (formerly OmiseGO).

Independent, EVM-compatible blockchains that run parallel to a mainnet (like Ethereum) and connect via a two-way bridge. They have their own consensus mechanism (e.g., Proof of Authority) and block parameters, offering full EVM compatibility.

• Key Mechanism: Operates as a separate network with independent security and finality, connected via bridges.
• Examples: Polygon PoS, Skale, Gnosis Chain.
• Trade-off: Higher throughput but does not inherit the L1's security directly; security is provided by the sidechain's own validator set.

The dominant L2 scaling approach that executes transactions off-chain and posts compressed data (or proofs) back to the L1. This bundles thousands of transactions into a single L1 batch.

• Optimistic Rollups: Assume transactions are valid and use a fraud-proof challenge period (e.g., 7 days) for disputes. Examples: Arbitrum, Optimism.
• ZK-Rollups: Use zero-knowledge proofs (ZKPs) to cryptographically validate all transactions before posting to L1, enabling near-instant finality. Examples: zkSync Era, Starknet, Polygon zkEVM.

A scaling solution where participants lock funds in a smart contract to conduct numerous off-chain transactions, only settling the final net result on the L1. This enables instant, high-volume, and private exchanges between known parties.

• Key Mechanism: Uses multisig contracts or similar constructs to manage the off-chain state.
• Use Cases: Micropayments, gaming, and high-frequency trading between two or more entities.
• Example: The Bitcoin Lightning Network is a payment channel network.

Independent, EVM-compatible blockchains that run parallel to a mainnet (L1) and connect via a two-way bridge. They have their own consensus mechanisms (e.g., PoA, PoS) and security models, offering high throughput but not inheriting the L1's full security.

• Trade-off: Sacrifices some decentralization/security for performance.
• Primary Use: Hosting high-throughput dApps and games.
• Examples: Polygon PoS, Skale, Gnosis Chain.

An earlier scaling framework that creates hierarchical trees of child chains anchored to the L1. It uses fraud proofs to ensure security but has limitations with data availability and mass exits.

• Core Concept: Moves computation and state storage entirely off-chain.
• Challenge: The data availability problem made generalized smart contracts complex.
• Legacy: Largely superseded by rollups but inspired key L2 concepts. OMG Network was a notable implementation.

A dominant L2 scaling approach that executes transactions off-chain and posts compressed data back to the main chain (Layer 1). This ensures security is inherited from the L1. There are two primary types:

• Optimistic Rollups: Assume transactions are valid and only run computation (via a fraud proof) if challenged. They have a longer withdrawal delay.
• ZK-Rollups: Use zero-knowledge proofs (validity proofs) to cryptographically verify the correctness of all transactions before posting to L1, enabling faster finality. Examples include Arbitrum, Optimism, zkSync, and Starknet.

A scaling technique where participants lock funds in a smart contract and conduct numerous fast, low-cost transactions off-chain. Only the final state (the net result of all interactions) is settled on the main chain. This is ideal for high-frequency, bidirectional interactions like micropayments or games.

• Key Mechanism: Uses multi-signature contracts or similar constructs.
• Example: The Lightning Network for Bitcoin.
• Trade-off: Requires participants to be online to monitor for fraud and is best suited for defined groups of users.

Independent blockchains that run parallel to a main chain (L1) and are connected via a bridge. They have their own consensus mechanisms (e.g., Proof of Authority) and security models, which are separate from the L1.

• Characteristics: Can offer high throughput and low fees but do not inherit the L1's security.
• Use Case: Often used for specific applications or experiments.
• Examples: Polygon PoS (though it has evolved), Skale, and Gnosis Chain (formerly xDai).

An earlier L2 framework for scaling that creates hierarchical trees of child chains anchored to the Ethereum main chain. It uses fraud proofs to ensure security but has significant limitations:

• Data Availability Problem: Requires users to monitor the chain and challenge exits, which is complex for general use.
• Mass Exit Issue: A problem on the root chain if the operator acts maliciously. While largely superseded by rollups for general-purpose scaling, Plasma concepts inspired later designs and see niche use for specific asset types.

A hybrid scaling solution that uses ZK-proofs like a ZK-Rollup but stores data off-chain with a committee or proof-of-stake system, rather than on the L1. This offers higher throughput but introduces a data availability risk.

• Trade-off: If the data custodians withhold data, users may be unable to prove ownership of their assets.
• Use Case: Ideal for applications prioritizing extreme throughput for non-financial data or where users trust the data availability committee.
• Example: StarkEx in Validium mode (used by dYdX, Immutable X).

Critical infrastructure that connects Layer 2 solutions to their Layer 1 and to other L2s or blockchains. They enable asset and data transfer across isolated systems.

• Types: Include trusted (custodial) bridges, which rely on a federation, and trustless bridges, which use cryptographic proofs.
• Security Consideration: Bridges are a major attack vector; their security model is distinct from the L1 or L2 they connect.
• Example Protocols: Across, Hop, Polygon Bridge, and native rollup bridges like the Arbitrum Bridge.