original:Mohamed Fouda，Alliance DAO

Compiled by: Deep Wave TechFlow

Bitcoin spot ETFs have become a hot topic in the past few weeks. As these discussions subsided, the communitys attention returned to building Bitcoin. This means answering the question: “How to improve Bitcoin’s programmability?”

Currently, Bitcoin’s L2 is the most promising answer to this question. This article compares Bitcoin L2 to earlier work and discusses some of the most promising Bitcoin L2 projects. The article then discusses interesting entrepreneurial opportunities related to Bitcoin L2.

Defending permissionless Bitcoin

Since many investors can now invest in Bitcoin through regulated products, they can trade BTC in traditional financial (TradFi) products, such as leveraged trading, mortgages, etc. However, these products do not use native BTC. Instead, they use a TradeFi version of BTC that is controlled by the issuer, while native BTC is locked by a custodian. Over time, the TradeFi version of BTC could become the primary way to hold and spend BTC, transforming it from a decentralized, permissionless asset into another one controlled by Wall Street. Bitcoin’s native permissionless nature is the only way to resist the control of Bitcoin by the old financial system.

Building Bitcoin-native products

L1 Application

Developers have tried many times to implement other functions on L1. These efforts focus on exploiting the ability of Bitcoin transactions to carry arbitrary data. This arbitrary data can be used to implement additional functionality, such as issuing and transferring assets and NFTs. However, these features are not built as part of the Bitcoin protocol and require additional software to interpret these data fields and operate on them.

These efforts include Colored Coins, Omni Protocol, Counterparty and most recently Ordinals. Omni was initially used to issue and transfer USDT on Bitcoin L1, and later expanded to other chains. Counterparty is the underlying technology for Bitcoin Stamps and SRC-20 tokens. Ordinals are currently the standard for issuing NFT and BRC-20 tokens on Bitcoin using inscriptions.

Ordinals has been a huge success since its launch, generating over $200 million in fees. Despite its success, Ordinals is limited to asset issuance and transfer. Ordinals cannot be used to implement applications on L1. Due to the limitations of Bitcoins native programming language, Bitcoin Script, more complex applications such as AMMs and lending are nearly impossible to build.

BitVM

One attempt to extend the functionality of Bitcoin L1 is BitVM. This concept is built on top of Bitcoin’s Taproot upgrade. The concept of BitVM is to extend the functionality of Bitcoin through off-chain execution of programs and guarantee that the execution of the program can be challenged on-chain through fraud proofs. Although BitVM seems like it can be used to implement arbitrary logic off-chain, in reality the cost of performing fraud proofs on L1 grows rapidly with the size of the off-chain program. This issue limits the applicability of BitVM to certain problems, such as trust-minimized BTC bridging. Many upcoming Bitcoin L2s utilize BitVM for bridging.

Simplified diagram of BitVM operation

side chain

Another way to solve Bitcoin’s limited programmability is to use sidechains. Sidechains are independent, fully programmable blockchains that are EVM-compatible and they attempt to align with and serve the Bitcoin community. Rootstock, Blocksteam’s Liquid, and Stacks V1 are examples of these sidechains.

Bitcoin sidechains have been around for years but have generally had limited success in attracting Bitcoin users. For example, there are less than 4,500 BTC bridged on the Liquid sidechain. However, some DeFi applications built on these chains have achieved good results, such as Sovryn on Rootstock and Alex on Stacks.

Bitcoin L2

Bitcoin L2 is becoming the focus for building permissionless applications based on BTC. They can offer the same benefits as sidechains, but with the security guarantees derived from Bitcoin’s base layer. There has been endless debate about what Bitcoin L2 really is. In this article, we will avoid this debate and instead discuss the main considerations of how to fully couple L2 with L1 and discuss some promising L2 projects.

Bitcoin L2 Requirements

L1 security

The most important requirement for Bitcoin L2 is to derive its security from the security of L1. Bitcoin is the most secure chain and users want this security to extend to L2. For example, the Lightning Network already achieves this.

This is why sidechains are classified as sidechains, they have their own security. For example, Stacks V1 relies on STX tokens to ensure its security.

Implementing security requirements in practice is extremely challenging. In order to ensure that L1 can safely support L2, L1 needs to be able to perform certain calculations to verify the behavior of L2. For example, Ethereums rollup obtains security from L1 because Ethereum L1 can verify zero-knowledge proofs (zk rollup) or verify fraud proofs (optimistic rollup). Bitcoin’s current base layer lacks the computing power to perform these operations. There are proposals to add new opcodes to Bitcoin so that the base layer can verify ZKPs submitted by rollups. Additionally, proposals like BitVM attempt to implement fraud proof methods without changing L1. The challenge faced by BitVM is that the cost of fraud proof can be extremely high (hundreds of L1 transactions), limiting its practical application.

In order for L2 to achieve L1 level security, L1 needs to have immutable records of L2 transactions. This is called a data availability (DA) requirement. It allows an observer monitoring only the L1 chain to verify the L2 state. Through inscriptions, L2 transaction records can be embedded into Bitcoin L1. However, this brings up another issue, namely scalability. Since Bitcoin L1s block time is limited to 4 MB every 10 minutes, its data throughput is limited to approximately 1.1 KB/s. Even if L2 transactions are highly compressed to about 10 bytes/transaction, L1 can only support L2 throughput of about 100 transactions per second, assuming all L1 transactions are used to store L2 data.

L1 to L2 trust minimization bridge

In Ethereum L2, the bridge to L2 is controlled by L1. Bridging to L2, or Peg-in, essentially means locking assets on L1 and minting copies of those assets on L2. In Ethereum, this is achieved through L2 native bridge smart contracts. This smart contract stores all assets bridged to L2. The security of smart contracts comes from L1 validators. This makes bridging to L2 secure and minimizes trust.

In Bitcoin, it is not possible to achieve a bridge secured by the entire set of L1 miners. Instead, your best option is to use a multi-signature wallet to store L2 assets. Therefore, the security of L2 bridging depends on multi-signature security, that is, the number of signers, their identities, and how Peg-in and Peg-out operations are protected. One way to improve L2 bridge security is to use multiple multi-signature wallets instead of a single multi-signature wallet to hold all L2 bridge assets. Examples of this include TBTC, where multi-signers are required to provide collateral that can be slashed. Similarly, the proposed BitVM bridge requires multisig signers to provide security deposits. However, in this multi-signature, any signer can initiate a Peg-out transaction. Peg-out interactions are protected by BitVM fraud proofs. If a signer behaves maliciously, other signers (verifiers) can submit fraud proofs at L1, causing the malicious signer to be eliminated.

Bitcoin L2 Current Status

Summary and comparison of Bitcoin L2 projects

Chainway

Chainway is building a zk rollup on top of Bitcoin. Chainway rollup uses Bitcoin L1 as the DA layer to store the ZKP and state differences of the rollup. Additionally, rollup exploits proof recursion so that each new proof aggregates proofs published on previous L1 blocks. The proof also aggregates forced transactions, which are transactions related to L2 that are broadcast on L1 to force their inclusion in L2. This design has several advantages:

• Forcing transactions ensures that rollups sequencer cannot censor L2 transactions and gives users the ability to include these transactions by broadcasting them on L1

• Using proof recursion means that the prover of each block must verify the previous proof. This creates a chain of trust and ensures that invalid proofs cannot be included in L1.

The Chainway team also discussed using BitVM to ensure that proof verification and peg-in/out transactions are executed correctly. Using BitVM to verify bridged transactions reduces the trust assumption of bridged multisigs to an honest few.

Botanix

Botanix is ​​building an EVM L2 for Bitcoin. In order to improve consistency with Bitcoin, Botanix L2 uses Bitcoin as a PoS asset to achieve consensus. L2 validators earn fees from transactions executed on L2. Additionally, L2 uses inscriptions to store the Merkle tree roots of all L2 transactions on L1. This provides partial security for L2 transactions, as the L2 transaction log cannot be altered, but does not guarantee DA for these transactions.

Botanix handles the bridging from L1 to L2 through a network of decentralized multi-signature systems called Spiderchain. Signers of a multi-signature are randomly selected from a set of coordinators. The coordinator locks user funds on L1 and signs a statement to mint an equivalent amount of BTC on L2. The coordinator posts a security bond to obtain this role. In the event of malicious behavior, the security deposit will be reduced.

Botanix has launched a public testnet and the mainnet is planned to be launched in the first half of 2024.

Bison Network

Bison uses a sovereign rollup style to implement its Bitcoin L2. Bison implements zk rollup using STARKs and uses Ordinals as a mechanism to store the generated ZKP and transaction data into L1. Since Bitcoin cannot verify these proofs on L1, verification is delegated to users, who verify ZKP on their own devices. In this sense, Bison is more like an Optimistic Rollup, but without the fraud proof.

For Bitcoin’s L2 bridging operations, Bison uses Discrete Logarithmic Contracts (DLC). DLC is secured by L1 but relies on external oracles. This oracle reads the state of the L2 network and passes the information to Bitcoins L1 network. If the oracle is centralized, the oracle could maliciously use assets locked on the L1 network. Therefore, it is very important for Bison to finally move to a decentralized DLC oracle.

Currently, Bison does not support specific virtual machines (VMs). Bison operating system implements some contracts, such as token contracts, which can be proven by Bison provers.

Stacks V2

Stacks is one of the first projects focused on extending Bitcoin’s programmability. Stacks is being revamped to better align with Bitcoin L1. The focus of this article’s discussion is the upcoming Stacks V2, which is expected to be launched on the mainnet in April 2024. Stacks V2 implements two new concepts that are improving consistency with L1. The first version is the Nakamoto version, which updates Stacks consensus to adhere to Bitcoin blocks and finality. The second is an improved Bitcoin bridging technology called sBTC.

In Nakamoto, blocks of Stacks are mined by miners who post Bitcoin as a deposit on the L1 network. When Stacks miners create a block, the blocks are anchored on Bitcoins L1 network and receive confirmations from proof-of-work (PoW) miners on the L1 network. When a block receives 150 L1 network confirmations, the block is considered final and cannot be forked without forking the Bitcoin L1 network. At this time, the Stacks miners who mined the block will be rewarded with STX, and their BTC deposits will be distributed to the Stackers on the network. This way, any Stacks block older than 150 blocks (blocks from approximately 1 day ago) relies on the security of the Bitcoin L1 network. For newer blocks (< 150 confirmations), the Stacks chain can only fork when 70% of Stackers support the fork.

Another upgrade to Stacks is sBTC, which provides a more secure way to bridge BTC to Stacks. To bridge assets to Stacks, users deposit their BTC into an L1 network address controlled by Stackers on the L2 network. When the deposit transaction is confirmed, sBTC is minted on the L2 network. To ensure the security of bridged BTC, Stackers must lock up STX that exceeds the value of bridged BTC as a deposit. Stackers are also responsible for executing redemption requests from the L2 network. Redemption requests are broadcast as L1 network transactions. After confirmation, Stackers will destroy sBTC on the L2 network and collaborate to sign an L1 transaction to release the users BTC on the layer 1 network. For this work, Stackers are rewarded with the previously discussed miner deposit. This mechanism is called Proof of Transfer (PoX).

Stacks aligns with Bitcoin by requiring many important L2 transactions, such as miner PoX deposits, redemption transactions, etc., to be executed as L1 network transactions. This requirement does improve the alignment and security of bridging BTC, but may result in a degraded user experience due to L1s volatility and high fees. Overall, the upgraded Stacks design solves many of the problems in V1, but there are still some weaknesses. This includes the use of STX as a native asset in L2, as well as L2 data availability where only hashes of transaction and smart contract code are available on the L1 network.

BOB

Bulid-on-Bitcoin (BOB) is an Ethereum L2 designed to align with Bitcoin. BOB runs as an Optimistic rollup on Ethereum and uses the EVM execution environment to implement smart contracts.

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

To differentiate itself from other Ethereum L2s that also support WBTC and TBTC, BOB is building features that allow users to interact directly with Bitcoin L1. BOB SDK provides a series of smart contract libraries that allow users to sign transactions on Bitcoin L1. The execution of these transactions on L1 is monitored by the Bitcoin light client. The light client adds the hash of the Bitcoin block to the BOB for Simple Verification (SPV), confirming that the submitted transaction was executed on L1 and included in the block. Another feature is standalone zkVM, allowing developers to write Rust applications for Bitcoin L1. Proof of correct execution can be verified on BOB rollup.

BOBs current design is more like a sidechain than Bitcoin L2. This is mainly because BOBs security depends on Ethereum L1, not Bitcoins security.

SatoshiVM

SatoshiVM is another project planning to launch zkEVM Bitcoin L2. The project popped up in early January and launched its testnet. There is very little information about the technical details of the project, and it is unclear who the developers behind it are. SatoshiVMs scant technical documentation mentions using Bitcoin L1 for data availability D), resisting censorship by supporting broadcasting transactions on L1, and using BitVM-like fraud proofs to verify L2s zero-knowledge proofs.

Due to its anonymous nature, there is a lot of controversy surrounding this project. Some investigations have shown that the project is related to Bool Network, an earlier Bitcoin L2 project.

Entrepreneurship opportunities in Bitcoin L2

The Bitcoin L2 space provides multiple opportunities for entrepreneurship. In addition to the opportunity to build the best Bitcoin L2, there are several other entrepreneurial opportunities.

Bitcoin DA layer

Many upcoming L2s are designed to increase their consistency with L1. One way is to use L1 for DA. However, given the strict limitations on Bitcoin block size and the long delay between L1 blocks, L1 cannot store all L2 transactions. This creates opportunities for Bitcoin-specific DA layers. Existing networks, such as Celestia, can be expanded to fill this gap. However, creating an off-chain DA solution that relies on Bitcoin security or BTC collateral could improve consistency with the Bitcoin ecosystem.

MEV extraction

In addition to using Bitcoin L1 for DA, some L2s may choose to delegate L2 transaction ordering to BTC-bound sequencers, or even to L1 miners. This means that any MEV extractions will be delegated to these entities. Given that Bitcoin miners are not suited for this task, there is an opportunity for a company like Flashbots to focus on MEV withdrawals and private order flow for Bitcoin L2. MEV extraction is often closely tied to the virtual machine (VM) used, and considering there is no recognized VM for Bitcoin L2 yet, there are likely to be multiple players emerging in this space. Each participant focuses on a different Bitcoin L2.

Bitcoin income tools

Bitcoin L2 will require the use of Bitcoin collateral for validator selection, DA security and other functions, which creates revenue opportunities for holding and using Bitcoin. Currently, there are tools that offer such opportunities. For example, Babylon allows users to stake BTC to secure other chains. As the Bitcoin L2 ecosystem prospers, there will be huge opportunities to provide an aggregation platform for BTCs native income opportunities.

Summarize

Bitcoin is the most well-known, secure, and liquid cryptocurrency. As Bitcoin enters the institutional adoption phase with the launch of the Bitcoin Spot ETF, it is more important than ever to maintain BTC’s fundamental nature as a permissionless and censorship-resistant asset.

This can only be achieved by expanding the permissionless application space surrounding Bitcoin. Bitcoin L2s and the entrepreneurial ecosystem that supports these L2s are fundamental to achieving this goal.