Source: Bitcoin Magazine; Compiled by: Wuzhu, Golden Finance

Rollups has become the focus of BTC expansion recently, and has become the first thing that truly steals the limelight from Lighting Network, in terms of broader attention. Rollups aims to become an off-chain second layer that is not constrained or restricted by Lighting Network's core Liquidity, that is, end users need someone to pre-allocate (or "lend") funds in advance to receive money, or intermediate routing nodes need channel balances to facilitate the full flow of payment amounts from senders to receivers.

These systems were originally run on Ethereum and other Turing Complete systems, but the focus has recently shifted to porting them to UTXO-based blockchains (such as 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 feature that BTC currently does not support.

The basic structure of Roll is as follows: a single account (UTXO in BTC) stores the balances of all users in 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 pairs, so in order to make off-chain expenditures, 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, they only need to provide transaction proof that their account is part of the Merkle tree, and 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 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 the off-chain account have been properly authorized by the account holder, and whether the operator has not maliciously updated the balance to steal funds from users or dishonestly reallocate them to other users.

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

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

In a more advanced implementation, use balance differences. 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 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 Merkle 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 rules require that these data be included in the formal rollup provided to users using the Block chain, and transactions that do not include account summaries or account differences are considered invalid transactions.

Expiry date

Another way to deal with the issue of user withdrawal data availability is to place the data somewhere other than the blockchain. This introduces subtle issues where rollups still need to enforce the availability of the data elsewhere. Traditionally, other blockchains have been used for this purpose, specifically designed to act as data availability layers for systems such as rollups.

This creates a dilemma of having the same level of security. When data is directly published to the BTCBlock chain, Consensus rules can ensure its absolute correctness. However, when it is published to an external system, the best it can do is to verify the SPV proof, which means the data has been published to another system.

This requires verifying that the data exists on other on-chain proofs, which is ultimately an Oracle Machine question. 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 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 a commitment to publish data and using it 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 fully rely 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 basically a binary choice of whether to publish the data on the BTC blockchain or elsewhere. This choice has significant implications for the security, sovereignty, and scalability of the rollup.

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 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 ceiling on scalability gains, but it also brings new security and sovereignty issues. In a Rollup that uses BTC to achieve data availability, if the data a user needs to withdraw isn't automatically published on the blockchain, the state of the Rollup can't change. With Validiums, this guarantee depends entirely on the external system used to resist fraud and data hiding.

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

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