Sidechains vs. Rollups: Breaking down the differences for dapp development

In this post, you’ll learn the difference between sidechains and rollups.

Sidechains and rollups are two solutions to the problem of blockchain scalability. Both solutions revolve around moving computation from a resource-constrained blockchain (like Ethereum) to an independent blockchain optimized for scale. This approach introduces benefits, such as reducing cost per transaction, decreasing latency, and improving overall throughput. But that’s where the similarities end.

Sidechains and rollups are fundamentally different in their approach to scaling and have different design decisions and tradeoffs. For developers hoping to leverage either of these solutions to build scalable dapps, it is important to know how they are different.

This post provides an overview of rollups and sidechains while exploring differences in architecture, security guarantees, scaling properties, and more. We also provide recommendations on when to deploy your dapp on a rollup or sidechain (or both).

What is a sidechain?

A sidechain is a blockchain network operating in parallel with another blockchain (called a “main chain”). Typically, a sidechain connects with the main chain via a two-way bridge that permits transferring assets—and possibly arbitrary data like contract state, Merkle proofs, and results of specific transactions—between the two networks.

Most sidechains have their consensus mechanism and validator set, separate from the main chain. This allows sidechains to settle and finalize transactions without relying on another blockchain. However, it also means that the security of funds bridged to the sidechain depends on the existence of strong crypto-economic incentives to discourage malicious behavior among validators.

Types of sidechains

EVM-compatible vs non-EVM sidechains: EVM-compatible sidechains use a custom implementation of the Ethereum Virtual Machine, the execution environment for smart contracts deployed on Ethereum. In fact, most of these blockchains started as forks of go-ethereum also known as Geth, the most popular implementation of the Ethereum protocol.

Although retaining most qualities of Ethereum’s design—like support for smart contracts—EVM sidechains optimized other areas, especially consensus, to improve execution and throughput. Today, EVM-compatible sidechains run most smart contracts written in EVM languages like  Solidity, whilst decreasing costs and latencies in execution for decentralized application users.

Non-EVM sidechains implement a different virtual machine architecture and cannot run Ethereum-native dapps without extensive code refactoring. Developers building on non-EVM chains can’t use familiar EVM development environments and tooling (eg. Truffle, Remix, Hardhat) and may need to learn another language, such as Rust or Golang, to create dapps.

Note: Avalanche, Fantom, Celo, and Palm are examples of EVM-compatible sidechains. NEAR,  Solana, and Algorand are examples of non-EVM sidechains.

Commit chains and optimistic sidechains: Not every sidechain completely bootstraps its security; some, especially commit chains and optimistic chains, depend on the main chain for certain safety guarantees. A commit chain periodically submits cryptographic commitments to its latest state (eg., block headers) to another blockchain. The main chain cannot verify these state proofs—since it cannot access the sidechain’s state—but it ensures honest parties can challenge invalid block headers before they’re confirmed.

This is usually done by implementing a smart contract on the main chain that handles rewards, stakes, rotations, and penalties of the sidechain’s validators. If a validator commits a provable offense—like signing two blocks at the same height—anyone can submit the proof to the smart contract and have that validator’s stake slashed.

Optimistic chains operate similarly and require validators to submit block headers to a smart contract on the main chain at intervals. However, optimistic chains don’t have a separate consensus mechanism—block headers are simply assumed valid until challenged by a fraud-proof (more on this later). Thus, optimistic chains can run with a single (honest) validator whereas commit sidechains require multiple validators to be functional.

In both cases, honest parties can prove malicious behavior occurring on the sidechain to the parent blockchain. This way users still have some guarantees of security even if the majority of the sidechain’s validator set is corrupt.

But there’s a caveat: honest parties cannot prove malicious behavior without access to state data stored in blocks.  However, since the main chain only receives block headers (and not block bodies) from the sidechain, it cannot guarantee the availability of blocks. This lets corrupt block proposers get away with dishonest acts—say, stealing funds from the bridge—by withholding block data.

This issue—known as the data availability problem—is central to the differences in the security properties of all sidechains, not just commit and optimistic sidechains, and rollups. The next section which discusses rollups explains how rollups solve the data availability problem to guarantee the safety of users’ funds.

Note: Polygon PoS and SKALE are examples of commit sidechains. Arbitrum Nova and Metis are examples of optimistic sidechains (ie. optimistic-rollup like constructions with off-chain data availability).

What is a rollup?

Rollups boost the scalability of an underlying blockchain by processing transactions in a separate execution environment. Like sidechains, rollups have bridges for moving assets to and from the parent blockchain. They also implement optimizations to enhance computational speeds and cost efficiencies for users.

Rollups, however, submit blocks to the main chain at intervals—inheriting the latter’s security and decentralization. This  means the parent blockchain guarantees the following security properties for rollups:

1. Availability: Rollup blocks are guaranteed to be available for verification because the data is stored on the more decentralized and secure parent network. For example, users can always prove details about the rollup’s state to the bridge contract (eg., owning some tokens) and withdraw funds if rollup validators withhold transaction data.

2. Validity: Rollup blocks can only be finalized if they meet conditions for validity, enforced by the parent chain.

3. Liveness: Because rollup data is stored on the base layer, anyone can reconstruct the rollup’s last valid state and produce new blocks. Also, users can force the inclusion of a transaction in a rollup by sending it to the rollup’s on-chain smart contracts. This prevents corrupt validators from freezing the chain and censoring users.

Types of rollups

Rollups come in two forms: optimistic and zero-knowledge. Zero-knowledge rollups (aka validity rollups) submit blocks to the parent chain along with validity proofs confirming that off-chain transactions were executed correctly. If the proof passes verification on-chain, the block is finalized on the base layer.

Optimistic rollups submit blocks without any proof attesting to the validity of off-chain computation. Blocks are simply assumed valid unless another party challenges the results of a transaction through a “fraud proof”. Fraud proofs take the form of a verification game, mediated by the parent chain, in which two parties dispute a particular computation until the dishonest party is discovered.

The optimistic assumption that state transitions are mostly valid is what gives optimistic rollups their name. Nevertheless, this optimism is combined with crypto-economic incentives guaranteeing that, except if an invalid block remains undisputed for long, it will never be finalized by the main chain.

Note: Arbitrum and Optimism are examples of optimistic rollups.

EVM compatibility is another noteworthy distinction between optimistic and ZK-rollups. While optimistic rollups are EVM-compatible, ZK-rollups vary in their degree of EVM compatibility. As proving native EVM instructions in a proof circuit is complex and resource-intensive, some validity rollups use a custom VM instruction set optimized for more efficient proving.

Where a ZK-rollup is EVM-compatible, we describe its execution environment as a “zero-knowledge EVM” (ZK-EVM). ZK-EVMs can execute Ethereum smart contracts off-chain and prove that all parts of the computation were carried out correctly. For this reason, ZK-rollups are considered more secure than optimistic rollups, which rely on crypto-economic incentives and honest assumptions to prevent invalid execution.

Linea is an example of a Layer 2 validity rollup with full EVM support—one that allows developers to reuse Ethereum infrastructure and tooling to build dapps. In contrast, deploying on a non-EVM ZK-rollup like StarkNet requires (a) building smart contracts with a different stack or (b) modifying the codebase to run in the StarkNet VM.

How are sidechains different from rollups?

Throughput: Sidechains can process more transactions on average than rollups because they don’t rely on the main chain for consensus and data availability. For example, a sidechain can implement large block sizes and extremely fast block times to gain more throughput which rollups cannot do.

Rollups must avoid processing too many transactions such that transaction batches cannot fit into a single main chain block. Otherwise, this would reintroduce congestion on the base layer and make it difficult for the former to keep up with blocks produced on the rollup. Thus, the data bandwidth of a rollup’s parent chain puts an effective cap on its throughput.

Even sidechains that partly rely on the main chain for security (i.e. commit chains and optimistic chains) still have better throughput than rollups. For context, block headers are constant-sized and consume less storage than rollup batches which vary in size. Therefore, commit chains and optimistic chains can produce arbitrarily large blocks at fast intervals without worrying about congesting the main blockchain network.

Costs: Users are likely to pay less for transactions on a sidechain compared to a rollup. Like other distinctions between sidechains and rollups, this one has to do with the latter’s reliance on the parent chain for settlement and finality. Here are some operational costs rollups incur (which are passed onto users):

• Data storage: Submitting a rollup block to the base layer incurs fixed costs (the cost of including the transaction in a block) and variable costs (based on the size of the rollup block). As a result, rollups charge users for computation and data—transactions generating more data pay more and vice-versa.
• Proof generation and verification: Zero-knowledge rollups incur extra costs from generating validity proofs for verification on the base layer. Verifying validity proofs is resource-intensive and presently costs around 500,000 gas on Ethereum, for example.

Pure sidechains don’t incur the costs described above; hence, they’re cheaper to use. A commit chain or optimistic sidechain may incur some extra costs from submitting block headers, but these costs are negligible. Besides, it is possible to reduce costs by accumulating several block headers before submitting in a single transaction.

Finality: Sidechains wholly responsible for their security have instant finality—blocks are irreversible once approved by a majority of validators. This doesn’t apply to commit chains or optimistic sidechains, however, since they must account for challenges that could delay the finalization of block headers.

Rollups usually have a longer time-to-finality than pure sidechains for different reasons. For instance, optimistic rollups delay confirmation of transactions to ensure honest participants have time to challenge invalid state updates.

Validity rollups have instant finality (once proof verification passes); but these, too, have long finality times than pure sidechains. As generating and verifying validity proofs is expensive, sequencers prefer to accumulate a sizable amount of transactions before generating and submitting proofs for batches.

Security: The safety of a rollup—optimistic or zero-knowledge—is guaranteed by the underlying blockchain, reducing trust assumptions for users. As explained previously, rollups depend on the (economically secure) main chain for consensus and data availability (unlike sidechains). This reduces the risk of censorship, frozen withdrawals, invalid execution, and more.

Pure sidechains are responsible for their security. However, bootstrapping a diverse and reliable validator set can be difficult, which is why sidechains are considered less secure than rollups.

Commit chains and optimistic sidechains are slightly more secure than pure sidechains, but users must trust validators and proposers for data availability. If data withholding attacks are performed without incurring penalties, commit chains and optimistic sidechains have no security guarantees whatsoever.

Bridging: Rollups and sidechains (mostly) use the same asset bridging scheme: lock X tokens in a smart contract on the main chain and mint X tokens for the user on the child chain. What separates them is how funds deposited in the bridge contract are secured.

Since rollups are specific to a particular base-layer blockchain, there are usually “canonical bridges” connecting the two. Funds deposited in a rollup’s bridge are secured by the parent chain:

• Funds deposited in a validity rollup can be withdrawn only if the proof associated with the batch containing the exit transaction is verified on-chain
• With optimistic rollups, users can withdraw funds after the block containing the user’s withdrawal transaction is unchallenged after the dispute window (~1-2 weeks) elapses.

Conversely, the security of funds deposited in a sidechain’s bridge depends on its design. For instance, if a sidechain has a canonical bridge connecting it to another blockchain, the security of bridged funds correlates to the honesty of validators. Another question to ask is whether the bridge is validated by the entire validator set (eg., Polygon PoS bridge) or a small group of external verifiers (eg., Avalanche-Ethereum bridge).

Variances in time-to-finality also account for differences between rollup and sidechain bridges. To illustrate, optimistic rollup users will experience more delays when bridging funds back to the main chain due to the challenge window. With sidechains, users can withdraw funds from the bridge contract once it receives a finalized block header (and a valid Merkle proof where necessary).

Choosing between rollups and sidechains

Selecting between a rollup and a sidechain when deploying smart contracts depends on your goals, user feedback, and project needs. Here are different scenarios that make using a rollup, a sidechain, or both, preferable.

When to use a rollup:

1. Your users want the highest security guarantees.

2. Your users can tolerate slightly higher costs and increased latency/finality (eg., when bridging funds). Rollups are cheaper and faster than Ethereum (by orders of magnitude), but cannot equal sidechains on those metrics.

2. You (or your users) want a closer relationship with the ecosystem of the parent blockchain (eg., Ethereum).

3. You have plans to improve UX for dapp users on rollups. This could mean using liquidity providers to reduce delay in withdrawing funds from an optimistic rollup or implementing code optimizations (see some real-world examples) to reduce transaction data generated by users interacting with your smart contracts.

4. You want to use EVM tooling and infrastructure when building dapps. Most rollups are EVM-compatible and use the same tooling, client software, and node APIs as Ethereum.

When to use a sidechain:

1. Your users want to pay the lowest fees possible for transactions.

2. Your users want transactions processed quickly, especially when bridging funds.

3. Your users can tolerate increased trust assumptions and lower security guarantees.

4. You (or your users) don’t consider a close relationship with the main chain’s ecosystem a top priority.

5. You can learn to use a new set of programming languages, tooling, and infrastructure to build dapps (if using a non-EVM sidechain).

When to use a sidechain and rollup:

1. Your project has already established strong network effects on one blockchain and is ready to expand to multiple ecosystems simultaneously (eg., to tap into liquidity).

2. You want to cater to different types of users and avoid alienating one side of the market.

3. Your project has enough resources to handle cross-chain expansion. This would potentially mean having different teams tasked with deploying your dapp on different blockchain platforms.

Build on rollups and sidechains with Infura

Whether you’re building dapps on a sidechain or prefer a rollup, Infura provides the infrastructure you need to build reliable and highly performant applications. Infura’s suite of blockchain node APIs gives you access to sidechains (NEAR, Avalanche, Celo, Polygon, Palm) and rollups (Optimism, Arbitrum, StarkNet, and Aurora).

Can’t quite make up your mind on which scaling solution to use after reading this guide? How To Choose The Right Blockchain For Your Next Dapp provides a comprehensive comparison framework for selecting the best blockchain for your Web3 project. You can also reach out to the Infura team if you need help with making decisions about your W1eb3 project’s infrastructure.

Keep building!