Biteye: An In-Depth Exploration of Bitcoin Layer Two Concepts

Author: Biteye Core Contributor Fishery Isla

Editor: Biteye Core Contributor Crush

Source: Biteye

When talking about Layer 2, most people think of various second-layer projects on Ethereum, such as Arbitrum, Zksync, Optimism, StarkWare, etc. Some may also say that the concept of Layer 2 originally came from the Bitcoin Lightning Network, which was later applied and popularized by Vitalik on Ethereum. These are all facts, just viewed from different perspectives.

The concept of Layer 2 is not unique to Bitcoin or Ethereum; rather, it is a broad direction of scaling technology within blockchain technology.

Layer 2 refers to a set of off-chain solutions built on top of the mainnet, aimed at increasing transaction throughput without sacrificing decentralization or security (take note!!).

As the narrative of BTC scaling continues to evolve, a variety of BTC Layer 2 projects have emerged. Layer 2 has gradually transformed from a technology-oriented blockchain scaling approach into a vague marketing label.

This article will provide a simple technical overview of projects labeled as BTC Layer 2. It is important to note that in this market driven by hype, the impact of technology on market trends is often secondary. Additionally, due to the author's own limitations, some technical viewpoints may differ from external opinions. Everyone is welcome to join the discussion group.

This article does not constitute any investment advice.

An Unavoidable Old Topic: What is the Difference Between Layer 2 and Sidechains?

The previous text mentioned that the purpose of Layer 2 technology is to scale the mainnet without sacrificing decentralization or security. Therefore, in a narrow sense, it is not a single technical concept, but encompasses various different solutions and implementations.

Currently, the most common Layer 2 technologies fall into two categories: State Channels and Rollups.

State Channels refer to establishing a channel between two or more parties on the mainnet, allowing multiple transactions to occur within the channel, with transactions only needing to be broadcast on the mainnet when the channel is opened or closed.

The Lightning Network officially adopts this solution. Simply put, the channels in the Lightning Network can be understood as a multi-signature address. After Bob and Alice each deposit BTC into this channel (address) on the mainnet, they can conduct daily transactions through the Lightning Network.

These daily transactions do not go on the mainnet, thus saving on expensive gas fees. When one day both parties believe they will no longer transact, they can initiate a withdrawal command to the mainnet. This command's signature can prove the authenticity of the series of transaction ledgers that occurred off the mainnet.

At this moment, the security consensus of the mainnet will intervene to settle and release funds for Bob and Alice, thus transactions occurring on the Lightning Network also possess the security level of the BTC mainnet. Currently, there are no precedents for implementing smart contracts with this solution.

Rollups may be more familiar to everyone. Optimistic Rollups and Zero-Knowledge Rollups on Ethereum are both Layer 2 scaling solutions for Ethereum, aiming to move complex execution and state storage processes to Layer 2 to improve throughput.

In simple terms, the mainnet will verify the proofs periodically submitted from Layer 2 to the mainnet to ensure the authenticity of the Layer 2 ledger (this verification process is particularly important).

Thus, the mainnet can "real-time" monitor the Layer 2 ledger. When Layer 2 funds cross back to the mainnet, the security consensus of the ETH mainnet will intervene, and the Layer 2 release contract on the mainnet can verify whether funds can be released solely based on data generated by the mainnet consensus without relying on third-party information sources.

By this point, many readers may realize that the traditional essence of Layer 2 is a cross-chain bridge with the same security as the mainnet. With this understanding, we can better distinguish sidechains.

A sidechain refers to an independent blockchain network established outside the mainnet (such as BSC), where the consensus of the mainnet cannot verify the legitimacy of cross-chain activities from the sidechain.

The cross-chain bridge to the sidechain locks assets on the mainnet and maps them to the sidechain. Subsequently, the assets mapped on the sidechain can perform functions such as transaction transfers. However, when returning from the sidechain to the mainnet, the cross-chain bridge contract on the mainnet will only verify the authenticity of the release message sent from the sidechain and will not verify the ledger of the sidechain.

In other words, if the cross-chain bridge project party acts maliciously, signs fraudulently, or the sidechain directly creates false ledgers, the funds on the mainnet will suffer losses.

It is not difficult to see that according to the traditional definition of L2, observing whether the mainnet can verify ledgers outside the mainnet is key to determining whether a chain is Layer 2.

With this concept, it is easy to explain why ETH launched later than BTC but was able to surpass it by asynchronously implementing Layer 2.

Technical Challenges of BTC Layer 2 ------ Verification

To understand the technical challenges of BTC Layer 2, one must first understand the BTC Taproot upgrade that made BTC Layer 2 possible.

Taproot was first proposed by Bitcoin Core contributor Gregory Maxwell in 2018. Taproot is an improvement to the Bitcoin protocol, aimed at enhancing the privacy and efficiency of Bitcoin transactions.

The core idea of Taproot is to make transactions under various conditions appear like ordinary single-signature transactions, thereby reducing on-chain data usage and leakage, allowing complex transactions (multi-signature, time-lock) to be executed like a single Bitcoin transaction.

The Taproot upgrade introduces two important technologies to create possibilities for future BTC Layer 2:

1) MAST (Merklized Abstract Syntax Tree);

2) Schnorr Signatures;

MAST is a mechanism that decomposes complex scripts into multiple sub-scripts and organizes them into a Merkle tree structure, where only the hash and content of a sub-script need to be revealed when the conditions of that sub-script are met. This saves space, increases flexibility, and enhances privacy.

Schnorr signatures are a type of digital signature algorithm that can combine multiple signers into a single signature, generating a unified signature. This simplifies multi-signature transactions, reduces costs, enhances security, and increases privacy.

MAST (Merkle Abstract Syntax Tree)

The significance of MAST is that before the Taproot upgrade, to implement complex script conditions, one had to use P2SH addresses and generate redeem scripts with the same hash value to include in the transaction.

For complex conditions of P2SH, the transaction size would become excessively large. For BTC in a P2SH address, one must generate redeem scripts with the same hash value and include them in the transaction. If there are too many spending conditions specified in the script, the transaction size will become excessively large.

MAST can effectively solve the above problems, and it is precisely for this reason that the development of BTC Layer 2 became possible.

MAST is a mechanism that combines Merkle trees and abstract syntax trees. It is similar to P2SH, which pays for scripts with specified hash values, but MAST pays for hashes with specified Merkle roots.

MAST assembles a large set of conditions into a hash tree, known as a Merkle tree. In this tree, each node is a hash value computed from its child nodes.

The root of the tree is a hash value representing the entire set of conditions. Thus, in a transaction, only this root hash needs to be included, rather than listing all conditions, which helps reduce the transaction size.

First, hash each script (condition) separately; then combine the computed hash values with adjacent hash values for further hashing, generating a new set of hash values. This process of pairwise hashing is repeated until the final hash value is computed.

This hash value is the Merkle root.

MAST can associate Bitcoin transactions with a Merkle tree, where each leaf node on the tree represents a condition for unlocking Bitcoin.

To spend these locked Bitcoins, one must construct an unlocking script that meets the conditions corresponding to a path in the Merkle tree.

The network only needs to verify whether the condition corresponding to this script belongs to the original set of conditions in the Merkle tree, i.e., to verify whether this condition exists in the Merkle tree.

Once the network confirms that this script (and the corresponding condition) belongs to the Merkle root, it knows that this script meets the requirements for unlocking Bitcoin, and then continues to verify this unlocking script. This way, we do not need to include the complete script in the transaction, thus reducing the size of Bitcoin transactions.\

It should be noted that while MAST greatly reduces the space occupied by transaction scripts and provides possibilities for complex on-chain operations, the logic that can be achieved by this tree structure is relatively limited. Therefore, some claims that "MAST can achieve smart contract-like functionality on Bitcoin" are inaccurate.

Currently, the BTC mainnet does not support implementing ledger verification functions like Ethereum Layer 2, which means that BTC Layer 2 cannot fully replicate the technical architecture of ETH Layer 2. To ensure the security of cross-chain bridges, new paths need to be explored.

If the combination of Schnorr signatures and MAST can provide a new idea for cross-chain bridges from the BTC mainnet to Layer 2, this technology is also the mainstream technical solution for current BTC Layer 2 projects.

Schnorr Signatures

Schnorr signatures are a digital signature scheme proposed by Claus Schnorr, known for their simplicity and efficiency. Their advantage lies in the ability to aggregate multiple signatures into a single signature, optimizing the verification and authentication processes in multi-signature scenarios.

For example, in a multi-signature transaction requiring 12 signatures, each signature may occupy 20 bytes of storage space, requiring a total of 240 bytes to store these 12 signatures.

However, Schnorr signatures can merge these 12 signatures into a unified Schnorr signature, which only requires about 60 bytes of space. This saves a significant amount of storage space, allowing for more transaction script information to be accommodated.

Schnorr signatures can provide privacy protection for all n-n multi-signature contracts. The most typical application is in Lightning Network payment channels, as it is essentially a 2-2 multi-signature contract.

For general m-n (m<n) multi-signature contracts, it can be expanded on the n-n scenario, where we can use MAST to fold all possible unlocking conditions into a branching structure.

Taking a 2-3 multi-signature as an example, it is equivalent to A, B unlocking or B, C unlocking or A, C unlocking in three scenarios. This can be viewed as a multi-condition script, where each condition is a 2-2 multi-signature, so it can also be defined using an aggregated public key instead of explicit multi-signatures.

This is the basis of the cross-chain technology currently adopted by projects like STX and BEVM: achieving cross-chain by creating BTC addresses controlled by hundreds of Layer 2 nodes.

Conclusion: Viable Development Path for BTC Layer 2

Based on the previous comparisons, it is clear that BTC Layer 2 solutions cannot simply replicate the design of Ethereum's second layer due to inherent differences between the two.

To plan the correct path forward, BTC Layer 2 solutions should focus on the core essence of security while considering the unique attributes of Bitcoin.

The foundational layer of Bitcoin adopts a simple UTXO model with limited block space.

As mentioned earlier, even with the existence of MAST, the BTC mainnet still cannot implement overly complex OP/ZKP verification logic.

This means that, unlike Ethereum Rollups, Bitcoin's second-layer solutions cannot periodically submit on-chain responsibility records for verification. Storing data on the Bitcoin blockchain can only serve as availability checkpoints, not for actual verification.

This is currently a significant concern for the market. For BTC believers, without verification involving BTC consensus, the narrative of BTC Layer 2 is lost; for long-time ETH users, solutions with weaker security than ETH Rollups will not be very attractive.

Decentralized Cross-Chain Capability Issues.

This is a crucial definition of Layer 2. Achieving a cross-chain bridge with security equivalent to the mainnet consensus on the BTC mainnet is highly challenging. Currently, traditional Bitcoin cross-chain technologies, such as hash/time locks, hooks, swaps, and multi-signatures, do not provide sufficient trust guarantees.

The combination of MAST contracts and Schnorr signatures introduced in Bitcoin's 2021 Taproot upgrade brings hope for decentralized Bitcoin cross-chain solutions and is a major breakthrough for achieving BTC Layer 2.

Compared to the on-chain verification of Rollups, the current focus for BTC Layer 2 development teams should be to maximize the security of cross-chain bridge signatures.

As for achieving a perfect Layer 2, only if Bitcoin upgrades the BIP layer, and miners update the underlying code to support OP/ZKP verification and the computational execution of Bitcoin miners, can a second-layer solution similar to ETH Rollup be realized. It should be noted that this will require a very long time and may never be adopted by miners.