Staking has been at the center of the Bitcoin scaling narrative recently, becoming the first thing to truly “steal the show” from the Lightning Network in terms of mindshare breadth. Staking is intended to be a second off-chain layer that is not limited or constrained by the liquidity constraints that are the core of the Lightning Network, i.e. end users need someone to allocate (or “lend”) funds to them in advance in order to receive funds, or intermediate routing nodes that require channel balances that can facilitate the transfer of payment amounts all the way from sender to receiver.
These systems were originally developed to work on Ethereum and other Turing Complete systems, but more recently the focus has shifted to porting them to UTXO-based blockchains like Bitcoin. This article will not discuss the current state of things that are currently implemented on Bitcoin, but will discuss the ideal aggregation function that people are aiming for in the long run based on features that Bitcoin currently does not support, which is the ability to verify zero-knowledge proofs (ZKPs) directly on Bitcoin.
The basic structure of the list is as follows: a single account (or in the case of Bitcoin UTXO), holds the balances of all users on the list. This list contains a commitment in the form of a Merkle root of a Merkle tree that commits all current balances of the accounts on the list. All of these accounts are authorized using public/private key pairs, so in order to propose an off-chain spend, a user must sign something with a key. This part of the structure allows users to leave without permission whenever they want, simply by crafting a transaction that proves their account is part of the Merkle tree, they can unilaterally exit the list without the operator’s permission.
The pool operator must include the ZKP in transactions that update the Merkle root of on-chain account balances in the process of finalizing off-chain transactions, without this ZKP the transaction will be invalid and therefore cannot be included in the blockchain. This proof allows people to verify that all changes to off-chain accounts were properly approved by the account holders, and that the operator has not maliciously updated the balances to steal funds from users or reallocate them to other users in a dishonest manner.
The problem is, if only the root of the Merkle tree is published on the chain where users can view and access it, how can they get their own branch in the tree so they can exit without permission whenever they want?
Correct combinations
In a correct aggregation, information is put directly into the blockchain every time new off-chain transactions are confirmed and the state of the aggregation accounts changes. Not the entire tree, that would be silly, but the information needed to reconstruct the tree. In a naive implementation, the summary of all the accounts in the aggregation would be balances and accounts simply added in the transaction to update the aggregation.
In more advanced applications, the difference in balance is used. It is essentially a summary of the accounts that have had money added to or subtracted from during the update process. This allows each aggregate update to include Changes Users can then scan the chain and perform a calculation from the beginning of the aggregation to arrive at the current state of account balances, allowing them to reconstruct the Merkle tree of current balances.
This saves a lot of overhead and block space (and therefore money) while allowing users to be guaranteed access to the information they need to exit unilaterally. Including this data in a formal aggregation that uses the blockchain to make it available to users is mandatory under the rules of aggregation, meaning that a transaction that does not include an account summary or account discrepancy is considered invalid.
powers
Another way to deal with the problem of data availability for users to pull is to put the data somewhere other than the blockchain. This poses subtle issues, as the aggregator still needs to assume that the data was available somewhere else. Traditionally, other blockchains have been used for this purpose, specifically designed to act as data-providing layers for systems like the aggregator.
This creates the dilemma of strong security guarantees. When data is published directly on the Bitcoin blockchain, consensus rules can guarantee its validity with absolute certainty. But when it is published on an external system, the best it can do is verify the SPV proof that the data was published on another system.
This requires validating the existence of data on other chains, which is ultimately the oracle problem. The Bitcoin blockchain cannot fully verify anything except what happens on its own blockchain, better Nothing else can be done except verifying the ZKP. However, the ZKP cannot verify that the block containing the assembly data was broadcast publicly after it was produced. Nor can it verify that external information is actually available to everyone.
This opens the door to data-locking attacks, where a commitment is created with the data being published and used to advance the aggregation, but the data is never actually made available. This leaves users with more funds than they can withdraw. The only real solution to this is to rely entirely on the value structure and incentives of systems that are completely external to Bitcoin.
The Rock and the Hard Place
This creates a dilemma when it comes to the issue of data availability, there is essentially a binary choice between publishing data on the Bitcoin blockchain or elsewhere. This choice has huge implications for both the security and sovereignty of the aggregation, as well as its scalability.
On the other hand, the Bitcoin blockchain’s use of a data availability layer imposes a hard cap on how much a pool can scale. There is only a finite amount of space, which puts an upper limit on the number of pools that can exist at one time and the number of transactions that all pools in total can process. off the chainEach aggregate update requires block space proportional to the number of accounts that have experienced balance changes since the last update. Information theory only allows data to be compressed to a certain point, at which point there is no possibility of further gains through scaling.
On the other hand, using a different layer of data availability removes the hard cap on scalability gains, but also introduces new issues of security and sovereignty. In Bitcoin-based data availability pooling, it is literally impossible to change the state of the pool without automatically publishing the data that users need to withdraw to the blockchain. With Validiums, this security relies entirely on the ability of any external system used to resist tampering and data blocking.
Any block producer on an external data availability system can now hold Bitcoin Rollup users’ funds hostage by producing a block and not actually broadcasting it to make the data available.
So, what would be the choice if we came up with a perfect Bitcoin withdrawal app that would allow users to withdraw their funds unilaterally? Would it be the best choice or the hard choice?
Comments are closed, but trackbacks and pingbacks are open.