In-depth Examination of Bitcoin’s Layer 2 Concept: Feasible Implementation with Uncertain Miner Adoption

When it comes to Layer 2, most people think of various Layer 2 projects on Ethereum, such as Arbitrum, Zksync, Optimism, StarkWare, etc. Some people also say that the concept of Layer 2 originated from the Bitcoin Lightning Network and was later applied and popularized on Ethereum by Vitalik. These are all facts, but it depends on the perspective.

The concept of Layer 2 is not unique to Bitcoin or Ethereum, but rather a general direction of scaling solutions in blockchain technology.

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

With the escalating narrative of Bitcoin scalability, a variety of Bitcoin Layer 2 projects have emerged. Layer 2 has gradually evolved from a technology-oriented blockchain scaling approach to 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 the market is often secondary. Also, due to the author’s limitations, some technical perspectives may differ from the outside world. Welcome to join the group for discussion.

The entire article does not constitute any investment advice.

Table of Contents
Toggle
The unavoidable topic: What is the difference between Layer 2 and sidechains?
Technical challenges of BTC Layer 2 – Verification
MAST (Merkle Abstract Syntax Tree)
Schnorr signatures
Conclusion: Feasible development path for BTC Layer 2
About us

As mentioned earlier, the purpose of Layer 2 technology is to scale the mainnet without sacrificing decentralization or security, so it is not a single technical concept in a narrow sense, but includes various different schemes and implementations.

Currently, the most common Layer 2 technologies can be divided into two categories: state channels and rollups.

State channels refer to establishing a channel between two or more parties on the mainnet, and then conducting multiple transactions within the channel. Only when the channel is opened or closed, transactions need to be broadcasted on the mainnet.

BTC’s Lightning Network formally adopts this approach. In simple terms, a Lightning Network channel can be understood as a multi-signature address. After Bob and Alice 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 expensive gas fees. When the two parties decide that they will no longer transact, they can initiate a withdrawal command to the mainnet. The signature of this command can prove the authenticity of a series of off-chain transactions between the two parties to the BTC mainnet.

At this moment, the mainnet’s security consensus will intervene to settle and disburse funds for Bob and Alice. Therefore, transactions that occur on the Lightning Network have the same level of security as the BTC mainnet. Currently, this approach does not have a precedent for implementing smart contracts.

Rollups may be more familiar. Optimistic Rollups and Zero-Knowledge Rollups on Ethereum are Layer 2 scaling solutions that aim to move complex execution and state storage processes to Layer 2 to increase throughput.

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

In this way, the mainnet can “real-time” control the L2 ledger. When the L2 funds cross back to the mainnet, the security consensus of the ETH mainnet will intervene, and the L2 withdrawal contract on the mainnet can verify whether the withdrawal is possible based solely on the data generated by the mainnet consensus, without relying on third-party information sources.

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

Sidechains refer to establishing an independent blockchain network (such as BSC) outside the mainnet, and the mainnet’s consensus cannot verify the legitimacy of cross-chain behavior on the sidechain.

The cross-chain bridge to the sidechain locks and maps assets on the mainnet to the sidechain, and then the assets mapped out on the sidechain can be used for functions such as transaction transfers. When the sidechain returns to the mainnet, the mainnet’s cross-chain bridge contract only verifies the authenticity of the withdrawal message sent by the sidechain itself, and does not verify the sidechain’s ledger.

In other words, if the cross-chain bridge project acts maliciously, signs maliciously, or the sidechain directly creates fake ledgers, the funds on the mainnet side will be at risk.

It can be seen that, according to the traditional definition of Layer 2, observing whether the mainnet can verify a ledger outside the mainnet can determine whether a chain is a Layer 2 key.

With this concept, it is not difficult to explain why Ethereum, which was launched later than Bitcoin, can achieve a comeback and take the lead in making Layer 2 solutions.

To understand the technical challenges of BTC Layer 2, we must first understand the BTC Taproot upgrade that creates possibilities for BTC Layer 2.

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

The core idea of Taproot is to make transactions under various conditions appear as ordinary single-signature transactions, thereby reducing the occupation and leakage of on-chain data, and making complex transactions (multi-signature, timelocks) execute like a single Bitcoin transaction.

Taproot introduces two important technologies that create possibilities for future BTC Layer 2:
1) MAST (Merkle Abstract Syntax Tree)
2) Schnorr signatures

MAST is a mechanism that breaks down complex scripts into multiple sub-scripts and organizes them into a Merkle tree structure. Only when a certain sub-script condition is met, the hash value and content of that sub-script need to be revealed. This saves space, increases flexibility, and enhances privacy.

Schnorr signatures are a type of digital signature algorithm that can aggregate multiple signers into a single signer and generate a single signature. This simplifies multi-signature transactions, reduces costs, improves security, and increases privacy.

The significance of MAST is that, before the Taproot upgrade, in order to implement complex script conditions, we could only use P2SH addresses and had to generate redeem scripts with the same hash value and include them in transactions.

For complex conditions specified in P2SH, the transaction size becomes extremely large. BTC in P2SH addresses must generate redeem scripts with the same hash value and include them in transactions. If the spending conditions specified in the script are too many, the transaction size becomes extremely large.

MAST can solve the above problems and create possibilities for the development of BTC Layer 2.

MAST combines the Merkle tree and abstract syntax tree into a mechanism. It is similar to P2SH, which pays for a script with a specified hash value. The difference is that MAST pays for a script with the hash value of a specified Merkle root.

MAST assembles a large set of conditions into a hash tree, which is the so-called Merkle tree. In this tree, each node is a hash value calculated from its child nodes.

The root of the tree is a hash value representing the set of all conditions. This way, only this root hash needs to be included in the transaction, and not all conditions need to be listed, reducing the size of the transaction.

First, hash calculations are performed on all scripts (conditions); then, the calculated hash values are combined with adjacent hash values for hash calculations, generating a new set of hash values. This process of pairwise hash calculations is repeated until the final hash value is calculated.

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, a unlocking script that matches a path on the Merkle tree needs to be constructed.

The network only needs to verify whether this script corresponds to a condition in the original set of conditions in the Merkle tree, that is, verify whether this condition exists on the Merkle tree.

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

It should be noted that although MAST greatly reduces the space occupied by transaction scripts and provides possibilities for complex on-chain operations, the logic that can be achieved with this syntax tree structure is relatively limited. Therefore, it is inaccurate to claim that “MAST can achieve smart contract-like functions on Bitcoin.”

Currently, the BTC mainnet does not support the implementation of ledger verification similar to Ethereum Layer 2, which means that BTC Layer 2 cannot simply copy the technical architecture of ETH Layer 2. To ensure the security of cross-chain bridges, an alternative approach is needed.

If Schnorr signatures are combined with MAST, it can provide a new approach for the cross-chain bridge from the BTC mainnet to Layer 2. This technology is also the mainstream technical solution for BTC Layer 2 projects on the market.

Schnorr signatures are a digital signature scheme proposed by Claus Schnorr, known for its simplicity and efficiency. Its advantage is that it can aggregate multiple signatures into a single signature, thereby optimizing the verification and authentication process in multi-signature scenarios.

For example, in a multi-signature transaction that requires 12 signatures, each signature may occupy 20 bytes of storage, so a total of 240 bytes are needed to store the 12 signatures.

Schnorr signatures can merge these 12 signatures into a unified Schnorr signature, which only requires approximately 60 bytes of space. This saves a lot of storage space, which can be used to accommodate more transaction script information.

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

As for the general m-n (m < n) multi-signature, for example, a 2-3 multi-signature is equivalent to A, B unlocking or B, C unlocking or A, C unlocking in three situations. This can be seen as a multi-condition script, where each condition is a 2-2 multi-signature, so it can also be defined using aggregated public keys instead of explicit multi-signatures.This is the underlying technology adopted by current projects such as STX and BEVM for cross-chain capabilities: by creating BTC addresses controlled by hundreds of Layer 2 nodes to achieve cross-chain capabilities.Based on the comparison above, it is clear that the BTC Layer 2 solution cannot simply replicate the design of Ethereum Layer 2, because there are inherent differences between the two.To plan the correct path forward, the BTC Layer 2 solution should focus on the core essence of security while considering the unique properties of Bitcoin.The Bitcoin base layer adopts a simple UTXO model and has 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, the Bitcoin Layer 2 solution cannot regularly submit responsibility records on-chain for verification. Storing data on the Bitcoin blockchain can only serve as availability checkpoints and cannot perform actual verification.This is currently a concern in the market. For BTC believers, without verification involving BTC consensus, the narrative of BTC Layer 2 is lost. For ETH users, a technical solution with weaker security than ETH Rollup may not be very attractive.The problem of decentralized cross-chain capabilities is crucial.This is the defining characteristic of Layer 2, and achieving a cross-chain bridge on the BTC mainnet that is as secure as the mainnet consensus is challenging. Currently, traditional Bitcoin cross-chain technologies, such as hash/timelocks, peg-in/peg-out, atomic swaps, and multisig, cannot provide sufficient trust guarantees.The combination of MAST contracts introduced in the Bitcoin Taproot upgrade in 2021 and Schnorr signatures brings hope for decentralized Bitcoin cross-chain and is a major breakthrough for realizing BTC Layer 2.Compared to on-chain verification in Rollups, the current development direction for BTC Layer 2 teams under development is to focus on maximizing the security of cross-chain bridge signatures.As for achieving a perfect Layer 2, only Bitcoin can upgrade the BIP layer, with miners updating the underlying code to support OP/ZKP verification and execution by Bitcoin miners, in order to achieve Layer 2 solutions similar to ETH Rollup. It should be noted that this requires a very long time and may never be adopted by miners.Biteye is the leading Web3 research community in Asia, generating forward-thinking investment research content and tools through community and AI-driven approaches to help community members explore the Web3 rabbit hole.WeChat group: Add assistant @Biteye01 to join the groupTwitter: @BiteyeCNDiscord: Discord.gg/ME582FXR4FL2MASTBitcoin