Bitcoin Magazine: What challenges does Rollup face?

Source: Bitcoin Magazine; Translation: Wuzhu, Golden Finance

Rollups have recently become the focus of Bitcoin scalability, becoming the first thing to truly overshadow the Lighting Network and gain wider attention. Rollups aim to be an off-chain second layer that is not limited or restricted by the core liquidity 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 flow of payment amounts from senders to receivers.

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 BTC). This article does not intend to discuss the current state of implementation on BTC, but rather the idealized Rollup functionality that people have long pursued, which depends on BTC’s current inability to directly verify Zero-Knowledge Proof (ZKP) on BTC.

The basic architecture of Roll is as follows: a single account (UTXO in BTC) holds 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 to the current balances of all existing accounts in the Rollup. All these accounts are authorized using a Public Key/Private Key pair, so users still need to sign certain content with a Secret Key in order to propose off-chain spending. This part of the structure allows users to exit unilaterally at any time without permission, by simply making a transaction proving that their account is part of the Merkle tree, without the need for operator permission.

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 user funds or dishonestly reallocate them to other users.

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

Appropriate Rollup

In the appropriate Rollup, every time a new off-chain transaction is confirmed and the state of the Rollup account changes, the information is directly put into the blockchain. Not the entire tree, that 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 account will only be added in the updated Rollup transactions.

In more advanced implementations, use balance differences. 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 changes in account balances that have occurred. Then, users can simply scan the chain and ‘calculate’ from the beginning of the Rollup to determine the current state of account balances, allowing them to reconstruct the current balance Merkle tree.

This can save a lot of expenses and Block space (thus 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, 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 of the Block chain. This introduces subtle issues as rollup still needs to enforce data availability elsewhere. Traditionally, other Block chains have been used for this purpose, specifically designed as data availability layers for systems like rollup.

This creates a dilemma of having equally strong security measures. 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 to verify the SPV proof, which means the data has been published to another system.

This requires verifying data exists 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. The best it can do is verify ZKP. However, ZKP cannot verify whether the Block containing rollup data is truly publicly broadcasted after generation. It cannot verify whether external information is truly made public to everyone.

This opens the door to data withholding attacks, where a commitment is made to publish data and use it to advance rollup, but the data is actually not available. This results in users being unable to withdraw funds. The only real solution is to rely on systems outside of BTC for value and incentive structures.

A dilemma

This creates a dilemma for rollups. There is basically a binary choice when it comes to data availability issues: whether to publish data to the BTC blockchain or elsewhere. This choice has significant implications for the security and sovereignty, as well as the scalability of the rollup.

On the one hand, using BTC blockchain as the data availability layer will set a hard limit on the scalability of rollups. 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 proportional to the number of accounts whose balance has changed since the last update. Information theory only allows data to be compressed to a certain extent, and there is no more room for expansion at this point.

On the other hand, using different layers to achieve data availability eliminates the hard upper limit of scalability gains, but it also brings new security and sovereignty issues. In 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 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 BTC and truly realized unilateral user withdrawals?