Source: Bitcoin Magazine; Compilation: 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 broader sense of attention. Rollups aim to become an off-chain second layer not constrained or limited by the core Liquidity of the Lighting Network, i.e., end users need someone to pre-allocate (or "lend out") 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 run on Ethereum and other Turing Complete systems, but the recent focus has shifted to porting them to UTXO-based blockchains (e.g., BTC). This article is not intended to discuss the current implementation on BTC, but to discuss the idealized Rollup functionality that people have been pursuing for a long time, which depends on the ability to directly verify Zero-Knowledge Proof (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 balance of all users in the Rollup. This UTXO contains a commitment that exists in the form of the Merkle root of a Merkle tree, committing all current balances of existing accounts in Rollup. All these accounts are authorized using Public Key/Private Key pairs, so users still need to sign certain content with Secret Key to make off-chain spending. This part of the structure allows users to leave at any time without permission, as long as they make a transaction proving that their account is part of the Merkle tree, they can unilaterally exit Rollup without the operator's permission.

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 whether all changes to the off-chain account have been properly authorized by the account holder, and whether the operator has not maliciously updated the balance to steal user funds or dishonestly reallocate them to other users.

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

Appropriate Rollup

In the appropriate Rollup, each time a new off-chain transaction is confirmed and the state of the Rollup account changes, the information is directly put into the blockchain. Not the entire tree, which would be absurd, 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 is only added in the updated transactions of the Rollup.

In more advanced implementations, balance differences are used. This is essentially 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 determine 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 required for unilateral withdrawal. Rollup rules require that these data be included in the formal rollup provided to users using Blockchains, and transactions that do not include account summaries or account differences are considered invalid.

Expiration date

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 rollups still need to ensure that the data is available elsewhere. Traditionally, other Block chains have been used for this purpose, specifically designed as data availability layers for systems like rollups.

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

This requires verifying that the data exists in 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 the block containing rollup data is actually publicly broadcasted after it is generated. It cannot verify whether external information is truly public to everyone.

This opens the door to data withholding attacks, creating commitments to release data and using it 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 outside of BTC.

Dilemma

This poses a dilemma for rollups. When it comes to data availability, there is essentially a binary choice between publishing data to the BTC blockchain or elsewhere. This choice has significant implications for the security, sovereignty, and scalability of rollups.

On the one hand, using BTCBlock chain 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 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, at which point there is no more potential for expansion.

On the other hand, using different layers to achieve data availability will eliminate the hard upper limit of scalability gains, but it also brings new security and sovereignty issues. In the Rollup using BTC to achieve data availability, if the data that users need to extract is not automatically published to the blockchain, the state of 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 users' funds by producing Blocks instead of actually broadcasting them, 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?