Blobtaliptus

DevLens: to scale or not to scale

September 5, 2025

Bitcoin L2 this, Bitcoin L2 that, sidechain this, sidechain that, rollup this, rollup that. Even BitVM this, BitVM that.

Today we will go over some semantics - particularly of Bitcoin sidechains and Bitcoin rollups. You may have seen these definitions and sentences many times, but perhaps a different angle can make you understand why these things matter, and why rollups might be a superior solution.

There are two separate surfaces: execution (i.e. how the solution computes the truth) and custody (how BTC moves with a bridge). Don’t blur them. I won’t let you blur them.

Since we announced Citrea, I’ve pitched this to hundreds, perhaps thousands of people. Aside from the giga-brain/black-magic BitVM-based bridge, the main improvement of Citrea, compared to other alternatives, is the fact that it is a rollup and it inherits the security of Bitcoin (at least from a DA perspective).

However, the message gets lost. Let’s go over it one more time.

I especially advise you to bear with me if you’re a Bitcoiner - often this stuff goes unnoticed, and it really should not be so.


0: Definitions (really simplified)

I know that this part is usually boring but I will keep it really, really simple here.

L2

This one is a bit tricky. In the Bitcoin world, many people consider any scaling solution as an L2 - this includes sidechains, rollups, or any other alternative. Whereas in the Ethereum world, people exclude sidechain from the L2 definition - but include rollups.

If you were to ask me, I’d say neither sidechains nor rollups are L2’s… unless they grant unilateral exits or an always-working mechanism that at least prevents funds to be stolen.

Lightning is an L2. Sidechains are not. But apparently no one cares :)

Sidechain

This is just a blockchain.

It generally publishes a very small cryptographic commitment to Bitcoin as part of its execution, like a hash, on a regular basis.

Sidechains have their own rules, own consensus, own risks and own security model. Most of these rules include a validator committee with an honest majority requirement.

Most of these sidechains have a currency of some wrapped BTC as an asset, either the main currency or in an alternative token form.

Rootstock, Stacks, Liquid are the most famous examples, I guess (each with their own nuances in terms of being federated, merge-mined, and etc).

Rollup

Guess what - this is also just a blockchain!

It generally publishes big commitments (a.k.a. state diffs) to Bitcoin as part of its execution. I say it is big, because this data should be comprehensive enough to recover the current state of the rollup by just looking at Bitcoin (I will explain why this matters too, keep reading).

Rollups also have their own rules. However, they do not necessarily involve a validator committee with an honest majority requirement. Generally there’s a block producer called “sequencer”(s), a ZK proof generator (a prover), and some lovely full nodes that are permissionless to run - some lovely full nodes that ultimately decide the fate of the rollup…

There are no Bitcoin rollups in production as of today. @citrea_xyz and @AlpenLabs to be the first ones most likely, with both using ZK Proofs. At least one of them may very well arrive this year :)

Rollup diagram

Perhaps you may ask:

Is having only one sequencer risky?

Continue scrolling down to find the answer :)

One thing perhaps you may have noticed: I did not talk about any two-way pegs so far. This is intentional: two-way pegs can be (and should be) considered separate notions. Both sidechains and rollups are blockchains, and they can pretty much exist without their bridges.

To understand what I mean, please please please keep reading until section 4, you will see what I mean.


1: Security Source (for Execution)

For the execution of a sidechain, in general, security comes from its own consensus.

An attack that targets a small subset of validators can halt the blockchain.

An attack that targets a majority of validators can create double spending attacks.

For both attack scenarios, the attacker doesn’t need to attack Bitcoin. Therefore, ultimately you depend on an honest majority validator set for the consensus - if it goes wrong, double spend/theft is theoretically possible.

Sidechain security diagram

For the execution of a Bitcoin rollup, security aspect is a bit different.

To start with, a rollup can halt if its sequencer halts - the block producer. In this case, the state will not advance until sequencer resumes.

While the funds cannot be stolen here, there are some solutions around this to make it less painful: like enabling a sequencer rotation mechanism to stop it from being stuck for a long time (or social consensus can step in).

Let’s review the possibility of double-spending attacks. Bitcoin rollups publish state data and validity proofs to Bitcoin. Once this data gets finalized on Bitcoin, the state becomes fully anchored in Bitcoin (from the full node set perspective).

If an attacker wants to alter the history of the rollup or double spend an asset, they first have to reorg Bitcoin more than 6 blocks (or the number of blocks you’d like to wait for) - which is arguably much more secure compared to an honest majority validator committee.


2: Data Availability

A boring part that actually matters. Where’s your data? What happens if it’s gone?

Sidechains

For sidechains, all the data (blocks, transactions, state) lives off Bitcoin - on the sidechain’s own network. Sometimes they post tiny headers or hashes to Bitcoin. You can check if it matches with what you have.

However… what happens if operators/validators withhold the actual blocks from public? What if the network goes dark and you have no visibility?

Well that sucks: posting only headers/hashes to Bitcoin does not solve DA withholding. As a user, you cannot prove balances by checking Bitcoin.

You cannot independently rebuild balances from Bitcoin, and now you don’t have any clue on what’s going on with the sidechain. If you were running a sidechain node on your own, you have your own latest knowledge - which may or may not be the same with the latest finalized state of the sidechain. Data is gone…

Sidechain data availability diagram

Rollups

Rollups post enough data to Bitcoin (typically state diffs or similarly compressed batch data) so that anyone with a Bitcoin node can replay and reconstruct the rollup’s state. No dependency on a trusted party.

This is also why I said the commitments of rollups are “big”: they must be sufficient to recover the state from Bitcoin. As long as Bitcoin is secure and functional, you’re good.

Also perhaps a question in mind:

What if you make a rollup on another blockchain with a Bitcoin bridge?

Then you depend on that blockchain for DA, simply. It’s not a Bitcoin rollup anymore (it’s called a validium). The trade-off here is, it’s OK to pay a lot for storing the data on the most premium/secure blockchain that exists.

Still, considering all of the above, Bitcoin DA matters.


3: A Note on Rollups, Sidechains, and Bridges

Considering all the concepts above, the main reason we believe why rollups are superior to sidechains is clear: in the case of attacks, they tend to have liveness failures, rather than custody failures.

If you check carefully, I did not mention any particular details about two-way peg solutions, a.k.a. bridges. That’s because these things are actually quite separate - you can build any blockchain without a canonical bridge.

Think of two failure surfaces:
(1) execution correctness (who sets truth?)
(2) custody correctness (who releases BTC?)

Bridges can be swapped, but the chain design is intrinsic.

Failure surfaces: execution vs custody

These truths and risks are different.

For Bitcoin rollups and Bitcoin sidechains, these bridges introduce another set of trust assumptions that is only relevant with the custodied Bitcoin itself, rather than the network.

This is a quite important but perhaps overlooked distinction: the networks themselves, in addition to bridges, also possess their own risks.

You have two points of failures. Better keep them safe.


4: Bridges

Now that I’ve mentioned bridges are quite distinct from the execution environments for 1000 times, we can talk about our final point: two-way pegs/bridges.

On today’s sidechain pegs, the BTC generally moves into an m-of-n multisig run by known entities. Deposits/withdrawals require an honest majority. Keep in mind, these entities may or may not be the same as sidechain’s committee. Federation ≠ validator set (not necessarily). They can be different. If an honest majority collude or are coerced, they can block or misdirect the funds.

Bitcoin here does not judge the sidechain state. It only checks signatures and time-locks.

Sidechain bridge diagram

For Bitcoin rollups, though, this is going to be different. All Bitcoin rollup constructions today involve an implementation of BitVM - a trust-minimized bridge design. To super simply explain:

For deposits, you lock BTC into a Taproot n-of-n on Bitcoin - which gets you rollupBTC on the rollup. If n-of-n signers ignore, refund paths are enabled with timelocks so that your funds are not stuck.

For withdrawals, you burn rollupBTC in a specific way. An operator out of n-of-n pays you your intent, then asks the n-of-n vault on Bitcoin for reimbursement.

If their claim is right and they paid you, they get it back. If their claim does not match with reality (i.e. malicious), there’s a challenge-response game using ZKPs and BitVM2. As long as 1 out of N is honest, they can push back against the claim and slash any malicious intent.

Last part is crucial - all Bitcoin sidechain bridges today are pretty much honest majority multisigs. Rollups, when they go live on mainnet soon, will change this with the idea of BitVM2/BitVM3. Instead of relying-on-M-of-N type of bridges, you will only need 1-of-N to be honest and functional.

This is big.


5: Bonus (once again)

Cannot sidechains move to a bridge design that uses BitVM, so that it becomes more secure?

Bonus: sidechains with BitVM bridge

They can. In fact, peg will indeed be more secure. Sidechains can adopt BitVM bridges to reduce the peg risk. However, considering all of the above, there’s still one important point:

The existing execution/consensus of the sidechain will still be depending on the validator committee.

So if today’s sidechains migrate to a BitVM based bridge, on the positive side one surface of risk gets eliminated. On the other hand, the other point of failure stays the same, unless consensus changes with a sidechain hard fork, which leads us to the following tweet.

janusz tapping the sign


Have a nice week and see you on the next one!