Bitcoin Scalability: Layer 2 Solutions and Related Projects

Author: Chakra; Translation: 0xjs@黄金财经

There are multiple paths to Bitcoin scaling. The first part of our series of articles has described one of them, "Bitcoin native scaling solution", and the other path is to build an additional protocol layer on top of Bitcoin, called Layer 2. The most critical aspects of the Layer 2 solution are secure two-way bridges and the inheritance of Bitcoin consensus security.

Sidechain

The concept of sidechain dates back to 2014, when Blockstream submitted "Blockchain Innovation Using Pegged Sidechains". It represents a relatively basic scaling method.

How Sidechains Work

A sidechain is a blockchain that runs independently of the main chain, has its own consensus protocol, and can serve as a testing ground for innovation on the main chain. When an adverse event occurs on the sidechain, the damage is completely confined to the sidechain itself without any impact on the main chain. Sidechains can adopt consensus protocols with higher TPS (transactions per second), enhance on-chain programmability, and promote the enhancement of BTC functionality.

Sidechains can realize the transfer of Bitcoin between different blockchains through two-way pegs or one-way pegs. But in reality, BTC can only reside on the Bitcoin mainnet, so an anchoring mechanism is needed to link BTC on the sidechain with BTC on the Bitcoin mainnet.

One-way pegs require users to send BTC from the mainnet to an unavailable address for destruction, and then mint an equal amount of BTC on the sidechain, but this process is irreversible. Two-way pegs are an improvement on one-way pegs, allowing BTC to move back and forth between the mainchain and the sidechain. Instead of destroying by sending to an unavailable address, two-way pegs lock BTC through multi-signature or other control scripts and mint new BTC on the sidechain. When the user wants to return to the mainnet, the BTC on the sidechain will be destroyed, and the originally locked BTC will be released on the mainnet.

The implementation of a one-way peg is much simpler than a two-way peg because it does not require the management of relevant states on the Bitcoin mainnet. However, sidechain assets created through one-way pegs are potentially worthless because they lack a reverse peg mechanism.

There are different schemes and security levels for verifying lock transactions on the mainchain and burn transactions on the sidechain. The simplest approach is external verification through multi-signature participants, but this carries a high centralization risk. A better option is decentralized verification using SPV proofs. However, because the Bitcoin mainnet lacks the necessary programming capabilities to perform SPV verification, other methods must be used, usually multi-signature escrow.

Issues and Methods

The main criticisms of sidechains include:

1. Asset cross-chain reliance on validators: Since the Bitcoin mainnet is still unable to implement smart contracts, cross-chain asset transfers cannot be managed through trustless contract logic. Returning assets from the sidechain to Bitcoin requires reliance on a set of validators, which introduces trust assumptions and fraud risks.

2. Sidechains cannot inherit the security of the mainchain: Since sidechains run completely independently of the mainnet, they cannot inherit the security of the mainnet, which may lead to malicious block reorganizations.

To address these issues, sidechains have adopted approaches including reliance on authorities (federation), economic security (PoS), decentralized Bitcoin miners (merged mining), and hardware security modules (HSM). The custody of funds on Bitcoin and the production of blocks on the sidechain can be managed by different roles, introducing more complex security mechanisms.

Case Study

Liquid

One of the earliest forms of sidechains is the federated sidechain, which relies on a pre-selected group of entities as validators, responsible for custody of assets on the main network and producing blocks on the sidechain.

Liquid is a typical example of a federated sidechain, with 15 participants acting as validators. The management of private keys is not public, and verification requires 11 of the 15 signatures. Block production on the Liquid sidechain is also maintained by these 15 participants. The fewer nodes in this federation result in higher transactions per second (TPS), thereby achieving scalability goals, and its main application area is DeFi.

However, the federated sidechain model has significant centralized security risks.

Rootstock (RSK)

RSK is also managed by 15 nodes that are responsible for hosting the main network funds, and only 8 signatures are required for verification. Unlike Liquid, RSK's multi-signature keys are managed by hardware security modules (HSMs), and the hook instructions are signed based on the proof-of-work (PoW) consensus, thereby preventing validators with key access rights from directly manipulating the escrow funds.

In terms of sidechain consensus, RSK uses merged mining to use the main network computing power to ensure the security of sidechain transactions. When a large part of the main network computing power is used for merged mining, it can effectively prevent double-spending attacks on the sidechain. RSK has made improvements on the basis of merged mining, and through the fork-aware method, it intervenes in the off-chain consensus of the fork behavior, thereby ensuring the security of the sidechain under low computing power and reducing the possibility of double-spending attacks.

However, merged mining changes miners’ incentives and exacerbates the risk of miner extractable value (MEV), potentially undermining the stability of the system. Over time, merged mining could exacerbate the centralization of mining.

Stacks

Stacks achieves the same finality as Bitcoin by anchoring its chain history to Bitcoin by committing the hash of its sidechain blocks to Bitcoin blocks. Forks in Stacks will only occur if Bitcoin itself forks, thus increasing its resistance to double-spend attacks.

sBTC introduces a new token and incentive model, utilizing a staking bridge that allows up to 150 mainnet validators. Validators need to stake STX tokens to gain permission to approve deposits and withdrawals. The security of the staking bridge depends heavily on the value of the staked assets, which poses a risk to BTC’s cross-chain security during periods of large price fluctuations in the staked assets.

Other sidechain proposals are currently being widely discussed in the community.

Drivechain

The most notable of these is the Drivechain proposal by Paul Sztorc in 2015, which allocates key technologies into BIP 300 (pegging mechanism) and BIP 301 (blind merge mining). BIP 300 defines the logic for adding new sidechains, similar to activating new sidechains through miner signaling (such as soft forks). BIP 301 allows Bitcoin miners to become block producers for sidechains without verifying the specific details of the transaction.

Bitcoin miners are also responsible for approving withdrawal transactions. They initiate withdrawal proposals by creating OP_RETURN outputs in the coinbase transaction of the block they mine. Other miners can then vote on the proposal by supporting or opposing it in each block they mine. Once a withdrawal transaction exceeds a threshold (13,150 blocks), it is executed and confirmed on the Bitcoin main chain.

In fact, miners have complete control over the funds on Drivechain. If funds are stolen, users can only rescue themselves through a user-activated soft fork (UASF), which is difficult to reach consensus. In addition, the unique position of miners in Drivechain increases the risk of MEV, which has been proven in Ethereum.

Spacechain

Spacechain takes a different approach, using a permanent one-way peg (P1WP), where users destroy BTC to obtain tokens on Spacechain, completely bypassing the issue of fund security. These tokens are only used to bid for block space on Spacechain and lack any value storage function.

To ensure the security of the sidechain, Spacechain uses blind merged mining, where users use ANYPREVOUT (APO) to publicly bid for the right to build blocks. Bitcoin miners only need to submit Spacechain block headers in their own blocks without verifying sidechain blocks. However, the launch of Spacechain requires Bitcoin's support for Covenants, and the Bitcoin community is still discussing whether it is necessary to soft fork to add Covenant opcodes.

Overall, Spacechain aims to achieve a sidechain with the same decentralization and censorship resistance as Bitcoin, while improving programmability through its block auction feature.

Softchain

Softchain is another two-way peg (2wp) sidechain proposal by Ruben Somsen that uses the PoW FP consensus mechanism to protect the sidechain. Under normal circumstances, Bitcoin full nodes only need to download the block headers of Softchain to verify the proof of work. In the event of a fork, they will download the orphan block and the corresponding UTXO set commitment to verify the validity of the block.

For the 2wp mechanism, when transferring in, a deposit transaction will be created on the main chain, and Softchain will reference this main chain transaction to obtain funds; when transferring out, a withdrawal transaction will be created on Softchain, and the main chain will reference this transaction to withdraw BTC after a long challenge period. The specific transfer-in and transfer-out mechanisms require soft fork support, so the proposal is named Softchain.

Softchain's proposal adds additional verification costs to the Bitcoin mainnet full node, and the consensus split within Softchain may affect the consensus of the mainnet, posing a possible attack vector for Bitcoin.

Lightning Network

The Lightning Network white paper was published in 2015 and officially launched in 2018. As a second-layer peer-to-peer payment protocol for the Bitcoin network, it aims to transfer a large number of small-amount high-frequency transactions to off-chain processing. It has always been considered the most promising expansion solution for the Bitcoin network.

Core Module

The implementation of the Lightning Network relies on several important modules within Bitcoin, which together ensure the security of network transactions.

First, there are pre-signed transactions. These transactions become safe to use after the SegWit upgrade. SegWit separates the signature from the rest of the transaction data, solving potential problems such as transaction scalability and third-party and second-party transaction tampering. The security of off-chain computation in the Lightning Network is guaranteed by the irrevocable commitment provided by the counterparty, which is executed through a pre-signed transaction. Once a user receives a pre-signed transaction from a counterparty, they can broadcast it to the blockchain at any time to fulfill their commitment.

Next comes multi-signatures. Frequent off-chain fund transfers between two parties require a medium that is jointly controlled by both parties, so multi-signatures are needed, usually using a 2-of-2 scheme. This ensures that fund transfers can only be made with the consent of both parties.

However, 2-of-2 multi-signatures can lead to liveness issues, where if one party does not cooperate, the other party cannot transfer any funds from the multi-signature address, resulting in the loss of the original funds. Time locks can solve the liveness problem; by pre-signing a contract with a time lock to return funds, it can be ensured that even if one party is inactive, the other party can still recover the initial funds.

Finally, hash locks are used to connect multiple state channels to form a network effect. The preimage of the hash acts as a means of communication, coordinating the correct actions between multiple entities.

How it works

Bidirectional channels

To trade using the Lightning Network, both parties first need to open a bidirectional payment channel on Bitcoin. They can conduct an unlimited number of transactions off-chain, and submit the latest status to the Bitcoin blockchain to settle and close the payment channel after completing all transactions.

Specifically, the implementation of a payment channel involves the following key steps:

1. Create a multi-signature address. The two parties first need to create a 2-of-2 multi-signature address as the channel's fund lock. Each party holds a private key for signing and provides its own public key.

2. Initialize the channel. The two parties broadcast a transaction on the chain to lock a certain amount of Bitcoin in the multi-signature address as the initial funds of the channel. This transaction is called the "anchor" transaction of the channel.

3. Update the channel status. When making payments within the channel, the two parties exchange pre-signed transactions to update the channel status. Each update generates a new "commitment transaction" representing the current fund allocation. The commitment transaction has two outputs, corresponding to the fund shares of both parties.

4. Broadcast the latest status. Either party can broadcast the latest commitment transaction to the blockchain at any time to withdraw its fund share. To prevent the other party from broadcasting an outdated state, each commitment transaction is accompanied by a corresponding "penalty transaction" that allows one party to claim all of the other party's funds if one party cheats.

5. Close the channel. When both parties decide to close the channel, they can collaborate to generate a "settlement transaction" and broadcast the final allocation of funds to the blockchain. This releases the funds locked in the multi-signature address back to the personal addresses of both parties.

6. On-chain arbitration. If the two parties cannot reach an agreement on closing the channel, either party can unilaterally broadcast the latest commitment transaction to initiate an on-chain arbitration procedure. If there is no dispute within a certain period of time (for example, one day), the funds will be distributed to both parties according to the allocation in the commitment transaction.

Payment Network

By using HTLC (Hash Time Lock Contract), payment channels can be interconnected to form a network that supports multi-hop routing. HTLC uses hash lock as a direct condition and time-locked signature payment as a fallback condition, allowing users to interact based on the original image of the hash before the time lock expires.

When there is no direct channel between two users, the payment can be completed using HTLC across the routing path. In this process, the original image R of the hash plays a vital role in ensuring the atomicity of the payment. In addition, the time lock in the HTLC is set to decrease along the route, ensuring that each hop has enough time to process and forward the payment.

Existing Problems

Fundamentally, the Lightning Network circumvents the external trust assumptions of asset bridging through peer-to-peer state channels, while using time-locked scripts to provide final protection for assets and provide fault protection. This allows unilateral exit in the event of a counterparty's inactivity and non-cooperation. Therefore, the Lightning Network has high practicality in payment scenarios, but it also has several limitations, including:

1. Channel capacity limit: The capacity of the payment channel in the Lightning Network is limited by the initial locked funds and cannot support payments exceeding the channel capacity. This may limit certain use cases, such as commodity trading.

2. Online and synchronization requirements: In order to receive and forward payments in a timely manner, nodes in the Lightning Network need to remain online. If a node is offline for a long time, it may miss some channel state updates, resulting in desynchronization. This can be a challenge for individual users and mobile devices, and will also increase the operating costs of the node.

3. Liquidity management: The routing efficiency of the Lightning Network depends on the distribution of liquidity between channels. If funds are unevenly distributed, some payment paths may become invalid, affecting the user experience. Managing the liquidity balance of the channel requires certain technical and financial resources.

4. Privacy issues: In order to find a feasible payment path, the routing algorithm of the Lightning Network needs to know a certain degree of channel capacity and connection information, which may leak user privacy, such as fund allocation and counterparties. The opening and closing of payment channels may also expose information about participants.

RGB

The original concept of the RGB protocol was inspired by Peter Todd's ideas of client verification and one-time sealing. It was proposed by Giacomo Zucco in 2016 as a scalable and privacy-preserving Bitcoin second-layer protocol.

Core concepts

Client Verification

The verification process in the blockchain involves broadcasting blocks consisting of transactions to the entire network, allowing each node to calculate and verify the transactions within these blocks. This effectively creates a public interest, where nodes in the network assist each individual who submits a transaction to verify, and users provide BTC as a transaction fee as a reward for verification. Client verification is more individual-centric, and state verification is not performed globally, but by individuals involved in a specific state transition. Only the parties that generated the transaction can verify the legitimacy of these state transitions, which significantly enhances privacy, reduces the burden on nodes, and improves scalability.

One-time seal

Peer-to-peer state transitions are risky, and if the complete state transition history is not accessible, users may be defrauded, resulting in double spending. One-time seals are proposed to solve this problem. By using special objects that can only be used once, they can ensure that double spending does not occur, thereby enhancing security. Bitcoin's UTXO (unused transaction output) model is the most suitable form of one-time seal, which is protected by the Bitcoin consensus mechanism and network hash power, allowing RGB assets to inherit Bitcoin's security features.

Crypto commitment

One-time seals need to be combined with cryptographic commitments to ensure that users clearly understand state transitions and prevent double-spending attacks. Commitments tell others that something has happened and cannot be changed later, and the specific details will not be revealed until verification is required. This can be achieved using hash functions. In RGB, the content of the commitment is the state transition, which signals the recipient of the RGB asset through the expenditure of UTXO. The asset recipient then verifies the commitment based on specific data transmitted off-chain by the asset spender.

Workflow

RGB leverages Bitcoin's consensus to ensure double-spending security and censorship resistance, while all state transition verification tasks are delegated off-chain and performed only by the client receiving the payment.

For the issuer of the RGB asset, creating an RGB contract involves initiating a transaction in which a commitment to specific information is stored in an OP_RETURN script within the Taproot transaction conditions.

When the holder of the RGB asset wants to spend it, they need to obtain relevant information from the asset recipient, create an RGB transaction, and submit the details of this transaction. The commitment is then placed in the UTXO specified by the asset recipient, and a transaction is issued to spend the original UTXO and create a new UTXO specified by the recipient. When the asset recipient notices that the UTXO storing the RGB asset has been spent, they can verify the validity of the RGB transaction through the commitment in the Bitcoin transaction. Once the verification is valid, they can confidently confirm the receipt of the RGB asset.

For the recipient of RGB assets, the payer must provide the initial state and state transition rules of the contract, each Bitcoin transaction used in the transfer, the RGB transaction submitted by each Bitcoin transaction, and evidence of the validity of each Bitcoin transaction. The recipient's client uses this data to verify the validity of the RGB transaction. In this setting, Bitcoin's UTXO acts as a container to save the state of the RGB contract. The transfer history of each RGB contract can be represented as a directed acyclic graph (DAG), and the recipient of the RGB asset can only access the history related to the assets it holds, but not any other branches.

Advantages and Disadvantages

Lightweight Verification

Compared to the full verification required by the blockchain, the RGB protocol greatly reduces the verification cost. Users do not need to traverse all historical blocks to obtain the latest status. They only need to synchronize the history related to the received assets to verify the validity of the transaction.

This lightweight verification makes peer-to-peer transactions easier and further reduces dependence on centralized service providers, enhancing decentralization.

Scalability

The RGB protocol only requires a hash commitment, inherits the security of Bitcoin, and uses Taproot scripts, consuming almost no additional Bitcoin block space. This makes complex asset programming possible. Using UTXO as a container, the RGB protocol naturally supports concurrency; RGB assets on different transfer branches will not block each other and can be used simultaneously.

Privacy

Unlike typical protocols, only the recipients of RGB assets can access the history of asset transfers. Once used, they cannot access the history of future transfers, which greatly ensures the privacy of users. The transaction of RGB assets is not associated with the transfer of Bitcoin UTXO, so outsiders cannot track RGB transactions on the Bitcoin blockchain.

In addition, RGB supports blind output, which means that the payer cannot determine which UTXO the RGB asset will be paid to, further enhancing privacy and censorship resistance.

Disadvantages

When RGB assets change hands many times, the new asset recipient may face a considerable verification burden to verify the lengthy transfer history, which may lead to longer verification time and loss of the ability to quickly confirm transactions. For nodes running in the blockchain, since they are always synchronized with the latest state, the time required to verify the state transition after receiving a new block is actually limited.

The community is discussing the possibility of reusing historical calculations, and recursive ZK proofs may achieve constant time and size of state verification.

Rollup

Overview

Rollup is the best expansion solution for the Ethereum ecosystem, derived from years of exploration from state channels to Plasma, and finally evolved to Rollup.

Rollup is an independent blockchain that collects transactions from the Bitcoin chain, batches multiple transactions, executes these transactions, and submits batch data and state commitments to the main chain. This enables off-chain transaction processing and state updates. To maximize scalability, Rollup usually uses a centralized sorter at this stage to improve execution efficiency without compromising security, as security is ensured by the main chain's verification of Rollup state transitions.

As the Ethereum ecosystem's Rollup solution matures, the Bitcoin ecosystem has also begun to explore Rollups. However, a key difference between Bitcoin and Ethereum is the lack of programming capabilities to perform the calculations required to build on-chain Rollups. Currently, the main focus is on achieving sovereign Rollups and OP Rollups.

Classification

Rollups can be divided into two main categories: optimistic Rollups and validity Rollups (ZK Rollups), the main difference being the method of state transition verification.

Optimistic Rollup uses an optimistic verification method. During the dispute period after each batch of transactions is submitted, anyone can view the off-chain data, raise objections to the problematic batches, and submit proofs of error to the main chain, thereby punishing the Sequencer. If no valid proof of error is submitted during the dispute period, the transaction batch is deemed valid and the status update is confirmed on the main chain.

Validity Rollup uses Validity Proof for verification. Sequencer uses a zero-knowledge proof algorithm to generate a concise validity proof for each batch of transactions, proving that the state transition of the batch is correct. Each update requires submitting a proof of validity of the transaction batch to the main chain, which verifies the proof and immediately confirms the status update.

The advantage of Optimistic Rollup is that it is relatively simple and requires few modifications on the main chain, but the disadvantage is that the transaction confirmation time is long (depending on the dispute period) and the data availability requirements are high. The advantage of Validity Rollup is that the transaction confirmation speed is fast, it is not affected by the dispute period, and the privacy of transaction data can be guaranteed, but the generation and verification of zero-knowledge proofs requires a lot of computational overhead.

Celestia also proposed the concept of sovereign Rollup, in which the transaction data of Rollup is published to a dedicated data availability (DA) layer blockchain, which is responsible for data availability, while the sovereign Rollup itself is responsible for execution and settlement.

Exploration and Discussion

Bitcoin-based Rollups are still in their early stages. Due to differences in accounting models and programming languages ​​with Ethereum, it is challenging to directly copy Ethereum. The Bitcoin community is actively exploring innovative solutions.

Sovereign Rollup

On March 5, 2023, Rollkit was announced as the first framework to support Bitcoin sovereign Rollups. Sovereign Rollups builders can use Rollkit to publish availability data on Bitcoin.

Rollkit is inspired by Ordinals and uses Taproot transactions to publish data. Taproot transactions that meet the public memory pool standard can contain up to 390KB of data, while non-standard Taproot transactions directly published by miners can contain nearly 4MB of arbitrary data.

Rollkit essentially provides an interface for reading and writing data on Bitcoin, providing middleware services that transform Bitcoin into a DA layer.

The idea of ​​sovereign Rollup has been greatly questioned. Many critics claim that sovereign Rollup based on Bitcoin only uses Bitcoin as a bulletin board and cannot inherit the security of Bitcoin. In fact, if transaction data is only submitted to Bitcoin, it will only increase activity-ensuring that all users can access and verify relevant data through Bitcoin. However, security can only be defined by the sovereign Rollup itself and cannot be inherited. In addition, block space on Bitcoin is extremely valuable, and submitting complete transaction data may not be a good decision.

OP Rollup and Validity Rollup

Although many Bitcoin Layer2 projects claim to be ZK Rollups, they are essentially closer to OP Rollups and involve Validity Proof technology. But the current programming capabilities of Bitcoin are not enough to support direct Validity Proof verification.

Currently, Bitcoin's opcode set is very limited, and even multiplication cannot be calculated directly. Verifying validity proofs requires extended opcodes, which largely depends on the implementation of recursive contracts. The community is actively discussing options including OP_CAT, OP_CHECKSIG, OP_TXHASH, etc. Ideally, adding OP_VERIFY_ZKP might solve the problem without any other modifications, but this is unlikely. In addition, the stack size limit also hinders efforts to verify validity proofs in Bitcoin scripts, and many explorations are ongoing.

So how do validity proofs work? Most projects publish the declared differences and validity proofs of batched transactions to Bitcoin in the inscribe format and use BitVM for optimistic verification. In this scheme, the operator of the bridge acts as a federation, managing user deposits. Before the user deposits, the federation pre-signs the UTXO to ensure that the deposit can only be legally claimed by the operator. After obtaining the pre-signature, the BTC is locked into the N/N multi-signature Taproot address.

When a user requests a withdrawal, Rollup sends the withdrawal root with the validity proof to the Bitcoin chain. The operator initially pays out of pocket to meet the user's withdrawal needs, and then the BitVM contract verifies the validity. If each operator believes the proof is valid, they will repay the operator through multi-signature; if someone believes there is fraud, a challenge procedure will be initiated and the wrong party will be punished.

This process is essentially the same as OP Rollup, where the trust assumption is 1/N - as long as one validator is honest, the protocol is secure. As for the validity proof, its purpose is not to make verification easier for the Bitcoin network, but to make it easier for individual nodes to verify.

However, the technical implementation of this scheme may face challenges. In Ethereum's OP Rollup project, Arbitrum has been developed for many years, and its Fraud Proof is still submitted by permissioned nodes; Optimism still does not support Fraud Proof, which shows the difficulty of implementation.

With the support of Bitcoin Covenant, the pre-signature operation in the BitVM bridge can be performed more efficiently, which still needs to be agreed upon by the community.

From the perspective of security properties, by submitting the Rollup block hash to Bitcoin, Bitcoin gains the ability to resist reorganization and double spending, while the optimistic bridge brings a 1/N security assumption. The censorship resistance of the optimistic bridge is also expected to be further improved.

Conclusion: Layer 2 is not a panacea

When we study various 2-layer solutions, it is clear that each solution has its limitations. The effectiveness of the 2-layer depends largely on the ability of the 1-layer (i.e. Bitcoin) under specific trust assumptions.

Without SegWit upgrades and time locks, the Lightning Network cannot be successfully established; without Taproot upgrades, commitments in RGB cannot be efficiently submitted; without OP_CAT and other Covenants, Validity Rollups on Bitcoin cannot be realized...

Many Bitcoin maximalists believe that Bitcoin should never change, new features should not be added, and all defects should be solved by 2-layer solutions. However, this is unachievable; layer 2 is not a panacea. We need a stronger layer 1 to build a more secure, efficient, and scalable layer 2.

In our next post, we will explore attempts to enhance Bitcoin’s programmability.