Bitcoin Magazine: What challenges does Rollup face?

Source: Bitcoin Magazine; Compiler: Wuzhu, Golden Finance

Rollups have recently become the focus of BTC expansion, becoming the first thing to truly steal the limelight from the Lighting Network, in a more extensive sense of attention. Rollups are designed to be an off-chain second layer that is not constrained or restricted by the core Liquidity of the Lighting Network, i.e., end users need someone to allocate (or ‘lend’) funds in advance 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 initially 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 does not intend to discuss the current state of implementation on BTC, but rather the desired functionality of an idealized Rollup that depends on capabilities not currently supported by BTC, namely the ability to directly verify Zero-Knowledge Proofs (ZKPs) on BTC.

The basic architecture of Roll is as follows: a single account (UTXO in BTC) saves 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 all current balances of existing accounts in the Rollup. All these accounts are authorized using Public Key/Private Key, so in order to make off-chain spending, users still need to sign certain content using Secret Key. This part of the structure allows users to exit at any time without permission, just by making transactions proving 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 on-chain account balance merkle root during off-chain transactions. Transactions without this ZKP will be invalid and cannot be included in the blockchain. This proof allows people to verify whether all changes to off-chain accounts have received proper authorization from account holders and whether operators have not maliciously updated balances to steal users’ funds or dishonestly reallocate them to other users.

The problem is, if only the root of the Merkle tree is published on-chain for users to view and access, how do they place their branches in the tree so that they can exit without permission whenever they want?

Proper 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 into 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 include the balance, and the account will only be added in the updated transactions of Rollup.

In more advanced implementations, use balance differences. This is essentially a summary of which accounts have added or subtracted 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, allowing them to reconstruct the Merkel 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 rule requires that this data be included in the formal rollup provided to users using the Block chain, so that transactions without account summaries or account differences are considered invalid.

Validity

Another approach to addressing the availability of user withdrawal data is to place the data elsewhere outside 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, Consensus rules can ensure its absolute correctness. However, when it is posted to an external system, the best it can do is to verify SPV proof, that is, the data has been posted 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 public to everyone.

This opens the door for data withholding attacks, which involves creating commitments to publish data and using them 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 a 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 once and the total number of off-chain transactions that all rollups can process. Each rollup update requires Block space proportional to the number of accounts whose balance has changed since the last update. Information theory only allows data to be compressed to a certain extent, and there is no more potential for expansion at this point.

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 extract 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 a Block instead of actually broadcasting that 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 unilateral user withdrawals?