Bitcoin Spot ETFs dominated discussions the last few weeks. With all that settled, the community’s attention got back to building on Bitcoin. This means answering the eternal question: “how to improve Bitcoin programmability?”

Bitcoin L2s are currently the most promising answer to this question. This article compares Bitcoin L2s to earlier efforts and discusses some of the most promising Bitcoin L2 projects. The article then touches on interesting startup opportunities that are relevant to Bitcoin L2s.

Startup founders who are interested in building Bitcoin-focused projects are encouraged to reach out to me and apply to Alliance.

Defending Permissionless Bitcoin

As many investors can now get Bitcoin exposure via a regulated product, they can use BTC in a plethora of TradFi products such as leveraged trading, collateralized lending, etc. However, these products don’t use native BTC. Instead, they use a TradeFi representation of BTC that is controlled by the issuers while the native BTC is locked by custodians. Over time, the TradeFi BTC can become the main way to hold and use BTC converting it from a decentralized permissionless asset to just another asset that is controlled by Wall Street. Bitcoin-native permissionless products are the only way forward to resist a capture of Bitcoin by the old financial system.

Building Bitcoin Native Products

L1 applications

There have been many attempts to implement additional functionalities on the L1. These efforts have focused on using the ability of Bitcoin transactions to carry arbitrary data. This arbitrary data can be used to implement additional functionalities, e.g., issue and transfer assets and NFTs. However, these functionalities are not built as part of the Bitcoin protocol but require additional software to interpret these data fields and act on them.

These efforts include Colored Coins, Omni Protocol, Counterparty, and recently Ordinals. Omni was initially used to issue and transfer Tether (USDT) on the Bitcoin L1 before it expanded to other chains. Counterparty is the underlying technology for Bitcoin Stamps and SRC-20 tokens. Ordinals is currently the de-facto standard for issuing NFTs and BRC-20 tokens on Bitcoin using inscriptions.

Ordinals have been a huge success leading to more than $200M of generated fees since inception. Despite that success, ordinals are limited to asset issuance and transfer. Ordinals cannot be used to implement applications on the L1. More complex applications, e.g., AMMs, and Lending, are almost impossible to build because of the limitations of Bitcoin Script, the native Bitcoin programming language.

BitVM

One unique effort to expand the Bitcoin L1 functionality is BitVM. The concept builds on the Taproot upgrade to Bitcoin. The concept of BitVM is to expand the functionality of Bitcoin via off-chain execution of programs with the assurance that the execution can be challenged on-chain via fraud proofs. Although it may seem possible that BitVM can be used to implement arbitrary logic off-chain, in practice the cost of executing the fraud proof on the L1 grows quickly with the size of the off-chain program. This issue limits the applicability of BitVM to specific problems such as trust-minimized BTC bridge. Many of the upcoming Bitcoin L2s leverage BitVM for bridge implementation.

Simplified Diagram of The Operation of BitVM

Sidechains

The other approach to address Bitcoin’s limited programmability was to utilize sidechains. Sidechains are independent blockchains that are fully programmable, e.g., EVM compatible, that try to be aligned with the Bitcoin community and provide services to this community. Rootstock, Blocksteam’s Liquid, and Stacks V1 are examples of these sidechains.

Bitcoin Sidechain have existed for years and have generally achieved limited success in attracting Bitcoin users. For instance, Liquid has less than 4500 BTC bridged to the sidechain. However, some of the DeFi applications that was built on top of these chains have achieved some success. Examples include Sovryn on Rootstock and Alex on Stacks.

Bitcoin L2s

Bitcoin L2s are becoming the focus point for building BTC-based permissionless applications. They can offer the same advantages of a sidechain but with security guarantees that are derived from the Bitcoin baselayer. There is continuous debate about what truly represents a Bitcoin L2. In this article, we avoid this debate but discuss the major considerations on how to make an L2 sufficiently coupled to the L1 and discuss some of the promising L2 projects.

The Bitcoin L2 Requirements

Security from the L1

The most important requirement for a Bitcoin L2 is to derive its security from the L1’s security. Bitcoin is the most secure chain and users expect that security to extend to the L2. For example, this is already the case with Lightning Network.

This is the reason sidechains are classified as such, they have their own security. For example, Stacks V1 depended on the STX token for its security.

The security requirement is hard to achieve in practice. For the L1 to secure an L2, the L1 needs to be able to perform certain computations to validate the behavior of the L2. For example, Ethereum rollups derive their security from the L1 because the Ethereum L1 can either verify a zero-knowledge proof (zk rollup) or verify a fraud proof (optimistic rollup). The Bitcoin base layer currently lacks the computing ability to do either. There are proposals to add new opcodes to Bitcoin that would allow the base layer to validate ZKPs submitted by rollups. Further, proposals such as BitVM tries to implement ways to implement fraud proofs without changes to the L1. The challenge with BitVM is that the cost of fraud proofs can be extremely high (hundreds of L1 transactions), limiting their practical applications.

Another requirement of achieving L1-level security for the L2 is for the L1 to have an immutable record of the L2 transactions. This is known as the Data Availability (DA) requirement. It allows an observer who only monitors the L1 chain to validate the L2 state. With inscriptions, it’s possible to embed a record of the L2 TXs to the bitcoin L1. However, this creates another issue which is scalability. With a block time limit of 4MB every ~ 10 mins, Bitcoin L1 has limited data throughput of ~ 1.1 KB/s. Even if the L2 transactions are highly compressed to about 10 bytes/tx, the L1 can only support a combined L2 throughput of ~ 100 tx/sec assuming all the L1 transactions are for storing L2 data.

Trust-minimized Bridging from L1

In Ethereum L2s, the bridging to and from the L2 is controlled by the L1. Bridging to the L2, aka Peg-in, actually means locking the asset on the L1 and minting a replica of this asset on the L2. In Ethereum, this is achieved via the L2 native-bridge smart contract. This smart contract stores all the assets that are bridged to the L2. The Smart contract security is derived from the L1 validators. This makes the bridging to L2s secure and trust-minimized.

In Bitcoin, it’s not possible to have a bridge that is secured by the whole set of the L1 miners. Instead, the best option is to have a multi-sig wallet that stores the L2 assets. Hence, the security of the L2 bridge depends on the multi-sig security, i.e., the number of signers, their identity, and how the peg-in and peg-out operations are secured. One approach to improve the L2 bridging security is to use multiple multi-sigs instead of a single multisig that holds all the L2 bridged assets. Examples of this include TBTC, where the multisig signers have to provide collateral that can be slashed if they cheat. Similarly, the proposed BitVM bridge requires the multisig signers to provide a security bond. However, in this multisig any of the signers can initiate a peg-out transaction. The peg-out interaction is protected by BitVM fraud proofs. If the signer commits a malicious behavior, other signers (verifiers) can submit a fraud proof on the L1 that results in the slashing of the malicious signer.

Bitcoin L2s Landscape

Summary comparison of Bitcoin L2 projects

Chainway

Chainway is building a zk rollup on top of Bitcoin. The Chainway rollup uses the Bitcoin L1 as a DA layer to store the rollup’s ZKPs and state differences. Further, the rollup utilizes proof recursion such that each new proof aggregates the proof that was published on the previous L1 block. The proof also aggregates “Forced Transactions” which are L2 related transactions that are broadcast on the L1 to force their inclusion on the L2 . This design have a few advantages

1. Forced Transactions guarantee that the rollups sequencer cannot censor L2 transactions and gives the user the power to include these TXs by broadcasting them on the L1.
2. Using proof recursion means that the prover of each block has to verify the previous proof. This creates a chain of trust and guarantees that invalid proofs cannot be included on the L1.

The Chainway team also discusses the use of BitVM to guarantee that the proof verification and the peg-in/out transactions are performed correctly. Using BitVM to verify the bridging transaction reduces the trust assumptions for the bridge multisig to honest minority.

Botanix

Botanix is building an EVM L2 for Bitcoin. To improve the alignment with Bitcoin, the Botanix L2 uses Bitcoin as the PoS asset to achieve consensus. The L2 validators earn fees from the transactions executed on the L2. Further, the L2 stores the Merkle Tree Root of all the L2 transactions on the L1 using inscriptions. This provides partial security for the L2 transactions because the L2 transaction logs cannot be altered but doesn’t guarantee the DA of these transactions.

Botanix handles bridging from the L1 via a network of decentralized multisig system called Spiderchain. The signers of the multisig are selected at random from a set of orchestrators. The Orchestrators lock the user funds on the L1 and sign an attestation to mint the equivalent numbers of BTC on the L2. Orchestors post a security bond to be eligible for this role. The security bond is slashable in case of malicious behavior.

Botanix has already launched a public testnet and the mainnet launch is planned for the first half of 2024.

Bison Network

Bison adopts the sovereign rollup style for its Bitcoin L2. Bison implements a zk rollup using STARKs and uses Ordinals to store the L2 TX data and the generated ZKPs to the L1. As Bitcoin cannot verify these proofs on the L1, the verification is delegated to users who verify the ZKPs in their devices.

For BTC bridging to/from the L2, Bison uses Discreet Log contracts (DLC). DLCs are secured by the L1 but depend on an external oracle. This oracle reads the L2 state and passes the information to the Bitcoin L1. If this Oracle is centralized, the Oracle can maliciously spend the locked assets on the L1. Hence, it’s important for Bison to eventually move to a decentralized DLC oracle.

Bison plans to support a rust-based zkVM. Currenty, the Bison OS implements a number of contacts, e.g., Token contract, that can be proven using the Bison prover.

Stacks V2

Stacks is one of the earliest projects to focus on extending Bitcoin programmability. Stacks is undergoing a remodel to better align with the Bitcoin L1. This discussion focuses on the upcoming Stacks V2 which is expected to be launched on Mainnet in April 2024. Stacks V2 implements two new concepts that are improving the alignment with the L1. The first, Nakamoto Release, updates Stacks consensus to follow Bitcoin blocks and finality. The second is improved BTC bridging called sBTC.

In Nakamoto’s release, blocks in Stacks are mined by Miners who commit a bond in BTC on the L1. When Stacks miners create a block these blocks are anchored in the Bitcoin L1 and receive confirmations from the L1 PoW miners. When a block receives 150 L1 confirmations, this block is considered final and cannot be forked without forking the Bitcoin L1. At this point, the Stacks miner who mined that block receives a reward in STX and their BTC bond is distributed to the network Stackers. This way any Stacks blocks that are older than 150 blocks (~ 1 day old) depend on the Bitcoin L1 security. For newer blocks (< 150 confirmations) the Stacks chain can fork only if 70% of the Stackers are supportive of the fork.

The other Stacks upgrade is sBTC, which offers a more secure way to bridge BTC to Stacks. To bridge assets to Stacks, users deposit their BTC to an L1 address controlled by the L2 Stackers. When the deposit transactions are confirmed, sBTC is minted on the L2. To ensure the security of the bridged BTC, Stackers have to lock a bond in STX that exceeds the value of the bridged BTC. Stackers are also responsible to execute peg-out requests from the L2. Peg out requests are broadcast as L1 transaction. After confirmation, stackers burn sBTC on the L2 and collaborate to sign an L1 tx that releases the user’s BTC on the L1. For this work, Stackers get rewarded the miner’s bond discussed before. This mechanism is called Proof of Transfer (PoX).

Stacks aligns with Bitcoin by requiring that many of the important L2 transactions, e.g., miner PoX bonds, peg-out txs, to be performed as L1. This requirement indeed improves alignment and security of bridged BTC but can lead to degraded UX because of the volatility and high fees of the L1. Overall, the upgraded Stacks design have addressed many of the issues in V1 but a few weakness remain. This includes the use of STX as the native asset in the L2 and the L2 DA, i.e., only a hash of transactions and smart contract code is available on the L1

BOB

Bulid-on-Bitcoin (BOB) is an Ethereum L2 that aims to be Bitcoin-aligned. BOB operates as an Optimistic rollup on Ethereum and uses an EVM execution environment to implement smart contracts.

BOB initially accepts different kinds of bridged BTC (WBTC, TBTC V2) but plans to adopt a more secure two-way bridge using BitVM in the future.

To differentiate from other Ethereum L2s that also support WBTC and TBTC, BOB is building features that allow users to interact directly with the Bitcoin L1 from BOB. The BOB SDK provides a library of smart contracts that allow users to sign transactions on the bitcoin L1. The execution of these transactions on the L1 is monitored by a bitcoin light client. The light client adds hashes of Bitcoin blocks to BOB to allow for simple verification (SPV) that the submitted transactions were executed on the L1 and included in a block. Another feature is the separate zkVM that allows developers to write rust applications for Bitcoin L1. The proof of correct execution can be verified on the BOB rollup.

The current design of BOB is better described as a sidechain than a Bitcoin L2. This is mainly because BOB’s security depends on the Ethereum L1 and not on the security of Bitcoin.

SatoshiVM

SatoshiVM is another project that plans to launch a zkEVM Bitcoin L2. The project appeared suddenly with a Testnet launch early January. The technical details of the project are sparse and it’s not clear who are the developers behind the project. The few technical documents on SatoshiVM state using the Bitcoin L1 for DA, censorship resistance by supporting the ability to broadcast transactions on the L1, and verifying the L2 ZKPs using BitVM-style fraud proofs.

Given its anonymous nature, there is a lot of controversy around the project. Some Investigations shows that the project has ties to Bool Network, which is an older Bitcoin L2 project.

Startup Opportunities in the Bitcoin L2 paradigm

The space for Bitcoin L2s comes with several startup opportunities. Setting aside the obvious opportunity of building the best L2 for Bitcoin, there are several other startup opportunities.

Bitcoin DA Layer

Many of the upcoming L2s aim to increase their alignment with the L1. One way to do so is to use the L1 for DA. However, given the hard constraints on the Bitcoin blocksize and the long delay between the L1 blocks, the L1 won’t be able to store all L2 transactions. This creates an opportunity for bitcoin specific DA layer. Existing networks, e.g., Celestia , can expand to fill this gap. However, creating an off-chain DA solution that depends on Bitcoin security or BTC collateral improves the alignment with the Bitcoin ecosystem.

MEV Extraction

In addition to using Bitcoin L1 for DA, some L2s may choose to delegate the L2 transaction ordering to BTC-bonded sequencers or even to the L1 miners. This means that any MEV extraction will be delegated to these entities. Given that bitcoin miners are not equipped for this task, there is an opportunity for a flashbot-like company that focuses on MEV extraction, and private order flow, for Bitcoin L2s. MEV extraction is often closely related to the VM used and given that there is no agreed-upon VM for Bitcoin L2, there could be multiple players in that field. Each focuses on a different Bitcoin L2.

Bitcoin Yield Tools

Bitcoin L2s will need to use BTC collateral for validator selection, DA security and other functionalities. This creates opportunities for yield for holding and using Bitcoin. Currently, there are a few tools that offer such opportunities. For instance, Babylon allows staking BTC to secure other chains. As the Bitcoin L2 ecosystem flourishes, there is a strong opportunity for platform that aggregates BTC-native yield opportunities.

In conclusion, Bitcoin is the most recognized, most-secure, and most liquid cryptocurrency. As Bitcoin enters the phase of institutional adoption with the launch of the Bitcoin Spot ETF, it’s more important than ever to keep the fundamental nature of BTC as a permissionless and censorship resistant asset. This can only happen via expanding the permissionless application space around Bitcoin. Bitcoin L2s and the startup ecosystem supporting these L2 are fundamental ingredients for this goal. At Alliance, we are looking to support founders who are building these startups.

声明：

1. 本文转载自[medium]，著作权归属原作者[Mohamed Fouda]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。

2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。

3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io)的情况下不得复制、传播或抄袭经翻译文章。