Bitcoin Magazine: What challenges does Rollup face?

Source: Bitcoin Magazine; Translation: Wuzhu, Golden Finance

Rollups have recently become the focus of BTC expansion and the first thing to truly steal the spotlight from Lighting Network, gaining broader attention. Rollups aim to be an off-chain second layer not constrained by the Lighting Network’s core Liquidity limitations, meaning end-users need someone to pre-allocate (or ‘lend’) funds before they can receive money, or intermediate routing Nodes need channel balances to facilitate the full flow of payment amounts from sender to receiver.

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 implementation on BTC, but rather the idealized Rollup functionality that people have long pursued, which depends on the ability to directly verify Zero-Knowledge Proofs (ZKPs) on BTC, a capability that BTC currently does not support.

The basic structure of Roll is as follows: a single account (UTXO in BTC) stores the balance of all users in the Rollup. This UTXO contains a commitment that exists in the form of the Merkle root of the Merkle tree, committing all current balances of existing accounts in the Rollup. All these accounts are authorized using Public Key/Private Key pairs, so to make off-chain spending, users still have to sign certain content with their Secret Key. This part of the structure allows users to exit at any time without permission, just by producing transaction proof that their account is part of the Merkle tree, they can unilaterally exit the Rollup without the operator’s 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 Blockchain. This proof allows people to verify whether all changes to the off-chain account are 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 withdraw without permission when they want to?

Appropriate Rollup

In the appropriate Rollup, every time a new off-chain transaction is confirmed and the Rollup account’s state changes, the information is directly put on the blockchain. Not the entire tree, that would be too absurd, but the information needed to rebuild the tree. In a simple implementation, the summary of all existing accounts in the Rollup will contain the balance, and the account will only be added in the updating transactions of the Rollup.

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 changes in account balances that have occurred. Then, users can simply scan the chain and ‘compute’ from the beginning of the Rollup to determine the current state of account balances, which allows them to reconstruct the Merkle tree of the current balance.

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 rules require the inclusion of this data 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.

Expiration Date

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

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

This requires verifying that the data exists on other on-chain proofs, which is ultimately an Oracle Machine problem. The BTC Block chain cannot fully verify anything except 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 really publicly broadcasted after generation. It cannot verify whether external information is truly public to everyone.

This opens the door for data withholding attacks, which is to create a commitment to the published data and use it to advance rollup, but the data is not actually available. This results in users being unable to withdraw 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 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 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 once 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, and at that point, there is no more room 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 the 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 being 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 them, thereby making the data available.

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