Why Bitcoin Has No Rollups
(Yet.)
Check Part 1 of this series on Starknet becoming a Bitcoin L2.
Rollups have been a recurring theme in this newsletter.
We've written about 7 Ethereum Rollups and even 1 Solana “Rollup” already (although Solana will insist they don't exist).
As an ecosystem with the single largest native asset in crypto without the social problem of “too many rollups”, all roads point to Bitcoin as the next rollup ecosystem to study.
In fact, after publishing Part 1 of this series, a number of people tempered my excitement at Starknet becoming a Bitcoin Rollup. They explained that Bitcoin already hosts rollups.
40 exist or are being developed, in fact, according to Galaxy.
And things are heating up even more with Galaxy estimating that over $47B of BTC could be bridged into Bitcoin L2s by 2030.
But are they really rollups?
WHAT IS A ROLLUP ON BITCOIN?
The broader concept of L2s has been explored early on with well known examples like the Lightning network.
Only as recently as 2022, people started to discuss rollups on Bitcoin. In order to make the distinction, we need to define what we mean by a “rollup” first.
Definitions for Ethereum rollups usually involve the word “smart contracts” which simply don't exist in Bitcoin and are not even entertained as part of “the roadmap”.
But the basic idea is that a rollup aggregates transactions posted on the rollup network and posts them in batches on the corresponding L1 network.
In addition, rollups also have dedicated bridges and some way to identify token withdrawals from the underlying state.
This is an important distinction.
You could already post state roots (effectively hashed state) of any blockchain on Bitcoin for persistence but the point of a rollup is to allow you to deposit and withdraw Bitcoin from the main network.
The lack of smart contracts means that it is difficult to create the type of programmatic rules that make up a rollup bridge.
To summarize and simplify, we will point to three criteria:
A: Bitcoin for Data Availability & Settlement. All transaction data is posted to Bitcoin mainnet. Bitcoin mainnet used for settlement finality without additional trust assumptions. Any network participant can reconstruct the complete rollup state via a derivation function from onchain data.
B: Trustless L1 verification. All state transitions are cryptographically verified on Bitcoin without intermediaries. All verification logic is executable directly within Bitcoin’s native script capabilities without relying on external verification mechanisms or trusted oracles.
C: Unilateral Exit Guarantee. Enable trustless exits without permission from operators.
The interesting thing is that while Ethereum rollups are looking increasingly homogeneous…
More new rollups seek to launch with proven technology stacks (e.g., OP Stack);
Vitalik’s/L2Beat rollup criteria followed closely by most teams;
Even optimistic rollup stacks are expecting to convert to validity proving systems over time;
Innovation and differentiation is becoming centered more on go-to market and apps instead of tech.
…Bitcoin rollups aren't looking homogeneous at all. They still have real technical barriers to becoming rollups and are taken very different paths by betting on different possible Bitcoin upgrade paths.
In this post, we’ll examine why these technical barriers exist or put more simply: why is it difficult to build a rollup on Bitcoin?
UTXOS EXPLAINED
The key to understanding Bitcoin and its programmability starts with UTXOs.
Both Bitcoin and Ethereum are distributed state machines. They seek to maintain consensus around common global state and allow users to send transactions which if valid modify that global state.
Ethereum’s state is easy to think about. Ethereum has “externally owned accounts”, accounts that can be generated using a private key and smart contracts, which provide ways developers can build their own “state machines”.
Ethereum follows the account model for state like a bank. Every user has a balance of ether. Some accounts also contain code and represent smart contracts. These smart contracts can define custom state and rules how that state changes with transactions.
This model is simple to reason about, maps well to how bank accounts work in practice and is easy to program with. Smart contracts can focus on defining their own state and defining how it can be modified.
Bitcoin doesn't have the concept of accounts. Instead users can have access to UTXOs, short for “Unspent Transaction Outputs” work like cash notes instead.
When you want to make a transaction, you pick a set of UTXOs and “spend” them by splitting/combining them in some way to create new UTXOs for yourself and the recipient.
You can think of this as an equivalent of bringing some notes to a cashier and having them figure out how to make change.
Here’s an illustration of how transactions spend UTXOs.
There are some immediate and interesting implications of this model:
Transaction costs depend on your UTXO set. The more UTXOs you have, the more expensive transactions will be when you necessarily need to combine UTXOs to spend a certain number of Bitcoin. This imposes a heavy UX burden on users. Users need to monitor gas fees and consolidate UTXOs during periods of low gas fees (this is called UTXO management). There are “dust UXTOs” that would cost more to be spent than the Bitcoin within them.
Every bit of spending is traceable. One common confusion with UTXOs is to claim that they add privacy. This is true to some extent, UTXOs can be used to build private transaction systems but that is not how Bitcoin works by default. For typical public key transactions, every bit of spending can be traced back to a specific miner receiving an UTXO in what is known as a “coinbase” transaction and all the new UTXOs that original coinbase UTXO spawned.
UTXOs are easier to verify than Ethereum transactions. The nice thing about UTXOs is that their rules are self contained and cannot refer to other UTXOs. The existence of UTXOs can also be established with merkle proofs meaning that you don't have to reply the entire Bitcoin state to verify a transaction.
But the analogy of UTXOs as cash notes in your personal wallet breaks down when we think about UTXOs enabling more complex behaviors.
UTXOS ARE PUZZLE BOXES
In fact a lot of what I implied above UTXOs is wrong. This is the most common misconception and exists in many explanations of UTXOS.
UTXOs do not belong to a single user. Most common UTXOs can be unlocked with a single public-private key pair and indeed can be thought of belonging to the user which is behind that pair. But more complex UTXOs could have custom rules for accessing the underlying assets.
Even basic UTXOs are not really cash notes. A cash note mechanism would suggest pure payments being built into the network. Instead, even the most basic transactions create UTXOs that have built-in verification logic (see below).
You can instead think of an UTXO as a puzzle box or vault. Every UTXO has some way of unlocking it and rules for what new UTXOs (think: new puzzle boxes) can arise out of that unlocking.
These puzzle games are described using a dedicated language called Bitcoin Script.
The language is not Turing Complete, it simply doesn't have looping constructs.
As an example, every simple payment UTXO on Bitcoin can be “spent” by running a simple “program” to verify the transaction signature, seen below (the program is called scriptPubKey).
WHY ROLLUPS ARE DIFFICULT
To summarize, Bitcoin is far less powerful than having a smart contract system in several ways:
Bitcoin doesn't have smart contracts. Instead, any complicated logic has to be packaged into UTXOs which spawn new UTXOs and so on.
UTXOs barely compose. You can't refer to or look into another UTXO from within an UTXO. Or even do something as simple as look at a user’s total Bitcoin balance. You can only have rules about what UTXOs can be combined together under what conditions. This results in unavoidable state fragmentation/statelessness at the network level.
Bitcoin script is not Turing complete. Based on the other 2 points even if Bitcoin script was Turing complete, the ergonomics of programming state machines with UTXOs is insufficient. While computationally complete, it would not match the ergonomics of interacting with global state in Ethereum. But Bitcoin script isn't Turing complete, which means that even computational completeness isn't achievable.
Bitcoin scripting needs requires DSLs. This is elaborated really well in Bitcoin DSLs and means that without great DSLs the cost of developing and auditing rollups is higher.
Luckily, rollup systems need to post state and verification only on L1.
The state is a solvable problem with Bitcoin (capacity aside).
But it’s a lot harder to do both complex optimistic verifications or ZK verifications with a restricted set of opcodes.
Aside from proving state correctly, there’s also the question of cost.
While these rollup teams absolutely need to focus on making their rollups viable through priority upgrades, optimizing the L1 to improve throughput, reduce transaction fees and latency will become crucial for competition.
In the following posts we will look at what paths different teams are taking to build trustless rollups on Bitcoin and why none of them can be called rollups yet.
Disclaimer: This research is supported by a grant from StarkWare. The views expressed are solely those of the author and do not represent the views of StarkWare or their employers, clients or affiliates. This report does not constitute financial advice. Peteris and Auditless are $STRK airdrop recipients.
Thanks to the StarkWare team for providing valuable research input for this article.