Bitcoin Magazine: What challenges are Rollups facing?

Source: Bitcoin Magazine; Translation: Wu Zhu, Golden Finance

Rollups have recently become a focus of BTC expansion, becoming the first thing that truly steals the spotlight from the Lighting Network, in terms of broader attention. Rollups aims to be an off-chain second layer that is not constrained or restricted by Lighting Network’s core Liquidity, i.e. end-users need someone to pre-allocate (or “borrow”) funds in order to receive money, or intermediate routing Nodes need channel balances to facilitate the full flow of payment amounts 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, such as BTC. This article is not intended to discuss the current state of implementation on BTC, but rather the desired functionality of an idealized Rollup, which depends on the ability to directly verify Zero-Knowledge Proofs (ZKPs) on BTC, a feature that is currently not supported.

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

Rollup operators must include a ZKP in transactions to update the merkle root of the on-chain account balance during the off-chain transaction 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 off-chain accounts have been properly authorized by the account holders and whether operators have not maliciously updated balances 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 the appropriate Rollup, each time 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 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 updated transactions of the Rollup.

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

This saves a lot of overhead and block space (and thus money) while still allowing users guaranteed access to the information they need for a unilateral exit. The rollup rule requires that this data be included in the official rollup provided to the user using the Block chain, i.e., transactions that do not contain an account summary or account discrepancy are considered invalid.

Expiration Date

Another approach to addressing the issue of user withdrawal data availability is to place the data elsewhere outside of the Block chain. This introduces subtle issues, as rollup still needs to ensure that the data is available elsewhere. Traditionally, other Block chains are used for this purpose, specifically designed to serve as data availability layers for systems such as rollup.

This has created a dilemma where security is equally strong. When data is directly posted to the BTCBlock chain, the 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 blockchain 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 a block containing rollup data is truly publicly broadcasted after it is generated. It cannot verify whether external information is truly made public to everyone.

This opens the door to data withholding attacks, where a commitment to publish data is made to advance rollup, but the data is not actually available. This prevents users from withdrawing funds. The only real solution is to rely entirely on the value and incentive structure of systems other than BTC.

Dilemma

This has posed 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 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 can be processed off-chain in 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, 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 on 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 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 fraud and data hiding.

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

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