Author: Chakra; Translation: 0xjs@Golden Finance
There are multiple paths to Bitcoin scaling. The first part of our series has described one of them, the “Bitcoin native scaling solution”. Another 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 a secure two-way bridge and the inheritance of Bitcoin consensus security.
Sidechain
The concept of sidechains dates back to 2014, when Blockstream submitted “Enabling Blockchain Innovation with Pegged Sidechains.” It represents a relatively basic approach to scaling.
How does the sidechain 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.
The sidechain can realize the transfer of Bitcoin between different blockchains through two-way 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.
The one-way peg requires 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. The two-way peg is an improvement on the one-way peg, allowing BTC to move back and forth between the mainchain and the sidechain. Instead of destroying by sending to an unavailable address, the two-way peg locks BTC through multi-signature or other control scripts and mints 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 state on the Bitcoin mainnet. However, sidechain assets created through a one-way peg may be worthless because they lack a reverse anchoring 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 has a high centralization risk. A better option is decentralized verification using SPV proofs. However, since the Bitcoin mainnet lacks the necessary programming capabilities to perform SPV verification, other methods must be used, usually multi-signature escrow.
Problems 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 group of validators, which introduces trust assumptions and fraud risks.
2. Sidechains cannot inherit the security of the main chain: Since sidechains run completely independently of the main network, they cannot inherit the security of the main network, which may lead to malicious block reorganization.
To solve these problems, sidechains have adopted methods including reliance on authority (federation), economic security (PoS), decentralized Bitcoin miners (merged mining), and hardware security modules (HSM). Fund custody on Bitcoin and block production on sidechains can be managed by different roles, thereby 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 to act as validators, responsible for custodying assets on the main network and producing blocks on the sidechain.
Liquid is a typical example of a federated sidechain, with 15 parties 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 allow for higher transactions per second (TPS), thus achieving scalability goals, with DeFi being the main application area.
However, the federated sidechain model has significant centralization security risks.
Rootstock（RSK）
RSK is also managed by 15 nodes that are responsible for escrow of 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 hook instructions are signed based on proof-of-work (PoW) consensus, preventing validators with key access from directly manipulating escrow funds.
In terms of sidechain consensus, RSK uses merged mining, which uses the mainnet computing power to ensure the security of sidechain transactions. When a large part of the mainnet computing power is used for merged mining, it can effectively prevent double-spending attacks on the sidechain. RSK has made improvements based on merged mining, and through the fork perception method, it intervenes in the off-chain consensus of 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 the incentives of miners, exacerbating the risk of miner extractable value (MEV), potentially undermining the stability of the system. Over time, merged mining may increase 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 into Bitcoin blocks. Forks in Stacks will only occur if Bitcoin itself forks, thus increasing its resistance to double-spending attacks.
sBTC introduces a new token and incentive model that utilizes 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 proposed by Paul Sztorc in 2015, which divides the 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 having to verify the specific details of transactions.
Bitcoin miners are also responsible for approving withdrawal transactions. They initiate a withdrawal proposal by creating an OP_RETURN output in the coinbase transaction of the block they mined. 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 full control over the funds on Drivechain. If funds are stolen, users can only save 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 confirmed in Ethereum.
Spacechain
Spacechain takes a different approach, using a Perpetual One-Way Peg (P1WP), where users burn BTC to obtain tokens on Spacechain, bypassing the issue of fund security entirely. These tokens are only used to bid for block space on Spacechain and lack any value storage functionality.
To ensure the security of the sidechain, Spacechain uses blind merged mining, where users publicly bid for the right to build blocks using ANYPREVOUT (APO). 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 a soft fork is necessary to add Covenant opcodes.
Overall, Spacechain aims to achieve the same decentralization and censorship-resistant sidechain properties as Bitcoin, while improving programmability through its block auction feature.
Softchain
Softchain is another two-way pegged (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 header of Softchain to verify the proof of work. If a fork occurs, they will download the orphan block and the corresponding UTXO set commitment to verify the validity of the block.
For the 2wp mechanism, when the transfer-in peg is in progress, a deposit transaction will be created on the main chain, and Softchain will reference this main chain transaction to obtain funds; when the transfer-out peg is in progress, a withdrawal transaction will be created on Softchain, and the main chain will reference this transaction to retrieve BTC after a long challenge period. The specific transfer-in peg and transfer-out peg 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 released in 2015 and officially launched in 2018. As a second-layer peer-to-peer payment protocol of the Bitcoin network, it aims to transfer a large number of small and high-frequency transactions to off-chain processing. It has always been considered the most promising expansion plan for the Bitcoin network.
Core Modules
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 became safe to use after the SegWit upgrade. SegWit separates the signature from the rest of the transaction data, solving potential issues such as transaction malleability, third-party and second-party transaction tampering. The security of off-chain computations in the Lightning Network is guaranteed by an 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 the commitment.
Next up is multi-signature. Frequent off-chain transfers of funds between two parties require a medium that both parties control, so multi-signatures are needed, usually using a 2-of-2 scheme. This ensures that the transfer of funds can only be made with the consent of both parties.
However, 2-of-2 multisigs can lead to liveness issues, where if one party does not cooperate, the other party cannot transfer any funds from the multisig address, resulting in loss of the original funds. Timelocks can solve the liveness problem; by pre-signing a contract with a return timelock, it can ensure 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, forming a network effect. The preimage of the hash acts as a means of communication to coordinate the correct operations between multiple entities.
operation flow
Two-way channel
To conduct transactions using the Lightning Network, both parties first need to open a two-way payment channel on Bitcoin. They can conduct an unlimited number of transactions off-chain, and after completing all transactions, submit the latest status to the Bitcoin blockchain to settle and close the payment channel.
Specifically, the implementation of a payment channel involves the following key steps:
1. Create a multi-signature address. Both parties first need to create a 2-of-2 multi-signature address as a fund lock for the channel. Each party holds a private key for signing and provides their own public key.
2. Initialize the channel. Both parties broadcast a transaction on the chain, locking a certain amount of Bitcoin in a multi-signature address as the initial funds for the channel. This transaction is called the "anchor" transaction of the channel.
3. Update channel status. When making payments within a channel, both parties exchange pre-signed transactions to update the channel status. Each update generates a new "commitment transaction" representing the current allocation of funds. The commitment transaction has two outputs, corresponding to the funds share 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 share of funds. In order 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 they cheat.
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 will release 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 the on-chain arbitration procedure. If there is no dispute within a certain period of time (such as 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 the direct condition and time-locked signature payment as the fallback condition, allowing users to interact based on the hashed preimage before the time lock expires.
When there is no direct channel between two users, payments can be completed using HTLCs across routing paths. In this process, the preimage 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.
Problems
Fundamentally, the Lightning Network circumvents the external trust assumptions of asset bridging through peer-to-peer state channels while utilizing time-lock scripts to provide final protection for assets and provide fail-safe. This allows for unilateral exits in the event of a counterparty becoming inactive and uncooperative. As a result, the Lightning Network has high utility in payment scenarios, but it also has several limitations, including:
1. Channel capacity limitation: 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 status 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 channels requires certain technical and financial resources.
4. Privacy issues: In order to find a feasible payment path, the Lightning Network's routing algorithm 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 layer 2 protocol.
Core idea
Client Validation
The verification process in a blockchain involves broadcasting blocks consisting of transactions to the entire network, allowing each node to compute and verify the transactions within these blocks. This effectively creates a public good, with nodes in the network assisting every individual who submits a transaction with verification, with users providing BTC as a transaction fee as a reward for verification. Client-side validation is more individual-centric, and state validation is not performed globally but by individuals involved in specific state transitions. Only the parties generating the transaction can verify the legitimacy of these state transitions, significantly enhancing privacy, reducing node burden, and improving scalability.
One-time seal
There are risks in peer-to-peer state transitions. 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 the security characteristics of Bitcoin.
Cryptographic Commitment
One-time seals need to be combined with cryptographic commitments to ensure that users clearly understand state transitions and prevent double-spending attacks. A commitment tells others that something has happened and cannot be changed later, without revealing specific details until verification is required. This can be achieved using hash functions. In RGB, the content of the commitment is the state transition, which is signaled to the recipient of the RGB asset through the spending of the 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 an RGB asset, creating an RGB contract involves initiating a transaction where a commitment to specific information is stored in an OP_RETURN script within the Taproot transaction conditions.
When the holder of RGB assets 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 for saving 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.
pros and cons
Lightweight Authentication
Compared with the complete 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 to inherit 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, greatly ensuring user privacy. Transactions of RGB assets are not associated with the transfer of Bitcoin UTXO, so outsiders cannot track RGB transactions on the Bitcoin blockchain.
Additionally, RGB supports blind outputs, which means that the payer cannot determine which UTXO the RGB assets will be paid to, further enhancing privacy and censorship resistance.
shortcoming
When RGB assets change hands multiple times, new asset recipients may face a considerable verification burden to verify the lengthy transfer history, which may result in longer verification times 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 computations, and recursive ZK proofs may achieve constant time and size for state verification.
Rollup
Overview
Rollup is the best scaling solution for the Ethereum ecosystem. It originates from years of exploration from state channels to Plasma, and eventually evolved into Rollup.
Rollup is an independent blockchain that collects transactions from off-chain Bitcoin, batches multiple transactions, executes them, and submits batch data and state commitments to the main chain. This enables off-chain transaction processing and state updates. To maximize scalability, Rollup typically 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 and the inability to perform the calculations required to build on-chain Rollups. Currently, the main focus is on implementing sovereign Rollups and OP Rollups.
Classification
Rollups can be divided into two main categories: Optimistic Rollups and ZK Rollups. The main difference lies in 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, object to the problematic batch, and submit an error proof to the main chain, thereby punishing the Sequencer. If no valid error proof is submitted during the dispute period, the transaction batch is deemed valid and the status update is confirmed on the main chain.
The validity of Rollup is verified using Validity Proof. 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 the validity proof 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 the 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.
Explore and discuss
Bitcoin-based Rollups are still in their early stages. Due to differences in Ethereum’s accounting model and programming language, directly copying Ethereum’s approach is challenging. The Bitcoin community is actively exploring innovative solutions.
Sovereign Rollup
On March 5, 2023, Rollkit announced that it had become the first framework to support sovereign Rollups on Bitcoin. Builders of sovereign Rollups can use Rollkit to publish availability data on Bitcoin.
Rollkit is inspired by Ordinals and uses Taproot transactions to publish data. Taproot transactions that comply with 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, and provides middleware services that transform Bitcoin into a DA layer.
The idea of a sovereign Rollup has been met with great skepticism. Many critics claim that a sovereign Rollup based on Bitcoin simply uses Bitcoin as a bulletin board and cannot inherit Bitcoin's security. In fact, if transaction data is only submitted to Bitcoin, it will only increase activity - ensuring that all users can access and verify the 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 full 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. However, Bitcoin's current programming capabilities are not sufficient 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 extending the 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 does the validity proof 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 an N/N multi-signature Taproot address.
When a user requests a withdrawal, Rollup sends the withdrawal root with a proof of validity to the Bitcoin chain. The operator initially pays out of pocket to meet the user's withdrawal request, and then the BitVM contract verifies the validity. If each operator believes the proof is valid, they repay the operator through multi-signature; if someone believes there is fraud, a challenge procedure is initiated and the wrong party is 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 validity proofs, their 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 solution may face challenges. In Ethereum's OP Rollup project, after years of development, Arbitrum's 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, pre-signing operations in the BitVM bridge can be performed more efficiently, still pending community consensus.
From the perspective of security properties, by submitting Rollup block hashes 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
As we examine various layer 2 solutions, it becomes clear that each has its limitations. The effectiveness of layer 2 depends heavily on the ability of layer 1 (i.e. Bitcoin) to function under certain trust assumptions.
Without the SegWit upgrade and time locks, the Lightning Network cannot be successfully established; without the Taproot upgrade, the commitments in the 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, no new features should be added, and all flaws should be solved through layer 2 solutions. However, this is unattainable; 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 article, we will explore attempts to increase Bitcoin’s programmability.
