This article, featuring additional research from 'eskimor' and Natalie Tillack, considers the inherent similarities, and benefits, of Polkadot’s case-specific chains when compared to the various “rollups” that have become popular in other ecosystems.
In blockchain technology, scaling while keeping a good level of security remains one of the most critical challenges. Ethereum, one of the most prominent chains, has faced its fair share of scaling issues due to its popularity and the vast number of transactions it handles. To overcome those challenges, rollups have gained popularity in recent years, offering a solution that enhanced Ethereum's capacity to optimize how transactions are processed and recorded. But what are rollups, how do they solve this problem, and, most importantly: how are they connected to Polkadot's chains?
The main task of a blockchain network is to verify transactions that are submitted on-chain through a consensus protocol. These include a "real" transaction, such as sending tokens from one account to another, or the transmission of data through the network. Since blockchain networks can only handle a certain number of transactions per block, they face limitations in throughput. This is where rollups come into play.
Simply put, rollups execute transactions off-chain, outside a Layer 1 (L1) mainnet such as Ethereum or Solana, in a separate environment. Rollups work by reducing the load on a blockchain's mainnet by "rolling up" multiple transactions into a single bundle. The transactions are processed off-chain, and the block data is compressed and "rolled up" into a smaller form. This compressed data is then submitted back to the L1 network, ensuring it leverages its security protocol, to guarantee the availability of the data. Finally, it is integrated into a block. This increases the network's capacity to handle more transactions.
Now what has this to do with Polkadot?
The case-specific chains in Polkadot have historically been called parachains. This term is still in use, though it is being phased out with the advent of Agile Coretime, in which all projects are invited to secure a quantity of high-quality blockspace to meet their needs. For ease of reference, we will continue to use it in this article. Parachains validate transactions independently and produce blocks. Each one operates according to its own business logic, determining the functionalities provided to end users or other chains. While parachains handle the execution and validation of transactions, the final consensus is provided by Polkadot's Relay Chain (L0). After parachain blocks are validated and backed by the Relay Chain validators, they are included in the Relay Chain and made available for other parachains to utilize.
First things first, let's break down how optimistic and ZK rollups actually work. After that, I'll dive into parachains and compare their block execution to that of the other rollups.
Optimistic rollups, as the name suggests, operate on an optimistic assumption: that all transactions are valid by default. Some might call this approach naive - or maybe that's just my trust issues speaking?
Instead of verifying each transaction in real-time, optimistic rollups approve all transactions and send their bundled data to the L1 mainnet. Unlike ZK rollups, which verify each transaction upfront, optimistic rollups rely on fraud proofs.
If a fraudulent transaction is detected, the system reverts to the state before that transaction was processed, penalizing the bad actors involved. When submitting a transaction or a fraud proof to the mainnet, both parties must stake a bond. If a dispute arises, the transaction is re-executed on the main chain to resolve it. To ensure accurate dispute resolution, rollups must implement a system capable of replaying the transaction. If either the transaction or fraud proof is shown to be fraudulent, the bad actors face slashing (forfeiture of the bond), which punishes them and deters future malpractice.
Entering a dispute is rare due to the high costs involved. And since there needs to be sufficient time to allow for potential disputes, finality for these transactions typically occurs 7-14 days after they are submitted.
ZK rollups are stricter when it comes to trust. In this system, transactions are first validated and only after they pass this validation are they bundled together and assigned a cryptographic proof, known as a zero-knowledge (ZK) proof. This proof is then submitted to the L1, where it is verified by a smart contract. This approach ensures only valid transactions make it on-chain, keeping the process efficient and secure. If any invalid batches manage to slip through, they can be slashed immediately, preserving the integrity of the network. However, ZK rollups are more expensive and complex to implement than optimistic rollups due to their advanced cryptography, specialized hardware requirements, and potential centralization risks. They also face interoperability challenges across different L1 protocols, complicating broader adoption.
Parachains are essentially Polkadot's own "version" of rollups. And, similar to ZK Rollups, they validate their transactions before submitting them to the L0 mainnet. However, there are multiple steps put in place to ensure the blocks are valid. Parachains are a "cynical" type of rollup because they assume participants may not always act honestly, requiring multiple layers of verification and checks to enforce the rules.
Parachains operate with their own set of nodes, called collators, who collect transactions from users, execute them, and propose new blocks. Collators are responsible for gathering and processing transactions within the parachain and then proposing these blocks to the parachain's backers. Now, you might be thinking, "Jeeeesus, another whole new terminology!🙄" I know, I know---blockchain ecosystems are full of it. But bear with me; it will make sense in the end.
Backers are a subset (currently five) of validators from the Polkadot Relay Chain (L0) who are temporarily assigned to a specific parachain to validate the blocks produced by collators. This rotation is typically managed by the L0 to ensure fairness and security, preventing any single group of validators from consistently controlling the validation process for a particular parachain. Backers verify the validity of the block proposed by the collators, ensuring it follows the parachain's rules and does not conflict with any other part of the system. A backer validates the block by attesting to its validity. These attestations are then put into a Relay Chain block, which together with the availability system ensures those backers are accountable. They now have skin in the game.
After availability of the parachain block is ensured, another set of validators (approval checkers) check again. If all goes well the Relay Chain and, by extension, the attested parachain blocks, get finalized via the GRANDPA finality mechanism. Approval checkers will raise a dispute if they believe the block is invalid, causing all the Relay Chain validators to conduct checks. Backing validators will be slashed (lose all their stake) if that proves to be true. This coordinated process ensures Polkadot achieves secure and reliable finality.
It sounds like a lot of work to be done in a short time, yet the whole process takes around 18 seconds in total to achieve finality, compared to other rollups where it takes up to 14 days for a block to gain finality and security from an L1 chain.
On top of secure finality, Polkadot comes with interoperability by default. Developers building on Polkadot can communicate effortlessly through XCM, enabling applications to leverage a wide array of multichain services across the ecosystem. This encourages true decentralization and a vibrant range of use cases. Developers have the tools to create versatile and interconnected dapps on top of the parachain layer, tapping into the diverse capabilities the Polkadot ecosystem has to offer. Due to the shared security offered by the L0, cross-chain communication is super fast (around 12s and plans to make it much faster than this) and secure. That's pretty good when you consider the seven days required for secure and decentralized communication between optimistic rollups.
In simple terms, Polkadot effectively has native rollup functionality included at the protocol level. It has rigorous processes in place to ensure accuracy and also comes with rapid finality and data availability built-in, culminating in a powerful alternative to rollups.
If you would like to learn more about Polkadot's rollup architecture, or compare it to other rollups, check out this comparison table. And if you're interested in diving deep into the mathematical foundations of the protocol, I highly recommend checking out the paper "Efficient Execution Auditing for Blockchains under Byzantine Assumptions" published in 2024 and authored by some (former) W3F and Parity members. Or, if you prefer to keep things simple, you can watch the Protocol Berg presentation by Parity's eskimor.
Thinking of building your own Rollup? Dive in and make it happen: https://polkadot.com/developers