Source: Bitcoin Magazine; Translation: Wuzhu, Golden Finance

Rollups has recently become the focus of BTC scalability, becoming the first thing that truly steals the spotlight from the Lighting Network and receives wider attention. Rollups aim to be an off-chain Layer 2 solution that is not constrained by the core Liquidity limitations of the Lighting Network. In other words, end users need someone to pre-allocate (or 'lend') funds in order to receive money, or intermediate routing Nodes need channel balances 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 the recent focus has shifted to porting them to UTXO-based blockchains (e.g. BTC). This article does not intend to discuss the current implementation on BTC, but to discuss the idealized Rollup functionality that people have been pursuing for a long time, which depends on the capability that BTC currently does not support, namely the ability to directly verify Zero-Knowledge Proof (ZKP) on BTC.

The basic architecture of Roll is as follows: a single account (UTXO in BTC) stores the balances of all users in Rollup. This UTXO contains a commitment, which exists in the form of the Merkle root of a Merkle tree, committing all current balances of existing accounts in Rollup. All these accounts are authorized using Public Key/Private Key, so in order to propose off-chain spending, users still need to sign certain content using the Secret Key. This part of the structure allows users to exit at any time without permission, just by proving with a transaction that their account is part of the Merkle tree. They can unilaterally exit Rollup without the permission of the operator.

The operator of Rollup must include a ZKP in the transaction to update the merkle root of the on-chain account balance during the process of completing off-chain transactions. Without this ZKP, the transaction will be invalid and cannot be included in the Block chain. This proof allows people to verify whether all changes to the off-chain account have been properly authorized by the account holder, and whether the operator has not maliciously updated the balance to steal users' funds or dishonestly reallocated them to other users.

The problem is, if only the root of the merkle tree is published on-chain, users can view and access it, how do they place their branches in the tree so that they can exit without permission when they want?

Suitable Rollup

In an appropriate Rollup, whenever a new off-chain transaction is confirmed and the Rollup account's status changes, the information is directly put on the blockchain. It's not the entire tree, which would be too absurd, but rather the information needed to rebuild the tree. In a simple implementation, the summary of all existing accounts in the Rollup will include the balance, and the account is simply added in the updated Rollup transaction.

In more advanced implementations, balance differences are used. This is essentially a summary of which accounts have increased or decreased funds during the update process. This allows each Rollup update to only include the balance changes that have occurred in the accounts. Then, users can simply scan the chain and 'compute' from the beginning of the Rollup to derive the current state of account balances, allowing them to reconstruct the Merkel tree of the current balances.

This can save a lot of expenses and Block space (thereby saving funds), while still allowing users to ensure access to the information required for unilateral exit. The rollup rule requires that this data be included in the formal rollup provided to users using the Block chain, i.e., transactions that do not include account summaries or account differences are considered invalid transactions.

Validity

Another way to address the issue of user withdrawal data availability is to place the data elsewhere outside the Block chain. This introduces subtle issues, as rollup still needs to ensure that the data is available elsewhere. Traditionally, other Block chains are used for this purpose, specifically designed to serve as data availability layers for systems like rollup.

This creates a dilemma of equal security. When data is directly published to the BTCBlock chain, Consensus rules can guarantee its absolute correctness. However, when it is published to an external system, the best it can do is to verify the SPV proof, which means the data has been published to another system.

This requires verifying the existence of data in other on-chain proofs, which ultimately is an Oracle Machine problem. The BTC Block chain cannot fully verify anything other than what happens on its own Block on-chain. At best, it can verify ZKP. However, ZKP cannot verify whether the Block containing rollup data has really been publicly broadcast after generation. It cannot verify whether external information is really made public to everyone.

This opens the door to data withholding attacks, which involve making commitments to published data and using it to drive rollups, but the data is not actually available. This prevents users from withdrawing funds. The only real solution is to rely on value and incentive structures outside of BTC completely.

Dilemma

This poses a dilemma for rollup. When it comes to data availability, there is basically a binary choice of whether to publish the data to the BTC blockchain or elsewhere. This choice has significant implications for the security, sovereignty, and scalability of the rollup.

On the one hand, using BTCBlock chain as the data availability layer will set a hard limit on the scalability of rollup. Block space is limited, which sets a limit on the number of rollups that can exist at a time and the total number of transactions that all rollups can process off-chain. 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 to a certain extent, at which point there is no more potential for expansion.

On the other hand, using different layers to achieve data availability will eliminate the hard upper limit of scalability gains, but it also brings new security and sovereignty issues. In a Rollup using BTC to achieve data availability, if the data that users need to extract is not automatically published to the blockchain, the state of the Rollup cannot change. With Validiums, this guarantee depends entirely on the ability of the external system used to resist deception and data hiding.

Now, any Block producer on the external data availability system can hijack the funds of BTCRollup users by producing Blocks instead of actually broadcasting the Block, thereby making the data available.

So, what would it be like if we really achieved the ideal Rollup implementation on Bitcoin and truly enabled unilateral user withdrawals?