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

As the world’s first cryptocurrency, Bitcoin (BTC) has gradually become the cornerstone of digital assets and decentralized finance since its debut in 2009.However, as the number of users and transaction volume increases,The problems of BTC network are becoming 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 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 blocks to be considered final confirmation.
Limitations of smart contracts: Bitcoin’s scripting language features are limited and it is difficult to implement complex smart contracts.

In this article, we collectively refer to Lightning Network, Sidechains, Rollup and other technologies as BTC Layer2 expansion solutions. While achieving fast and low-cost transactions, they maintain the decentralization and security of the BTC network.sex.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 innovative directions 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, several well-known public chains have passed Beosin’s public chain security audit, includingRonin Network, Clover, Self Chain, Crust Networkwait.Beosin now launches an audit plan for BTC Layer2, providing comprehensive and reliable security audit services to the entire BTC ecosystem.

Lightning Network

The earliest concept of Lightning Network was called “payment channel”. Its design idea is to constantly update unconfirmed transaction status 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 a payment channel and included a draft code for the payment channel in Bitcoin 1.0, which allows users to update the transaction status before the transaction is 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 solutions for payment channels and Lightning Network are very mature.As of now, Lightning Network has 13,325 nodes and 49,417 channels, and the total amount of staking 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 of both parties submit two transactions to the Bitcoin main network: one is used to open the channel and the other is used to close the channel.It is roughly divided into the following three steps:

1. Channel opening:

First, users of both parties pledge Bitcoin to Lightning Network’s multi-signature wallet on BTC.Once 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 by the number of times.Of course, these transactions do not need to be submitted immediately to the Bitcoin main network, 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 main network.

3. Channel closing and account settlement:

When the user of either party decides to exit the channel, the final ledger settlement will be conducted.This process ensures that all funds in the channel are allocated on the latest status.At the same time, users of both parties will withdraw the settlement 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 ledger transaction to the Bitcoin main network.

The advantage of Lightning Network is:

Increased trading speed.Lightning Network allows users to trade off-chain, meaning that transactions can be completed almost instantly without waiting for block confirmation time.This can achieve transaction speed at the second level, greatly improving the user experience.
Enhanced privacy.Off-chain transactions of 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 the channel needs to be recorded on the main chain, so the user’s transaction behavior will not be fully disclosed.
Micropayment Support.Lightning Network is very suitable for handling small payments (micro payments), such as content payments, Internet of Things device payments, etc.Traditional Bitcoin transactions are not suitable for frequent small payments due to their high handling fees, and Lightning Network solves this problem.

The challenges facing the Lightning Network:

Network liquidity issues: Lightning Network relies on Bitcoins that are pre-locked in the channel.This means that users must deposit enough Bitcoin in their payment channel in advance for transactions.Inadequate liquidity can lead to payment failure, especially when larger payments are made.
Routing issues: Finding a valid path from the sender of the payment to the receiver can be a complex problem, especially when the network is large.As network nodes and channels increase, it also becomes more difficult to ensure smooth payment completion.
Fund custody trust issues: Nodes may encounter malicious attacks, and users need to trust the nodes they are connected to will not try to steal funds.Can nodes prevent private key leakage
Technical standards and interoperability: There are consistent technical standards and protocols between different lightning network implementations to ensure interoperability.Currently, multiple development teams are developing different implementations of Lightning Networks, which can lead to compatibility issues.
Privacy Issues: Although Lightning Network has improved the privacy of Bitcoin transactions, transaction information may still be tracked or analyzed.In addition, network node operators can see transactions through their nodes, which may reveal certain privacy information.

The security of the Lightning Network directly affects Bitcoin’s off-chain expansion capabilities and the security of user funds.thereforeIn addition to the general audit items of public chains(See the appendix at the end of this article for details)outside,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 and whether the channel congestion will be caused by sad attacks.
Channel interference: Check the security of the channel structure of the Lightning Network and whether it will be attacked by channel interference.
Channel Asset Locking and Unlocking: Review the process of asset locking and unlocking in the Lightning Network to ensure that the transfer of funds on and off-chain is safe and reliable when opening or closing the payment channel.
Status update and close: 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 an exception occurs.
Time Lock and Hash Lock Contract (HTLC): Evaluate the implementation of HTLC to ensure that the time lock and hash lock conditions can be executed correctly and prevent fund losses caused by time window problems.
Blockchain timestamp dependence: Evaluate the dependence of Lightning Network on Bitcoin blockchain timestamps, ensure that on-chain and off-chain time can be coordinated correctly and 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 state can be restored when the node fails or unexpectedly disconnects, and avoids loss of funds.

Side chain

Unlike Lightning Network, Sidechain 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 side chains 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, ensuring the free and secure transfer of assets 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 agency 1 acquires and uses SPV verification 2 to ensure that the user locks the transaction is confirmed.

2. Trusted institutions will issue tokens of equivalent value to users on the side chain.

3. After the user free transaction, he locks the remaining tokens on the side chain.

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

Note 1:Trusted InstitutionsPlay 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 level of credibility and technical capabilities to ensure the security of user assets.

Note 2:SPV VerificationAllows nodes to verify the validity of a specific transaction without downloading the complete blockchain.The SPV node simply downloads the block header and verifies whether the transaction is included in the block through Merkle Tree.

Representative items of side chains:

CKB (Nervos Network)

Nervos Network is an open source public blockchain ecosystem designed to leverage the security and decentralization of BTC’s POW consensus mechanism, while introducing a more scalable and flexible UTXO model to handle 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 a consensus.It expands the UTXO model into a Cell model, allowing it to store any data, and supports scripting in any language to be executed on-chain as a smart contract.

Stacks

Stacks connects each Stacks block with a 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 passing in the Bitcoin block height and getting the header hash of that block.At the same time, the burn-block-height keyword can obtain the current block height of the Bitcoin chain.These two functions allow Clarity smart contracts to read the state of the Bitcoin basic chain, thus allowing Bitcoin transactions to act as contract triggers.Stacks expands the capabilities of Bitcoin by automatically executing these smart contracts.

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

The advantage of side chains is:

Sidechains can adopt 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., enrich the application scenarios of the blockchain ecosystem.

Challenges facing side chains:

Side chains have independent consensus mechanisms, probably not as secure as the BTC main chain.If the consensus mechanism of the side chain is weak or there are vulnerabilities, it may lead to 51% attacks or other forms of attacks, affecting the security of user assets.The security of the BTC main chain depends on its huge computing power and extensive node distribution, while the side chain may not meet the same security standards.
The implementation of a two-way anchoring mechanism requires complex encryption algorithms and protocols. If there are vulnerabilities, it may lead to problems in asset transfer between the main chain and the side chain, and may even lead to asset loss or stolen.
To find a balance between speed and safety, most side chainsHigher centralization than the main chain.

Layer2 is a complete blockchain system, so the general audit items of public chains are also applicable to side chains, see the appendix at the end of this article for details.

also,Due to its particularity, the side chain also requires some additional audits:

Consensus protocol security: Review whether the consensus protocols (such as PoW, PoS, DPoS) of the side chain have 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 compromised or abused.
Asset locking and release: Review the two-way asset anchoring mechanism between the side chain and the main chain to ensure that the smart contract for locking and releasing assets is safe and reliable, and prevent double spending, asset loss or locking failure.
Cross-chain verification: Check the accuracy and security of cross-chain verification to ensure that the verification process is decentralized and tamper-proof, and prevent verification failure or malicious verification.
Contract Code Audit: Deeply audit all smart contracts running on the sidechain, detecting possible vulnerabilities or backdoors, especially contract logic when handling cross-chain operations.
Upgrade mechanism: Check whether the upgrade mechanism of smart contracts is safe and whether there are appropriate audit and community consensus processes to prevent malicious upgrades or contract tampering.
Internode communication: Check whether the communication protocol between side chain nodes is secure and whether an encrypted channel is used to prevent man-in-the-middle attacks or data leakage.
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 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 difference.
On-chain governance security: Review the governance mechanisms of side chains to ensure transparency and security of voting, proposals and decision-making processes, and prevent malicious control or attacks.
Token Economic Audit: Check the token economic model of the side chain, including token allocation, incentive mechanisms and inflation models, to ensure that economic incentives do 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 the main chain and side chain users, and prevents fee manipulation or network congestion.
Asset security: The management mechanism of assets on the audit chain ensures that the storage, transfer and destruction of assets are safe and reliable, and there is no risk of unauthorized access or theft.
Key management: Check the sidechain’s key management policy to ensure the security and access control of the private key, and prevent the key from being leaked or stolen.

Rollup

Rollup is a Layer2 scaling solution designed to improve transaction throughput and efficiency of blockchain.It greatly reduces the burden on the main chain by packaging a large number of transactions (“Rollup”) and processing off-chain, only submitting the final result 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:

To complete zero-knowledge proof verification on BTC, B² Network created a Taproot script that combines zk-Rollup’s zero-knowledge proof verification and op-Rollup’s motivational challenge.Its operating mechanism is roughly as follows:

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

2. After sorting Rollup transactions using the sorter, 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 contract execution and other transactions, and merges and packages the results and sends them to the aggregator.

4. Prover generates zero-knowledge proofs and sends them to the aggregator, and sends them to B² Nodes through the aggregator aggregation transaction and proofs.

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

The advantages of Rollup are:

RollupInherited the security and decentralization of the main chain.Data integrity and transparency are ensured by submitting transaction data and status to the main chain regularly.
Rollup is able to seamlessly integrate into existing blockchain networks, such as Ethereum, allowing developers to easily leverage their advantages without having to significantly modify existing smart contracts and applications.
Rollup has greatly improved transaction processing capabilities by processing a large number of transactions off-chain and packaging them into a batch to submit them to the main chain, resulting in a significant increase in 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 facing Rollup:

If off-chain data is not available, users may not be able to verify transactions and restore states.
Rollup transactions need to be processed in batches and finally submitted to the main chain, which may result in a longer settlement time.Especially in op-Rollup, there is a controversial period, and users may have to wait a long time before they can finally confirm the transaction.
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 ETH Layer2.

Others (Babylon)

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

Babylon’s goal is to convert 21 million BTC into decentralized staking assets.Unlike other Layer2s of BTC, Babylon does not expand the BTC chain.It is a unique chain with a special BTC staking protocol. The main purpose is to connect with the PoS chain. Pledge BTC provides stronger security for the PoS chain and solves attack risks and centralization such as remote attacks from the chain.question.

The architecture is divided into three layers:

Bitcoin layer: This is a solid foundation for Babylon, 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 with various proof-of-stake (PoS) chains.It processes transactions, runs smart contracts, and ensures that everything goes smoothly throughout the ecosystem.

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

The operation is to protect the PoS chain using the final block signed on the BTC chain.This essentially extends the underlying protocol with additional signature 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 to solve the problems of long-term unbinding periods and remote attacks of PoS.

Babylon’s advantages are:

Make the unbinding period of PoS faster
Because BTC is pledged, the price is linked to BTC, which can alleviate the inflation pressure of the corresponding PoS network
Opening new ways to gain BTC

Challenges Babylon:

Economic designs such as pledge return rate have a great impact on the enthusiasm of BTC pledge
Lack of reward consistency regulations between PoS chains

The security points of concern to third-party agreements are not consistent depending on their implementation. Take Babylon as an example. Some security audit items that need to be paid attention to are as follows.:

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

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

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

appendix:

Public chain & Layer2 general audit item

Integer overflow: Check for integer overflow and integer underflow
Dead loop: Check whether the loop judgment conditions of the program are reasonable
Infinite recursive call: Check whether the exit condition of the program recursive call is reasonable
Race condition: Check the access operation to shared resources in a concurrent state
Exception crash: Check the exception throw code that allows the program to actively exit
Dividing 0 vulnerability: Check whether there is any situation where the dividing is 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 to access elements that exceed the array bounds
Deserialization vulnerability: Check whether there are any problems during deserialization
Functional security: Check whether there are security risks in each RPC interface implementation and whether it is effective in interface with RPC.
Can design to match
Is the permission settings for sensitive RPC interface reasonable: Check the access permission settings for sensitive RPC interfaces
Encrypted transmission mechanism: Check whether an encrypted transmission protocol is used, such as TLS, etc.
Request data format analysis: Check the format analysis process of requested 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 vulnerability / HTTP parameter pollution / SQL injection / XXE entity injection / Desequence
Traditional vulnerabilities such as SSRF vulnerabilities / Code Injection / Local File Inclusion / Remote File Inclusion / Command Execution Injection
Network node identity authentication and identification mechanism: Check whether there is a node identity identification mechanism and whether the node identity identification mechanism can be reversed.
Router table pollution: Check whether the routing table can be inserted or overwritten at will
Node discovery algorithm: Check whether the node discovery algorithm is balanced and unpredictable, such as the distance algorithm imbalance and other problems
Audit for the number of connections: Check whether the limit and management of the number of nodes connected to the p2p network is reasonable
Eclipse Attack: Assess the cost and harm of eclipse attacks and provide quantitative analysis if necessary
Witch Attack: Evaluate voting consensus mechanisms and analyze voting qualification check strategies
Eavesdropping attack: Check whether the communication protocol leaks privacy
Alien attack: Evaluate whether a node can identify similar chain nodes
Time hijacking: Check the network time computer system of nodes
Memory exhaustion attack: Check where large memory consumes
Hard disk exhaustion attack: Check where large files are stored
Socket pressure attack: a limiting strategy for checking the number of links
Kernel handle exhaustion attack: Check the limitations of kernel handle creation, such as file handles, etc.
Continuous memory leaks: Check where memory leaks are
Hash algorithm security: Check the collision resistance of hash algorithm
Digital signature algorithm security: check the security of signature algorithm and the security of algorithm implementation
Encryption algorithm security: check the security of encryption algorithm and the security of algorithm implementation
Random number generator security: Check whether the key random number generation algorithm is reasonable
BFT implementation security: Evaluate the implementation security of BFT algorithm
Fork selection rules: Check fork selection rules for security
Determination of centralization: identifying whether there is over-centralized design in system design
Incentive mechanism audit: Evaluate the impact of incentive mechanisms on security
Double-sweet Attack: Check whether consensus can defend against Double-sweet Attack
MEV Attack Audit: Check the impact of MEV on chain fairness of block packaging nodes
Block synchronization process audit: Check security issues during synchronization process
Block format parsing process audit: Check security issues during format parsing, such as parsing errors that lead to crashes
Audit of the block generation process: Check security issues during block generation, including whether the Merkle tree root build 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 processing during collision is reasonable
Block processing resource limitations: Check whether orphan block pools, verification computing, hard disk addressing and other resource limitations are reasonable
Transaction synchronization process audit: Check security issues during synchronization process
Transaction hash collision: Check the construction method of transaction hash collision and the processing during collision
Transaction format analysis: Check security issues during format parsing, such as parsing errors that lead to crashes
Transaction legality verification: Check whether the content items and verification logic of each type of transaction signature are sufficient
Transaction processing resource limitations: Check whether the resource limitations such as transaction pool, verification calculation, hard disk addressing are reasonable
Transaction Extensibility Attack: Can a transaction change internal fields (such as ScriptSig) and change the transaction hash without affecting the validity of the transaction
Trading replay attack audit: Check the system’s detection of transaction replay
Contract bytecode verification: Check the security issues of the process of checking contracts by virtual machines, such as integer overflow, dead loop, etc.
Contract bytecode execution: Check the security issues of the process of executing bytecode by virtual machines, such as integer overflow, dead loop, etc.
Gas model: Check whether the corresponding handling fees for each atomic operation executed by transaction processing/contract are proportional to resource consumption
Logging integrity: Check whether key information is logged
Security of logging: Check whether security problems caused by improper processing during log processing, such as integer overflow, etc.
Log contains privacy information: Check whether the log contains privacy information such as keys.
Log storage: Check whether the log records too much content, resulting in node resource consumption
Node code supply chain security: Check all third-party libraries, components and public chain frameworks for known issues