Written by Chakra Research
In addition to the native expansion solution mentioned in the first part, another way to expand Bitcoin is to build an additional layer of protocol on top of Bitcoin, called Layer 2. The most critical points of the Layer 2 solution are secure two-way bridging and inheriting Bitcoin's consensus security.
Sidechain
The origin of the sidechain concept can be traced back to "Enabling Blockchain Innovations with Pegged Sidechain" submitted by blockStream in 2014, which is a relatively simple expansion solution.
working principle
The sidechain is a blockchain that runs completely independently from the main chain, has its own consensus protocol, and can serve as a testing ground for innovation on the main chain. When a malicious incident occurs on the sidechain, the damage is completely limited to the sidechain itself and has no impact on the main chain. The sidechain can use a consensus protocol with a higher TPS, increase the programming capabilities on the chain, and achieve BTC enhancement.
The sidechain can realize the transfer of Bitcoin between different blockchains through two-way peg or one-way peg. Of course, in reality BTC can only stay on the Bitcoin network, so we need an anchoring mechanism to connect the BTC in the sidechain with the BTC on the Bitcoin network.
One-way peg requires users to send BTC on the mainnet to an unavailable address for destruction, and then they will get the corresponding amount of BTC on the sidechain, but the process cannot be reversed. Two-way peg is a further upgrade of one-way peg, allowing BTC to move back and forth between the mainchain and the sidechain. Unlike sending to an unavailable address for destruction, two-way peg will lock BTC through control scripts such as multi-signatures and mint new BTC on the sidechain. When the user wants to return to the mainnet, the BTC on the sidechain will be burned and the previously locked B TC will be released on the mainnet.
The implementation of one-way peg is much simpler than two-way peg because there is no need to manage the relevant status on the Bitcoin network. However, the sidechain assets generated by one-way peg may be worthless due to the lack of a reverse anchoring mechanism.
There are different solutions and different security levels for the verification of locking transactions on the main chain and destroying transactions on the side chain. The simplest is to use external verification by multi-signature participants, but the centralization risk is high. A better choice is to use SPV Proof to achieve decentralized verification. Of course, since the Bitcoin mainnet lacks the necessary programming capabilities, it cannot perform SPV verification and can only choose other methods, usually multi-signature custody.
Problems and ideas
There are two main issues that sidechains are criticized for:
Cross-chain asset dependence on validators: Since the Bitcoin mainnet is not yet able to implement smart contracts, it is impossible to handle cross-chain asset transfers through trustless contract logic. When crossing back from the sidechain to Bitcoin, it is necessary to rely on a group of validators to complete the operation, which involves trust assumptions and the risk of fraud.
The sidechain cannot inherit the security of the main chain: the sidechain runs completely independently of the main network and cannot inherit the security of the main network. Malicious block reorganization and other events may occur.
In this regard, the ideas of side chains include relying on authority (alliance type), relying on economic security (PoS), relying on decentralized Bitcoin miners (Merged Mining), and relying on hardware security modules (HSM). The custody of funds on Bitcoin and the block production of the side chain can be the responsibility of different roles, thereby introducing more complex security mechanisms.
Case Introduction
Liquid
The first form of sidechain was the consortium sidechain, where multiple pre-selected entities acted as validators and were responsible for the custody of mainnet funds and block generation on the sidechain.
Liquid is a representative of the consortium sidechain, with 15 participants acting as validators. The private key management method is not public, and 11 signatures are required for verification. The blocks on the Liquid sidechain are also jointly maintained by 15 participants. The consortium chain with a low number of nodes can achieve a higher TPS and achieve the expansion goal. The main application scope is DeFi.
The alliance side chain approach has significant centralized security risks.
Rootstock (RSK)
RSK also has 15 nodes acting as the mainnet fund custodian, and only 8 signatures are required for verification. The difference from Liquid is that the multi-signature key is managed by the hardware security module HSM, and the peg-out instruction is signed according to the PoW consensus to prevent the validator holding the key from directly manipulating the custodial funds.
In terms of sidechain consensus, RSK uses Merged Mining to ensure the security of transactions on the sidechain with the help of the mainnet computing power. When the proportion of merged mining computing power to the mainnet is high, it can better prevent double-spending attacks on the sidechain. RSK has made improvements to Merged Mining to ensure the security of the sidechain under low hash rates, and adopts a fork-aware method to intervene in the off-chain consensus on forking behavior to reduce the probability of double spending.
However, Merged Mining changes the incentives of miners and increases the risk of MEV, which may eventually shake the stability of the system. In the long run, Merged Mining may increase the centralization of mining.
Stacks
Stacks anchors the Stacks chain history to Bitcoin by submitting the block hash of the side chain to the Bitcoin block, and has the same finality as Bitcoin. The fork of Stacks can only be caused by the fork of Bitcoin, which improves the ability to resist double spending.
sBTC introduces a new token STX and an incentive model, using a pledge bridge approach, allowing up to 150 mainnet validators. The so-called pledge bridge requires validators to pledge STX tokens to obtain permission to approve deposits and withdrawals. The security of the pledge bridge is heavily dependent on the value of the pledged assets. When the value of the pledged assets fluctuates violently, the security of BTC cross-chain is easily compromised. If the value of the pledged assets is lower than the value of the cross-chain assets, the validator has an incentive to do evil.
There are also some sidechain proposals that are being widely discussed in the community.
Drivechain
The most popular one is Drivechain proposed by Paul Sztorc in 2015. The key technologies in the solution have been assigned BIP 300 (pegging mechanism) and BIP 301 (blind merge mining). BIP 300 defines the logic of adding a new sidechain in detail. Activating a new sidechain is similar to activating a soft fork through miner signals. BIP 301 allows Bitcoin miners to become block producers of sidechains without verifying the specific transaction content.
Bitcoin miners are also responsible for approving withdrawal transactions. Miners first need to create an OP_RETURN output in the coinbase transaction of the block they mined to propose a withdrawal transaction. After that, miners can vote on the proposal. They can vote for or against the proposal when each block is mined. Once a withdrawal transaction exceeds the threshold (13150 blocks), the withdrawal transaction is officially executed and confirmed by the Bitcoin main chain.
In fact, miners fully control the funds on Drivechain. If funds are stolen, users can only save themselves through UASF (user-activated soft fork), but it is very difficult to reach consensus. In addition, the unique position of miners in Drivechain exacerbates the risk of MEV, which has been verified in Ethereum.
Spacechain
Spacechain takes a different approach and uses Perpetual 1 way peg (P1WP), where users burn BTC to obtain tokens on Spacechain, directly skipping the issue of fund security. The token can only be used to auction block space on Spacechain, and does not have any value storage function.
To ensure the security of the sidechain, Spacechain uses blind merged mining, where other users use ANYPREVOUT (APO) to publicly bid for the right to build blocks. Bitcoin miners only need to commit to Spacechain's block header in the block, without verifying the sidechain block. However, the launch of Spacechain requires the support of Covanent, and the Bitcoin community is still discussing the necessity of adding Covanent opcodes through soft forks.
In general, Spacechain can realize a side chain with the same decentralization and anti-censorship properties of Bitcoin and more programmability through the block auction function on Bitcoin.
Softchain
Softchain is a 2wp sidechain proposal proposed by Ruben Somsen, the author of Spacechain. It uses the PoW FP consensus mechanism to ensure the security of the sidechain. Under normal circumstances, a full Bitcoin node only needs to download the block header of the softchain to verify the proof of work. When a fork occurs, the orphan block and the corresponding UTXO set commitment are downloaded to verify the validity of the block.
For the 2wp mechanism, a deposit transaction is created on the main chain during peg-in, and the main chain transaction is referenced on the softchain to obtain funds; a withdrawal transaction is created on the softchain during peg-out, and the main chain references the transaction to retrieve BTC, and the withdrawal process needs to wait for a long challenge period before it can be completed. The specific peg-in and peg-out mechanisms require soft fork support, so the scheme is called Softchain.
The Softchain solution creates additional verification costs for the full nodes of the Bitcoin mainnet. The split of the Softchain consensus may affect the achievement of the mainnet consensus and become a possible means of attack on the Bitcoin mainnet.
Lightning Network
The Lightning Network released its white paper in 2015 and was officially launched in 2018. As a Layer2 p2p payment protocol on Bitcoin, it aims to transfer a large number of small, high-frequency transactions to off-chain processing. For a long time, it has been considered the most promising expansion solution for the Bitcoin network.
Core Modules
The implementation of Lightning Network is inseparable from several important modules in Bitcoin, which together ensure the security of Lightning Network transactions.
The first is pre-signed transactions. Pre-signed transactions only become safe and available after the SegWit upgrade. SegWit separates signatures from the rest of the transaction data, solving potential circular dependencies, third-party transaction tampering, and second-party transaction tampering. The security of off-chain computing in the Lightning Network is guaranteed by the irrevocable commitment given by the other party, and this commitment is achieved through pre-signed transactions. After receiving the pre-signed transaction given by the other party, the user can broadcast the transaction to the chain at any time to fulfill the commitment.
The second is multi-signature. Frequent off-chain fund transfers between two parties require a carrier, which requires both parties to have certain control rights, so multi-signature is required, generally using 2/2 multi-signature, which ensures that the transfer of funds can only be carried out with the mutual consent of both parties.
However, 2/2 multi-signatures will cause activity problems, that is, if the other party does not cooperate, the user cannot transfer any assets from the multi-signature address, resulting in the loss of the original funds. Time locks can solve the activity problem. By pre-signing a contract with a time lock to return funds, it can ensure that even if one party is inactive, the other party can recover the initial funds.
Finally, there is the hash lock, which can connect multiple state channels and build a network. The original image of the hash will serve as a communication medium to coordinate the correct operation of multiple entities.
Running the process
Two-way channel
The two parties using the Lightning Network to conduct transactions first need to open a two-way payment channel on Bitcoin. Both parties can conduct any number of transactions off-chain. After all transactions are completed, the latest status is submitted to the Bitcoin chain to complete the settlement and close the payment channel.
Specifically, the implementation of the payment channel involves the following key steps:
Create a multi-signature address. Both parties in the channel first need to create a 2-of-2 multi-signature address as the channel's fund lock address. Both parties hold a signature private key and provide their own public key.
Initialize the channel. Both parties broadcast a transaction on the chain, locking a certain amount of Bitcoin into a multi-signature address as the initial funds for the channel. This transaction is called the "anchor" transaction of the channel.
Update channel status. When making payments in a channel, both parties update the channel status by exchanging pre-signed transactions. Each update generates a new "commitment transaction" representing the current state of funds allocation. The commitment transaction has two outputs, corresponding to the funds share of both parties.
Broadcast the latest status. Any party in the channel can broadcast the latest commitment transaction to the blockchain at any time to withdraw their share of funds. In order to prevent the other party from broadcasting the old status, each commitment transaction has a corresponding "penalty transaction". If the other party cheats, you can get all the other party's funds.
Closing the channel. When both parties decide to close the channel, they can collaborate to generate a "settlement transaction" to broadcast the final fund allocation status to the blockchain. In this way, the funds locked in the multi-signature address are released back to the personal addresses of both parties.
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 start the on-chain arbitration process. If there is no objection within a certain period of time (such as 1 day), the funds will be sent to both parties according to the allocation of the commitment transaction.
Payment Network
Payment channels can be connected to form a network, supporting multi-hop routing, which is achieved through HTLC. HTLC uses hash lock as a direct condition and signature payment with time lock as a backup condition. Users can interact around 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 with the help of HTLC between routers. The hash original image R plays a key role in the whole process, ensuring the atomicity of the payment. At the same time, the time lock of HTLC is set to decrease along the way, ensuring that each hop has enough time to process and forward the payment.
Problems
In essence, the Lightning Network circumvents the external trust assumption of asset bridging through the p2p state channel, and uses the time lock script to provide the ultimate guarantee of assets, which can provide fault protection. In the case of the other party losing activity and not cooperating, a unilateral exit can be completed. Therefore, the Lightning Network has a high use value in payment scenarios, but it also has many limitations, mainly including:
Channel capacity limitation. The capacity of the payment channel in the Lightning Network is limited by the initial locked funds and cannot support large payments that exceed the channel capacity. This may limit certain application scenarios, such as commodity trading.
Online and synchronous. In order to receive and forward payments in a timely manner, the nodes of the Lightning Network need to remain online. If the node is offline for a long time, some channel status updates may be missed, resulting in status out of sync. This may be a challenge for individual users and mobile devices, and also increases the cost of node operation.
Liquidity management. The routing efficiency of the Lightning Network depends on the liquidity distribution of the channel. If the funds are unevenly distributed, some payment paths may fail, affecting the user experience. Managing the liquidity balance of the channel requires certain technical and financial costs.
Privacy leakage. In order to find available payment paths, the Lightning Network's routing algorithm needs to know the capacity and connectivity information of the channel to a certain extent. This may leak the privacy of some users, such as fund distribution, counterparties, etc. The opening and closing of payment channels may also expose the information of related participants.
RGB
The original conception of the RGB protocol was inspired by the concepts of client verification and one-time sealing proposed by Peter Todd. It was proposed by Giacomo Zucco in 2016 and is a scalable, privacy-preserving Bitcoin layer 2 protocol.
main idea
Client Validation
The verification process of the blockchain is to broadcast the blocks composed of transactions to all, allowing each node to calculate the transactions in the block and complete the verification. This actually creates a public good, that is, nodes across the network help each individual who submits a transaction complete verification, and users provide BTC as a handling fee as an incentive to help with verification. Client-side verification is more individual-centered. State verification is not performed globally, but is verified by individuals participating in specific state transitions. Only the parties that generate the transaction verify the validity of the state transition. This significantly improves privacy and also Reduces the burden on nodes and improves scalability.
One-time seal
There is a hidden danger in peer-to-peer state transitions. If users cannot collect the complete state transition history, they may be defrauded and double spending may occur. One-time sealing is proposed to solve this problem. Through a special object that can only be used once, double spending is ensured not to occur, thereby improving security. Bitcoin's UTXO is the most suitable one-time sealing object, which is guaranteed by Bitcoin's consensus mechanism and the computing power of the entire network. Therefore, RGB assets can inherit the security of Bitcoin.
Cryptographic Commitment
One-time sealing needs to be combined with cryptographic commitments to ensure that users clearly know when state transitions have occurred and to avoid double-spending attacks. A commitment is to inform others that something has happened and cannot be modified afterwards, but there is no need to expose the specific event until the moment of verification. We can use hash functions to make commitments. In RGB, the content of the commitment is the state transition. Through the spending of UTXO, the recipient of the RGB asset will receive a signal of state transfer, and then verify the commitment against the specific data transmitted off-chain by the spender of the asset.
work process
RGB uses Bitcoin's consensus to ensure double-spending security and censorship resistance, and all state transfer verification work is transferred off-chain and only verified by the client that accepts the payment.
For the issuer of RGB assets, it is necessary to create an RGB contract by initiating a transaction, and the commitment of specific information will be stored in the OP_RETURN script of a spending condition in the Taproot transaction.
When the holder of RGB assets wants to spend, he needs to obtain relevant information from the recipient of the assets, create an RGB transaction, commit to the details of the RGB transaction, place the committed value into the UTXO specified by the asset recipient, and issue a transaction to spend the original UTXO and create the UTXO specified by the recipient. When the recipient of the assets observes that the UTXO that originally stored the RGB assets has been spent, the validity of the RGB transaction can be verified through the commitment in the Bitcoin transaction. Once the verification is valid, it is considered that it has indeed received the RGB assets.
For the recipient of RGB assets, the payer needs to provide the initial state and state transition rules of the contract, the Bitcoin transaction used for each transfer, the RGB transaction promised by each Bitcoin exchange, and the evidence of the validity of each Bitcoin transaction. The recipient's client verifies the validity of the RGB transaction based on these data. Among them, Bitcoin's UTXO is used as a container to store the state of the RGB contract. The transfer history of each RGB contract can be represented as a directed acyclic graph. The recipient of the RGB asset can only obtain the history related to the RGB asset he holds, but cannot obtain other branches.
Advantages and Disadvantages
Lightweight verification
Compared with the complete verification of the blockchain, the RGB protocol greatly reduces the cost of verification. Users do not need to traverse all historical blocks to obtain the latest status. Instead, they only need to synchronize the historical records related to the assets they receive to verify the validity of the transaction.
This lightweight verification makes peer-to-peer transactions easier, further eliminating the need for centralized service providers and increasing the level of decentralization.
Scalability
The RGB protocol only needs to inherit the security of Bitcoin through a hash commitment. Through the Taproot script, almost no additional Bitcoin chain space is consumed, which makes complex asset programmability possible. Due to the use of UTXO as a container, the RGB protocol has natural concurrency, and RGB assets on different transfer branches will not block each other and can be spent at the same time.
Privacy
Different from general protocols, only the recipient of RGB assets can obtain the historical transfer status of RGB assets. Once the spending is completed, future transfer status cannot be obtained, which significantly guarantees user privacy. There is no correlation between the transaction of RGB assets and the transfer of Bitcoin UTXO, and others cannot obtain traces of RGB transactions on the Bitcoin chain.
In addition, RGB also supports blind spending, and the payer cannot clearly determine which UTXO the RGB assets will be paid to, further improving privacy and enhancing anti-censorship capabilities.
insufficient
When RGB assets have been transferred many times, the new user who receives the assets will be forced to verify the lengthy transfer history, resulting in a heavy verification burden, which may take a long time to verify and lose the ability to quickly confirm. For nodes that keep running in the blockchain, since they are always synchronizing the latest status, the time to receive the new zone fast verification status transfer is limited each time.
The community is discussing the possibility of reusing historical computations, and recursive ZK Proof has the opportunity to achieve state verification with constant time and size.
Rollup
Overview
Rollup is the best scaling solution that the Ethereum ecosystem has come up with after years of exploration, evolving from state channels to Plasma and finally to Rollup.
Rollup is an independent blockchain that collects transactions outside the Bitcoin chain, packages multiple transactions into a batch and executes them, and submits the data and status commitments of this batch to the main chain, realizing off-chain transaction processing and status updates. In order to maximize capacity expansion, Rollup usually uses a centralized sorter at this stage to improve execution efficiency without sacrificing security, because security is guaranteed by the verification of Rollup state transitions on the main chain.
As the Ethereum ecosystem's Rollup solution matures, the Bitcoin ecosystem has also begun to experiment with Rollup. However, the most critical difference between Bitcoin and Ethereum is the lack of programming capabilities, and the inability to perform the calculations required to build Rollup on the chain, which means that people can only try to implement sovereign Rollup and OP Rollup.
Classification
Depending on the verification method of state transfer, Rollup can be divided into two categories, Optimistic Rollup and Validity Rollup (ZK Rollup).
Optimistic Rollup uses an optimistic verification method. During the dispute period after each transaction batch is submitted, anyone can check the off-chain data, object to the problematic transaction batch, submit fraud proof to the main chain, and fine the Sequencer. If there is no valid fraud proof after the dispute period, the transaction batch is considered valid and the status update is confirmed on the main chain.
Validity Rollup uses Validity Proof to complete verification. Sequencer uses a zero-knowledge proof algorithm to generate a concise validity proof for each transaction batch to prove that the state transfer of the batch is correct. Each update needs to submit the validity proof of the transaction batch to the main chain. The main chain verifies the proof and confirms the status update.
The advantage of Optimistic Rollup is that it is relatively simple to implement and requires fewer modifications to the main chain. However, its transaction confirmation time is longer (depending on the objection period) and requires higher data availability. Validity Rollup has fast transaction confirmation, does not rely on the objection period, and transaction data can remain private, but generating and verifying zero-knowledge proofs requires higher computational overhead.
Celestia also proposed the concept of a sovereign Rollup, in which the transaction data of the Rollup is published to a dedicated DA layer blockchain, which is responsible for data availability, while the sovereign Rollup itself is responsible for execution and settlement.
Explore and discuss
Rollup on Bitcoin is still in its early stages. Due to the differences in accounting models and programming languages from Ethereum, it is difficult to directly copy Ethereum's practical experience. 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 Bitcoin sovereign Rollups, allowing builders of sovereign Rollups to publish availability data on Bitcoin through Rollkit.
Rollkit is inspired by Ordinals and publishes data through Taproot transactions. A standard Taproot transaction through the public memory pool can contain up to 390 KB of data, and a non-standard Taproot transaction directly issued by miners can contain nearly 4 MB of arbitrary data.
Rollkit’s actual work is to provide an interface for sovereign Rollup to read and write data on Bitcoin, provide middleware services to customers, and turn Bitcoin into a DA layer.
The idea of sovereign Rollup has been questioned by many, and many opponents claim that sovereign Rollup on Bitcoin is nothing more than using Bitcoin as a bulletin board and cannot inherit Bitcoin's security at all. In fact, if transaction data is only submitted to Bitcoin, it can only improve activity, that is, all users can obtain the corresponding data through Bitcoin for verification, and security can only be defined by the sovereign Rollup itself and cannot be inherited. In addition, the block space on Bitcoin is very valuable, and submitting the full amount of transaction data may not be a good decision.
OP Rollup & Validity Rollup
Although many Bitcoin second-layer projects call themselves ZK Rollup, they are essentially closer to an OP Rollup, except that the Validity Proof technology is involved in the process. However, Bitcoin's programming capabilities are not yet sufficient to support direct Validity Proof verification.
Currently, Bitcoin's opcode set is very limited, and even multiplication cannot be calculated directly. Verification of Validity Proof requires the expansion of opcodes, and also largely relies on the implementation of recursive contracts. The community is hotly discussing OP_CAT, OP_CHECKSIG, OP_TXHASH, etc. Of course, if we can directly add an OP_VERIFY_ZKP, maybe we don't need any other modifications, but this is obviously unlikely. In addition, the limitation of stack size also hinders the efforts to verify Validity Proof in Bitcoin scripts, and many attempts are being explored.
So how does Validity Proof work? Most projects publish the statediff and Validity Proof of the transaction batch on Bitcoin in the form of an inscription, and use BitVM for optimistic verification. The BitVM bridge replaces the traditional multi-signature scheme here. The Operator of the bridge will form an N-person alliance to schedule the user's deposit. Before the user makes a deposit, the alliance will be required to pre-sign the UTXO to be generated to ensure that the deposit can only be legally collected by the Operator. After obtaining the pre-signature, BTC will be locked to an N/N multi-signature Taproot address.
When a user makes a withdrawal request, Rollup will send the Validity Proof with the withdrawl Root to the Bitcoin chain. The Operator will first meet the user's withdrawal request out of his own pocket, and then verify the validity through the BitVM contract. If each Operator believes that the proof is valid, the Operator will be reimbursed through multi-signature; as long as anyone believes that there is fraud, a challenge process will be carried out, and the wrong party will be slashed.
This process is actually the same as OP Rollup. The trust assumption is 1/N. As long as there is one honest validator, the protocol is secure.
However, the technical implementation of this solution may be difficult. In Ethereum’s OP Rollup project, Arbitrum has been developed for many years, and the current Fraud Proof is still submitted by permissioned nodes; Optimism only recently announced support for Fraud Proof, which shows the difficulty of implementation.
As for the pre-signature operation in the BitVM bridge, it can be implemented more efficiently with the support of Bitcoin Covanent, which is still awaiting community consensus.
In terms of security attributes, by submitting the Rollup block hash to Bitcoin, anti-reorganization and anti-double-spending properties are achieved, and the optimistic bridge brings a 1/N security assumption. However, the bridge's anti-censorship properties can still be further improved.
Conclusion: Layer 2 is not a panacea
Looking at so many Layer 2 solutions, it is easy to find that each solution has limited capabilities. Under certain trust assumptions, the effects that Layer 2 can achieve depend largely on Layer 1, which is the native capabilities of Bitcoin.
Without SegWit upgrade and time lock, the Lightning Network cannot be built smoothly; without Taproot upgrade, RGB commitment cannot be submitted smoothly; without OP_CAT and other Covanent, Validity Rollup on Bitcoin cannot be built smoothly...
Many Bitcoin Maxi believe that Bitcoin should never be changed, new features should not be added, and all defects should be solved by Layer 2. This is impossible. Layer 2 is not a panacea. We need a more powerful Layer 1 to build a more secure, efficient, and scalable Layer 2.
In the next article, we will introduce attempts to improve programmability on Bitcoin, so stay tuned.
