Back to all stories
Scaling with Layer 2s: Rollups vs Sidechains

In a previous article, we explored key consensus algorithms that underpin the majority of current blockchain systems. Lately, a large portion of interest and engineering focus within the ecosystem have shifted towards Layer 2 protocols. These aim to enhance blockchain scalability while preserving decentralization.

They have been extremely successful at their first goal: Optimism and Arbitrum often process nearly a million transactions per day, and occasionally surpass Ethereum in terms of total number of daily transactions. Meanwhile, Coinbase’s recently-released Base blockchain (built on the Optimism stack) is already shooting up the TVL charts and giving users an innovative, low-fee environment to transact in.

Yet, as we will see, there is still some work to be done in order to reach the second aim of preserving decentralization.

In the following sections, we will provide an overview of the main concepts underpinning recent Layer 2 implementations. We will first explore the principal solution often referred to as Layer 2: rollups. Subsequently, we will discuss sidechains and how they differ from other L2 solutions.

Scaling with Layer 2s: Rollups vs Sidechains


As the name suggests, the primary characteristic of a rollup is the bundling of transactions that rely on a foundational blockchain, the Layer 1. The performance boost that rollups offer stems from the fact that Layer 1 and Layer 2 possess different execution states within their respective virtual machines, allowing an L2 to process an entire batch of transactions at a much higher speed. The sole responsibility of the base Layer 1 is to provide finality to the transaction batch, though it may also intervene to resolve disputes or facilitate the transfer of assets between the two layers.

In practical terms, a rollup enables a secondary blockchain — with its own transactions, execution environments, and blocks — to reside within the state of a parent blockchain. The containers, or blocks, housing the child blockchain's transactions become transactions within the parent blockchain. Imagine the child blockchain as a train with multiple carriages. Each carriage (or block) contains numerous passengers (transactions). With a rollup, each carriage doesn't just travel along the tracks, it becomes an entity of its own, integrated into the broader railway system – the parent blockchain. This relationship between the child's blocks and the parent's transactions illustrates the interconnectedness of different layers in blockchain architecture.

This mechanism is so modular that we can envision extending the boundary to Layer 3, Layer 4, and beyond, if needed, by recursively applying the same principles.

unnamed - 2023-09-11T173150.564 Figure 1: Rollup mechanism. Blocks of an L2 are transactions storing data on the L1

The manner in which transactions are consolidated within the parent blockchain differentiates various types of rollups:

  • Optimistic rollups proceed with the assumption that transactions are valid. The L1, substantially slower than the L2, only archives batches of transactions; it doesn’t execute them. If a disagreement occurs, an L1 smart contract intervenes to resolve it by verifying and accepting a legitimate fraud proof, which then reverses a particular state commitment. Notable examples of optimistic rollups include Optimism and Arbitrum.

  • Zero-knowledge rollups employ a recent technology that utilizes a specialized execution virtual machine. Through the use of zero-knowledge logic circuits, this machine can generate proofs that a given execution is accurate. When submitting a batch of transactions, the rollup smart contract on L1 inspects the attached zero-knowledge proofs to confirm the resultant execution state's accuracy, thereby accepting them. This novel approach eliminates the necessity to handle disputes on L1, as it only accepts transaction batches that have been executed correctly. Additionally, the zero-knowledge aspect facilitates the creation of private L2s atop public L1s.

On the consensus level, regardless of the rollup type, the algorithm employed by L1 suffices to validate the entire chain's content, since any child blockchain (L2, L3, etc.) merely exists as a smart contract, and consensus doesn't concern it.

However, from a broader business perspective, the integration of sub-chains within a blockchain amplifies the importance of a precise consensus algorithm and the demands on its nodes. A malfunction within this structure could have a ripple effect, not only impacting the primary parent chain but also all the child Layer 2s. Therefore, the proper functioning and robustness of the consensus algorithm becomes paramount, reflecting the complex nature of the interconnected blockchain layers.

Sequencers and Their Centralization

The entry point of an L2 rollup is known as the sequencer, a crucial network element responsible for gathering sets of transactions, batching them, and then transmitting them as a transaction on the parent chain's (L1) smart contract. Although the state can be computed by anyone by accessing the sequence of transactions sent to the L1, either from the L1 itself or from other servers that have completed the task, the duty of the sequencer is exclusively assigned to a single node, which is charged with advancing the network.

As new transactions are directed to the sequencer, it singularly embodies both the mempool and the block producer of the network. This concentration of responsibility means that the sequencer becomes a potential single point of failure. Any malfunction or outage of the sequencer has a direct impact on the overall L2 performance, as the block production process is intricately tied to the sequencer's availability. A recent interruption in the transaction submission process in Arbitrum exemplifies the type of issues that can arise.

However, the risk extends beyond merely being a single point of failure; the sequencer could also constitute a single point of trust. Two main issues must be addressed here: first, the output of transactions recorded on the L1 may be flawed; second, the sequencer might exploit its centralized position to arbitrarily censor certain transactions. Though both issues can be rectified through the aid of the L1 contract, further development and refinement in this area are still needed. For instance, Optimism has disabled the submission of fraud proofs.

Concerning discrepancies in the computed transaction outputs, the L1 contract encompasses logic that permits another party, known as a verifier, to present a proof of fraud. This is done by executing the transaction on the L1 to highlight the problem and reverse the state. If such a mechanism is disabled, the sequencer's role becomes even more influential, and its integrity must be beyond reproach. This requirement is specific to optimistic rollups since data is usually just documented on the L1. Conversely, zk-rollups validate state correctness through zk-proofs with every new transaction batch, ensuring immediate rejection of any faulty states.

In the context of censorship, a secondary transaction submission mechanism is implemented via the L1 contract. If a transaction is logged there, the sequencer cannot issue new blocks, consolidated as L1 transactions, without including the recorded one. Although this method is likely more costly, as an L2 transaction necessitates an L1 transaction, it offers an effective means to bypass the problem. Furthermore, it serves as a deterrent, ensuring that the sequencer operates correctly.


Sidechains represent an alternate scaling solution for blockchains and are distinguished by their significant disconnection from their parent chain. Essentially, a sidechain operates an independent technology stack compared to the parent or main chain, incorporating an independent consensus algorithm and its own specific set of validators. Sidechains may employ consensus algorithms founded on Proof of Stake (PoS) or Proof of Authority (PoA), and the primary function of the main chain is to serve as an oracle for necessary information, such as monitoring the assembly of validators and their deposited stake.

In this configuration, each node in a sidechain bears a close resemblance to a conventional L1 blockchain node but additionally includes a software module to access the state of the main chain and gather essential information. Sidechains may also routinely save a snapshot of their state on the main chain to offer enhanced integrity assurances. A notable example of a sidechain is Polygon Proof of Stake, which utilizes Ethereum as the primary blockchain.

unnamed - 2023-09-11T173547.747 Figure 2: Sidechain overview. The sidechain progresses independently and periodically submits a fingerprint to the main L1 chain.

Sidechain Security When exploring sidechain security, it is essential to recognize that sidechains encounter challenges similar to those faced by L1s. They are susceptible to vulnerabilities and attacks that may impact any part of the system, including modules associated with consensus, execution, and transaction submission.

Moreover, a comprehensive architectural evaluation must account for the sidechain's dependency on the parent chain, as any malfunction on the parent chain can directly impair the sidechain's functionality. For instance, if the Ethereum blockchain were to halt, it could become impossible to refresh the validator set on the Polygon PoS chain. More ominously, if the parent chain permits state reverts, extensive segments of the sidechain might be reversed or plunged into an undefined state if the information about validators was updated in the reverted condition.

Lastly, since the primary goals of sidechains are achieving higher transaction throughput and lower fees, there might be a preference for smaller sets of validators. This choice, although seemingly pragmatic, lessens the diversity of parties involved in the consensus algorithm, potentially introducing new risks or undermining the robustness of the consensus process.

Sidechains provide an exciting avenue for scaling blockchain technologies but come with their unique set of complexities and risks. The interdependence between parent and side chains, coupled with the drive for efficiency, creates a landscape where careful planning, robust implementation, and ongoing vigilance are essential to maintaining integrity and security.

Consequences On Existing Layer 1s

L2s are currently the foremost and most promising technology designed to scale existing blockchains to achieve higher and more cost-effective transaction throughput. This focus on scaling has given birth to dedicated new functionalities within L1s. A case in point is Ethereum's EIP-4844, aimed at implementing a pruneable blob storage to facilitate more economical rollup transaction batching.

The success of rollups and sidechains has notably influenced the L1 development roadmaps, resulting in a diminished emphasis on a mechanism known as sharding. Sharding is a consensus-level mechanism that splits the state of a blockchain into several sub-chains or "shards," enabling them to process transactions independently. Essentially, the number of shards multiplies the system's capacity to handle transactions.

However, the emergence of rollups and sidechains has positioned sharding as a more distant, long-term objective, to be pursued only if there is a pressing need. Some second-generation blockchains, which were promising in terms of native sharding support, have experienced a decline in interest due to the same factors.


The quest to scale blockchain performance to support the growing demands of DeFi and to pave the way for broader adoption has been a consistent driving force within the Web3 ecosystem. L2s, particularly rollups, present a solution that is orthogonal to the consensus scalability challenge. They offer more affordable transactions by delegating the consensus and finality issues to L1s and by supplying additional usable block space.

The main trade-off for these enhancements at present is the centralization of the sequencer component, the decentralization of which remains an ongoing work-in-progress for major projects within the ecosystem.

Sidechains offer an additional solution for applications that require greater transaction throughput, enabling quicker consensus algorithms based on a limited set of validators governed by a parent L1. Though they operate almost like a standalone blockchain, sidechains still necessitate the complete functionality of the parent chain and often rely on smaller validator committees.

In sum, the blockchain scaling landscape is marked by innovations like L2s and sidechains that have the potential to propel the technology towards mass adoption. However, these solutions come with their own unique challenges and trade-offs. The interplay between different layers and components requires careful consideration to ensure that the pursuit of scalability does not compromise other essential aspects of blockchain technology, such as security and decentralization. The ongoing developments in this field continue to shape the future of Web3, reflecting both the transformative potential and complexity inherent in this frontier of digital innovation.