Bitcoin Rollups: Navigating the Data Dilemma and Security Risks

Rollups have recently become the center of attention in Bitcoin scaling discussions, overshadowing the Lightning Network in terms of wider awareness. Rollups are designed to be an off-chain layer two solution that isn’t limited by the liquidity challenges inherent to the Lightning Network. In other words, users need someone to allocate (or “lend”) funds in advance to receive money, or routing nodes require channel balances to facilitate the payment amount from sender to receiver.

Originally conceived for Ethereum and other Turing complete systems, the focus has now shifted towards adapting rollups for UTXO based blockchains like Bitcoin. This article won’t delve into the current implementations on Bitcoin; instead, it will explore the concept of an ideal rollup that developers aspire to create long-term, particularly regarding features that Bitcoin currently lacks, such as the ability to directly verify Zero Knowledge Proofs (ZKPs) on the Bitcoin network.

The basic structure of a rollup consists of a single account (or in Bitcoin’s case, a UTXO) that holds the balances of all users participating in the rollup. This UTXO serves as a commitment in the form of a Merkle root of a Merkle tree, committing to the current balances of all existing accounts in the rollup. All accounts are authorized through public/private key pairs, meaning that to propose an off-chain transaction, a user must sign it with their key. This structure allows users to exit freely whenever they choose; by constructing a transaction that proves their account is part of the Merkle tree, they can exit the rollup unilaterally without needing permission from the operator.

The rollup operator is responsible for including a ZKP in transactions that update the Merkle root of account balances on-chain as part of finalizing off-chain transactions. Without this ZKP, the transaction is deemed invalid and cannot be included in the blockchain. This proof enables users to confirm that all modifications to off-chain accounts were properly authorized by the respective account holders and ensures that the operator has not maliciously altered balances to misappropriate funds.

The challenge arises when only the root of the Merkle tree is posted on-chain. Users are left wondering how they can access their branch in the tree to exit without permission when they wish to do so.

Proper Rollups

In a proper rollup, relevant information is directly inserted into the blockchain every time new off-chain transactions are confirmed, triggering changes in the rollup accounts. Not the entire tree—this would be impractical—but rather the information necessary to reconstruct the tree. In a simplistic implementation, the summary of all accounts in the rollup would simply append balances and accounts in the transaction that updates the rollup.

More advanced implementations utilize a balance diff. This essentially summarizes which accounts have had funds added to or subtracted from them during the update. By doing so, each rollup update only requires the inclusion of the changes to account balances that transpired. This allows users to scan the blockchain and “do the math” from the inception of the rollup to reconstruct the present account balances.

This approach significantly reduces overhead and blockspace (and consequently costs) while ensuring that users can access the information needed for unilateral exits. The inclusion of this data in a formal rollup that utilizes the blockchain for user accessibility is mandated by the rollup’s rules; transactions that omit the account summary or account diff are regarded as invalid.

Validiums

Another solution to the issue of data availability for user withdrawals is to store the data outside of the blockchain. However, this introduces certain complexities, as the rollup must still ensure that the data is indeed accessible externally. Traditionally, other blockchains serve this purpose, functioning specifically as data availability layers for rollup systems.

This creates a dilemma regarding the robustness of security guarantees. When data is posted directly to the Bitcoin blockchain, consensus rules can ensure its correctness with absolute certainty. In contrast, data posted to an external system can only be verified through an SPV proof that it was published elsewhere.

This involves confirming an attestation that the data exists on other chains, ultimately turning it into an oracle problem. The Bitcoin blockchain can only verify events that occur locally, with its best capability being the validation of a ZKP. However, a ZKP alone cannot confirm whether a block containing rollup data was publicly broadcast after its generation, nor can it verify that external information is indeed made accessible to all.

This leads to potential data withholding attacks, where a commitment to the data being published is created and used to promote the rollup, but the data itself is not made available. Consequently, users’ funds may become unrecoverable. The only viable solution to this problem is to rely entirely on the value and incentive structures of external systems beyond Bitcoin.

The Rock and Hard Place

This creates a significant dilemma when discussing rollups. Regarding the data availability issue, there exists a binary choice: post the data to the Bitcoin blockchain or somewhere else. This decision dramatically influences both the security and sovereignty of rollups and their scalability.

On one side, utilizing the Bitcoin blockchain for data availability establishes a hard limit on how much rollups can scale. There is a finite amount of blockspace, which restricts the total number of concurrent rollups and the aggregate number of transactions they can process off-chain. Each rollup update necessitates blockspace proportional to the number of accounts that have experienced balance changes since the last update. Information theory imposes limits on data compression, and once reached, scaling opportunities are exhausted.

On the other side, opting for a different layer for data availability eliminates the fixed ceiling on scalability gains, introducing new security and sovereignty challenges in the process. In a rollup that utilizes Bitcoin for data availability, it is impossible for the rollup’s state to change without the accompanying data necessary for user withdrawals being concurrently posted to the blockchain. Meanwhile, with Validiums, that assurance hinges solely upon the robustness of the external systems employed and their ability to thwart any manipulation or data withholding.

Any block producer on the external data availability system could effectively hold Bitcoin rollup users’ funds hostage by generating a block and then failing to broadcast it to make the data available.

So, if we ever achieve a scenario featuring an ideal rollup implementation on Bitcoin that allows for unilateral user withdrawals, which will it be—the rock or the hard place?