Rollups have become the narrative focus of Bitcoin scaling lately, becoming the first to truly “steal the spotlight” from the Lightning Network in terms of broader mindshare. Rollups are intended to be an off-chain layer two that isn’t bound or limited by the liquidity constraints at the heart of the Lightning Network, i.e. end users require someone to allocate funds in advance (or ‘ borrow’) in order to receive money, or intermediate routing nodes that require channel balances that can facilitate the movement of the payment amount all the way from sender to receiver.
These systems were originally developed to function on Ethereum and other complete Turing systems, but recently the focus has shifted to porting them to UTXO-based blockchains such as Bitcoin. This article will not discuss the current state of affairs currently implemented on Bitcoin, but will discuss the feature of an idealized rollup that people are aiming for in the long run, depending on features that Bitcoin does not currently support, namely the ability to verify Zero Knowledge Proofs (ZKPs) directly on Bitcoin.
The basic architecture of a roll-up is as follows: a single account (or in the case of Bitcoin UTXO) contains the balances of all users in the roll-up. This UTXO contains a commitment in the form of a merkle root of a merkle tree that commits to all current balances of existing accounts in the rollup. All of these accounts are authorized using public/private key pairs, so proposing an off-chain release still requires a user to sign something with a key. This part of the structure allows users to leave whenever they want without permission. By simply making a transaction that proves their account is part of the merkle tree, they can unilaterally leave the pack without the operator’s permission.
The rollup operator must include a ZKP in transactions that update the merkle root of on-chain account balances during the process of finalizing 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 any 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 user funds or dishonestly transfer them to assign other users.
The problem is, if only the root of the merkle tree is put on the chain where users can view and access it, how do they get their branch into the tree so they can leave without permission whenever they want?
Proper rollups
In a proper rollup, the information is placed directly into the blockchain whenever new off-chain transactions are confirmed and the status of the rollup accounts changes. Not the entire 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 merge would include balances and accounts that are simply added in the transaction that updates the merge.
In more advanced implementations, a balance difference is used. This is essentially a summary of which accounts had money added or subtracted during an update. As a result, each update package can only use the changes to take into account the arising balances. Users can then simply scan the chain and ‘compute’ from the start of the merge to arrive at the current state of the account balances, allowing them to reconstruct the merkle tree of the current balances.
This saves a lot of overhead and block space (and therefore money), while still guaranteeing users access to the information needed for unilateral shutdown. Including this data in a formal merge that the blockchain uses to make it available to users is mandated by the merge’s rules, i.e. a transaction that does not include an account summary or account difference is considered an invalid transaction .
Validiums
The other way to address the issue of data availability to users is to place the data somewhere else besides the blockchain. This introduces subtle problems; the rollup must still enforce that the data has been made available elsewhere. Traditionally, other blockchains have been used for this purpose, specifically designed to function as data availability layers for systems such as rollups.
This creates the dilemma that the safety guarantees must be equally strong. When the data is posted directly onto the Bitcoin blockchain, consensus rules can guarantee that it is correct with absolute certainty. However, when posting to an external system, it is best to have an SPV verify that the data was posted to another system.
This involves verifying an attestation that data exists on other chains, which is ultimately an oracle problem. Bitcoin’s blockchain cannot fully verify anything except what happens on its own blockchain, the best all you can do is verify a ZKP. However, a ZKP cannot verify that a block of merge data was actually broadcast publicly after it was produced. It cannot verify that external information is actually publicly available to everyone.
This opens the door to data withholding attacks, where an obligation to publish the data is created and used to promote aggregation, but the data is not actually made available. This gives users money beyond their ability to withdraw. The only real solution to this is to be completely dependent on the value and incentive structure of systems completely outside of Bitcoin.
The rock and hard place
This creates a dilemma in terms of rollups. When it comes to the issue of data availability, there is essentially a binary choice between putting the data on the Bitcoin blockchain or somewhere else. This choice has enormous consequences for both its overall security and sovereignty, as well as its scalability.
On the one hand, using the Bitcoin blockchain for the data availability layer introduces a hard ceiling on how much rollups can scale. There is only a limited amount of block space, and that puts an upper limit on the number of rollups that can exist at once and the number of transactions that all rollups can process in total outside the chain. Each update requires a block space proportional to the number of accounts whose balances have changed since the last update. Information theory only allows for a limited amount of data compression, at which point there is no way to scale the gains.
On the other hand, using another layer for data availability removes the hard ceiling on scalability gains, but also introduces new security and sovereignty issues. In a package using Bitcoin for data availability, there is literally no way for the package’s state to change without the data users need to withdraw being atomically placed on the blockchain. With Validiums, that guarantee depends entirely on the ability of any external system used to withstand gaming and data withholding.
Any block producer on the third-party data availability system is now able to hold Bitcoin rollup users’ funds hostage by producing a block and not actually broadcasting it to make the data available.
So what will it be like if we ever get to an ideal rollup implementation on Bitcoin that actually allows for unilateral user withdrawal? The rock or the hard place?
