Almost since its creation, some Bitcoin enthusiasts have looked to ways the functionality and scalability of Bitcoin might be increased. As Bitcoin adoption continues to expand, the ability to build trustless, financial primitives on top of the protocol will be key in challenging the fiat-based monetary system(s).
To date scaling solutions to Bitcoin have varied from side-chains to layer-1s to trustless solutions like the Lightning Network. When it comes to more complex smart-contract enabled financial primitives, most Bitcoin scaling solutions have relied on side-chains & layer-1s, which present unique centralization risks.
Examples of Existing Bitcoin Scaling Solutions:
| Scaling Solution | Mechanism | Bridge to/from BTC | Use |
| DeFiChain | Proof-of-Stake Side Chain, w/ Proof-of-Work attributes | Multisig run by The DefiChain Foundation | Enables Smart Contracts |
| RSK | Proof-of-Work, ‘Merge Mined’ Sidechain | Multisig w/10 parties | Enables Smart Contracts |
| Stacks | Proof-of-Transfer, layer-1 that ‘leverages the security of the BTC network’ | Sent to ‘Burn’ Address | Enables Smart Contracts |
| Liquid Network | Proof-of-Authority / Strong Federation | Multisig w/15 parties | Enables Smart Contracts |
| Lightning Network | State Channel Solution; bi-directional channels requiring user provided liquidity | Direct to BTC, via a Revocable Commitment Transaction system to ensure trustless integrity of transactions prior to settlement on main chain | Payments |
Enter ZK-BTC
A recent report published by a participant in the Human Rights Foundation’s ZK-Rollup Research Fellowship, John Light, lays out how Bitcoin could deploy a trustless layer-2 solution — through the use of a validity rollup. I will give a high-level overview of Mr. Light’s findings (a more detailed report is available here).
What is a Validity Rollup?
A rollup holds the state root and the transaction data needed to recompute the current state on the rollup blockchain from its genesis. This state data is stored on the parent chain — in this case Bitcoin — while transaction execution is handled on the rollup itself.
A validity rollup uses “validity proofs” to ensure the new rollup blocks follow the rules of the rollup protocol. Every time a new block is created on the validity rollup, the block producer sends a state update to the parent chain — in this case Bitcoin.
The validity proof is used to show that the update from the block producer is valid before the state data is updated on the parent chain.
Deploying A Validity Rollup to Bitcoin
A recently published post from Trey Del Bonis has documented how a validity rollup could be deployed to Bitcoin’s Turing-incomplete language, Script, with minor changes (in terms of code changes). By enabling a few extra opcodes, two new primitives could be enabled on Bitcoin: validity proof verification and recursive covenants. This could be done, according to Del Bonis, without the need for a hard fork.
However, given that this requires giving Bitcoin full nodes the ability to verify validity proofs, the community will need to decide what type of rollup they’d want to enable if any — for example better smart contract functionality. Put simply, Bitcoin full nodes would be the gatekeepers that verify validity proofs before they are able to be added to the Bitcoin network.
Because the Bitcoin full nodes would not actually need to verify the computations taking place on the validity rollup, the computational effort is the same whether the full node is verifying one validity transaction or a full block of validity transactions.
Del Bonis covers other potential methods of enabling rollups on Bitcoin and more technical aspects of the implementation here.
Benefits of Using A Validity Rollup
A validity rollup would enable an entirely new functionality to be added to Bitcoin without the need for any consensus rule changes on the parent chain itself — in this case Bitcoin. The reason behind this is that the Bitcoin full nodes would only need to know how to verify the rollup validity proof — not all the specific consensus rules on the rollup itself.
This would allow for additional functionality to be added that builds on top of Script without the need to hard-fork the network.
The goal of the rollup is in essence is to allow for an alternative programming language — say a smart contract enabling one — to operate directly on Bitcoin instead of using a “two-way peg” or a Layer-1 as is the case in Liquid Network and Stacks respectively.
Though there are Bitcoin-focused side-chains with smart-contract functionality today, they have drawbacks and centralization risks. Presently for example, RSK and the Liquid Network are essentially custodial side-chains: you peg in your BTC to their protocol and get an IOU back, which their multisig process says they will give back to you if and when you “peg out.” A rollup would allow for the experimentation with alternative execution environments, while maintaining full custody of one’s bitcoin – a key tenant of Bitcoin ethos.
Final Thoughts
Assuming a validity rollup could be implemented on top of Bitcoin without a need for a hard fork (or other drastic changes to the protocol), this is a solution that warrants further consideration.
Ultimately, though, the community will need to decide if the benefits of this solution outweigh both the risks and costs. Another consideration is where the addition of this rollup functionality fits with the long-term vision and ethos of the Bitcoin community.
