Since its inception in 2009, Bitcoin (BTC), as the world’s first cryptocurrency, has gradually become the cornerstone of digital assets and decentralized finance. However, as the number of users and transaction volumes grow, several issues with the BTC network have become increasingly apparent:

• High Transaction Fees: When the Bitcoin network is congested, users need to pay higher fees to ensure that their transactions are confirmed promptly.
• Transaction Confirmation Time: The Bitcoin blockchain generates a new block approximately every 10 minutes, meaning that on-chain transactions typically require multiple block confirmations before they are considered final.
• Smart Contract Limitations: Bitcoin’s scripting language is limited in functionality, making it difficult to implement complex smart contracts.

In this article, we refer to technologies such as the Lightning Network, Sidechains, and Rollup collectively as BTC Layer2 scaling solutions. These technologies enable fast, low-cost transactions while maintaining the decentralization and security of the BTC network. The introduction of Layer2 technologies can enhance transaction speed, reduce transaction costs, optimize user experience, and expand network capacity, providing crucial technical support and innovation for BTC’s future development.

Currently, Beosin has become the official security partner for several BTC Layer2 projects like Merlin Chain and has audited multiple BTC ecosystem protocols, including Bitmap.Games, Surf Protocol, Savmswap, and Mineral. In past audits, numerous well-known public chains, such as Ronin Network, Clover, Self Chain, and Crust Network, have successfully passed Beosin’s public chain security audits. Beosin now offers a comprehensive audit solution for BTC Layer2, providing reliable and thorough security auditing services for the entire BTC ecosystem.

The Lightning Network

The initial concept behind the Lightning Network was known as a “payment channel.” The design philosophy was to continuously update the status of unconfirmed transactions through transaction replacement until they were eventually broadcast to the Bitcoin network. When Satoshi Nakamoto created Bitcoin in 2009, he had already proposed the idea of payment channels, even including a draft code for payment channels in Bitcoin 1.0. This draft allowed users to update the transaction status before it was confirmed by the network. However, it wasn’t until the release of the white paper titled The Bitcoin Lightning Network: Scalable Off-Chain Instant Payment that the Lightning Network truly came into existence and gained public attention.

Today, the implementation of payment channels and the Lightning Network has become quite mature. As of now, the Lightning Network consists of 13,325 nodes and 49,417 channels, with a total of 4,975 BTC staked.

https://1ml.com/

In the Lightning Network, ensuring the security of users’ assets during transfers is crucial. Below, we will explain how the Lightning Network operates and how it protects the security of user assets, based on the scale of network nodes.

Both parties involved submit two transactions to the Bitcoin mainnet: one to open the channel and another to close it. The process generally involves three steps:

1.Channel Opening:

First, both users stake Bitcoin into a multi-signature wallet on the BTC network through the Lightning Network. Once the Bitcoin is successfully staked and locked, the payment channel is opened, allowing both parties to conduct off-chain transactions within this channel.

2.Off-chain transactions:

Once the channel is opened, all transfer transactions between the users are processed within the Lightning Network, and there is no limit to the number of these off-chain transactions. These transactions do not need to be immediately submitted to the Bitcoin mainnet but are instead instantly completed through the Lightning Network’s off-chain mechanism.

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

3.Channel Closure and Ledger Settlement:

When either user decides to exit the channel, a final ledger settlement occurs. This process ensures that all funds in the channel are distributed according to the most recent state. Both users then withdraw their respective settled balances from the multi-signature wallet, reflecting the actual distribution of funds at the time the channel is closed. Finally, the transaction representing the final state of the ledger is submitted to the Bitcoin mainnet.

The advantages of the Lightning Network include:

• Increased Transaction Speed:
  The Lightning Network allows users to conduct transactions off-chain, meaning transactions can be completed almost instantly without waiting for block confirmation times. This enables second-level transaction speeds, greatly enhancing the user experience.
• Enhanced Privacy:
  Off-chain transactions on the Lightning Network do not need to be publicly recorded on the Bitcoin mainchain, improving transaction privacy. Only the opening and closing of channels need to be recorded on the mainchain, so users’ transaction activities are not fully disclosed.
• Support for Micro-Payments:
  The Lightning Network is particularly well-suited for handling micro-payments, such as content payments and payments between IoT devices. Traditional Bitcoin transactions, due to high fees, are not ideal for frequent micro-payments, but the Lightning Network addresses this issue.

Challenges faced by the Lightning Network include:

• Network Liquidity:
  The Lightning Network relies on Bitcoin being pre-locked in the channel. This means users must deposit enough Bitcoin in their payment channels in advance to facilitate transactions. Insufficient liquidity can lead to payment failures, especially for larger payments.
• Routing:
  Finding an effective route from the sender to the recipient can be a complex issue, especially as the network grows in scale. As the number of network nodes and channels increases, ensuring successful payment completion becomes more challenging.
• Custodial Trust: Nodes may be susceptible to malicious attacks, and users need to trust that the nodes they are connected to will not attempt to steal funds. There is also the question of whether nodes can prevent private key leaks.
• Technical Standards and Interoperability: Consistent technical standards and protocols are required to ensure interoperability between different implementations of the Lightning Network. Currently, multiple development teams are working on various implementations of the Lightning Network, which could lead to compatibility issues.
• Privacy Issues: Although the Lightning Network enhances privacy for Bitcoin transactions, transaction information could still be tracked or analyzed. Moreover, network node operators can see transactions passing through their nodes, potentially compromising some privacy.

The security of the Lightning Network directly impacts Bitcoin’s off-chain scalability and the safety of user funds. Therefore, in addition to the common audit items for public chains (detailed in the appendix at the end of this document), the Lightning Network also needs to address the following key security risks:

• Channel Congestion:
  Evaluate the comprehensiveness of the Lightning Network system design to ensure it is not susceptible to denial-of-service attacks that could lead to channel congestion.
• Channel Interference:
  Assess the security of the Lightning Network’s channel structure to ensure it is not vulnerable to channel jamming attacks.
• Channel Asset Locking and Unlocking:
  Review the processes for locking and unlocking assets in the Lightning Network to ensure that fund transfers between on-chain and off-chain are secure and reliable during the opening or closing of payment channels.
• State Updates and Channel Closure:
  Evaluate the processes for updating the state of channels and the force-close mechanism to ensure that, in the event of an abnormal situation, the latest state can be accurately recognized and executed.
• Time Locks and Hash Time-Locked Contracts (HTLCs):
  Assess the implementation of HTLCs to ensure that time lock and hash lock conditions are correctly enforced, preventing potential fund loss due to timing window issues.
• Dependency on Blockchain Timestamps:
  Evaluate the Lightning Network’s dependence on Bitcoin blockchain timestamps to ensure proper synchronization of on-chain and off-chain times, preventing time-based attacks.
• Routing Algorithm Security: Examine the efficiency and security of routing algorithms to prevent risks of privacy exposure and malicious routing manipulation.
• Channel Storage and Data Recovery:
  Check the channel’s storage mechanism and data recovery strategy to ensure that channel states can be restored in the event of node failures or unexpected disconnections, preventing the loss of funds.

Sidechains

Unlike the Lightning Network, a sidechain is an independent blockchain that operates parallel to the mainchain (such as the BTC blockchain) and interoperates with it through a mechanism known as a two-way peg (2WP). The purpose of sidechains is to enable additional functionality and scalability without altering the mainchain’s protocol.

A sidechain, as an independent blockchain, has its own consensus mechanism, nodes, and transaction processing rules. It can adopt different technologies and protocols according to the needs of specific application scenarios. Through the two-way peg mechanism, the sidechain communicates with the mainchain, ensuring that assets can be transferred freely and securely between them. The operation of the two-way peg mechanism generally involves the following steps:

1. The user locks BTC on the mainchain. A trusted entity then obtains and uses Simplified Payment Verification (SPV) to confirm whether the user’s lock transaction has been confirmed.

2. The trusted entity issues an equivalent amount of tokens to the user on the sidechain.

3. After completing their transactions, the user locks the remaining tokens on the sidechain.

4. After verifying the transactions’ legitimacy, the trusted entity unlocks and releases the corresponding value of BTC to the user on the mainchain.

Note 1: Trusted entities play a critical role in the two-way peg mechanism, managing the locking and releasing of assets. These entities must possess high levels of trustworthiness and technical capability to ensure the security of users’ assets.

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

Representative Sidechain Projects

CKB (Nervos Network) \
Nervos Network is an open-source public blockchain ecosystem designed to leverage the security and decentralization benefits of Bitcoin’s Proof of Work (PoW) consensus mechanism while introducing a more scalable and flexible UTXO model to handle transactions. At its core is the Common Knowledge Base (CKB), a Layer 1 blockchain built on RISC-V and using PoW as its consensus mechanism. It extends the UTXO model into the Cell model, allowing it to store any data and support scripts written in any language to execute as smart contracts on-chain.

Stacks

Stacks connects each Stacks block with a Bitcoin block through its Proof of Transfer (PoX) mechanism. To facilitate the development of smart contracts, Stacks has designed the Clarity programming language. In Clarity, the get-burn-block-info? function allows the input of a Bitcoin block height to retrieve the block’s header hash, while the burn-block-height keyword retrieves the current block height of the Bitcoin chain. These functions enable Clarity smart contracts to read the state of the Bitcoin base chain, allowing Bitcoin transactions to trigger contracts. By automatically executing these smart contracts, Stacks extends Bitcoin’s functionality. For a detailed analysis of Stacks, you can refer to Beosin’s previous research article: What is Stacks? What Challenges Might BTC Layer 2 Network Stacks Face?

Advantages of Sidechains

• Sidechains can adopt different technologies and protocols, enabling various experiments and innovations without affecting the stability and security of the mainchain.
• Sidechains can introduce features not present on the mainchain, such as smart contracts, privacy protection, and token issuance, enriching the application scenarios of the blockchain ecosystem.

Challenges of Sidechains

• Sidechains have independent consensus mechanisms, which may not be as secure as the BTC mainchain. If a sidechain’s consensus mechanism is weak or has vulnerabilities, it could lead to a 51% attack or other forms of attacks, jeopardizing the security of user assets. The BTC mainchain’s security relies on its massive hash power and widespread node distribution, which a sidechain may not be able to match.
• Implementing the two-way peg mechanism requires complex cryptographic algorithms and protocols. If there are vulnerabilities within this mechanism, it could lead to issues in asset transfers between the mainchain and the sidechain, potentially resulting in asset loss or theft.
• To balance speed and security, most sidechains are more centralized than the mainchain.

Layer 2 is a complete blockchain system, so the general audit items for public blockchains also apply to sidechains. For details, please refer to the appendix at the end of this article.

Additionally, due to its unique characteristics, sidechains require some extra audits:

• Security of Consensus Protocol:
  Review whether the sidechain’s consensus protocol (e.g., PoW, PoS, DPoS) has been thoroughly validated and tested for potential vulnerabilities or attack vectors, such as 51% attacks or long-range attacks.
• Consensus Node Security:
  Assess the security of consensus nodes, including key management, node protection, and redundancy backups, to prevent nodes from being compromised or abused.
• Asset Locking and Releasing:
  Examine the two-way peg mechanism between the sidechain and the mainchain to ensure that the smart contracts responsible for locking and releasing assets are secure and reliable, preventing double-spending, asset loss, or lock failures.
• Cross-Chain Verification:
  Check the accuracy and security of cross-chain verification to ensure the process is decentralized and tamper-proof, preventing verification failures or malicious verification.
• Smart Contract Code Audit:
  Conduct a thorough audit of all smart contracts running on the sidechain, detecting any potential vulnerabilities or backdoors, especially in the contract logic handling cross-chain operations.
• Upgrade Mechanism:
  Review the security of the smart contract upgrade mechanism, ensuring that there are appropriate audit and community consensus processes in place to prevent malicious upgrades or contract tampering.
• Inter-Node Communication:
  Inspect the security of the communication protocol between sidechain nodes, ensuring the use of encrypted channels to prevent man-in-the-middle attacks or data breaches.
• Cross-Chain Communication:
  Assess the communication channels between the sidechain and the mainchain to ensure data integrity and authenticity, preventing the communication from being hijacked or tampered with.
• Timestamp and Block Time:
  Verify the time synchronization mechanism of the sidechain to ensure consistency and accuracy in block generation time, preventing attacks or block rollbacks caused by time discrepancies.
• On-Chain Governance Security:
  Review the governance mechanism of the sidechain to ensure transparency and security in voting, proposal, and decision-making processes, preventing malicious control or attacks.
• Token Economics Audit:
  Examine the tokenomics of the sidechain, including token distribution, incentive mechanisms, and inflation models, ensuring that economic incentives do not lead to malicious behavior or system instability.
• Fee Mechanism:
  Review the transaction fee mechanism of the sidechain to ensure it aligns with the needs of both mainchain and sidechain users, preventing fee manipulation or network congestion.
• Asset Security:
  Audit the management mechanism of on-chain assets to ensure that the processes for storing, transferring, and burning assets are secure and reliable, with no risk of unauthorized access or theft.
• Key Management:
  Inspect the key management strategy of the sidechain to ensure the security of private keys and access control, preventing key leakage or misuse.

Rollup

Rollup is a Layer 2 scaling solution designed to enhance blockchain transaction throughput and efficiency. By aggregating a large number of transactions (“Rolling up”) and processing them off-chain, it reduces the load on the main chain, submitting only the final results back to it.

Rollup comes in two main types: zk-Rollup and op-Rollup. However, unlike Ethereum, Bitcoin’s lack of Turing completeness prevents the use of smart contracts for zero-knowledge proof (ZKP) verification directly on its network. This means that traditional zk-Rollup solutions cannot be implemented on Bitcoin. So, how can zk-Rollup be used to achieve Bitcoin Layer 2 scaling? Let’s explore the B² Network project as an example:

To perform ZKP verification on Bitcoin, B² Network has developed a Taproot script that integrates zk-Rollup’s zero-knowledge proof verification with op-Rollup’s incentive challenge mechanism. Here’s how it works:

1. B² Network first aggregates all user transactions into a Rollup.
2. A sequencer then orders these Rollup transactions, storing them in decentralized storage and processing them through a zkEVM.
3. After syncing the Bitcoin chain state, the zkEVM processes contract executions and other transactions, consolidating the results and sending them to the aggregator.
4. The prover generates a zero-knowledge proof and sends it to the aggregator, which combines the transactions and proof and forwards them to B² Nodes.
5. B² Nodes verify the zero-knowledge proof and create a Taproot script based on the Rollup data stored in decentralized storage.
6. The Taproot, which is a UTXO with a value of 1 satoshi, contains B² Inscription in its data structure, storing all Rollup data, while the Tapleaf stores the verification data of all proofs. After passing the incentive challenge mechanism, it is submitted to Bitcoin as a zk-proof-based commitment.

Advantages of Rollup:

• Rollup inherits the security and decentralization features of the main chain. By regularly submitting transaction data and state to the main chain, it ensures data integrity and transparency.
• Rollup can be seamlessly integrated into existing blockchain networks, such as Ethereum, allowing developers to easily leverage its benefits without significant modifications to existing smart contracts and applications.
• Rollup significantly increases transaction throughput by processing a large number of transactions off-chain and submitting them in batches to the main chain, leading to a notable increase in transactions per second (TPS).
• Since Rollup transactions are processed off-chain, it drastically reduces the computational resources and storage space required for on-chain transactions, thereby significantly lowering user transaction fees.

Challenges of Rollup:

• If off-chain data becomes unavailable, users may be unable to verify transactions and recover their state.
• Rollup transactions need to be processed in batches and eventually submitted to the main chain, which may lead to longer settlement times. This is especially true in the case of op-Rollup, where there is a dispute period, causing users to wait longer for final transaction confirmation.
• While ZK Rollup provides higher security and instant confirmation, it requires substantial computational resources for generating zero-knowledge proofs.

Given that Rollup is used, its key security audit items are consistent with those of Ethereum’s Layer 2.

Others (Babylon)

In addition to traditional BTC Layer 2 solutions, some new third-party protocols related to the BTC ecosystem have emerged, such as Babylon:

Babylon aims to transform 21 million BTC into decentralized staking assets. Unlike other BTC Layer 2 solutions, Babylon does not focus on scaling the BTC network. Instead, it is a unique blockchain with a specialized BTC staking protocol designed primarily to interface with Proof of Stake (PoS) chains. The goal is to stake BTC to enhance the security of PoS chains, addressing issues like long-range attacks and centralization risks.

The architecture is divided into three layers:

• Bitcoin Layer: This is the solid foundation of Babylon, leveraging Bitcoin’s renowned security to ensure that all transactions are ultra-secure, just as they are on the Bitcoin network.
• Babylon Layer: The core of Babylon, this custom blockchain connects Bitcoin to various PoS chains. It handles transactions, runs smart contracts, and ensures smooth operation across the ecosystem.
• PoS Chain Layer: The top layer consists of multiple PoS chains, each selected for its unique advantages. This structure grants BabylonChain remarkable scalability and flexibility, allowing users to benefit from the best features of different PoS blockchains.

Babylon operates by signing final blocks on the BTC chain to secure PoS chains. This essentially extends the base protocol with an additional round of signatures. These signatures in the final +1 round have a unique feature: they are Extractable One-Time Signatures (EOTS). The goal is to integrate PoS checkpoints onto the BTC chain, addressing the issues of long unbinding periods and long-range attacks in PoS systems.

Advantages of Babylon:

• Babylon accelerates the unbinding process of PoS staking.
• By staking BTC, Babylon helps alleviate inflationary pressures on the corresponding PoS network.
• Babylon opens up new avenues for BTC holders to earn returns.

Challenges of Babylon:

• The staking reward rates and other economic factors significantly impact the incentive for BTC staking.
• There is no uniformity in reward mechanisms across different PoS chains.

The security focus varies depending on the specific implementation of third-party protocols. For Babylon, some key security audit points include:

1. Smart Contract Security: Staking contracts on BTC are implemented through UTXO scripts, which require careful attention to their security.
2. Signature Algorithm Security: The security of the signature algorithm used to manage staking in the contract is critical, as it affects the generation and verification of signatures.
3. Economic Model Design: The economic model of the protocol, particularly in terms of rewards and penalties, needs to be scrutinized to ensure it doesn’t lead to the loss of user assets.

Appendix:

General Audit Items for Public Chains & Layer 2

• Integer Overflow: Check for integer overflow and underflow.
• Infinite Loop: Verify whether the loop conditions in the program are reasonable.
• Infinite Recursion: Ensure that the exit conditions for recursive calls are properly set.
• Race Condition: Examine access operations on shared resources under concurrent conditions.
• Unhandled Exceptions: Identify code that throws exceptions causing the program to exit unexpectedly.
• Division by Zero: Check for instances where division by zero may occur.
• Type Conversion: Ensure type conversions are accurate and no critical information is lost in the process.
• Array Out-of-Bounds: Ensure that array elements are accessed within valid boundaries.
• Deserialization Vulnerabilities: Check for issues during the deserialization process.
• Functionality Implementation Security: Verify whether the implementation of RPC interfaces is secure and consistent with their functional design.
• Sensitive RPC Interface Permission Settings: Ensure that access permissions for sensitive RPC interfaces are appropriately configured.
• Encrypted Transmission Mechanism: Verify the use of encrypted transmission protocols, such as TLS.
• Request Data Format Parsing: Check the process for parsing request data formats.
• Wallet Unlock Attack: Ensure that funds are not stolen via RPC requests when a node unlocks its wallet.
• Traditional Web Security: Check for the following vulnerabilities: Cross-Site Scripting (XSS), Template Injection, Third-Party Component Vulnerabilities, HTTP Parameter Pollution, SQL Injection, XXE Injection, Deserialization Vulnerabilities, SSRF Vulnerabilities, Code Injection, Local File Inclusion, Remote File Inclusion, Command Injection, etc.
• Network Node Authentication and Identification Mechanism: Ensure there is a node identity recognition mechanism and that it cannot be bypassed.
• Routing Table Poisoning: Check if the routing table can be manipulated or overwritten arbitrarily.
• Node Discovery Algorithm: Ensure the node discovery algorithm is balanced and unpredictable, addressing issues such as imbalances in distance algorithms.
• Connection Occupancy Audit: Ensure that the limit and management of nodes connected in the p2p network are reasonable.
• Eclipse Attack: Assess the cost and impact of eclipse attacks, providing quantitative analysis if necessary.
• Sybil Attack: Evaluate the voting consensus mechanism and analyze the strategies for verifying voting eligibility.
• Eavesdropping Attack: Verify that the communication protocol does not leak private information.
• Alien Attack: Assess whether nodes can recognize other nodes from the same blockchain network.
• Time Hijacking: Verify the mechanism for calculating network time on nodes.
• Memory Exhaustion Attack: Check areas of high memory consumption.
• Disk Exhaustion Attack: Check areas involving large file storage.
• Socket Stress Attack: Verify strategies limiting the number of connections.
• Kernel Handle Exhaustion Attack: Ensure that limits on kernel handle creation, such as file handles, are reasonable.
• Persistent Memory Leaks: Identify areas prone to memory leaks.
• Hash Algorithm Security: Ensure the hash algorithm is collision-resistant.
• Digital Signature Algorithm Security: Verify the security of the signature algorithm and its implementation.
• Encryption Algorithm Security: Ensure the encryption algorithm and its implementation are secure.
• Random Number Generator Security: Verify that critical random number generation algorithms are reasonable.
• BFT Implementation Security: Evaluate the security of the Byzantine Fault Tolerance (BFT) algorithm implementation.
• Fork Choice Rule: Verify the fork choice rule to ensure security.
• Centralization Detection: Identify any excessive centralization in system design.
• Incentive Mechanism Audit: Assess the impact of the incentive mechanism on security.
• Double-Spending Attack: Verify whether the consensus can defend against double-spending attacks.
• MEV Attack Audit: Evaluate the impact of Maximum Extractable Value (MEV) on chain fairness during block packing.
• Block Synchronization Process Audit: Check for security issues during the synchronization process.
• Block Format Parsing Audit: Assess security concerns during block format parsing, such as parsing errors leading to crashes.
• Block Generation Process Audit: Review the security of the block generation process, including the construction of the Merkle tree root.
• Block Verification Process Audit: Check the content items of block signatures and whether the verification logic is adequate.
• Block Confirmation Logic Audit: Assess whether the block confirmation algorithm and its implementation are reasonable.
• Block Hash Collision: Check how block hash collisions are constructed and whether the handling of such collisions is appropriate.
• Block Processing Resource Limits: Verify whether resource limits for the orphan block pool, verification computation, and disk addressing are reasonable.
• Transaction Synchronization Process Audit: Review security issues during the transaction synchronization process.
• Transaction Hash Collision: Check how transaction hash collisions are constructed and handled.
• Transaction Format Parsing: Assess security concerns during transaction format parsing, such as parsing errors leading to crashes.
• Transaction Legitimacy Verification: Verify the content items of various transaction signatures and whether the verification logic is sufficient.
• Transaction Processing Resource Limits: Review whether resource limits for the transaction pool, verification computation, and disk addressing are reasonable.
• Transaction Malleability Attack: Assess whether transactions can alter internal fields (e.g., ScriptSig) to change the transaction hash without affecting its validity.
• Transaction Replay Attack Audit: Verify the system’s detection of transaction replay attacks.
• Smart Contract Bytecode Verification: Review the security of the virtual machine’s contract verification process, such as checking for integer overflows and infinite loops.
• Smart Contract Bytecode Execution: Assess security concerns during the execution of bytecode by the virtual machine, such as integer overflows and infinite loops.
• Gas Model: Ensure that the transaction processing/contract execution fees for each atomic operation are proportional to resource consumption.
• Log Integrity: Ensure that critical information is recorded in logs.
• Log Security: Check whether log processing introduces security issues, such as integer overflows.
• Logs Containing Sensitive Information: Ensure that logs do not contain keys or other private information.
• Log Storage: Check whether excessive logging leads to resource consumption on nodes.
• Node Code Supply Chain Security: Review known issues with all third-party libraries, components, and public chain framework versions.

As one of the earliest blockchain security companies globally specializing in formal verification, Beosin focuses on a comprehensive “security + compliance” ecosystem. The company has established branches in over 10 countries and regions worldwide. Its services encompass one-stop blockchain compliance products and security services, including code security audits before project launches, real-time security risk monitoring and interception during project operation, stolen asset recovery, anti-money laundering (AML) for virtual assets, and compliance assessments that meet local regulatory requirements. We welcome projects with auditing needs 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.