Bitcoin Rollups – The Rock or The Hard Place?

Rollups have become the narrative centerpiece of Bitcoin’s recent escalation, becoming the first thing to really “steal the spotlight” from the Lightning Network in terms of wider mindshare. Rollups aim to be an off-chain layer two that is not bound or constrained by the liquidity limitations that are central to the Lightning Network, i.e. end users have requested that someone allocate (or “lend”) them funds up front to be able to receive money or intermediate routing nodes that require channel balances that can facilitate the movement of payment amount from sender to recipient.

These systems were originally developed to run on Ethereum and other Turing complete systems, but lately the focus has shifted to porting them to UTXO-based blockchains like Bitcoin. This article will not discuss the current state of things implemented on Bitcoin today, but will discuss the function of an idealized rollup that people are looking for in the long term, based on features that Bitcoin does not currently support, namely the ability to to verify Zero Knowledge Proofs (ZKPs) directly on Bitcoin.

The basic architecture of a role is as follows: a single account (or in the case of Bitcoin UTXO), holds the balances of all users in the bundle. This UTXO contains a commitment in the form of a merkle root of a merkle tree that commits to all current account balances in the bundle. All of these accounts are authorized using public/private key pairs, so to propose an off-chain spend, a user still needs to sign something with a key. This part of the structure allows users to leave without permission whenever they want, simply by making a transaction that proves their account is part of the merkle tree, they can unilaterally exit the rollup without the operator’s permission.

The rollup operator must include a ZKP in transactions that update the merkle root of on-chain account balances in the process of completing off-chain transactions, without this ZKP the transaction will be invalid and therefore cannot be included in the blockchain. This proof allows people to verify that all changes to off-chain accounts have been properly authorized by the account holder(s) and that the operator has not maliciously updated balances to steal money from users or to reallocate to other users dishonestly.

The problem is, if only the root of the merkle tree is posted on the chain where users can view and access it, how do they put their branch in the tree so they can exit without permission when they want?

Proper rollups

In a proper stack, information is entered directly into the blockchain every time new off-chain transactions are confirmed and the state of accumulated accounts changes. Not the whole tree, that would be absurd, but the information needed to reconstruct the tree. In a naive implementation, the summary of all existing accounts in the stack would have balances and accounts simply added in the package update transaction.

In more advanced implementations, a balance differential is used. This is essentially a summary of the accounts that have had money added or subtracted during an update. This allows each cumulative update to include only change to account for the balances that appear. Users can simply scan the chain and “do the math” from the beginning of the packet to arrive at the current state of the account balances, which allows them to reconstruct the merkle tree of the current balances.

This saves a lot of overhead and block space (and therefore money), while still allowing users to guarantee access to the information needed to exit unilaterally. The inclusion of this data in a formal package that uses the blockchain to make it available to users is mandated by the rules of the package, i.e. a transaction that does not include the account summary or account difference is considered an invalid transaction.

Validities

The other way to handle the issue of data availability for users to withdraw is to put the data somewhere other than the blockchain. This introduces subtle problems, the rollup still needs to enforce that the data has been made available elsewhere. Traditionally, other blockchains are used for this purpose, specifically designed to function as data availability layers for systems such as rollups.

This creates the dilemma of having security safeguards as strong. When data is posted directly to the Bitcoin blockchain, consensus rules can guarantee that it is correct with absolute certainty. However, when posted to an external system, the best it can do is verify an SPV proof that the data has been posted to another system.

This involves verifying an attestation that data exists on other chains, which is ultimately an oracle problem. The Bitcoin blockchain cannot verify anything completely except what happens on its own blockchain, the best can do is check a ZKP. However, a ZKP cannot verify that a block containing cumulative data has actually been publicly broadcast after it has been produced. It cannot verify that external information is actually publicly available to everyone.

This opens the door to data retention attacks, where a commitment to published data is created and used to advance the accumulation, but the data is not actually available. This gives users funds beyond their ability to withdraw. The only real solution to this is to depend entirely on the value structure and incentives of completely external Bitcoin systems.

The Rock and Hard Place

This creates a dilemma regarding rollups. When it comes to the issue of data availability, there is essentially a binary choice between posting the data to the Bitcoin blockchain or elsewhere. This choice has massive implications for both security and package sovereignty, as well as their scalability.

On the one hand, using the Bitcoin blockchain for the data availability layer introduces a hard cap on how much rollups can scale. There is only so much block space, and that puts an upper limit on how many packets can exist at once and how many transactions all cumulative packets can process in total outside the chain. Each cumulative update requires lock space proportional to the number of accounts that have had balance changes since the last update. Information theory only allows data to be compressed so much, and at that point there is no more potential for scaling gains.

On the other hand, using a different layer for data availability removes the hard cap on scalability gains, but also introduces new security and sovereignty issues. In a package that uses Bitcoin for data availability, it is literally impossible for the state of the package to change without the data required for users to withdraw being atomically posted to the blockchain. With Validiums, this guarantee is entirely dependent on the ability of any external system used to resist gaming and data retention.

Any block producer in the external data availability system is now able to hold Bitcoin packet user funds hostage by producing a block and not actually broadcasting it to make the data available.

So what will it be, if we ever get to an ideal Bitcoin aggregator implementation that actually allows users to withdraw unilaterally? The rock or the hard place?