Rollups have become the narrative focus of bitcoin’s scalability lately, becoming the first thing to truly “steal the thunder” from the Lightning Network in terms of increased mindshare. Rollups aim to be an off-chain layer two that is not limited or restricted by the liquidity constraints that are fundamental to the Lightning Network — i.e. end users requiring someone to allocate (or “lend”) them funds in advance in order to receive money, or intermediary routing nodes requiring channel balances that can facilitate the movement of the payment amount from sender to receiver.
These systems were originally developed to run on ethereum and other Turing-complete systems, but lately the focus has shifted towards porting them to UTXO-based blockchains like bitcoin. This article will not look at the current state of affairs as it is currently being implemented in bitcoin, but rather will look at the function of an idealized rollup that people aspire to in the long term based on features that bitcoin currently does not support, namely the ability to verify zero-knowledge proofs (ZKPs) in bitcoin directly.
The basic architecture of a rollup is as follows: a single account (or in the case of bitcoin, UTXO) contains the balances of all users in the rollup. This UTXO contains a commitment in the form of the merkle root of a merkle tree that commits to all current balances of existing accounts in the rollup. These accounts are all permissioned using public/private key pairs, so in order to propose an off-chain spend, a user must still sign something with a key. This part of the structure allows users to permission-exit whenever they want — by simply creating a transaction proving 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 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 all changes to off-chain accounts were correctly authorized by the account holder, and that the operator has not maliciously updated balances to steal money from users or reallocate it to other users in a dishonest manner.
The problem is that if only the root of the Merkle tree is published on the chain where users can see and access it, how do they manage to place their branch on the tree so they can leave without permission whenever they want?
Suitable rollups
In a proper rollup, information is fed directly into the blockchain whenever new off-chain transactions are confirmed and the state of the accounts in the rollup 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 rollup would have balances and accounts simply added in the transaction updating the rollup.
In more advanced implementations, a balance difference is used. This is essentially a summary of the accounts that have had money added or subtracted during the course of an update. This allows each accrual update to only include the balance. changes Users can then simply scan the chain and “do the math” from the beginning of the backlog to arrive at the current state of account balances, allowing them to reconstruct the Merkle tree of current balances.
This saves a lot of overhead and block space (and therefore money), while allowing users to ensure access to the information needed to unilaterally exit. Including this data in a formal summary that the blockchain uses to make it available to users is mandated by the summary rules, i.e. a transaction that does not include the account summary or account difference is considered an invalid transaction.
Validios
The other way to handle the problem of data availability for users to rollup is to put the data somewhere other than the blockchain. This presents subtle issues, but the rollup still needs to ensure that the data was made available somewhere else. Traditionally, other blockchains are used for this purpose, specifically designed to function as data availability layers for systems like rollups.
This raises the dilemma of whether security guarantees are as strong as before. When data is published directly to the bitcoin blockchain, consensus rules can ensure that it is correct with absolute certainty. However, when it is published to an external system, the best you can do is verify an SPV proof that the data was published to another system.
This involves verifying an attestation that the data exists on other chains, which is ultimately an oracle problem. The bitcoin blockchain cannot fully verify anything except what happens on its own blockchain, the better The only thing a ZKP can do is verify. However, a ZKP cannot verify that a block containing backlog data was publicly disseminated after it was 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 publishing data is created and used to advance accumulation, but the data is not actually made available. This leaves users’ funds outside of their ability to withdraw. The only real solution to this is to rely entirely on the value and incentive structure of systems completely external to bitcoin.
On the horns of a dilemma
This creates a dilemma in terms of rollups. When it comes to the issue of data availability, there is essentially a binary choice between publishing the data on the bitcoin blockchain or somewhere else. This choice has huge implications for both the security and sovereignty of rollups, as well as their scalability.
For one, using the bitcoin blockchain for the data availability layer introduces a hard limit to the scalability of rollups. There is only a certain amount of block space, and that imposes an upper limit on the number of rollups that can exist at once and the number of transactions that all the rollups together can process. off the chainEach cumulative update requires block space proportional to the number of accounts that have had balance changes since the last update. Information theory only allows data to be compressed up to a certain point, and at that point there is no longer any potential for scaling gains.
On the other hand, using a different layer for data availability removes the upper limit on scalability gains, but also introduces new security and sovereignty issues. In a rollup that uses bitcoin for data availability, it is literally not possible for the state of the rollup to change without the data that users need to withdraw being atomically published to the blockchain. With Validiums, that guarantee is entirely dependent on the ability of the external system being used to resist data tampering and retention.
Any block producer in the external data availability system can now hold bitcoin rollup users' funds hostage by producing a block and not broadcasting it to make the data available.
So what will be the situation if we ever manage to implement an ideal rollup implementation in bitcoin that actually allows unilateral withdrawal by users? The rock or the stone?
