Blockchain interoperability and layer 2 rollups solve different scaling problems for a blockchain app. Most apps do not need their own chain. These apps deploy on a mature rollup, keep their state on one chain and add cross-chain messaging only where users and liquidity are already on another chain.
Scaling an app involves three separate decisions: where the contracts run, where the transaction data is published, and how the app talks to other chains. This article covers each decision and the trade-offs that cause problems later.
What scaling means for a dApp
When a team says its app "does not scale", the team usually means one of four problems:
- Cost per action. Fees on Ethereum mainnet make small, frequent actions such as game moves, social posts and micro-payments too expensive.
- Throughput. The chain cannot include all the app's transactions in each block.
- Latency. Users wait too long for confirmation or finality.
- Reach. Users and assets sit on several chains, and the app runs on only one.
Layer 2 rollups mostly solve the first three problems, and interoperability solves the fourth. A common mistake mixes the two: a team deploys on five chains to cut costs and ends up with liquidity split five ways and five times as much code for attackers to target.
How layer 2 rollups work
A rollup runs transactions off the base chain and groups them into batches. The rollup then posts the batch data and a commitment to the new state back to Ethereum. Ethereum stores the data, so anyone can rebuild the rollup's state. In a mature rollup, users can withdraw their funds even if the rollup operator disappears. A sidechain gives no such guarantee, because a sidechain has its own validators and its own security.
Optimistic rollups
Arbitrum One, OP Mainnet, Base and the other chains built on the OP Stack are optimistic rollups. An optimistic rollup assumes each batch is valid. A challenge period of about seven days follows, during which a fraud proof can show that a batch is wrong. A native withdrawal to Ethereum therefore takes about a week, and third-party "fast bridges" pay the user sooner for a fee.
ZK rollups
A ZK rollup posts a validity proof with each batch. ZKsync Era, Starknet, Scroll and Linea are ZK rollups. Once Ethereum verifies the proof, the new state is final, so a withdrawal does not wait a week, although proof generation and batching still add some delay. ZK rollups differ in how closely they match the EVM: some run EVM bytecode unchanged, while Starknet uses its own language, Cairo, so EVM contracts must be rewritten for it.
ZK rollups can also close. Polygon announced in June 2025 that it would shut down Polygon zkEVM Mainnet Beta, and the chain stopped producing blocks in July 2026. Users of that chain can claim wallet balances through a Polygon claims page until 31 December 2027. Assets held in DeFi contracts, multisigs or bridge contracts on the chain fall outside that claims process.
Why rollup fees fell
Ethereum's Dencun upgrade in March 2024 added EIP-4844, which created "blobs", a cheaper and temporary data space for rollups, and rollup fees fell sharply. The Pectra upgrade in May 2025 raised the blob target per block from 3 to 6. The Fusaka upgrade on 3 December 2025 added PeerDAS, which lets nodes check blob data without downloading all of it. Two later configuration forks raised the target to 10 blobs per block in December 2025 and to 14 in January 2026. Rollup transactions now cost little enough for many consumer apps that mainnet fees had ruled out.
Rollup maturity
Rollups differ in how much users must trust the operator. Many rollups still run one central sequencer and use upgradeable contracts controlled by a multisig, and some allow only approved parties to submit fraud proofs. The independent project L2BEAT rates each rollup from Stage 0 to Stage 2 on these points. In a well-built rollup, a central sequencer cannot steal funds, but it can still censor or delay transactions, or go offline.
Layer 2 scaling solutions compared
| Option | Security source | Cost and speed | Suits | Main drawback |
|---|---|---|---|---|
| Ethereum mainnet | Ethereum validators | Highest fees, 12-second blocks | High-value DeFi, settlement | Cost of small actions |
| General-purpose rollup | Ethereum plus a proof system | Low fees, fast preliminary confirmation | Most dApps, DeFi, NFTs | Trust in the sequencer and the upgrade keys |
| App-specific rollup | Ethereum plus the app's own operators | Very low, adjustable | Games, high-volume apps | The team runs the infrastructure. Liquidity sits apart from other apps. |
| Sidechain or other layer 1 | Its own validator set | Low to very low | Apps whose users already use that chain | Security that does not come from Ethereum |
| Sovereign app-chain (Cosmos SDK, Avalanche L1, Polkadot) | The app's own validators or shared security | Fully adjustable | Protocols that need custom execution | Validator operations and launch cost |
| Validium or rollup with external data | Proofs plus an outside data committee or data layer | Lowest | Games and other high-volume, low-value apps | Risk that the data becomes unavailable |
Data availability is the place where a rollup publishes its transaction data. Ethereum blobs give the strongest guarantee, while an external data layer such as Celestia or EigenDA, or a data availability committee, costs less. If that outside party withholds the data, users may be unable to prove their balances.
Blockchain interoperability: how chains talk to each other
An app on more than one chain needs a way to move assets and messages between those chains. Blockchain interoperability uses four main patterns:
| Pattern | How it works | Main risk |
|---|---|---|
| Lock and mint | A bridge locks tokens on chain A and mints a wrapped copy on chain B. | The locked pool becomes a large target for attackers. |
| Burn and mint | The token issuer burns tokens on one chain and mints them on another, so no wrapped copy exists. Circle's CCTP moves USDC this way. | Works only when the issuer controls the token. |
| Liquidity networks | Market makers hold tokens on both chains, swap for users and settle later. | Large transfers depend on how much liquidity the makers hold. |
| General message passing | A protocol carries any message, so a contract on one chain can trigger logic on another. Examples are Chainlink CCIP, LayerZero, Wormhole, Hyperlane and Axelar. Cosmos chains use IBC, which checks the other chain with light clients. | Whoever verifies the messages can forge them. |
Why bridges carry the most risk
Bridges have caused some of the largest losses in crypto, and four bridge attacks in 2022 show the pattern:
- The Ronin bridge lost over $600 million after attackers took control of validator keys.
- Wormhole lost about 120,000 wrapped ETH through a bug in signature checks.
- Harmony's Horizon bridge lost about $100 million after attackers took over a small multisig.
- Nomad lost about $190 million when a setup error let anyone forge messages.
In each case, the thing that verified cross-chain messages held control of every bridged asset, whether that verifier was a multisig, a validator set or code. Before choosing a messaging layer, ask four questions. Who confirms each message? How many independent parties must collude to forge one? Can the app choose its own verifiers? Which rate limits cap the loss if something fails?
Chain abstraction and intents
A newer approach hides chains from users. In an intent-based design, the user signs the result they want, such as "swap this USDC on Base for ETH on Arbitrum", and competing solvers fill the order and handle the bridging themselves. ERC-7683 defines a common format for cross-chain intents, so that different protocols can fill the same orders. With intents, an app can accept deposits from many chains and keep its core contracts on one chain.
A scaling plan in seven steps
- Measure the real bottleneck. Estimate transactions per user per day, value per transaction and the delay users accept. A DeFi vault with a few large deposits has different needs from an on-chain game.
- Start on one chain. Pick the rollup or chain where your users, wallets and liquidity already are. An app on one chain is much easier to secure and to understand.
- Optimize before you move. Move data that is not critical off-chain: use events and an indexer, and store media on IPFS. Batch operations, and use signatures for actions that do not need immediate settlement.
- Design state that can move. Allow upgrades only through a multisig with a timelock. Do not assume block times or
block.numbervalues, because these differ between chains. - Add chains for reach, not for cost. Add a chain only when users or liquidity there give a clear reason, and name one chain as the source of truth for each piece of state.
- Choose one messaging layer and limit it. Use rate limits, caps per chain and a pause function. Treat every incoming cross-chain message as untrusted input.
- Consider an app-chain last. Build one only when the app needs its own gas economics, custom execution or sequencer revenue, and the team can staff the operations.
Common mistakes
- A team deploys the same contracts on many chains with no rule for which chain's state wins.
- A team assumes a layer 2 behaves like mainnet. Opcodes, precompiles, gas pricing and block timestamps can differ, and oracle feeds on a rollup need a check that the sequencer is up.
- A team picks a bridge by its fees and ignores its trust model.
- A team launches an app-chain before it has enough users to pay for validators, explorers and indexers.
- A team forgets the user's side: wallet support, gas tokens and fiat on-ramps for the chosen chain.
The guide to multichain blockchain development covers apps on several chains, and the layer 2 guide for NFT projects covers rollups for NFTs. The ZKsync integration guide covers one ZK rollup in detail, and the cross-chain marketplace guide covers marketplace architecture.
Frequently asked questions
What is blockchain interoperability?
Blockchain interoperability is the ability of separate chains to exchange assets and messages. Bridges, burn-and-mint token designs, liquidity networks and message-passing protocols provide it.
Is a layer 2 as secure as Ethereum?
A fully mature rollup takes its security from Ethereum for correct state and for withdrawals. Many rollups still have upgrade keys or approved provers, and L2BEAT shows each rollup's current stage.
Optimistic or ZK rollup: which one fits?
For most apps, the proof type matters less than where the users, wallets, oracles and liquidity are. ZK rollups allow faster withdrawals to Ethereum. Optimistic rollups have matched the EVM most closely and have had the largest ecosystems.
Does an app need its own chain to scale?
Rarely, because shared rollups handle high volumes at low cost. An app-chain makes sense when the app needs custom fee logic or execution and the team can run the infrastructure.
What is the difference between a sidechain and a rollup?
A sidechain has its own consensus and security. A rollup posts its data and proofs to a parent chain, so users rely on the parent chain's security.
How can a token exist on several chains safely?
If you control the token, use a burn-and-mint design with rate limits instead of a lock-and-mint bridge. Make one chain the record of total supply and monitor supply on every chain. The ethereum.org layer 2 overview and the text of EIP-4844 give the official background.