Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance

Rollups have recently become the focus of BTC scalability, becoming the first thing to truly steal the spotlight from the Lighting Network and gaining 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. In other words, 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 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 (e.g., BTC). This article does not intend to discuss the current status of implementation on BTC, but rather the desired functionality of an idealized Rollup that depends on the ability to directly verify Zero-Knowledge Proofs (ZKPs) on BTC, which 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 the Merkle tree, committing all current balances of existing accounts in Rollup. All these accounts are authorized using Public Key/Private Key, so in order to make off-chain payments, users still need to sign certain content using the Secret Key. This part of the structure allows users to exit at any time without permission, just by providing proof of their account being part of the Merkle tree, they can unilaterally exit Rollup without the permission of the operator.

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 Block chain. 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 funds from users or dishonestly reallocated 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 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 Rollup account's status changes, the information is directly put into the blockchain. Not the entire tree, which would be ridiculous, but the information needed to rebuild the tree. In a simple implementation, the summary of all existing accounts in the Rollup will include the balance, and the account will only be added in the updated Rollup transaction.

In more advanced implementations, balance diffs 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 the account balance changes that occurred. Then, users can simply scan the chain and 'do the math' from the beginning of the Rollup to arrive at the current state of account balances, enabling them to reconstruct the Merkel tree of the current balances.

This can save a lot of expenses and Block space (thus saving funds), while still allowing users to ensure the information required to access unilateral exits. Rollup rules require that this data be included in the formal rollup provided to users using the Block chain, and transactions that do not include the account summary or account difference are considered invalid transactions.

Validity Period

Another way to address the issue of user withdrawal data availability is to store the data outside of the Block chain. This introduces subtle issues as rollup still needs to enforce the availability of the data elsewhere. Traditionally, other Block chains are used for this purpose, specifically designed as data availability layers 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 to verify the SPV proof, that is, the data has been posted to another system.

This requires verifying that the data exists in proofs from other on-chain sources, which ultimately is an Oracle Machine problem. The BTC blockchain cannot fully verify anything outside of what happens on its own on-chain events, and it can only do its best to verify ZKPs. However, ZKPs cannot verify whether the Block containing rollup data has actually been publicly broadcasted after it was generated. It cannot verify whether external information is truly public to everyone.

This opened the door for data withholding attacks, which involves creating a commitment to publish data and using it to advance rollups, but the data is not actually available. This results in users being unable to withdraw their funds. The only real solution is to rely on value and incentive structures outside of BTC entirely.

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 significant implications for the security, sovereignty, and scalability of rollup.

On the one hand, using BTC blockchain as the data availability layer will set a hard upper limit on the scalability of rollups. 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 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, 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 achieve data availability using BTC, 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 the funds of BTCRollup users by producing a Block instead of actually broadcasting that Block, thereby making the data available.

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