Validiums, volitions, and superstitions. Bitcoin L2s aren’t real, but rollups will be

This is a post that outlines how rollups work on bitcoin without a soft fork.

Tl;dr

• Rollups on bitcoin is an incredibly new design space and there are many misconceptions regarding them
• Rollups are blockchains that use a parent blockchain for data availability
• Validiums are not real. They are blockchains that are rollups to other blockchains (this doesn’t mean they’re bad!)
• Rollup finalization is not dependent on validating bridges custodying L1 assets. What users consider final is subjective
• The majority of rollup users on bitcoin will not interact with validating bridges custodying L1 assets. They have additional trust assumptions outside the bridge
• The most secure L1 asset bridge is not always the most popular one 
• L1 settlement is a meme
• Some proposed opcodes make rollups better, but rollups can be built today
• There are not “100 bitcoin rollups”

Thank you to Trey Del Bonis, Veronika Kütt, Mark Odayan, Jesse R., John Light, Orkun Kilic, Adrien Lacombe, and Preston Evans for discussions on bitcoin rollups recently. The opinions listed in this blog, and any mistakes, are my own.

This blog started out as a passionate defense of rollups, but over the course of drafting the post, I quickly realized I believed some misconceptions about rollups. It actually was a cool post to work through and it helped me gain a better understanding of the space. I hope it helps readers as well. I think some of the concepts in this post may be off a tad, but generally I feel it’s correct. If something is glaringly wrong, just let me know on twitter and I’ll update if I agree. I think the idea that “rollups rely on a soft fork” is the thing I want to rebut against. I also want to really clarify that rollups do not have trustless bridges on bitcoin. While some really cool designs are being shaped up, the users who deposit funds via (even the most) trust-minimized bridge designs in bitcoin trust bridge operators to process withdrawals to exit and honest verifiers to maintain the peg’s security. While I might come off as “critical” in this post, if I wasn’t writing about rollups on bitcoin, I’d probably try to convince Alpen or Citrea to give me a job. I still think they’re cool.

I’m also aware I’m repeating a lot of the arguments made by a few people in Ethereum last year. I’ve just seen some of these statements (e.g. bitcoin is a settlement layer) in bitcoin, and decided it’s worth pushing back against.

If you don’t want to read the whole blog, I’ll quickly describe what rollups are. Bitcoin rollups are blockchains that use bitcoin for ordering and consensus. They are able to fully derive their chain and state from Bitcoin block history. They do this via submitting compressed batches of transactions to bitcoin via inscription-like envelopes. This sees the rollup use bitcoin for data availability. A rollup operator is usually responsible for ordering the transactions and submitting these batches. After this batch has been published to bitcoin, bitcoin full nodes will make the data available to rollup nodes. Rollup nodes will scan bitcoin, find the relevant batches, and apply the state transition function over this data and compute a new state root. For rollup nodes, rollup transactions are now settled. Once the new state root is computed, a prover will take this state root and publish it to bitcoin (possibly with a validity proof attesting to valid execution). For light clients, rollup transactions are now settled. Designs can vary from this, but this is basically how it works.

Rollups benefit from bitcoin because they do not have to bootstrap their own consensus set. Rollups may also have a bridge with bitcoin, but this is not a requirement. This bridge can be a single custodian, an honest majority federation, a variant of BitVM, or something else. BitVM bridges are synonymous with rollups (although I feel this is incorrect). A BitVM bridge consists of a federation of operators that manage peg-ins and peg-outs from the sidesystem. Spending paths in and out of the bridge contract are fixed and only spendable by the operators to themselves. It also has a group of verifiers who are able to challenge operators in the event that the operator attempts to commit fraud. Operators, along with verifiers, commit to executing a SNARK verifier and bitcoin light client offchain to process valid withdrawals from the rollup bridge based on the rollup’s state commitments posted to the L1. When a user withdraws, they submit a burn transaction on the rollup and a withdrawal request to the operator. An operator finds this request, fulfills it by fronting the liquidity for the withdrawal (presumably in exchange for a fee), and sends the funds to the user. After this is processed, the operator will request a reimbursement from the bridge program. If honest, the request is processed. If dishonest, a verifier will be able to challenge the request by forcing the operator to reveal intermediary results of the committed-to program onchain and within the 4MB block size limit. After this, a challenge response game plays out. If the operator’s results do not align with the rollup’s state commitment, then the operator loses the challenge.

When you think of the main bitcoin rollups, this is basically how they work in theory. In practice, we might see a lot of variation and different user patterns. Let’s break it down.

Rollups aren’t real (yet)

The new wave of EVM chains promising “smart contracts on bitcoin” usually lack substance. Some say the gold rush is simply due to being early. The cynics say it’s all a scam.

The controversial “Bitcoin L2” design space is often (and I think incorrectly) associated with “rollups”. This is because rollups are a popular scaling solution in other ecosystems like Ethereum. And most “bitcoin L2” projects are simply deploying forks of Ethereum rollup stacks, or other EVM-compatible blockchain frameworks, to launch their bitcoin “L2”.

So now we have this weird association between bitcoin L2s, custodial bridges, and rollups. It’s all kind of confusing, and I get why people conflate all of these things into one group.

We can do rollups today. Don’t let them tell you otherwise!

Why we’re defining all of this

Simply put, rollups on bitcoin can exist today. They do not need a soft fork, and I feel it’s useful to define what a rollup actually is, and how it can be constructed.

This isn’t meant to change your mind on how we should define bitcoin L2s and sidesystems. I also think that some rollup teams are defining their systems incorrectly, so I’ll point out some disagreements I may have with those building sidechains, rollups, or “validium-style” blockchains.

All of these systems, including rollups and other systems that rely on bitcoin for some form of security, are sovereign blockchains that are not defined by their “official” bitcoin bridge. They are not bitcoin L2s, and even in the event they build bridges that facilitate unilateral exit (meaning users can exit the system with their own bitcoin L1 transaction), their existence as a bitcoin L2 is determined by which asset a user holds on the rollup chain.

Initial definitions

Before we start, we need to define some terms for the blog. I’m borrowing definitions from the Bitcoin Layers’ glossary:

• Blockchain: A system where nodes hold a local copy of the state and come to consensus on a new state after applying a state transition function. Basically a big machine where individual nodes agree on some state of the world.
• State transition function: A mechanism where the blockchain’s current state adds an input and generates the new state. This advances the blockchain’s state.
• Data availability: The act of making recently published transaction data available so nodes can verify transactions, satisfy proving schemes, or otherwise progress the chain. (I'll sometimes refer to this as DA)
• Network operators: The party or parties responsible for proposing blocks and state transitions for the blockchain.

More definitions will be outlined in the blog, but these are the core, general ones. Now, let’s define some blockchains.

What are rollups

Rollups are blockchains that post the latest state root, and enough transaction data to reconstruct the latest state of the block from genesis, to a parent blockchain. Essentially, they are sidechains that rely on a parent blockchain for consensus and finality of transaction ordering. 

How this works: rollup operators publish batches of transactions from their blockchain to a parent blockchain, parent blockchain nodes make this data available to rollup nodes, rollup nodes scan the parent blockchain for these transactions, find them, run some code over it, and generate a new state. They do this over and over again until the end of time.

^ This is really it. ^

Before we go full-semantics mode, let’s quickly cover why we’re all getting nerd-sniped by this stuff in the first place.

Why do we want rollups?

Rollups can be extensions of bitcoin and provide new functionality for BTC the asset if they have a bridge between bitcoin and the rollup. They also contribute directly to the security budget.

Since rollups only post a summary of transactions to bitcoin, they can compress the amount of data that is needed to be posted onto bitcoin. This offers an increase in throughput via transactions that happen offchain.

Rollups can offer different execution environments from Script. This means they could possibly create more expressive smart contracts and offer different types of applications than what’s available on bitcoin.

Projects may want to build rollups because they don’t have to bootstrap their own consensus mechanism. They also may want to build a rollup to inherit consensus from bitcoin, which can provide some additional security benefits for bitcoin-backed assets.

Are they more secure than sidechains?

I thought about taking this section out because it’s a load of “it depends”, so take it with a grain of salt.

It depends. Rollups rely on bitcoin for ordering and consensus. Sidechains also rely on an additional consensus set for these guarantees But, in the context of bridges, rollups still may provide better security (in theory). Let’s define what a “trust-minimized” bridge should be:

“Trust-minimization” should be defined as composability is trust-minimized if an unbounded 1-of-N honesty, or a weaker assumption, is required for safety. I borrowed this definition from this conference talk.

This means users continue to take on the trust assumptions of bitcoin and additionally take on the trust assumptions of a trust-minimized bridge secured by validity proofs or permissionless fraud proofs. Any bridge operated by a custodian or any style federation is disqualified.

For sidechains, even if the bridge had a mechanism to verify offchain state transitions on bitcoin (e.g. an onchain contract executes a bitcoin light client & sidechain light client), it cannot meet this definition because a dishonest majority of sidechain validators could convince the bridge to execute a malicious peg-out from the bridge. If the sidechain was Proof-of-Work (or merge-mined), 51%, or more, of the hashrate could create a private fork and convince the bridge to execute a malicious peg-out. This is because the bridge would follow the chain with the most accumulative proof-of-work or stake.

Rollups can meet this definition if the parent blockchain enables the onchain verification of L2 state transitions and if there is a valid proof system securing the bridge contract. Since rollup nodes update the state of the chain based on data from the L1, rollup nodes are able to see that invalid state transitions were proposed by the sequencer. In a fraud proof scheme, these nodes would be able to submit a challenge onchain if a fraudulent state root was posted to the bridge. In a validity proof scheme, the bridge would need a validity proof of proving rollup finalization (e.g. settlement) and the latest state root to process withdrawals. A malicious sequencer cannot generate, or provide, an invalid validity proof.

Still, the bridges and trust-minimized security are not requirements to be a rollup!

I'm unsure if any proposed bridge design meets this definition of trust-minimized. It'll always be an ongoing debate of how to define this and people will likely never agree on the term. Again, take the above section with a grain of salt.

Onchain data availability is good for security (and the security budget)

The reason a rollup can meet this definition is due to the fact that it inherits consensus from bitcoin. If the bridge (an onchain contract) is immutable and can verify validity proofs, or challenge invalid state roots from the sequencer, then it qualifies as a trust-minimized chain per our previous definition. This is because users trust bitcoin and at most a 1-of-N trust assumption.

Users can also bypass sequencers (if the rollup architecture enables this) trustlessly if the data is made available on bitcoin. If the rollup operator went down and stopped producing blocks, a user, in theory, could be able to recreate the state of the rollup based on the data made available via bitcoin full nodes, run their own L2 full node, and self-propose a state transition to force a bridge withdrawal to the bridge operators or bridge smart contracts. This is another unique advantage that rollups have over other blockchain designs (sidechains, validiums, etc.)

There's some arguments against that forced inclusion and self-proposing state transitions is not really that viable in practice. I don't have an opinion yet. Here's a piece that covers limitations here.

So posting this data onto bitcoin is a long-term net positive for users and bitcoin miners. These transactions are typically larger in size, and thus have higher fees associated with them. Rollups can contribute to the security budget and provide incentives for miners after new coin issuance within the block reward is nearing zero. Since rollups depend on this data being made available by bitcoin, it is a necessary part of their settlement. It also can provide some advantages to users wanting to exit the rollup.

You might be thinking, “oh, well this is sounding great.” 

Well stop 🙂 Forget everything I just said. Block out the rollup cartel and ignore any bias towards them. These people will take you down a road of nerd-sniping and introduce you to fancy terms that are meant to confuse you.

I’m going to cover how bitcoin rollups actually work.

How *proposed* rollups on bitcoin work

Proposed bitcoin rollups post transaction batches, and maybe with corresponding validity proofs stating that these batches were executed correctly, to bitcoin as inscriptions-like envelopes. Rollups use bitcoin as a data availability layer.Posting this data, and being able to reconstruct the state of the rollup based from this data, which is made available by bitcoin full nodes, is what makes a blockchain a bitcoin rollup. In a rollup blockchain, there are a few different roles.

Sequencers (and proposers)

A sequencer is the role that builds rollup blocks. A proposer is the role that posts the latest rollup state root to the parent blockchain. These roles can be combined via one central node, two different parties, or a decentralized network of nodes participating in a consensus protocol. For the sake of simplicity, we will describe them as one party in this blog.

Rollups typically have a centralized block producer (the sequencer) that constructs rollup blocks. Sequencers typically produce blocks every other second, providing users with soft confirmations. Soft confirmations (also known as preconfirmations) are promises that the users’ transactions will ultimately be finalized on the bitcoin blockchain.

The rollup sequencer will then submit a summary of these transactions to the parent blockchain. How often the rollup does this is entirely dependent on its design. It can do this every 10 minutes, every hour, every day, etc.

Rollup users trust that the sequencer eventually posts this data to the parent blockchain so the rollup nodes can apply the STF and generate a new state root. If the sequencer doesn’t post this data, and a new state root is not computed (and posted onto bitcoin), the sequencer can reorg the rollup.

It’s argued centralized rollup sequencers have a business incentive to process transactions and not reorg. If they started breaking these pinky promises, users might leave (or avoid) the rollup due to the sequencer’s poor reputation.

Transactions for rollups are not final until the data has been posted to bitcoin and a new state has been generated. But, a lot of users trust soft confirmations for faster finality.

A rollup sequencer can double-spend users, similar to Ark, Statechains, et al., prior to a transaction summary being posted, and accepted, onto bitcoin. Bitcoiners can think of a sequencer as a “Rollup Service Provider”.

Rollup sequencers can also be decentralized through a federation of operators or an alternative consensus network. Some decentralized sequencer protocols are on mainnet today.

Rollup Transaction lifecycle

Below we quickly describe the rollup transaction lifecycle:

• Alice submits a transaction to the rollup network
• The sequencer scans submitted transactions, sees Alice’s transaction, and then includes the transaction in a rollup block
• The sequencer will publish the block (or a batch of N number of blocks) onto the Bitcoin blockchain. Full nodes accept this transaction and now the rollup’s latest batch can be made available by bitcoin full nodes
• Rollup full nodes scan the bitcoin blockchain, identify inscriptions relevant to the rollup’s state transition, apply the state transition function to the data that’s been made available, and then compute the rollup’s new state root. From the perspective of rollup full nodes, transactions are settled and finalized

Every N number of rollup batches, a prover will create a validity proof attesting to the summary of the rollup’s state changes and post it, along with the new state root, to bitcoin. Light clients can now consider the rollup state finalized

Rollups can design their finality mechanism in a variety of ways. For example, the rollup sequencer could deliver the transaction batch to the proposer offchain, and the proposer could publish a new state root with state differentials onchain.

But… the validating bridge?

Interactions with a bridge can be additionally introduced to support withdrawals for bridged L1 assets. But, it is not required for a blockchain to be a rollup.

A bridge is a program that convinces a blockchain of the state of another blockchain. In the case of the rollup, it tells a rollup smart contract to mint and burn BTC-backed tokens on the rollup. Related to bitcoin, the program needs to convince the bitcoin bridge to release funds to users, on bitcoin, based on the current state of the rollup. We use the bridge to mint and burn bitcoin-backed assets on the rollup.

Bitcoin script is not expressive enough to verify rollup state transitions directly in an onchain smart contract. Therefore, we need to do some neat tricks to work around this.

So most bitcoin rollups today are building BitVM-style bridges to accompany their rollup design. This is basically how they work:

• A bunch of people come together in an n-of-n multisig to emulate a covenant. Spending paths in and out of the multisig are predetermined. We do this because we can’t do covenants (:sad:)
• Operators join the multisig. They commit to running a program (SNARK verifier & bitcoin light client) offchain. They process deposits and withdrawals, of fixed amounts, presumably in exchange for a fee based on the results of this program
• When a user requests a withdrawal, an operator fronts the liquidity to the user. They then request a reimbursement from the bridge
• If all is well, request is processed and operator is reimbursed
• If the bridge operator submits a dishonest reimbursement request (e.g. a peg-out did not align with the updated state of the rollup) a verifier can challenge them by submitting a fault proof. This fault proof forces the operator to reveal the intermediary results of the committed-to program (the bitcoin light client) onchain
• A challenge response game is played out over a series of bitcoin transactions. If the fault proof is valid, the challenge-response game will eventually result in the bridge operator's reimbursement not being processed and the fraudulent bridge operator being slashed (or simply kicked out of the bridge program)

The proposed bridge designs will see a federation of operators manage peg-outs and a wider set of users act as verifiers to ensure the integrity of the bridge. The trust assumption is a 1-of-N assumption of the federation related to liveness. Its 1-of-N trust assumption related to security is any online user who is able to submit a fault proof.

A user, Alice, would likely never even interact with a bridge in this context. This is because deposits and withdrawals are fixed, and will likely be large amounts. The bridge will likely only be used by service providers (e.g. LPs and market makers) and users will onboard to the rollup via atomic swaps.

And since rollup users are unlikely to interact with the bridge, their trust assumptions, related to the bridge, are simply:

• the BTC issued on the rollup is always backed by BTC on the L1 (secured by a 1-N trust assumption) so…
• the rollup BTC is worth something and an atomic swap provider will facilitate an exchange of rollup BTC for L1 BTC and…
• the transaction(s) containing the swaps are finalized on bitcoin, enabling the user to exit the rollup

Users who do not have the exact denomination of BTC supported by the bridge must use a third party service or bridge to withdraw funds.

People put so much emphasis on the bridge because it's how you get BTC onto the rollup system, thus making it a “bitcoin layer” or “layer 2”. That’s why teams want to make this bridge really secure.

But you could simply swap an honest-majority federation for a BitVM Bridge, the rollup transaction lifecycle and state transition function would not change. A closed federation would simply replace the BitVM Bridge in facilitating deposits and withdrawals from the rollup.

Even more extremely, if the bridge breaks, and assets on the rollup become undercollateralized, it does not break the rollup. The rollup could function as normal, and users could even interact with previously L1-backed assets. Bridges don’t move funds over, they simply lock funds in an onchain contract to back assets on a corresponding chain. BTC doesn’t leave bitcoin.

So yes, previously bitcoin-backed tokens can still be transferred on a rollup if all of the bitcoin locked on a corresponding contract is gone. Yes, this is bad. But it doesn’t break the rollup.

Thus, to build a rollup on bitcoin, all that is needed is a mechanism to apply a state transition function over data that is posted to, and made available, by bitcoin full nodes. Rollups can exist on bitcoin today and do not need a soft fork. They can have a bridge to bitcoin. This bridge can be a single custodian, a federation, some threshold signature mechanism, or BitVM-based. The bridge does not define the rollup.

Offchain data availability

Bitcoin is limited in its throughput, potentially causing it to be an expensive data availability layer in the future. A number of rollup teams have noted this as a potential problem, and have stated that they will likely integrate with alternative data availability solutions to lower costs.

Our chart below outlines potential DA costs associated with rollups on bitcoin.

If a protocol uses an alternative data availability layer, users then take on a trust assumption that another set of signers/full nodes/validators, in an alternative system, will make the data available for the period of time that they need it. This means that the blockchain no longer inherits consensus from bitcoin.

What are validiums (and optimiums)

Protocols that use an offchain DA system, and have an official bridge program, are known as validiums or optimiums. In a validium, the bridge is secured by a sequencer posting the latest state root and a valid proof of execution (validity proof) to an L1 verifier contract. In an optimium, the sequencer posts the latest state root and relies on a challenger to submit a fraud proof if the state root is fraudulent.

A number of projects are planning on building such a system for bitcoin assets due to the potential high DA costs of bitcoin DA.

Here is a bitcoin validium’s transaction lifecycle:

• Alice submits a transaction to the validium network
• The sequencer scans submitted transactions, sees Alice’s transaction, and then includes the transaction in a validium block
• The sequencer will publish the block (or a batch of N number of blocks) onto the data availability layer. Validators accept these transactions and finalize them on the DA layer
• Validium full nodes scan the DA layer, identify transactions relevant to the validium’s state transition, apply the STF to the data that’s been made available, and then compute the validium’s new state root. From the perspective of validium full nodes, transactions are settled
• Every N number of validium batches, the prover will create a validity proof attesting to the summary of the validium’s state changes and, and post it, along with the new state root, to bitcoin. Light clients can now consider the validium state finalized

The finalization of a state transition for a rollup and validium are basically the same. The finalization of the bridge program relies on a validity proof and a state root being posted to bitcoin. The difference is that one chain is a rollup to bitcoin, and the other is not. Validiums are rollups to their respective DA layer.

Validiums are rollups to other chains

But, as stated previously by Jon Charbonneau, validiums aren’t really real! They’re just rollups to another chain, where a bridge contract/program has a view into the rollup. Social consensus is what arguably makes it a “bitcoin validium” versus a sovereign rollup to another chain.

And they might not even be rollups to other blockchains. The validium might leverage a data availability committee, where a small committee (for example, ⅗ multisig) is responsible for attesting to the fact that the data is indeed available. But I digress.

The security, and consensus, of the chain relies on the security of the data availability layer. If a data availability layer is backed by economic security greater than that of the TVL locked in a rollup bridge, then its operators are disincentivized to withhold data and try to steal funds from the sidechain bridge.

We will now refer to validiums and optimiums as "validiums" and "optimiums" 😄

Data withholding attacks and a misbehaving sequencer

DA layers (or committees) might be incentivized to steal from bridge programs if there’s a sizable amount of funds locked in them.

For those who use use fraud proof schemes ("optimiums") to secure a specific bridge contract, it unfolds as:

• A sequencer posts a fraudulent state root to the bridge contract, proposing a state transition that sees it drain the bridge and steal everyone’s funds
• The data availability committee withholds the data from prospective challengers, leaving them unable to create a fraud proof
• The challenge period passes, allowing the sequencer to steal all the money

Theft is not possible with a "validium" as the L1 bridge contract requires a validity proof, and a valid state root, to be verified to permit withdrawals. The sequencer (prover, really) cannot produce a validity proof with a fraudulent state root. Any fraudulent data they post to the L1 bridge contract would be rejected. The worst case scenario here is that the sequencer and data availability committee misbehave, freeze the chain and withdrawals, and request a ransom.

BitVM bridges are a bit different from both of these models. Let’s cover how this attack might play out there:

• A sequencer could post a fraudulent state root to the bridge, proposing a state transition that sees it drain the bridge and steal everyone’s funds. It submits this to the bridge operators as a withdrawal request
• The data availability committee withholds the data
• Upon receiving the request, the BitVM bridge operator must front all the liquidity to drain the bridge contract and then request a reimbursement. It is unlikely that an operator would acknowledge this withdrawal request, but even if they did and fronted the withdrawal from their own balance, no validity proof attesting to this state has been posted onto bitcoin (because it can’t be).
• A challenger (because they are also running the bridge program offchain) challenge the invalid reimbursement request and force the operator to reveal a intermediary results of the program onchain. Since these results would reveal a conflicting state related to the malicious withdrawal attempt, the operator would lose the dispute.

As long as there is one honest, and capable, challenger they can challenge the operator’s reimbursement request. This attack likely fails in the BitVM context in the context of theft. However, if the DA layer withheld data, the rollup’s state could not progress for rollup nodes and light clients. Thus, as mentioned, "validium" users could be held at ransom.

Thus, pure "optimiums" have security similar to that of a sidechain. The data availability layer and sequencer can collude to make data unavailable. This is similar to the majority of a sidechain operator set creating a malicious fork and convincing the bridge program that a malicious withdrawal is indeed a valid one.

"Validiums" have improved security. because withdrawals from the bridge contract rely on a valid validity proof being posted to a verifier contract to process withdrawals. Sequencers (and provers) are unable to produce invalid validity proofs.

BitVM-based bridges somewhat avoid this because the operator, attesting to the invalid state root, could be challenged because verifiers are running the full bridge program, including the SNARK verifier, offchain. If the operator attests to an invalid state root, they can be challenged and forced to reveal their incorrect assertion onchain.

Care for a volition, my dear?

A hybrid between these two designs is the volition model. A volition is basically a blend between a rollup and a "validium" where a user (or an application) chooses where they post their data. If a user values the security of bitcoin DA, they’ll pay higher transaction fees to post their data there.

Users should be able to update their DA preferences in this model. Maybe I want to upgrade to bitcoin and get more security. This could be done by splitting the implementation of the chain into two state branches. A user posts all their data to the alternative DA layer and wants to switch to bitcoin? They submit a transfer to move the funds to a new account on the bitcoin DA branch.

We have different sets of account balances on the blockchain that need to be updated. A user can atomically update their balance (transfer) to the other state tree because the two state trees’ state transitions are proposed by the same sequencer. The state transition proof that is produced for these state trees contains the same state root.

Alice is using a “validium”, Bob is using a bitcoin rollup, the rollup is the same blockchain, and the state root is the same across all instances. The user relationship with the blockchain is different depending on the security model (DA) they choose. It being a “volition” is because the users of the blockchain all view the official bridge implementation as the ultimate source of truth. 

The beauty of the volition model is that users of varying security can interact with the same bridge, with the same trust assumptions, access the same liquidity, and choose their own security. Still, this does not mean that the user has “volition-level” security. Their security is per the data availability layer they use and the official bridge they view as the source of truth. If they have some assets on one state branch, and others on its counterpart, then the security is not defined at the user level. It’s defined at the asset level.

For what it’s worth, I don't think there aren’t any volitions in production.

They’re going to nerd snipe you with bridges… not *rollups*

The terms validity rollup, optimistic rollup, "validium", and "optimum" aren’t actually describing the rollup. They’re describing the bridges.

Optimistic rollups have bridges secured by fraud proofs. Validity rollups by validity proofs. "Optimiums" and "validiums" are simply rollups to other data availability layers that have a bridge on another chain secured by a specific proof scheme. Bitcoin rollups might have BitVM bridges. They might use something else.

Does that mean the rollup is a “BitVM rollup” or a “federation rollup” or a “third party bridge rollup”? 

No, it’s just a rollup with a bitcoin bridge.

So it’s completely asset based…

Also, who’s to say that BitGo won’t natively mint wBTC on a rollup protocol in the future? If a user leverages wBTC, instead of rollup BTC, then their “settlement” assurances are ultimately granted by BitGo, a centralized custodian, not one of the official bridge programs.

And what if wBTC is the most used asset on said bitcoin rollup? Even if the rollup has a BitVM bridge? Is the rollup now a “wBTC rollup”?

Again, no. It’s simply a bitcoin rollup with different bridges providing different security assurances for the L1 assets backing the bitcoin-backed tokens on the rollup.

Got one bridge? Nah fam, make it two

Let’s muddy the water even further. What if we want “hybrid settlement” through two validating bridges?

Take an ethereum rollup with an ethereum smart contract bridge and a bitvm bridge. It is a rollup on Ethereum, but it wants to be a hybrid L2 “settling” to both Ethereum and bitcoin. It has a smart contract bridge on Ethereum for ETH assets and has a BitVM bridge on bitcoin for BTC assets. It uses Ethereum for data availability. Is it an Ethereum rollup or a bitcoin "validium"?

Like any blockchain, there is a full node software for this ethereum rollup. There are (or can be) a group of nodes that scan the data from the data availability layer, agree on the proposed state transition, and come to settlement prior to the sequencer publishing the latest state root to the Ethereum validating bridge and a state root + validity proof to the BitVM bridge on bitcoin.

Bridge finality is usually seven days on Ethereum optimistic rollups due to the challenge window for fraud proofs. Most users don’t withdraw from the BitVM bridge, but let’s say the challenge window is the same for sake of simplicity. Rollup nodes settle every time they apply the STF of the data that has been posted to Ethereum.

What considers the rollup state final? Is it the Ethereum bridge or bitcoin bridge?

It depends! The settlement for tokens on the rollup blockchain is determined by rollup full nodes. The finalization for L1 assets backing a number of L2 tokens (like wrapped bitcoin tokens) is subject to each bridge receiving a state root and having a valid proving system in place to validate it.

This example has an Ethereum rollup with a bitcoin bridge, but you could easily swap the definitions around. You could have a bitcoin rollup with a “validating bridge” on Ethereum and get the type of answer and result.

“Settlement” is just finalization for assets and bridges. The chain can even have two different bitcoin bridges with different security properties, meaning that finalization for the assets locked on L1 is different per the bridge.

Bitcoin isn’t a settlement layer. Bitcoin bridges simply provide security guarantees and “settlement” guarantees pertaining to withdrawals.

For more on wtf settlement actually is, see this blog “wtf is settlement” from the Bedlam team.

What if the bridge breaks?

A common rebuttal here is that if a bitcoin rollup launches with the most secure bridge, has that bridge attract 95% of the TVL of the rollup, the bridge defines the rollup. Especially if the rollup’s gas token is backed by assets locked in the bridge.

If the bridge breaks, then this is obviously bad. Rollup assets would become undercollateralized, users would lose money, the reputation of the rollup would tank, and the future of the project would probably be in jeopardy.

But the rollup would still work. The state transition function would still work. The previously backed tokens would still be able to be transferred and used to pay fees to the sequencer. A user could still reconstruct the state of the rollup from the data posted to bitcoin. 

And the collapse would be isolated to the official bridge with the majority of the TVL. Users of a different bridge, that was backing another bitcoin asset on the rollup, would be able to withdraw their funds back to the L1.

Bridges breaking is the absolute worst thing that could happen here. That’s why teams are working on BitVM2 and/or proposing soft forks.

Rollups = rollups today. Rollups (can) = L2s tomorrow

Rollups can exist on bitcoin today. They do not require a soft fork.

But, bitcoin rollups (and "validiums") are not L2s because users who deposit funds into the rollup trust bridge operators to process withdrawals. 

Operators in BitVM bridges can not be challenged for liveness. They can only be challenged for processing a fraudulent withdrawal while requesting the reimbursement from the bridge. The assumption is that 1-of-N operators in the bridge will process a withdrawal request, and that 1-of-N verifiers will remain honest and protect the security of the bridge.

So a user wanting to peg out cannot unilaterally force a withdrawal. If all bridge operators go offline, a user can not recover their funds. And as mentioned above, a user with funds below, or between, a certain peg out amount, cannot withdraw all of their funds from the bridge either. 

Still, for a sidechain-like system, rollups are the closest thing to an L2. In order to propose an exit, a user needs to have the ability to do two things:

1. Access to the sidesystem transaction data (and latest state root) pertaining to their bitcoin assets. This access is provided by the user’s bitcoin full node.
2. The ability to propose their own state transition and submit a withdrawal request to operators of a bridge in the event that the sequencer/proposer is faulty or censoring

Rollups can provide this. Whether they immediately provide this in their design is completely up to the implementation.

And if new opcodes are added to allow Bitcoin to more efficiently verify validity proofs, then rollups have a path towards becoming L2s.

Note that there is research ongoing to support rotation of operators in the setup, potentially creating a scenario where a new operator could enter the set and process censored withdrawals.

Summary

Funny enough, rollups are the reason I became interested in bitcoin. My first work in the bitcoin ecosystem was building a community website that attempted to explain how rollups worked. So, if there's any bias in this post, attribute it to that.

Looking back on it, I was wrong about a few things. And throughout building Bitcoin Layers, I’ve seen claims related to rollups that are incorrect. So to sum it up…

There are no rollups on bitcoin today. To my knowledge, only three to four teams are building rollups on bitcoin. All other modular chains will be rollups to other chains and may have a bridge to bitcoin in place. I don’t know why people claim that there are 100 rollups on bitcoin. Maybe it’s because people think that claiming their chain is a rollup is good for marketing. But, unfortunately, it gets more people turned off from the idea.

Rollups are likely the most trust-minimized sidesystems being proposed in theory. In practice, they are hard to build and will likely have “training wheels” before becoming more trust-minimized.

Rollups on bitcoin do not provide unlimited scalability due to limited throughput on bitcoin. Other chains that use alternative data availability layers may have higher throughput and lower costs. 

BitVM bridges and rollups are sometimes synonymous because rollup teams are core contributors to BitVM bridges. BitVM bridges can be used for a number of different systems.

Proposed opcodes to bitcoin can make rollups more trust-minimized in theory. In practice, they may have some limitations.

Some of the teams building rollups are extremely talented. I want them to succeed to see if we can get more trust-minimized solutions that are aligned with bitcoin and contribute directly to the security budget.