The Problem With Bitcoin Scalability
Bitcoin is great at a couple of things. For example, it is good at storing data in a decentralized, tamper-proof manner, and it is good at solving the Byzantine Generals’ Problem.
Bitcoin is also bad at a lot of things. For example, Bitcoin is not good at storing a lot of data at once. It turns out that when you are replicating a database across a decentralized network of nodes, the network gets more unwieldy the larger the network gets and the larger the database gets.
This leads to limited blockspace and limited throughput. Each Bitcoin block has a max size of 4MB, and Bitcoin famously has a throughput of ~7 transactions per second. This makes block space expensive. For example, in January a user spent $64,000 to inscribe just 9MB of data on Bitcoin.
Limited blockspace and throughput are fine when thousands of people are using Bitcoin—most of the time, people aren’t spending $64K to use Bitcoin—but if you want to scale Bitcoin to support billions of users, Bitcoin in its current state can’t get anywhere close.
What is a Rollup?
Rollups are one approach to solving this scalability problem, and the idea behind them is simple: what if you take execution off-chain and bundle (or roll up) transactions off-chain into batches and post those batches on-chain all at once?
This greatly reduces the amount of data that needs to be stored on-chain, making these transactions cheaper and making the network as a whole more scalable.
However, it’s not quite that simple. Rollups are just one type of scaling approach, alongside other designs like sidechains and state channels. Rollups generally differ from independent sidechains in that rollups push data availability to the L1 whereas that is not a requirement for sidechains. Rollups and sidechains differ from state channels in the sense that state channels are not full blockchains: they do not have global state, which means no smart contracts. Each individual channel is private, and only once a channel is closed does the updated state settle back to the L1.
Like any scaling solution, rollups come with a series of tradeoffs. The main challenge with rollups is in verifying that the batches of transactions posted to the L1 blockchain are accurate. If the data isn’t all on-chain, how can you trust it?
There are several design approaches to answer that question.
Validity vs Optimistic Rollups
When looking at the implementation of rollups, there are two main variants that have market traction today: validity and optimistic rollups.
In a validity rollup, users do a bunch of transactions offchain (on the rollup), and then once the transactions are processed, a proof of validity is submitted to the L1. This validity proof summarizes how those transactions changed the state of the blockchain. This proof is automatically validated, and it can be audited and verified by anyone. By their nature, validity rollups prevent invalid transactions.
In an optimistic rollup, users do a bunch of transactions offchain (on the rollup), and then those transactions are processed and submitted to the L1 in batches. In this construction, the L1 assumes the transactions are valid (an optimistic outlook) and transactions are only proved invalid if challenged. Instead of enforcing accuracy via a cryptographic proof, optimistic rollups enable honest users to submit fraud proofs to challenge a transaction outcome within a specified time window. By their nature, optimistic rollups allow invalid transactions.
These two different design approaches have a number of ramifications. First, validity rollups are considered optimal and have fewer trust assumptions, but technically they are much harder to build. Validity rollups are an area of cutting edge innovation that have gained traction in Ethereum.
Optimistic rollups on the other hand are easier to implement, but they have additional trust assumptions. And given there is a time window in which users can challenge transactions, that means withdrawal times are longer, impacting the user experience.
Data Availability and Settlement
Another important variation of rollup designs relates to data availability and settlement. Both of these concepts describe how and to what extent a rollup stores information on the L1 .
Data Availability
Data availability is defined as the ability for any network participant (nodes) to independently verify that a block is valid. When a rollup project claims to use Bitcoin for “data availability,” they are saying that the rollup stores enough information on Bitcoin that anyone can independently verify that blocks processed by the rollup are valid.
Another way to describe this is that you can reconstruct the state of the L2 (a rollup in this case) purely by looking at information on the L1 (Bitcoin in this case). It’s worth noting that there are several approaches to data availability, from fully on-chain to off-chain and everything in between.
This is another way that rollups differ from sidechains. For example, the Stacks blockchain takes a different approach. In the case of Stacks, block hashes are stored on the Bitcoin L1, meaning that anyone on the Bitcoin L1 can verify that the latest Stacks block is valid. However, there is not enough information on Bitcoin to reconstruct the chainstate of Stacks. We don’t believe that level of data availability is necessary, or even a good use of Bitcoin’s premium blockspace, since as long as there is any value in the Stacks network, Stacks miners will maintain a copy of the Stacks network.
Settlement
Settlement refers to where in the process a transaction is determined valid. For example, some rollup designs use a smart contract as a bridge back to the L1. This contract is used to process and generate proofs for the off-chain rollup transactions, and the L1 blockchain is used for consensus, settlement, and data availability. In this design, the contract is the source of truth, and all verification occurs on the L1, and this contract acts as a bridge to the off-chain rollup.
Other designs take a sovereign approach, in which a sovereign rollup uses the L1 blockchain for data availability, not for settlement. This means that the rollup nodes order and settle transactions on the rollup, and only the data is made available on the L1 chain. Sovereign rollups are much closer in design to sidechains, with the exception that not all sidechains use the L1 for full data availability.
As a result of these design differences, 1) sovereign rollups have a smaller on-chain footprint relative to optimistic and validity rollups (which makes them cheaper to use), 2) sovereign rollups can function independently of the L1 chain (which makes them modular), and 3) sovereign rollups do not inherit L1 security in the same way that other rollup designs do (which isn’t a bad thing, but it does introduce different trust assumptions).
Traction of Rollups Today
The concept of rollups has become increasingly popular in the past few years. Notably, Ethereum has embraced rollup architecture and led the way for the industry. Ethereum rollup networks like Arbitrum, Optimism, Loopring, Starknet, and Polygon have all seen strong adoption and have paved the way for a thriving Ethereum ecosystem. Other ecosystems have taken note and are now working to bring rollups to different L1s, Bitcoin included.
What is a Bitcoin Rollup?
A Bitcoin rollup is a scaling solution for the Bitcoin blockchain that bundles off-chain transactions and posts them to the Bitcoin L1 for settlement. Bitcoin rollups could be a means to scale Bitcoin to billions of users, but they are still in the research and early development phase.
One key difference between Ethereum rollups and Bitcoin rollups is that Ethereum rollups have the benefit of a virtual machine on the Ethereum L1. This means that most rollups on Ethereum use the Ethereum blockchain as both a data availability layer and a consensus layer (meaning the validity of rollup transactions is determined by logic running on Ethereum L1).
As Hiro’s Chairman Muneeb Ali puts it, today Bitcoin rollups require a trusted setup because there is no virtual machine on Bitcoin. This means the Bitcoin L1 cannot interpret the validity of the rollup proofs. Rollup projects on Bitcoin have developed clever ways to this, in the most trust-minimized way possible.
Building on Bitcoin is notoriously difficult, but there are a number of projects working on them. Some have argued that “true Bitcoin rollups” are not possible without a soft-fork to Bitcoin core, enabling op_codes needed to verify rollup proofs at the L1.
For the projects that exist today, it might be more accurate to describe these projects as BitVM rollups, where BitVM (a protocol we’ll get into below) is used to verify proofs. Regardless, Bitcoin rollups captured the imagination of Bitcoin builders and inspired many teams to take a closer look at Bitcoin layers.
The Bitcoin Rollup Landscape
This list is far from comprehensive, but let’s take a look at some of the teams contributing to Bitcoin rollups.
In alphabetical order:
BitVM
BitVM is a project in R&D that launched in October 2023 with the publication of a white paper authored by Robin Linus on the ZeroSync team (more on that project below). BitVM is not a Bitcoin rollup—instead it is a method that brings expressive logic directly to Bitcoin without requiring any changes to Bitcoin itself. That logic can be used to build rollups, but it can also be used for a range of other use cases.
The core idea of BitVM is to take computation off-chain with an on-chain fraud proving mechanism. Bitcoin Script is very simple, so to run more advanced programs, you need to run them off-chain and somehow prove that the computation was done correctly.
To verify computation, BitVM uses a similar scheme to optimistic rollups: a prover (who executes the computation off-chain) makes a claim about the output of the computation. If this claim is disputed, the verifier can challenge it on the Bitcoin blockchain. The Bitcoin blockchain would only be used for disputes in this scheme.
BitVM has generated a lot of excitement in the Bitcoin community and for good reason. It greatly reduces the trust assumptions involved in building Bitcoin layers. Most existing approaches to Bitcoin layers assume an “honest majority” to prevent what’s known as a 51% attack. BitVM introduces an “honest minority” model, meaning as long as one participant is honest, you can prevent a malicious actor from corrupting the system.
BitVM can be incorporated into a number of existing Bitcoin layers, not just rollups, and can bring more functionality and decentralization to these layers. There’s no timeline to mainnet, but a number of developers are actively working on the protocol.
BOB
BOB (short for Build on Bitcoin) is a Bitcoin L2 with EVM compatibility. BOB uses a rollup design that enables it to be connected to Ethereum while being secured by Bitcoin. BOB came out of the Interlay ecosystem, which in turn grew out of Polkadot and Cosmos. Interlay launched in August of 2022 with iBTC, a trust-minimized Bitcoin peg.
BOB’s goal is to support not only a Bitcoin peg, but also Ordinals, Lighting and other building blocks for Bitcoin DeFi. Bob is using the Optimism stack, including the ZK work being done by RiscZero, and long term hopes to settle directly on the Bitcoin L1 via a ZK verifier. In the midterm, they are looking into optimistic rollup designs on the Bitcoin L1 that use mechanisms like BitVM to implement onchain fraud proofs. BOB is currently on public testnet.
Citrea
Citrea is a new optimistic sovereign rollup for Bitcoin developed by Chainway that was just announced in February 2024. Based on the limited docs available, the protocol plans to inscribe proofs of state changes directly on Bitcoin, which would allow anyone with a Bitcoin node to verify Citrea and retrieve the entire rollup state using only the Bitcoin L1.
The project plans to use BitVM as a settlement layer, to verify proofs on the Bitcoin L1. As a sovereign rollup, Citrea intends to leverage Bitcoin for data availability (see the GitHub repo here) and doesn’t have a separate miner network or token. Importantly, Citrea is EVM-compatible, and devs can use Ethereum tooling when building with Chainway, making it easy for developers to port some of the innovations from the Ethereum ecosystem to Bitcoin.
Sovryn
BitcoinOS is a new project from Sovryn, a DeFi-focused community that launched in 2019 with ties to Rootstock. The Sovryn application enables non-custodial, permissionless swaps, trading, lending, liquidity mining, and more. Sovryn is taking that DeFi expertise to build BitcoinOS, which will enable a “superchain of rollups that all use the same modular parts.”
Their vision is to create a network of rollups, where each rollup can have its own execution environment while maintaining interoperability with each other. The design uses a shared compression, aggregation and settlement layer (called CASTL) that allows any app on a rollup to be compatible with apps on another rollup, creating cross-rollup liquidity.
BitcoinOS is currently under development, with the testnet launch scheduled for Q3 2024. BitcoinOS hopes to launch mainnet shortly after in Q4 2024
Rollkit
Rollkit launched in February 2023 as a modular framework for sovereign rollups, and the project was developed by the Celestia team, a modular EVM blockchain specializing in data availability solutions. Shortly after launch, Rollkit announced support for Bitcoin.
The design uses Bitcoin for consensus and data availability and stores data via Taproot transactions, while handling execution offchain. Using this model, the team was able to create a demo running EVM as a sovereign rollup on Bitcoin testnet. Per Rollkit’s website, Bitcoin support is not yet production-ready, and this integration should only be used for experimentation and research.
Zerosync
ZeroSync is actively researching zero-knowledge proof systems for Bitcoin. While this project has not announced plans to launch a rollup, their research could pave the way for validity rollups, trustless two-way pegs, or perfectly private transactions down the road. So far, they are working on three types of proofs, the first two of which they've successfully prototyped. In order of increasing complexity, these proofs are:
- A header chain proof that validates Bitcoin block headers, difficulty adjustments, and proof of work. This proof is simple, lightweight, and cheap to compute.
- An “assumevalid” state proof that verifies all Bitcoin consensus rules, except for transaction signatures (witness data is assumed to be valid).
- A full state proof that verifies all Bitcoin consensus rules, including all witness data. This is the most complex proof that ZeroSync is working on, and they have yet to prototype it.
These proofs can help builders sync Bitcoin’s chain state instantly and enable zk-proof light clients for Bitcoin, which would enable users to run a full Bitcoin node on much lighter software, maybe even a mobile phone. Over time, ZeroSync plans to work towards an integration of a ZKP verifier into the Bitcoin L1.
ZeroSync is built with StarkWare’s Cairo programming language, another example of Ethereum’s rollup research bleeding into Bitcoin rollups. StarkWare is a company developing zero-knowledge tech in the Ethereum ecosystem, and ZeroSync is the first project to work with Cairo outside of the EVM-world.
Conclusion
The innovations in the world of Bitcoin rollups aren’t fully covered in this post. For additional reading, check out John Light’s research on Bitcoin rollups.
The Bitcoin ecosystem is evolving so quickly it can be hard to keep up, and in 6 months, I imagine I will be back to update this article because the landscape of Bitcoin rollups will look entirely different. Such is the beauty of innovation.