Source: Bitcoin Magazine; Translation: Wuzhu, Golden Finance

Rollups has become the focus of BTC expansion recently, becoming the first thing that truly steals the spotlight from Lighting Network and attracts wider attention. Rollups aims to be an off-chain second layer that is not restricted by the Liquidity constraints of the Lighting Network core, i.e., 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 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 does not intend to discuss the current state of implementation on BTC, but rather the idealized Rollup functionality that people have been pursuing for a long time, which depends on BTC's current inability to directly verify Zero-Knowledge Proof (ZKP) on the chain.

The basic architecture of Roll is as follows: a single account (UTXO in BTC) holds the balances of all users in the Rollup. This UTXO contains a commitment that takes 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 pairs, so in order to make off-chain expenditures, users still need to sign certain contents with their Secret Key. This part of the structure allows users to exit at any time without permission, by proving their account is part of the Merkle tree through making a transaction, they can unilaterally exit the Rollup without the operator's permission.

Rollup operators must include a ZKP in transactions to update the merkle root of on-chain account balance during the process of off-chain transactions. Transactions will be invalid without this ZKP and cannot be included in the blockchain. This proof allows people to verify that all changes to off-chain accounts are properly authorized by the account holders, and that operators are not maliciously updating balances to steal users' funds or dishonestly reallocating 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 do they put their branches in the tree so that they can exit without permission whenever they want?

Suitable Rollup

In the appropriate Rollup, every 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 absurd, but rather the information needed to reconstruct 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 transactions.

In a more advanced implementation, use balance difference. 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 Merkle tree of current balances.

This saves a lot of expenses and Block space (thus saving money), 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 Blockchains, and transactions that do not include account summaries or account differences are considered invalid transactions.

Validity

Another way to address data availability issues for user withdrawals is to place the data somewhere other than on the blockchain. This introduces subtle issues as rollups still need to enforce that the data is available elsewhere. Traditionally, other blockchains have been used for this purpose, specifically designed to act as data availability layers for systems like rollups.

This creates a dilemma of having equally strong security measures. When data is directly published to the BTCBlock chain, Consensus rules 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 shows that 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 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 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, where a commitment to publish data is made 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 other than BTC.

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 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 for all rollups. 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, 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 the funds of BTCRollup users by producing Blocks instead of actually broadcasting the Block, thus making the data available.

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