Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance

Rollups have recently become the focus of BTC scalability, becoming the first thing that truly steals the limelight from the Lighting Network and gains wider attention. Rollups aim to be an off-chain second layer that is not restricted or limited by the core Liquidity of the Lighting Network, which means that end users need someone to allocate (or 'lend') funds in advance in order to receive money, or intermediate routing Nodes need channel balances to facilitate the smooth flow of payment amounts from senders to receivers.

These systems were initially run on Ethereum and other Turing Complete systems, but recently the focus has shifted to porting them to UTXO-based blockchains such as BTC. This article does not intend to discuss the current state of implementation on BTC, but rather the desired functionality of an idealized Rollup that relies on capabilities currently not supported by BTC, namely the ability to directly verify Zero-Knowledge Proofs (ZKP) on BTC.

The basic architecture of Roll is as follows: a single account (UTXO in BTC) stores the balances of all users in the 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 the Rollup. All these accounts are authorized using Public Key/Private Key pairs, so in order to make off-chain expenditures, users still need to sign certain content using the Secret Key. This aspect of the structure allows users to exit at any time without permission, simply by making a transaction proving that their account is part of the Merkle tree. They can unilaterally exit the 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 off-chain transaction process. 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 user funds or dishonestly reallocate them to other users.

The problem is, if only the root of the merkle tree is published on-chain, and 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 the appropriate Rollup, whenever a new off-chain transaction is confirmed and the state of the Rollup account changes, the information is directly put into the blockchain. It is not the entire tree, which would be absurd, but 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 accounts are only added in the updated transactions of the Rollup.

In a more advanced implementation, use balance diffs. This is essentially a summary of which accounts have had funds added or subtracted during the update process. This allows each Rollup update to only include the account balance changes that have occurred. 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 rebuild the Merkle tree of the current balance.

This saves a lot of expenses and Block space (thus saving money), while still allowing users to ensure access to the information needed for unilateral exit. Rollup rules require these data to be included in the formal rollup provided to users using the Block chain, and transactions that do not include account summaries or account differences are considered invalid transactions.

Validity Period

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

This has created a dilemma of equally strong security. When data is directly published to the BTCBlock chain, Consensus rules can ensure its absolute correctness. However, when it is published to an external system, the best it can do is verify the SPV proof, that is, the data has been published to another system.

This requires verifying that the data exists in other on-chain proofs, which ultimately is an Oracle Machine problem. The BTC Blockchain cannot fully verify anything other than what happens on its own Block on-chain, the best it can do is verify ZKP. However, ZKP cannot verify whether a Block containing rollup data is actually publicly broadcasted after it is generated. It cannot verify whether external information is truly accessible to everyone.

This opens the door to data withholding attacks, which is to create a commitment to publish data and use it to advance rollup, but the data is actually not available. This prevents users from withdrawing funds. The only real solution is to fully rely on the value and incentive structure of systems other than BTC.

A dilemma

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

On the one hand, using BTCBlock chain as the data availability layer will set a hard upper limit on the scalability of rollup. Block space is limited, which sets a limit on the number of rollups that can exist at one time and the total number of transactions that can be processed off-chain for all rollups. Each rollup update requires Block space that is 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 eliminates the hard upper limit on scalability gains, but it also brings new security and sovereignty issues. In Rollups that achieve data availability using BTC, the state of the Rollup cannot change if the data that users need to extract is not automatically published on the blockchain. With Validiums, this guarantee depends entirely on the ability of the external system being used to resist deception and data concealment.

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

So, if we really achieve the ideal Rollup implementation on BTC, truly realizing unilateral user withdrawals, what would that be like?