Cracking the Bitcoin Bottleneck: A Comprehensive Audit Guide to BTC Layer2 Scaling Technology

Bitcoin (BTC), as the world's first cryptocurrency, has gradually become the cornerstone of digital assets and decentralized finance since its launch in 2009. However, with the increase in the number of users and transaction volume, the problems of the BTC network have become increasingly apparent, mainly manifested in the following points:

• High transaction fees: When the Bitcoin network is congested, users need to pay higher fees to ensure that transactions can be confirmed as soon as possible.

• Transaction confirmation time: The Bitcoin blockchain generates a new block every 10 minutes on average, which means that on-chain transactions usually need to wait for multiple block confirmations before they can be considered final.

• Limitations of smart contracts: Bitcoin's scripting language has limited functions, making it difficult to implement complex smart contracts.

In this article, we refer to technologies such as Lightning Network, Sidechains, and Rollup as BTC Layer2 expansion solutions, which maintain the decentralization and security of the BTC network while achieving fast and low-cost transactions. The introduction of Layer2 technology can increase transaction speed and reduce transaction costs, optimize user experience and expand network capacity, providing important technical support and innovation direction for the future development of BTC.

Currently, Beosin has become the official security partner of BTC Layer2 such as Merlin Chain, and has audited multiple BTC ecological protocols, such as Bitmap.Games, Surf Protocol, Savmswap, Mineral. In the past audits, many well-known public chains have passed Beosin's public chain security audit, including Ronin Network, Clover, Self Chain, Crust Network, etc. Beosin now launches an audit solution for BTC Layer2, providing comprehensive and reliable security audit services for the entire BTC ecosystem.

Lightning Network

The earliest concept of the Lightning Network is called "payment channel", and its design idea is to continuously update the status of unconfirmed transactions through transaction replacement until it is finally broadcast to the Bitcoin network. When Satoshi Nakamoto created Bitcoin in 2009, he had already proposed the idea of ​​payment channels and included a code draft of payment channels in Bitcoin 1.0, which allowed users to update the status of transactions before they were confirmed by the network. However, it was not until the release of the white paper "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payment" that the Lightning Network was truly born and entered the public eye.

Today, the implementation of payment channels and Lightning Networks is very mature. As of now, the Lightning Network has a total of 13,325 nodes, 49,417 channels, and the total number of staked BTC has reached 4,975.

https://1ml.com/

In the Lightning Network, it is very important to ensure the security of user assets during the transfer process. The following will explain how the Lightning Network works and how to protect the security of user assets based on the scale of network nodes.

Both users submit two transactions to the Bitcoin mainnet: one for opening the channel and one for closing the channel. It is roughly divided into the following three steps:

1. Channel opening:

First, the participating users pledge Bitcoin to the Lightning Network's multi-signature wallet on BTC. Once the Bitcoin is successfully pledged and locked, the payment channel is opened, and both parties can conduct off-chain transactions in this channel.

2. Off-chain transactions:

Once the channel is opened, all transfer transactions between users will be processed in the Lightning Network, and these off-chain transactions are not limited in number. Of course, these transactions do not need to be submitted to the Bitcoin mainnet immediately, but are completed instantly through the off-chain mechanism of the Lightning Network.

This off-chain processing method significantly improves transaction speed and efficiency, avoiding congestion and high transaction fees on the Bitcoin mainnet.

3. Channel Closure and Ledger Settlement:

When a user on either side decides to exit the channel, the final ledger settlement will be carried out. This process ensures that all funds in the channel are allocated according to the latest status. At the same time, users on both sides will withdraw the settled balance from the multi-signature wallet, which reflects the actual fund allocation when the channel is closed. Finally, the channel will submit the final state of the ledger transaction to the Bitcoin mainnet.

The advantages of the Lightning Network are:

• Increased transaction speed. The Lightning Network allows users to trade off-chain, which means that transactions can be completed almost instantly without waiting for block confirmation time. This can achieve transaction speeds of seconds, greatly improving the user experience.

• Enhanced privacy. Off-chain transactions of the Lightning Network do not need to be publicly recorded on the Bitcoin main chain, which improves the privacy of transactions. Only the opening and closing of channels need to be recorded on the main chain, so users' transaction behaviors will not be fully public.

• Micropayment support. The Lightning Network is well suited for processing small payments (micropayments), such as content payments, IoT device payments, etc. Traditional Bitcoin transactions are not suitable for frequent small payments due to their high handling fees, but the Lightning Network solves this problem.

Challenges facing the Lightning Network:

• Network liquidity issues: The Lightning Network relies on Bitcoin that is pre-locked in the channel. This means that users must deposit enough Bitcoin in their payment channels in advance in order to make transactions. Insufficient liquidity can cause payment failures, especially for larger payments.

• Routing issues: Finding an efficient path from the sender of a payment to the receiver can be a complex problem, especially when the network is large. As the number of network nodes and channels increases, the difficulty of ensuring that payments are completed smoothly also increases.

• Trust issues in fund custody: Nodes may encounter malicious attacks, and users need to trust that the nodes they are connected to will not try to steal funds. Can nodes prevent private key leakage

• Technical standards and interoperability: There needs to be consistent technical standards and protocols between different lightning network implementations to ensure interoperability. Currently, multiple development teams are developing different implementations of the lightning network, which may lead to compatibility issues.

• Privacy issues: Although the lightning network improves the privacy of Bitcoin transactions, transaction information may still be tracked or analyzed. In addition, network node operators can see transactions passing through their nodes, which may leak certain private information.

The security of the Lightning Network directly affects the off-chain expansion capabilities of Bitcoin and the security of user funds. Therefore, in addition to the general audit items of the public chain (see the appendix at the end of this article for details), the Lightning Network also needs to pay attention to the following important security risk points:

• Channel congestion: Check the comprehensiveness of the design of the Lightning Network system to see if it will cause channel congestion due to sadness attacks.

• Channel interference: Check the security of the Lightning Network channel structure to see if it will be subject to channel interference attacks.

• Channel asset locking and unlocking: Review the process of locking and unlocking assets in the Lightning Network to ensure that the transfer of funds on and off the chain is safe and reliable when opening or closing payment channels.

• State update and closure: Evaluate the channel's state update process and force-close mechanism to ensure that the latest state can be correctly identified and executed when an abnormal situation occurs.

• Time lock and hash lock contract (HTLC): Evaluate the implementation of HTLC to ensure that time lock and hash lock conditions can be correctly executed to prevent capital losses caused by time window problems.

• Blockchain timestamp dependency: Evaluate the Lightning Network's dependency on the Bitcoin blockchain timestamp to ensure that the on-chain and off-chain times can be correctly coordinated to prevent time attacks.

• Routing algorithm security: Check the efficiency and security of the routing algorithm to prevent user privacy exposure and malicious routing manipulation risks.

• Channel storage and data recovery: Check the channel's storage mechanism and data recovery strategy to ensure that the channel status can be restored in the event of node failure or accidental disconnection to avoid fund loss.

Sidechain

Unlike the Lightning Network, a sidechain is an independent blockchain that runs in parallel with the main chain (such as the BTC blockchain) and interoperates with the main chain through a two-way peg. The purpose of the sidechain is to achieve more functions and improve scalability without changing the main chain protocol.

As an independent blockchain, the sidechain has its own consensus mechanism, nodes, and transaction processing rules. It can use different technologies and protocols from the main chain according to the needs of specific application scenarios. Through the two-way peg mechanism (2WP), the sidechain communicates with the main chain to ensure that assets can be transferred freely and securely between the two. The operating mechanism of the two-way anchoring mechanism (2WP) is as follows:

1. The user locks BTC on the main chain, and the trusted institution 1 obtains and uses SPV verification 2 to ensure that the user's locked transaction is confirmed.

2. The trusted institution will issue tokens of equal value to the user on the side chain.

3. After the user has freely traded, he locks the remaining tokens on the side chain.

4. After verifying the legitimacy of the transaction, the trusted institution unlocks and releases the corresponding value of BTC to the user on the main chain.

Note 1: Trusted institutions play a key role in the two-way anchoring mechanism, responsible for managing the locking and release of assets. These institutions need to have a high degree of credibility and technical capabilities to ensure the security of user assets.

Note 2: SPV verification allows nodes to verify the validity of specific transactions without downloading the entire blockchain. SPV nodes only need to download the block header and verify whether the transaction is included in the block through the Merkle Tree.

Representative projects of side chains:

CKB (Nervos Network)

Nervos Network is an open source public blockchain ecosystem that aims to leverage the security and decentralization advantages of BTC's POW consensus mechanism while introducing a more scalable and flexible UTXO model to process transactions. Its core is Common Knowledge Base (CKB), which is a Layer 1 blockchain built on RISC-V and uses PoW (proof of work) as consensus. It expands the UTXO model to the Cell model, allowing it to store any data and support scripts written in any language to be executed on the chain as a smart contract. Stacks connects each Stacks block to the Bitcoin block through its PoX (Proof of Transfer) mechanism. In order to develop smart contracts, Stacks designed a special Clarity programming language. In Clarity, the get-burn-block-info? function allows the Bitcoin block height to be passed in and the header hash of the block to be obtained. At the same time, the burn-block-height keyword can obtain the current block height of the Bitcoin chain. These two functions enable Clarity smart contracts to read the state of the Bitcoin base chain, allowing Bitcoin transactions to serve as contract triggers. By automatically executing these smart contracts, Stacks expands the functionality of Bitcoin.

For a detailed analysis of Stacks, read Beosin's previous research article: "What are Stacks? What challenges may BTC's second-layer network Stacks face?"

The advantages of side chains are:

• Side chains can use different technologies and protocols to conduct various experiments and innovations without affecting the stability and security of the main chain.

• Sidechains can introduce features that the main chain does not have, such as smart contracts, privacy protection, token issuance, etc., to enrich the application scenarios of the blockchain ecosystem.

Challenges faced by sidechains:

• Sidechains have independent consensus mechanisms and may not be as secure as the BTC main chain. If the consensus mechanism of the sidechain is weak or has loopholes, it may lead to 51% attacks or other forms of attacks, affecting the security of user assets. The security of the BTC main chain relies on its huge computing power and wide node distribution, while the sidechain may not meet the same security standards.

• The implementation of the two-way anchoring mechanism requires complex encryption algorithms and protocols. If there are loopholes in them, it may cause problems in the transfer of assets between the main chain and the side chain, and may even cause the loss or theft of assets.

• In order to find a balance between speed and security, most side chains are more centralized than the main chain.

Layer2 is a complete blockchain system, so the general audit items of the public chain also apply to the side chain. For details, see the appendix at the end of this article.

In addition, due to its particularity, the side chain also needs to undergo some additional audits:

• Consensus protocol security: Review whether the consensus protocol of the side chain (such as PoW, PoS, DPoS) has been fully verified and tested, and whether there are potential vulnerabilities or attack vectors, such as 51% attacks, long-range attacks, etc.

• Consensus node security: Evaluate the security of consensus nodes, including key management, node protection and redundant backup to prevent nodes from being hacked or abused.

• Asset locking and release: Review the two-way anchoring mechanism between the side chain and the main chain to ensure that the smart contracts for locking and releasing assets are safe and reliable to prevent double spending, asset loss or locking failure.

• Cross-chain verification: Check the accuracy and security of cross-chain verification, ensure that the verification process is decentralized and tamper-proof, and prevent verification failure or malicious verification.

• Contract code audit: In-depth audit of all smart contracts running on the side chain to detect possible vulnerabilities or backdoors, especially in the contract logic when dealing with cross-chain operations.

• Upgrade mechanism: Check whether the upgrade mechanism of the smart contract is safe, whether there is an appropriate audit and community consensus process, and prevent malicious upgrades or contract tampering.

• Inter-node communication: Check whether the communication protocol between side chain nodes is secure and whether encrypted channels are used to prevent man-in-the-middle attacks or data leaks.

• Cross-chain communication: Check the communication channel between the side chain and the main chain to ensure the integrity and authenticity of the data and prevent the communication from being hijacked or tampered with.

• Timestamp and block time: Verify the time synchronization mechanism of the side chain to ensure the consistency and accuracy of the block generation time and prevent attacks or block rollbacks caused by time differences.

• On-chain governance security: Review the governance mechanism of the side chain to ensure the transparency and security of the voting, proposal and decision-making process and prevent malicious control or attacks.

• Token economic audit: Check the token economic model of the side chain, including token allocation, incentive mechanism and inflation model, to ensure that economic incentives do not lead to malicious behavior or system instability.

• Fee mechanism: Check the transaction fee mechanism of the sidechain to ensure that it matches the needs of the mainchain and sidechain users to prevent fee manipulation or network congestion.

• Asset security: Audit the management mechanism of assets on the chain to ensure that the storage, transfer and destruction of assets are safe and reliable, without the risk of unauthorized access or theft.

• Key management: Check the key management strategy of the sidechain to ensure the security and access control of private keys to prevent key leakage or theft.

Rollup

Rollup is a Layer2 expansion solution designed to improve the transaction throughput and efficiency of blockchain. It significantly reduces the burden on the main chain by packaging a large number of transactions ("Rollup") and processing them off-chain, and only submitting the final results to the main chain.

Rollup is mainly divided into zk-Rollup and op-Rollup. However, unlike ETH, due to the Turing incompleteness of BTC, it is impossible to use contracts for zero-knowledge proof verification on BTC. Traditional zk-Rollup solutions cannot be implemented on BTC. So how to use zk-Rollup to implement BTC Layer2? Let's take the B² Network project as an example:

In order to complete zero-knowledge proof verification on BTC, B² Network created the Taproot script, which combines the zero-knowledge proof verification of zk-Rollup and the incentive challenge of op-Rollup. Its operating mechanism is as follows:

1. B² Network first rolls up all transactions initiated by users.

2. After sorting the Rollup transactions using the sorter, the Rollup transactions are saved using decentralized storage and simultaneously handed over to zkEVM for processing.

3. After zkEVM synchronizes the BTC chain status, it processes transactions such as contract execution, and merges and packages the results and sends them to the aggregator.

4. Prover generates a zero-knowledge proof and sends it to the aggregator, which aggregates the transactions and proofs and sends them to B² Nodes.

5. B² Nodes verify the zero-knowledge proof and create a Taproot script based on the Rollup data in the decentralized storage.

6. Taproot is a UTXO with a value of 1 satoshi. The B² Inscription in its data structure stores all Rollup data, and the Tapleaf stores all the verify data of the proof. After passing the incentive challenge mechanism, it will be sent to BTC as a commitment based on zk proof verification.

The advantages of Rollup are:

• Rollupinherits the security and decentralization characteristics of the main chain. By regularly submitting transaction data and status to the main chain, the integrity and transparency of the data are ensured.

• Rollup can be seamlessly integrated into existing blockchain networks, such as Ethereum, allowing developers to easily take advantage of its advantages without significantly modifying existing smart contracts and applications.

• Rollup greatly improves transaction processing capabilities by processing a large number of transactions off-chain and packaging them into a batch and submitting them to the main chain, significantly increasing the number of transactions per second (TPS).

• Rollup transactions only need to be processed off-chain, greatly reducing the computing resources and storage space required for on-chain transactions, thereby significantly reducing users' transaction fees.

Challenges faced by Rollup:

• If off-chain data is unavailable, users may not be able to verify transactions and restore status.

• Rollup transactions need to be processed in batches and eventually submitted to the main chain, which may result in a long settlement time. Especially in op-Rollup, there is a dispute period, and users may need to wait a long time before the transaction is finally confirmed.

• Although ZK Rollup provides higher security and instant confirmation, it has higher computing and storage requirements, and generating zero-knowledge proofs requires a lot of computing resources.

Since the solution adopted is Rollup, its key security audit items are basically the same as ETH Layer2.

Others (Babylon)

In addition to the traditional BTC Layer2, there are some new third-party protocols related to the BTC ecosystem recently, such as Babylon:

Babylon's goal is to convert 21 million BTC into decentralized pledge assets. Unlike other Layer2s of BTC, Babylon does not expand the BTC chain. It is a unique chain with a special BTC pledge agreement. Its main purpose is to connect with the PoS chain. Pledge BTC to provide stronger security for the PoS chain and solve problems such as the risk of attacks from the remote end of the chain and centralization.

The architecture is divided into three layers:

Bitcoin layer: This is the solid foundation of Babylon, using the well-known security of Bitcoin to ensure that all transactions are super secure, just like on the Bitcoin network.

Babylon Layer: At the heart of Babylon is the Babylon layer, a custom blockchain that connects Bitcoin with various Proof of Stake (PoS) chains. It processes transactions, runs smart contracts, and ensures that everything runs smoothly across the ecosystem.

PoS Chain Layer: The top layer consists of multiple PoS chains, each of which is chosen for its unique advantages. This gives BabylonChain amazing scalability and flexibility, allowing users to enjoy the best features of different PoS blockchains.

The way it works is to secure the PoS chain using the final block signed on the BTC chain. This essentially extends the base protocol with additional signing rounds. These signatures in the last +1 round have a unique feature: they are extractable one-time signatures (EOTS). The purpose is to integrate PoS checkpoints into BTC and solve the long unbinding period and long-range attack problems of PoS.

Babylon's advantages are:

• Speed ​​up the unbinding period of PoS

• Due to the pledge of BTC, the price is linked to BTC, which can reduce the inflation pressure of the corresponding PoS network

• Opens a new path for BTC income

Challenges faced by Babylon:

• Economic designs such as staking return rate have a great impact on the enthusiasm for BTC staking

• Lack of reward consistency regulations between PoS chains

Depending on the implementation, third-party protocols focus on different security points. Taking Babylon as an example, some security audit items that need attention are as follows:

1. Smart contract security: The pledge contract on BTC is implemented through UTXO script, and its security needs to be paid attention to.

2. Signature algorithm security: The contract uses signatures to manage the user's pledge, and the algorithm security is related to the generation and verification of signatures.

3. Protocol economic model design: Whether the economic model of the protocol is reasonably set in terms of rewards and penalties, and whether it will lead to user asset losses.

Appendix:

Public chain & Layer2 general audit items

• Integer overflow: Check integer overflow and integer underflow

• Dead loop: Check whether the loop judgment condition of the program is reasonable

• Infinite recursive call: Check whether the exit condition of the recursive call of the program is reasonable

• Competition condition: Check the access operation to shared resources in a concurrent state

• Exception crash: Check the exception throwing code that can make the program exit actively

• Division by 0 vulnerability: Check whether there is division by 0

• Type conversion: Check whether the type conversion is correct and whether important information is lost during the conversion

• Array out of bounds: Check whether elements beyond the array bounds are accessed

• Deserialization vulnerability: Check whether there are any problems during the deserialization process

• Function implementation security: Check whether there are security risks in the implementation of each RPC interface and whether it is consistent with the RPC interface function design

• Whether the permission settings of sensitive RPC interfaces are reasonable: Check the access permission settings of sensitive RPC interfaces

• Encrypted transmission mechanism: Check whether an encrypted transmission protocol, such as TLS, is used.

• Request data format parsing: Check the format parsing process of the request data

• Wallet unlock attack: When a node unlocks its wallet, funds are stolen by RPC requests

• Traditional Web security: Check whether the following vulnerabilities exist: Cross-site scripting (XSS) / Template injection /

• Third-party component vulnerability / HTTP parameter pollution / SQL injection / XXE entity injection / Deserialization vulnerability / SSRF vulnerability / Code injection / Local file inclusion / Remote file inclusion / Command execution injection and other traditional vulnerabilities

• Network node authentication and identification mechanism: Check whether there is a node identification mechanism and whether the node identification mechanism can be bypassed

• Routing table pollution: Check whether the routing table can be inserted or overwritten with data at will

• Node discovery algorithm: Check whether the node discovery algorithm is balanced and unpredictable, such as problems such as imbalanced distance algorithm

• Connection number occupancy audit: Check whether the restriction and management of the number of connected nodes in the p2p network are reasonable

• Eclipse attack: Assess the cost and harm of eclipse attack, and provide quantitative analysis when necessary

• Symphony attack: Assess the voting consensus mechanism and analyze the voting qualification check strategy

• Eavesdropping attack: Check whether the communication protocol leaks privacy

• Alien attack: Evaluate whether the node can identify nodes of the same chain

• Time hijacking: Check the node's network time calculation mechanism

• Memory exhaustion attack: Check where large memory is consumed

• Hard disk exhaustion attack: Check where large files are stored

• Socket pressure attack: Check the limit policy on the number of links

• Kernel handle exhaustion attack: Check the restrictions on kernel handle creation, such as file handles, etc. Persistent memory leaks: Check where the memory leaks are

• Hash algorithm security: Check the anti-collision performance of the hash algorithm

• Digital signature algorithm security: Check the signature algorithm security and the security of the algorithm implementation

• Encryption algorithm security: Check the encryption algorithm security and the security of the algorithm implementation

• Random number generator security: Check whether the key random number generation algorithm is reasonable

• BFT implementation security: Evaluate the implementation security of the BFT algorithm

• Fork selection rule: Check the fork selection rule to ensure security

• Centralization degree detection: Identify whether there is over-centralization in the system design

• Incentive mechanism audit: Evaluate the impact of incentive mechanism on security

• Double-spending attack: Check whether the consensus can defend against double-spending attacks

• MEV attack audit: Check the impact of MEV of block packaging nodes on chain fairness

• Block synchronization process audit: Check security issues in the synchronization process

• Block format parsing process audit: Check security issues in the format parsing process, such as crashes caused by parsing errors

• Block generation process audit: Check security issues in the block generation process, including Merkle tree Is the root construction method reasonable?

• Block verification process audit: check whether the block signature content items and verification logic are sufficient

• Block confirmation logic audit: check whether the block confirmation algorithm and implementation are reasonable

• Block hash collision: check the construction method of block hash collision and whether the processing when the collision is reasonable

• Block processing resource restrictions: check whether the resource restrictions such as orphan block pool, verification calculation, and hard disk addressing are reasonable

• Transaction synchronization process audit: check security issues in the synchronization process

• Transaction hash collision: check the construction method of transaction hash collision and the processing when the collision is reasonable

• Transaction legitimacy verification: Check whether the signature content items and verification logic of each type of transaction are sufficient

• Transaction processing resource restrictions: Check whether resource restrictions such as transaction pool, verification calculation, and hard disk addressing are reasonable

• Transaction ductility attack: Whether the transaction can change internal fields (such as ScriptSig) to change the transaction hash without affecting the validity of the transaction

• Transaction replay attack audit: Check the system's detection of transaction replay

• Contract bytecode verification: Check security issues in the process of virtual machine verification of contracts, such as integer overflow, infinite loop, etc.