Bitcoin Magazine: What Challenges Does Rollup Face?

Source: Bitcoin Magazine; Translation: Wu Zhu, 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 attracts wider attention. Rollups aim to be an off-chain second layer that is not constrained or limited by the core liquidity of the Lighting Network, meaning that 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 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 functionality of an idealized Rollup that people have long pursued, which depends on the ability to directly verify Zero-Knowledge Proofs (ZKP) on BTC, a capability that BTC currently does not support.

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 the Merkle tree, committing to the current balances of all 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 with their Secret Key. 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 the Rollup without the permission of the operator.

Rollup operators 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 that all changes to the off-chain account are properly authorized by the account holder, and that the operator does not maliciously update the balance to steal user funds or dishonestly redistribute them to other users.

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

Suitable Rollup

In the appropriate Rollup, each 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 Rollup will contain the balance, and the account will only be added in updating Rollup transactions.

In more advanced implementations, balance variances are used. This is essentially a summary of which accounts increased or decreased their funds during the update process. This allows each Rollup update to include only the account balance changes that have occurred. Users can then simply scan the chain and “calculate” from the beginning of the Rollup to derive the current state of the account balance, which allows them to rebuild 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 the information required for unilateral exit. Rollup rules require that these data be included in the formal rollup provided to users using the Block chain, that is, transactions that do not include account summaries or account differences are considered invalid transactions.

Validity period

Another way to deal with the issue of user withdrawal data availability is to place the data elsewhere outside of the blockchain. This introduces subtle issues, as rollup still needs to enforce that the data is available elsewhere. Traditionally, other blockchains have been used for this purpose, specifically designed to serve as data availability layers for systems like rollup.

This creates a dilemma of having equally strong security guarantees. When data is directly published to the BTCBlock chain, Consensus rules can ensure that it is absolutely correct. However, when it is published to external systems, the best it can do is to verify the SPV proof, that is, the data has been published to another system.

This requires verification that the data exists in proofs on other on-chain, which ultimately is an Oracle Machine problem. The Bitcoin Block chain cannot fully verify anything other than what happens on its own Block on-chain, and the best it can do is verify ZKP. However, ZKP cannot verify whether the Block containing rollup data has actually been publicly broadcasted after generation. It cannot verify whether external information is truly open to everyone.

This opens the door to data withholding attacks, which means creating a commitment to publish data and using 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.

Be in a 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 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 an upper limit on the number of rollups that can exist at once and the total number of transactions that can be processed off-chain in all rollups. Each rollup update requires a proportional amount of block space 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 this point, there is no more 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 a user needs to withdraw is not automatically published on the blockchain, the state of the Rollup cannot change. With Validiums, this guarantee depends entirely on the external system’s ability to resist fraud and data hiding.

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

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