Bitcoin (BTC), as the world’s first cryptocurrency, has gradually become the cornerstone of digital assets and decentralized finance since its advent in 2009. However, as the number of users and transaction volume increases,The problems of the BTC network are becoming increasingly apparent, mainly as follows:：

• High transaction fees: When the Bitcoin network is congested, users need to pay higher fees to ensure transactions are confirmed as quickly as possible.
• Transaction confirmation time: The Bitcoin blockchain generates a new block every 10 minutes on average, meaning on-chain transactions often need to wait for multiple block confirmations before they are considered final.
• Limitations of smart contracts: Bitcoin’s scripting language has limited functions and is difficult to implement complex smart contracts.

In this article, we willLightning Network(Lightning Network), Sidechains, Rollup and other technologies are collectively referred to as BTC Layer2 expansion solutions. They maintain the decentralization and security of the BTC network while achieving fast and low-cost transactions. The introduction of Layer2 technology canImprove transaction speed and reduce transaction costs, optimize user experience and expand network capacity,It provides important technical support and innovation direction for the future development of BTC.

At present, Beosin has become the official security partner of BTC Layer2 such as Merlin Chain., audited multiple BTC ecological protocols, such asBitmap.Games、Surf Protocol、Savmswap、Mineral. In past audits, many well-known public chains have passed Beosin’s public chain security audits, includingRonin Network、Clover、Self Chain、Crust Networkwait.Beosin now launches an audit solution for BTC Layer2 to provide comprehensive and reliable security audit services for the entire BTC ecosystem.。

Lightning Network

The earliest concept of Lightning Network is called “payment channel”. Its design idea is to continuously update unconfirmed transaction status through transaction replacement until it is finally broadcast to the Bitcoin network.. Satoshi Nakamoto had already proposed the idea of ​​payment channels when he created Bitcoin in 2009, and included a draft code for payment channels in Bitcoin 1.0, which allowed users to update transaction status before the transaction was 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 Network is very mature. As of now, the Lightning Network has a total of 13,325 nodes, 49,417 channels, and the total number of pledged 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 operates and how to protect the security of user assets based on the scale of network nodes.

Users from both parties submit two transactions to the Bitcoin main network: one to open the channel and one to close the channel. It is roughly divided into the following three steps:

1.Channel opening:

First, users from both parties 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 there is no limit on the number of these off-chain transactions. 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 the congestion and high transaction fees of the Bitcoin mainnet.

3.Channel closing and ledger settlement:

When users on either side decide to exit the channel, final ledger settlement will occur. This process ensures that all funds in the channel are allocated up to date. At the same time, users on both sides will withdraw the post-settlement balance from the multi-signature wallet, which reflects the actual distribution of funds when the channel is closed. Eventually, the channel will submit the final state of the ledger transaction to the Bitcoin mainnet.

The advantage of Lightning Network is that：

• Increased transaction speed. The Lightning Network allows users to conduct transactions off-chain, which means transactions can be completed almost instantly without waiting for block confirmation time. This can achieve second-level transaction speeds, greatly improving user experience.
• Enhanced privacy. Lightning Network’s off-chain transactions do not need to be publicly recorded on the Bitcoin main chain, which improves the privacy of transactions. Only the opening and closing of the channel need to be recorded on the main chain, so the user’s transaction behavior will not be fully disclosed.
• Micropayment support. The Lightning Network is very suitable 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 high handling fees, while the Lightning Network solves this problem.

Challenges facing the Lightning Network：

• network liquidity issues: The Lightning Network relies on Bitcoins being pre-locked in channels. This means that users must deposit enough Bitcoin into their payment channel in advance in order to make a transaction. Insufficient liquidity can cause payments to fail, especially on larger payments.
• routing problem: Finding an efficient path from a payment sender to a receiver can be a complex problem, especially at larger network sizes. As the number of network nodes and channels increases, the difficulty of ensuring smooth completion of payments also increases.
• Fund custody trust issues: Nodes can be subject to 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 leaks?
• Technical standards and interoperability: Consistent technical standards and protocols are needed between different Lightning Network implementations to ensure interoperability. Currently, multiple development teams are working on different implementations of the Lightning Network, which can lead to compatibility issues.
• privacy issues: Although the Lightning Network improves the privacy of Bitcoin transactions, transaction information may still be tracked or analyzed. Additionally, network node operators can see transactions passing through their nodes, potentially revealing certain private information.

The security of the Lightning Network directly affects Bitcoin’s off-chain scalability and the security of user funds. thereforeIn addition to the general audit items of the public chain(See the appendix at the end of this article for details)other than，The Lightning Network also needs to pay attention to the following important security risks:

• Channel congestion: Check the comprehensiveness of the design of the Lightning Network system and whether it will cause channel congestion due to grief attacks.
• Channel interference: Check the security of the Lightning Network channel structure and whether it will be subject to channel interference attacks.
• Channel asset locking and unlocking: Review the process of asset locking and unlocking in the Lightning Network to ensure that when opening or closing a payment channel, the transfer of funds on and off the chain is safe and reliable.
• Status update and closure: Evaluate the status update process and force-close mechanism of the channel to ensure that the latest status can be correctly identified and executed when abnormal conditions occur.
• Time Lock and Hash Lock Contract (HTLC): Evaluate the implementation of HTLC to ensure that time lock and hash lock conditions can be executed correctly to prevent fund losses caused by time window issues.
• Blockchain timestamp dependence: Evaluate the Lightning Network’s dependence on the Bitcoin blockchain timestamp to ensure that on-chain and off-chain time 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 unexpected disconnection to avoid loss of funds.

side chain

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

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

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

2. The trusted institution will issue equivalent tokens to users on the side chain.

3. After free transactions, users lock the remaining tokens on the side chain.

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

Note 1:trusted authorityPlays a key role in the two-way anchoring mechanism and is responsible for managing the locking and releasing 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 verificationAllows nodes to verify the validity of specific transactions without downloading the full 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 using PoW (Proof of Work) as the consensus. It expands the UTXO model into a Cell model, allowing it to store any data and support writing scripts in any language to execute on the chain as a smart contract.

Stacks

Stacks connects each Stacks block to the Bitcoin block through its PoX (Proof of Transfer) mechanism. To develop smart contracts, Stacks designed the specialized Clarity programming language. In Clarity, the get-burn-block-info? function allows passing in the Bitcoin block height and obtaining the header hash of the block. 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 automating the execution of these smart contracts, Stacks extends the capabilities of Bitcoin.

For a detailed analysis of Stacks, you can read Beosin’s previous research article: “What are Stacks? What challenges may BTC layer 2 network Stacks face?》

The advantage of side chains is that：

• Side chains can use different technologies and protocols to conduct various experiments and innovations without affecting the stability and security of the main chain.
• Side chains can introduce functions 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 facing sidechains：

• The side chain has an independent consensus mechanism, may not be as secure as the BTC main chain. If the consensus mechanism of the side chain 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 side chains 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 with asset transfer between the main chain and the side chain, and may even lead to the loss or theft of assets.
• To find a balance between speed and security, most sidechainsThe degree of centralization is higher than that of 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.

also,Due to its special nature, sidechains also require some additional auditing：

• 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 breached or abused.
• Asset locking and release: Review the two-way anchoring mechanism of assets between the side chain and the main chain to ensure that the smart contracts for locking and releasing assets are safe and reliable, preventing 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 loopholes or backdoors, especially the contract logic when handling cross-chain operations.
• Upgrade mechanism: Check whether the upgrade mechanism of smart contracts is safe and whether there are appropriate auditing and community consensus processes to 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 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 voting, proposal and decision-making processes, and prevent malicious control or attacks.
• Token economic audit: Check the side chain’s token economic model, including token allocation, incentive mechanism and inflation model, to ensure that economic incentives will not lead to malicious behavior or system instability.
• Fee mechanism: Check the transaction fee mechanism of the side chain to ensure that it matches the needs of main chain and side chain 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 process of assets is safe and reliable, and there is no risk of unauthorized access or theft.
• Key management: Check the key management policy of the side chain to ensure the security and access control of the private key and prevent the key from being leaked or stolen.

Rollup

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

Rollup is mainly divided into zk-Rollup and op-Rollup. But unlike ETH,Due to the Turing incompleteness of BTC, it is impossible to use contracts on BTC for zero-knowledge proof verification.. Traditional zk-Rollup solutions cannot be implemented on BTC. So how to implement BTC Layer2 using zk-Rollup? Next, 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 roughly as follows:

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

2. After using the sorter to sort the Rollup transactions, save the Rollup transactions using decentralized storage and hand them over to zkEVM for processing at the same time.

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

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

5. B² Nodes performs zero-knowledge proof verification and creates Taproot scripts based on the Rollup data in 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 Tapleaf stores all verification data. After passing the incentive challenge mechanism, it will be sent to BTC as a commitment verified based on zk proof.

The advantage of Rollup is that：

• RollupInherits the security and decentralization features of the main chain. By regularly submitting transaction data and status to the main chain, data integrity and transparency are ensured.
• Rollup can be seamlessly integrated into existing blockchain networks such as Ethereum, allowing developers to easily take advantage of its benefits without significantly modifying existing smart contracts and applications.
• By processing a large number of transactions off-chain and packaging them into one batch for submission to the main chain, Rollup greatly improves transaction processing capabilities and significantly increases the number of transactions per second (TPS).
• Rollup transactions only need to be processed off-chain, which greatly reduces the computing resources and storage space required for on-chain transactions, thereby significantly reducing user transaction fees.

Challenges faced by Rollup：

• If off-chain data is unavailable, users may be unable to verify transactions and restore status.
• Rollup transactions need to be processed in batches and finally submitted to the main chain, which may result in longer settlement times. Especially in op-Rollup, there is a dispute period and users may have to wait for a long time before the transaction is finally confirmed.
• Although ZK Rollup provides higher security and instant confirmation, its computing and storage requirements are high, and generating zero-knowledge proofs requires a large amount of computing resources.

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

Others (Babylon)

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

Babylon’s goal is to convert 21 million BTC into decentralized staking assets. Unlike other Layer 2 of BTC, Babylon does not expand the BTC chain. It is a unique chain in itself, with a special BTC mortgage protocol. The main purpose is to connect with the PoS chain. Mortgage BTC to provide stronger security for the PoS chain and solve the risk of attacks from the remote end of the chain and centralized question.

The architecture is divided into three layers:

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

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

PoS chain layer: The top layer is composed of multiple PoS chains, each PoS chain being selected 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 final blocks signed on the BTC chain. This essentially extends the base protocol with additional signing rounds. These signatures in the final +1 round have a unique characteristic: they are Extractable One-Time Signatures (EOTS). The purpose is to integrate PoS checkpoints into BTC to solve the long unbinding period and remote attack problems of PoS.

The advantage of Babylon is that：

• Make the unbinding period of PoS faster
• Since BTC is pledged, the price is linked to BTC, which can reduce the inflationary pressure on the corresponding PoS network.
• Opens new avenues for BTC earnings

Challenges facing Babylon：

• Economic designs such as staking return rate have a greater impact on BTC staking enthusiasm
• Lack of reward consistency provisions between PoS chains

Third-party protocols have different security points depending on their implementation. 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: Signatures are used in the contract to manage user pledges, and the security of its algorithm is related to the generation and verification of signatures.

3. Design of protocol economic model: Whether the economic model of the protocol is reasonably set in terms of rewards and penalties, and whether it will lead to loss of user assets.

appendix:

Public chain & Layer2 general audit items

• Integer overflow: Check for integer overflow and integer underflow
• Infinite loop: Check whether the loop judgment conditions of the program are reasonable
• Infinite recursive call: Check whether the exit condition of the program’s recursive call is reasonable
• Race conditions: Check access operations to shared resources in concurrent conditions
• Abnormal crash: Check the exception throwing code that allows the program to actively exit
• Division by 0 vulnerability: Check if there is division by 0
• Type conversion: Check whether the type conversion is correct and whether important information is lost during the conversion process
• Array out of bounds: Check whether an element beyond the bounds of the array is accessed
• Deserialization vulnerability: check if there are any problems during the deserialization process
• Functional implementation security: Check whether there are security risks in each RPC interface implementation and whether it is consistent with the RPC interface function.
• Can be designed to match
• Whether the sensitive RPC interface permission settings are reasonable: Check the access permission settings of the sensitive RPC interface
• Encrypted transmission mechanism: Check whether an encrypted transmission protocol is used, such as TLS, etc.
• Request data format parsing: Check the format parsing process of request data
• Wallet unlock attack: When a node unlocks its wallet, it is requested by RPC to steal funds.
• Traditional Web Security: Check for the following vulnerabilities: Cross-site scripting (XSS) / Template injection
• Third-party component vulnerabilities / HTTP parameter pollution / SQL injection / XXE entity injection deserialization
• vulnerabilities/SSRF vulnerabilities/code injection/local file inclusion/remote file inclusion/command execution injection and other traditional vulnerabilities
• Network node identity 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 randomly inserted or overwritten data
• Node discovery algorithm: Check whether the node discovery algorithm is balanced and unpredictable, such as unbalanced distance algorithm and other issues
• Connection number occupancy audit: Check whether the limit and management of the number of p2p network connection nodes are reasonable
• Eclipse attack: Evaluate the cost and harm of an eclipse attack and provide quantitative analysis if necessary
• Sybil attack: Evaluate voting consensus mechanism and analyze voting qualification check strategy
• Eavesdropping attack: Checking communication protocols for privacy leaks
• Alien attack: Evaluate whether the node can identify similar chain nodes
• Time Hijacking: Checking a node’s network time calculation mechanism
• Memory Exhaustion Attack: Checking for Big Memory Consumption Places
• Hard Drive Exhaustion Attack: Check Where Large Files Are Stored
• Socket pressure attack: check the limit policy on the number of connections
• Kernel handle exhaustion attack: Check the limits of kernel handle creation, such as file handles, etc.
• Persistent memory leaks: Check for memory leaks
• Hash Algorithm Security: Checking the Collision Resistance of a Hash Algorithm
• Digital signature algorithm security: Check the security of the signature algorithm and the security of the algorithm implementation
• Encryption algorithm security: Check encryption algorithm security, algorithm implementation security
• Random number generator security: Checking whether critical random number generation algorithms are sound
• BFT implementation security: Evaluating the implementation security of the BFT algorithm
• Fork-choice rules: Check fork-choice rules to ensure safety
• Centralization detection: identify whether there is excessive centralization in system design
• Incentive audit: Assess the impact of incentives on security
• Double-spending attack: Check whether consensus can defend against double-spending attack
• MEV attack audit: Check the impact of MEV of block packaging nodes on chain fairness
• Block synchronization process audit: Check security issues during the synchronization process
• Block format parsing process audit: Check security issues in the format parsing process, such as parsing errors leading to crashes
• Block generation process audit: Check the security issues during the block generation process, including whether the Merkle tree root construction method is 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 handling of the collision is reasonable.
• Block processing resource limits: Check whether resource limits such as orphan block pool, verification calculation, hard disk addressing, etc. are reasonable.
• Transaction synchronization process audit: Check security issues during the synchronization process
• Transaction hash collision: Check the construction method of transaction hash collision and the processing of collision
• Transaction format parsing: Check security issues during the format parsing process, such as parsing errors leading to crashes
• Transaction legality verification: Check whether each type of transaction signature content items and verification logic are sufficient
• Transaction processing resource limits: Check whether resource limits such as transaction pools, verification calculations, hard disk addressing, etc. are reasonable.
• Transaction malleability attack: Can a transaction change internal fields (such as ScriptSig) to change the transaction hash without affecting the validity of the transaction?
• Transaction replay attack audit: Check system detection of transaction replay
• Contract bytecode verification: Check the security issues of the virtual machine verification process of the contract, such as integer overflow, infinite loop, etc.
• Contract bytecode execution: Check the security issues in the process of virtual machine executing bytecode, such as integer overflow, infinite loop, etc.
• Gas model: Check whether the handling fees corresponding to each atomic operation of transaction processing/contract execution are proportional to resource consumption
• Logging integrity: Check whether key information is logged
• Security of log records: Check whether there are security issues caused by improper handling during log processing, such as integer overflow, etc.
• The log contains private information: Check whether the log contains private information such as keys
• Log storage: Check whether the log records too much content, causing node resource consumption
• Node code supply chain security: Check the known issues of all third-party libraries, components and corresponding versions of the public chain framework

Beosin is one of the first blockchain security companies in the world to engage in formal verification.Focusing on the “security + compliance” full ecological business, it has established branches in more than 10 countries and regions around the world. Its business covers code security audits before the project goes online, security risk monitoring and blocking during project operation, theft recovery, “One-stop” blockchain compliance products + security services such as virtual asset anti-money laundering (AML) and compliance assessments that comply with local regulatory requirements. Project parties with audit needs are welcome to contact the Beosin security team.

Disclaimer：

1. This article is reprinted from [Beosin]. All copyrights belong to the original author [Beosin]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.