Bitcoin Magazine: What challenges are Rollups facing?

Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance

Rollups have recently become the focus of BTC expansion, becoming the first thing to truly steal the spotlight from the Lighting Network, in a more widespread attention aspect. Rollups aim to be an off-chain second layer not constrained or limited by the core Liquidity of the Lighting Network, meaning that end users need someone to allocate (or ‘lend out’) funds in advance in order to receive money, or intermediate routing Nodes need channel balance to facilitate the full flow of payment from sender to receiver.

These systems were originally implemented on Ethereum and other Turing Complete systems, but recently the focus has shifted to porting them to UTXO-based blockchains like 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 (ZKPs) on BTC, a capability that BTC currently does not support.

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 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 in order to propose off-chain spending, users still need to sign certain content with the Secret Key. This part of the structure allows users to exit at any time without permission, simply by proving that their account is part of the Merkle tree with a transaction, they can unilaterally exit the Rollup without the permission of the operator.

Operators of Rollup must include a ZKP in the transaction to update the merkle root of on-chain account balance during 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 off-chain accounts 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 problem is, if only the Merkle tree root is published on-chain, which users can view and access, how do they place their branches in the tree so that they can exit without permission when they want to?

Suitable Rollup

In the appropriate Rollup, whenever a new off-chain transaction is confirmed and the state of the Rollup account changes, the information will be directly put on 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 Rollup will contain the balance, and the account will only be added in the updated transactions of Rollup.

In more advanced implementations, balance differences are used. This essentially provides a summary of which accounts have increased or decreased funds during the update process. This allows each Rollup update to only include the balance changes that have occurred in the accounts. Then, users can simply scan the chain and ‘compute’ from the beginning of the Rollup to derive the current state of account balances, which allows them to reconstruct the Merkle tree of the current balances.

This can save a lot of expenses and Block space (thus saving funds), while still allowing users to ensure access to the information necessary for unilateral exit. The rollup rule requires that this data be included in the formal rollup provided to users using the blockchain, 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 place the data elsewhere outside the Block chain. This introduces subtle issues, rollup still needs to ensure the data is available elsewhere. Traditionally, other Block chains are used for this purpose, specially designed to serve as data availability layers for systems like rollup.

This has created 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 external systems, the best it can do is to verify SPV proof, which means 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 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 broadcast 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 to the published data is made and used to drive rollup, but the data is not actually available. This leads to users being unable to withdraw funds. The only real solution is to rely on value and incentive structures outside of BTC entirely.

Dilemma

This poses a dilemma for 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 significant implications for the security and sovereignty of the rollup, as well as its scalability.

On the one hand, using BTC blockchain as the data availability layer will set a hard 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 off-chain processed transactions for all rollups. 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, beyond which there is no more potential for expansion.

On the other hand, using different layers to achieve data availability would eliminate the hard upper limit of scalability gains, but it also brings new security and sovereignty issues. In the Rollup that uses 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 used to resist deception and data hiding.

Now, any Block producer on the external data availability system can hijack BTCRollup user funds by producing Blocks instead of actually broadcasting the Block, thus 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?