jakiro
Author: Chakra; Translation: 0xjs@Bitchain Vision
There are multiple paths for Bitcoin expansion, and the first part of our series has described one of the paths “Bitcoin native expansion solution”, Another path is to establish an additional layer of protocols above Bitcoin, called Layer 2. The most critical aspect of the 2-layer solution is the two-way bridge of security and the inheritance of Bitcoin consensus security.
Side chain
The concept of sidechain dates back to 2014, when Blockstream submitted “Using hooked sidechains to achieve blockchain innovation.”It represents a relatively basic method of scaling.
How to run the side chain
Sidechain is a blockchain that runs independently of the main chain, with its own consensus protocol and can serve as a test site for main chain innovation.When adverse events occur on the side chain, the damage is completely limited to the side chain 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 enhancement of BTC capabilities.
Sidechain can realize the transfer of Bitcoin between different blockchains through two-way or one-way peg.But in reality, BTC can only reside on the Bitcoin main network, so an anchoring mechanism is needed to connect BTC on the side chain with BTC on the Bitcoin main network.
The one-way hook requires the user to send BTC from the main network to an unavailable address for destruction, and then cast an equal amount of BTC on the side chain, but this process is irreversible.Bidirectional hooks are an improvement in one-way hooks that allow BTC to move back and forth between the main chain and the side chain.The two-way hook is not destroyed by sending to an unavailable address, but locking the BTC through multiple signatures or other control scripts, casting new BTC on the sidechain.When a user wants to return to the main network, the BTC on the side chain will be destroyed, and the originally locked BTC will be released on the main network.
The implementation of one-way peg is much simpler than a two-way peg, because it does not require managing the relevant state on the Bitcoin main network.However, sidechain assets created through one-way hooks may be worthless because they lack the reverse anchoring mechanism.
There are different solutions and security levels for locked transactions on the main chain and destroy transactions on the side chain.The easiest way is to perform external verification through multi-signature participants, but this poses a high risk of centralization.A better option is to use SPV proof for decentralized verification.However, because the Bitcoin mainnet lacks the necessary programming capabilities and cannot perform SPV verification, other methods must be used, usually multi-signature hosting.
Problems and methods
The main criticisms of side chains include:
1. Cross-chain asset dependency verifier: Since the Bitcoin main network still cannot implement smart contracts, cross-chain asset transfer cannot be managed through contract logic without trust.Returning assets from sidechains to Bitcoin requires relying on a set of validators, introducing trust assumptions and fraud risks.
2. Sidechains cannot inherit the security of the main chain: Because sidechains operate 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, the sidechain adopts methods including relying on authoritative institutions (federal), economic security (PoS), decentralized Bitcoin miners (merger mining), and hardware security modules (HSM).Fund custody on Bitcoin and block production on sidechains can be managed by different roles, introducing more complex security mechanisms.
Case study
Liquid
One of the earliest forms of sidechains is a federated sidechain, which relies on a pre-selected group of entities as validators, responsible for custodying assets on the main network and generating blocks on the sidechain.
Liquid is a classic example of a federal sidechain with 15 participants acting as validators.The management of private keys is not publicly available, and verification requires 11 of the 15 signatures.Block production on the Liquid sidechain is also maintained by these 15 participants.The number of nodes in this federation is smaller and therefore higher transaction volume per second (TPS) to achieve scalability goals, and its main application area is DeFi.
However, the federal sidechain model poses significant centralized security risks.
Rootstock (RSK)
RSK is also managed by 15 nodes that host the main network funds and only 8 signatures are required for verification.Unlike Liquid, RSK’s multi-signature keys are managed by the Hardware Security Module (HSM), and the hook instructions are signed based on Proof of Work (PoW) consensus, preventing verifiers with key access to directly manipulate custodial funds.
In terms of side chain consensus, RSK adopts merge mining and uses the main network computing power to ensure the security of side chain transactions. When a large part of the main network computing power is used for merge mining, it can effectively prevent the double-spending attack of side chains.RSK has improved on the basis of merger mining, and through fork perception, off-chain consensus intervention is carried out on the fork behavior, thereby ensuring the security of side chains under low computing power and reducing the possibility of double-spending attacks.
However, merger mining has changed the incentive mechanism for miners, exacerbating the risk of miners extractable value (MEV), and potentially undermining the stability of the system.Over time, merger mining may exacerbate the centralization of mining.
Stacks
Stacks achieves the same finality as Bitcoin by submitting the hash value of its sidechain block into the Bitcoin block and anchoring its chain history to Bitcoin.Only when Bitcoin itself forked will the fork in Stacks occur, thereby enhancing its resistance to double-spending payment attacks.
sBTC introduces a new token and incentive model that utilizes a staking bridge that allows up to 150 mainnet validators.Verifiers need to pledge STX tokens to obtain permission to approve deposits and withdrawals.The security of the pledge bridge depends to a large extent on the value of the pledged assets, which poses a risk to the cross-chain security of BTC during a period of substantial fluctuation in the price of the pledged assets.
Other sidechain proposals are currently being discussed extensively in the community.
Drivechain
The most notable of these is the Drivechain proposal proposed by Paul Sztorc in 2015, which allocates key technologies to BIP 300 (hook mechanism) and BIP 301 (blind merger mining).BIP 300 defines the logic of adding new sidechains, similar to activating new sidechains through miner signals (such as soft forks).BIP 301 allows Bitcoin miners to become block producers of sidechains without verifying the specific details of the transaction.
Bitcoin miners are also responsible for approving withdrawal transactions.They initiate withdrawal proposals 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 the withdrawal transaction exceeds the threshold (13,150 blocks), it is executed and confirmed on the Bitcoin main chain.
In fact, miners have complete control over funds on Drivechain.If funds are stolen, users can only save themselves through user activation soft forks (UASF), which is difficult to reach a consensus.In addition, miners’ unique position in Drivechain increases MEV risk, 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 fund security issues.These tokens are only used to bid for block space on Spacechain and lack any store of value capabilities.
To ensure the security of side chains, Spacechain uses blind merger mining, and users use ANYPREVOUT (APO) to publicly bid for the right to build blocks.Bitcoin miners simply submit Spacechain block headers in their blocks without verifying the sidechain blocks.However, Spacechain’s launch requires Bitcoin’s support for Covenants, and the Bitcoin community is still discussing whether it is necessary to perform a soft fork to add Covenant opcodes.
Overall, Spacechain’s goal is to achieve the same decentralized and censor-resistant sidechains as Bitcoin, while improving programmability through its block auction capabilities.
Softchain
Softchain is another bidirectional hook (2wp) sidechain proposal proposed by Ruben Somsen, which uses the PoW FP consensus mechanism to protect sidechains.Under normal circumstances, the full Bitcoin node only needs to download the Softchain block header to verify the proof of work.If a forking occurs, they download orphaned blocks and corresponding UTXO set promises to verify the validity of the block.
For the 2wp mechanism, when transferring to the link, a deposit transaction will be created on the main chain, and Softchain will refer to this main chain transaction to obtain funds; when transferring to the link, a withdrawal transaction will be created on the Softchain, and the main chain willQuote this transaction to retrieve BTC after a longer challenge period.The specific transfer-in and transfer-out hook mechanisms require soft fork support, so the proposal was named Softchain.
Softchain’s proposal adds additional verification costs to the full nodes of the Bitcoin mainnet, and the consensus split within Softchain may affect the consensus on the mainnet and form a possible attack vector for Bitcoin.
Lightning Network
The Lightning Network White Paper was released in 2015 and officially launched in 2018. As a layer 2 peer-to-peer payment protocol for Bitcoin network, it aims to transfer a large number of small-scale high-frequency transactions to off-chain processing. It has always been considered the most promising expansion of Bitcoin network.plan.
Core modules
The implementation of the Lightning Network relies on several important modules within Bitcoin, which jointly ensure the security of online transactions.
First, there is a pre-signature transaction.These transactions become safe to use after SegWit upgrades.SegWit separates signatures from the rest of the transaction data, addressing potential issues such as transaction scalability, third-party and second-party transaction tampering.The security of off-chain calculations in Lightning Network is guaranteed by an irrevocable commitment provided by the counterparty, which is executed through pre-signature transactions.Once users receive a pre-signed transaction from their counterparties, they can broadcast it to the blockchain at any time to fulfill their commitments.
Next is multi-signature.Frequent off-chain funds transfers between the two parties require a media controlled by both parties, so multiple signatures are required, and the 2-of-2 scheme is usually used.This ensures that the transfer of funds can only be carried out with the consent of both parties.
However, 2-of-2 multi-signatures can cause activity issues, and if one party does not cooperate, the other party cannot transfer any funds from the multi-signature address, resulting in loss of the original funds.Time locks can solve the activity problem; by pre-signing a contract with a time lock for return funds, it can ensure that even if one party is inactive, the other party can still recover the initial funds.
Finally, a hash lock is used to connect multiple state channels to form a network effect.The preimage of the hash acts as a means of communication to coordinate the correct operation between multiple entities.
Operation process
Two-way channel
To use the Lightning Network for transactions, both parties first need to open a two-way payment channel on Bitcoin.They can make an unlimited number of transactions off-chain and submit the latest status to the Bitcoin blockchain for settlement and closing the payment channel after all transactions are completed.
Specifically, the implementation of the 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 to serve as the channel’s fund lock.Each party holds the private key for signature and provides its 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 fund of the channel.This transaction is called the “anchor” transaction of the channel.
3. Update channel status.When payments are made within the channel, both parties exchange pre-signed transactions to update the channel status.Each update generates a new “commitment transaction” that represents the current allocation of funds.There are two outputs for the promised transaction, which correspond to the capital share of both parties.
4. Broadcast latest status.Either party can broadcast the latest commitment transactions to the blockchain at any time to withdraw their share of funds.To prevent the other party from broadcasting an outdated state, each promised transaction is accompanied by a corresponding “punishment transaction”. If one party cheats, the transaction allows one party to ask for all the other party’s funds.
5. Close the channel.When both parties decide to close the channel, they can collaborate to generate “settlement transactions” and broadcast the final allocation of funds to the blockchain.This releases funds locked in the multi-signature address back to both parties’ personal addresses.
6. On-chain arbitration.If both parties cannot agree on closing the channel, either party can unilaterally broadcast the latest committed transaction to initiate an on-chain arbitration process.If there is no dispute over a certain period of time (e.g. one day), the funds will be distributed to both parties based on the distribution in the promised transaction.
Payment Network
By using HTLC (Hash Time Locking Contract), payment channels can be interconnected to form a network that supports multi-hop routing.HTLC takes hash lock as a direct condition and time lock signature payment as a fallback condition, allowing users to interact based on the hashed image before the time lock expires.
When there is no direct channel between two users, payment can be completed using HTLC across the routing path.In the process, the hash’s avatar R plays a crucial role in ensuring the atomicity of the payment.Additionally, the time lock in HTLC is set to reduce along the route, ensuring that each jump has enough time to process and forward payments.
Existing problems
Fundamentally, the Lightning Network circumvents the external trust assumption of asset bridging through point-to-point state channels, while using time lock scripts to provide ultimate protection for assets and failure protection.This allows unilateral exit if the counterparty loses activity and does not cooperate.Therefore, Lightning Network is highly practical 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 the node is offline for a long time, it may miss some channel state updates, resulting in out-of-sync.This can be a challenge for individual users and mobile devices and will also increase the operating costs of nodes.
3. Mobility management: The routing efficiency of the Lightning Network depends on the liquidity distribution between channels.If funds are unevenly distributed, some payment paths may become invalid, affecting the user experience.The liquidity balance of management channels requires certain technical and financial resources.
4. Privacy Issue: In order to find a feasible payment path, Lightning Network’s routing algorithm needs to understand a certain level of channel capacity and connection information, which may reveal user privacy, such as fund allocation and counterparty.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 idea of client verification and one-time sealing.It was proposed by Giacomo Zucco in 2016 and is a scalable and privacy-protecting Bitcoin Layer 2 protocol.
Core concept
Client Verification
The verification process in the blockchain involves broadcasting blocks composed of transactions to the entire network, allowing each node to compute and verify transactions within those blocks.This effectively creates a public interest where nodes in the network assist each individual submitting a transaction for verification, and the user provides BTC as a transaction fee as a reward for verification.Client verification is more individual-centered, and state verification is not performed globally, but is performed by individuals participating in a specific state transition.Only the parties that generate transactions can verify the legitimacy of these state transitions, thereby significantly enhancing privacy, reducing node burdens, and improving scalability.
Disposable seal
Point-to-point state transitions are at risk, and if the full state transition history is not accessible, users may be fraudulent, resulting in double spending.The disposable seal is proposed to solve this problem.By using special objects that can only be used once, they ensure that no double payment occurs, thereby enhancing security.Bitcoin’s UTXO (Unused Transaction Output) model is the most suitable one-time sealing form, protected by Bitcoin consensus mechanism and network hash computing power, allowing RGB assets to inherit the security characteristics of Bitcoin.
Encryption promise
One-time sealing needs to be combined with encryption commitments to ensure users have a clear understanding of state transitions and prevent double payment attacks.Commitment to inform others that something has happened and cannot be changed later, and no specific details will be disclosed until verification is required.This can be done using a hash function.In RGB, the promised content is a state transition that signals the recipient of the RGB asset through UTXO’s expenses.The asset recipient then verifies the commitment based on the specific data transmitted off-chain by the asset spender.
Workflow
RGB utilizes Bitcoin consensus to ensure dual payment security and censorship resistance, while all state transition verification tasks are entrusted off-chain and are only performed by the client receiving payments.
For issuers of RGB assets, 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 holders of an RGB asset want to spend it, they need to get relevant information from the asset recipient, create an RGB transaction, and submit details of the transaction.The promise is then placed in the UTXO specified by the asset recipient and a transaction is issued to spend the original UTXO and create the new UTXO specified by the receiver.When asset recipients notice that the UTXOs storing RGB assets have been spent, they can verify the validity of RGB transactions through commitments in Bitcoin transactions.Once the verification is valid, they can confidently confirm receipt of the RGB assets.
For recipients of RGB assets, the payer must provide evidence of the initial state and state transition rules of the contract, each Bitcoin transaction used in the transfer, the RGB transaction submitted for each Bitcoin transaction, and the validity of each Bitcoin transaction.The recipient’s client uses this data to verify the validity of RGB transactions.In this setup, Bitcoin’s UTXO acts as a container for holding 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 an RGB asset can only access the history related to the assets it holds, and cannot access any other branches.
Pros and Cons
Lightweight verification
Compared with the complete verification required by blockchain, the RGB protocol greatly reduces the verification cost. Users do not need to traverse all historical blocks to obtain the latest state. 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 requires only a hash commitment to inherit the security of Bitcoin and uses Taproot scripts to consume 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 at the same time.
privacy
Unlike typical protocols, only the recipient of an RGB asset can access the history of asset transfers.Once used, they have no access to future transfer history, thus greatly ensuring user privacy.Transactions of RGB assets are not associated with the transfer of Bitcoin UTXO, so external personnel cannot track RGB transactions on the Bitcoin blockchain.
Additionally, RGB supports blind output, which means the payer is unable to determine which UTXO the RGB assets will pay, further enhancing privacy and censorship resistance.
shortcoming
When RGB assets change hands multiple times, new asset recipients can face considerable verification burdens to verify lengthy transfer history, which can lead to longer verification times and lose 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, while recursive ZK proofs may implement constant time and size of state validation.
Rollup
Overview
Rollup is the best expansion solution for the Ethereum ecosystem. It originated from years of exploration from state channels to Plasma, and finally evolved into Rollup.
Rollup is a standalone 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 implements off-chain transaction processing and state update.To maximize scalability, Rollup usually uses a centralized sorter to improve execution efficiency at this stage without compromising security, as security is ensured by the main chain’s verification of Rollup state transitions.
As the Rollup solution of the Ethereum ecosystem becomes more mature, 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 computations required to build on-chain Rollups.Currently, it is mainly committed to achieving sovereign Rollups and OP Rollups.
Classification
Rollups can be divided into two categories: Optimistic Rollups (Optimistic Rollups) and Valid Rollups (ZK Rollups), the main difference lies in the method of state transition verification.
Optimistic Rollup adopts an optimistic verification method. During the dispute period after each batch of transactions is submitted, anyone can view off-chain data, raise objections to the problematic batch, and submit incorrect proofs to the main chain, thereby causing punishment for Sequencer..If no valid erroneous proof is submitted during the dispute period, the transaction batch is deemed valid and the status update is confirmed on the main chain.
Validity Rollup is validated using Validity Proof.Sequencer uses the zero-knowledge proof algorithm to generate a concise proof of validity 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 will verify the proof and confirm the status update immediately.
The advantage of Optimistic Rollup is that it is relatively simple and has few modifications on the main chain, but the disadvantage is that the transaction confirmation time is long (depending on the dispute period) and has high requirements for data availability.The advantage of Validity Rollup is that the transaction confirmation speed is fast and not affected by the dispute period. It can ensure the privacy of transaction data, but generating and verifying zero-knowledge proofs requires a lot of computational overhead.
Celestia also proposed the concept of sovereign Rollup, where Rollup’s transaction data is published to a dedicated data availability (DA) layer blockchain, which is responsible for data availability, while sovereign Rollup itself is responsible for execution and settlement.
Explore and discuss
Bitcoin-based Rollups are still in their early stages. Due to differences from Ethereum’s bookkeeping model and programming language, the practice of directly copying Ethereum is challenging, and the Bitcoin community is actively exploring innovative solutions.
Sovereign Rollup
On March 5, 2023, Rollkit announced that it was the first framework to support Bitcoin sovereignty Rollups.The builders of sovereign Rollups can use Rollkit to publish availability data on Bitcoin.
Rollkit was inspired by Ordinals to use Taproot transactions to publish data.Taproot transactions that comply with the public memory pool standards can contain up to 390KB of data, while non-standard Taproot transactions published directly by miners can contain nearly 4MB of arbitrary data.
Rollkit essentially provides an interface for reading and writing data on Bitcoin, providing a middleware service that transforms Bitcoin into a DA layer.
The idea of sovereign Rollup was met with great doubt.Many critics claim that Bitcoin-based sovereignty Rollup simply uses Bitcoin as a bulletin board and cannot inherit the security of Bitcoin.In fact, if transaction data is submitted only 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.Additionally, block space on Bitcoin is extremely valuable, and submitting full transaction data may not be a good decision.
OP Rollup and Validity Rollup
While many Bitcoin Layer2 projects claim to be ZK Rollups, they are essentially closer to OP Rollups, involving Validity Proof technology.But Bitcoin’s current programming capabilities are not enough to support direct Validity Proof verification.
Currently, Bitcoin’s opcode set is very limited and it is impossible to directly calculate multiplication. Verifying the validity proof requires extended opcodes, which depends largely on the implementation of recursive contracts.The community is actively discussing options including OP_CAT, OP_CHECKSIG, OP_TXHASH and other options.Ideally, adding OP_VERIFY_ZKP might solve the problem without any additional modifications, but this is unlikely.In addition, stack size limitations have also hindered efforts to verify proof of validity in Bitcoin scripts, and many explorations are underway.
So how does the validity proof work?Most projects publish declared differences and validity proofs of bulk transactions to Bitcoin in inscribe format and use BitVM for optimistic verification.In this scheme, the operator of the bridge acts as a federal government, managing user deposits.Before a user deposits, the federal government pre-signs UTXO to ensure that the deposit can only be legally collected 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 a proof of validity to the Bitcoin chain.The operator initially pays out of pocket to meet the user’s withdrawal needs, and then the BitVM contract verifies validity.If each operator believes that the proof is valid, they will repay the money to the operator through multiple signatures; if someone believes that there is fraud, they will initiate the challenge process and punish the wrong party.
This process is essentially the same as OP Rollup, where the trust assumes 1/N – the protocol is secure as long as one verifier is honest.As for the validity proof, its purpose is not to make verification of the Bitcoin network easier, but to make verification easier for each node.
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 a licensed node; Optimism still does not support Fraud Proof, which shows the difficulty of implementation.
With the support of Bitcoin Covenant, pre-signature operations in the BitVM bridge can be executed more efficiently, and the community still needs to reach a consensus.
From the perspective of security attributes, by submitting a Rollup block hash to Bitcoin, Bitcoin gains the ability to resist restructuring and double spending, while Optimistic Bridge brings the 1/N security assumption.Optimistic Bridge’s ability to resist censorship is also expected to be further improved.
Conclusion: Layer 2 is not a magic pill
When we look at various 2-layer solutions, it is obvious that each solution has its limitations.The effectiveness of layer 2 depends to a large extent on the ability of layer 1 (i.e., Bitcoin) under a specific assumption of trust.
Without SegWit upgrades and time locks, the Lightning Network could not be successfully established; without Taproot upgrades, the commitments in RGB could not be efficiently submitted; without OP_CAT and other Covenant, Validity Rollups on Bitcoin would not be possible…
Many Bitcoin biggestists believe that Bitcoin should never be changed, new features should not be added, and all flaws should be solved with a 2-layer solution.However, this is impossible; Level 2 is not a magic pill.We need a more powerful layer 1 to build a safer, more efficient, and more scalable layer 2.
In our next post, we will explore attempts to enhance Bitcoin programmability.
