Bitcoin Magazine: What challenges does Rollup face?

Source: Bitcoin Magazine; Translation: Wuzhu, Golden Finance

Rollups have recently become the focus of BTC 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 constrained or limited by the Lighting Network’s core liquidity restrictions. 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 smooth flow of payment amounts from senders to receivers.

These systems were initially operated 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 is not intended 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 ability to directly verify Zero-Knowledge Proof (ZKP) on BTC, a feature that BTC currently does not support.

The basic structure of Roll is as follows: a single account (UTXO in BTC) stores the balances of all users in the Rollup. This UTXO includes 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 Rollup. All these accounts are authorized using Public Key/Private Key pairs, so users still need to sign certain content with their Secret Key in order to make off-chain expenditures. This part of the structure allows users to exit unilaterally at any time without permission, just by producing transaction proofs that their account is part of the Merkle tree, they can exit Rollup without the permission of the operator.

Rollup operators must include a ZKP in transactions to update the merkle root of on-chain account balances during the off-chain transaction completion process. Without this ZKP, the transaction will be invalid and cannot be included in the blockchain. 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 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 can they place their branches in the tree so that they can exit without permission whenever they want?

Suitable Rollup

In an appropriate Rollup, information is directly placed on the blockchain every time a new off-chain transaction is confirmed and the Rollup account’s status changes. It’s not the entire tree, which would be ridiculous, 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 will only be added in the updated Rollup transactions.

In more advanced implementations, balance delta is used. This is essentially a summary of which accounts have had funds added or removed during the update process. This allows each Rollup update to only include balance changes that have occurred to accounts. Users can then simply scan the chain and ‘compute’ from the start of the Rollup to derive the current state of account balances, allowing them to reconstruct the Merkle tree of the current balances.

This allows for significant cost and Block space savings (thus saving funds) while still allowing users to ensure access to the information required for unilateral exit. Rollup rules require 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.

Validity Period

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

This has created a dilemma where security assurances are equally strong. When data is directly posted to the BTCBlock chain, the Consensus rules can guarantee its absolute correctness. However, when it is posted to an external system, the best it can do is verify the SPV proof, which means the data has been posted to another system.

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

This opens the door to data withholding attacks, which involve creating commitments to published data and using them to advance rollup, 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 has brought a dilemma to rollup. When it comes to data availability issues, there is basically a binary choice of whether to publish 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 rollups. Block space is limited, which sets an upper limit on the number of rollups that can exist at a 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 that have had balance changes since the last update. Information theory only allows data to be compressed to a certain extent, and at this point, there is no further potential for expansion.

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 Rollups that use BTC to achieve data availability, if the data that users need to withdraw is not automatically published on 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 fraud 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, thus making the data available.

So, what would it be like if we really achieved the ideal Rollup implementation on BTC and truly realized one-sided user withdrawals?