Source: Bitcoin Magazine; Compilation: Wuzhu, Golden Finance

Rollups have recently become the focus of BTC scalability and the first thing that has truly overshadowed the Lighting Network, in terms of broader attention. Rollups aim to be an off-chain second layer that is not limited or constrained by Lighting Network's core liquidity. 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 smooth flow of payment amounts from senders to receivers.

These systems were initially run on Ethereum and other Turing Complete systems, but the focus has recently shifted to porting them to UTXO-based blockchains like BTC. This article does not intend to discuss the current state of implementation on BTC, but rather the desired functionality of an idealized Rollup that 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) stores the balances of all users in the Rollup. This UTXO contains a commitment, which exists in the form of the Merkle root of a Merkle tree, committing to all current balances of accounts in Rollup. All these accounts are authorized using Public Key/Private Key pairs, so in order to make off-chain spends, users still need to sign certain content with their Secret Key. This part of the structure allows users to exit at any time without permission, by simply providing proof of their account being part of the Merkle tree, they can unilaterally exit the 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 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 reallocate them to other users.

The question is, if only the root of the Merkle tree is published on-chain and accessible to users, 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, each 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, which would be absurd, but the information needed to rebuild the tree. In a simple implementation, the digests 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 a more advanced implementation, use balance differences. 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 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 this data be included in the formal rollup provided to users using the Block chain, so 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 in places outside the Block chain. This introduces subtle issues as rollup still needs to enforce the availability of data elsewhere. Traditionally, other Block chains have been used for this purpose, specifically designed as the data availability layer for systems like rollup.

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

This requires proof that the data exists on other on-chain, which is ultimately an Oracle Machine problem. The BTC blockchain cannot fully verify anything that happens outside of its own on-chain events. The best it can do is verify ZKP. However, ZKP cannot verify whether the block containing rollup data is actually publicly broadcast after it is generated. It cannot verify whether external information is truly public to everyone.

This opens the door to data withholding attacks, which involve creating commitments to published data and using them 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 systems outside of BTC for value and incentive structures.

Between Scylla and Charybdis

This poses a dilemma for rollup. When it comes to data availability, there is basically a binary choice of whether to publish 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 the BTC blockchain as the data availability layer will set a hard 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 all rollups can process off-chain. 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 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 on 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 concealment.

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 achieve the ideal Rollup implementation on BTC and truly enable unilateral user withdrawals?