Bitcoin Magazine: What difficulties does Rollup face?

Source: Bitcoin Magazine; Compiled by: Wuzhu, Golden Finance

Rollups have recently become the focus of Bitcoin scaling, becoming the first thing to really "steal the limelight" from the Lightning Network in terms of broader attention. Rollups aim to be an off-chain second layer that is not bound or limited by the core liquidity restrictions of the Lightning Network, that is, the end user needs someone to allocate (or "lend") funds in advance to receive the money, or the intermediate routing node needs a channel balance to facilitate the full flow of payment amounts from sender to receiver.

These systems were originally run on Ethereum and other Turing-complete systems, but recently the focus has shifted to porting them to UTXO-based blockchains (such as Bitcoin). This article is not intended to discuss the current status of implementation on Bitcoin, but rather to discuss the functions of the long-sought idealized Rollup, which depends on the function that Bitcoin does not currently support, namely the ability to verify zero-knowledge proofs (ZKP) directly on Bitcoin.

The basic architecture of Roll is as follows: a single account (UTXO in Bitcoin) saves the balances of all users in the Rollup. This UTXO contains a commitment in the form of a Merkle root of a Merkle tree, committing to all the current balances of the existing accounts in the Rollup. All of these accounts are authorized using public/private key pairs, so in order to propose an off-chain spend, the user still has to sign something with the key. This part of the structure allows users to leave without permission at any time, just by making a transaction proving that their account is part of the Merkle tree, they can unilaterally exit the Rollup without the operator's permission.

The operator of the Rollup must include a ZKP in the transaction to update the merkle root of the on-chain account balances in the process of completing the off-chain transaction. 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 are properly authorized by the account holders, and that the operator is not maliciously updating the balances to steal users' funds or dishonestly redistribute them to other users.

The problem is, if only the root of the merkle tree is published on-chain and users can see and access it, then how do they place their branch in the tree to be able to exit without permission when they want?

A Proper Rollup

In a proper Rollup, every time a new off-chain transaction is confirmed and the state of a Rollup account changes, information is put directly into the blockchain. Not the entire tree, which would be ridiculous, but the information needed to rebuild the tree. In a simple implementation, a summary of all existing accounts in the Rollup would contain the balances, and accounts are only added in transactions that update the Rollup.

In more advanced implementations, balance differences are used. This is essentially a summary of which accounts had funds added or subtracted during the update. This allows each Rollup update to contain only the account balance changes that occurred. Users can then simply scan the chain and "do the math" from the beginning of the Rollup to work out the current state of account balances, which allows them to reconstruct the Merkle tree of current balances.

This saves a lot of overhead and block space (and therefore money) while still allowing users to have guaranteed access to the information they need to make a unilateral exit. The rollup rules require that this data be included in the official rollup provided to users using the blockchain, i.e. transactions that do not include account summaries or account differences are considered invalid transactions.

Validity Periods

Another way to deal with the problem of data availability for user extraction is to put the data somewhere else outside the blockchain. This introduces subtle issues, and the rollup still needs to enforce that the data is available somewhere else. Traditionally, other blockchains are used for this purpose, specifically designed to act as a data availability layer for systems like rollups.

This creates a dilemma where security guarantees are equally strong. When data is published directly to the Bitcoin blockchain, the consensus rules can guarantee that it is absolutely correct. However, when it is published to an external system, the best it can do is verify an SPV proof that the data was published to another system.

This requires verifying proof that the data exists on other chains, which is ultimately an oracle problem. Bitcoin’s blockchain cannot fully verify anything other than what happens on its own blockchain, the best it can do is verify ZKPs. However, ZKPs cannot verify that the block containing the rollup data was actually broadcast publicly after it was generated. It cannot verify that external information is actually public to everyone.

This opens the door to data withholding attacks, where a commitment to publish data is created and used to advance a rollup, but the data is not actually available. This results in users being unable to withdraw their funds. The only real solution is to rely entirely on the value and incentive structure of a system outside of Bitcoin.

Dilemma

This presents a dilemma for rollups. When it comes to the issue of data availability, there is essentially a binary choice between publishing data to the Bitcoin blockchain or elsewhere. This choice has significant implications for both the security and sovereignty of the rollup, as well as its scalability.

On the one hand, using the Bitcoin blockchain as a data availability layer puts a hard cap on the scalability of the rollup. Block space is finite, which places an upper limit on the number of rollups that can exist at once, and the number of transactions that can be processed off-chain by all rollups in total. Each rollup update requires block space proportional to the number of accounts whose balances have changed since the last update. Information theory only allows data to be compressed up to a certain point, at which point there is no more potential for scaling.

On the other hand, using a different layer to implement data availability removes the hard upper limit on scalability gains, but it also introduces new security and sovereignty issues. In a Rollup using Bitcoin for data availability, it is impossible for the state of the Rollup to change without the data that the user needs to extract being automatically published to the blockchain. With Validiums, this guarantee depends entirely on the ability of the external system used to resist spoofing and data hiding.

Right now, any block producer on an external data availability system is able to hijack the funds of a Bitcoin Rollup user by producing a block without actually broadcasting that block, making the data available.

So, if we actually achieve an ideal Rollup implementation on Bitcoin, with true unilateral user withdrawals, what would that look like?