Source: Bitcoin Magazine; Translation: Wuzhu, Golden Finance

Rollups have recently become the focus of BTC expansion, becoming the first thing to truly steal the spotlight from the Lighting Network, in a more widespread attention aspect. Rollups are intended to be an off-chain second layer not constrained by the core Liquidity limitations of the Lighting Network, meaning that 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 initially deployed 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 state of implementation on BTC, but rather the idealized functionality of Rollup that people have long pursued, which depends on the capability, not currently supported on BTC, to directly verify Zero-Knowledge Proofs (ZKP) on BTC.

The basic architecture 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 accounts in 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 with Secret Key. This part of the structure allows users to exit at any time without permission, just by making a transaction proving that their account is 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 off-chain transaction. Without this ZKP, the transaction will be invalid and therefore 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 users' funds or dishonestly reallocated 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 do they place their branches in the tree so that they can exit without permission whenever they want?

Appropriate Rollup

In the appropriate Rollup, whenever 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, 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 accounts are only added in the updated transactions of the Rollup.

In more advanced implementations, balance differences are used. This essentially summarizes which accounts have increased or decreased funds during the update process. This allows each Rollup update to only include the account balance changes that have occurred. Then, users can simply scan the chain and 'compute' from the beginning of the Rollup to derive 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 money), while still allowing users to ensure the information needed for unilateral exit access. The rollup rule requires that these data be included in the formal rollup provided to users using Block chain, and transactions that do not include account summaries or account differences are considered invalid transactions.

Validity period

Another way to address the issue of data availability for user withdrawals is to store the data outside of the Block chain. This introduces subtle issues as rollups still need to enforce data availability elsewhere. Traditionally, other Block chains have been used for this purpose, specifically designed as data availability layers for systems like rollups.

This has created a dilemma where the security guarantee 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 SPV proof, that is, the data has been posted to another system.

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

This opens the door to data withholding attacks, creating commitments to published data and using it to advance rollups, but the data is not actually available. This prevents users from withdrawing funds. The only real solution is to fully rely on the value and incentive structure of systems outside of BTC.

Caught in a 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 the rollup.

On the one hand, using the BTCBlock chain as the data availability layer will set a hard upper 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 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 at this point, there is no more potential for expansion.

On the other hand, using different layers to achieve data availability will eliminate the hard 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. Using Validiums, this guarantee depends entirely on the ability of the external system being used to resist deception and data hiding.

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

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