How to resist the old financial system’s takeover of Bitcoin

Bitcoin spot ETFs have dominated the discussion over the past few weeks. With everything settled, the community’s attention is turning back to Bitcoin. This means answering the eternal question: “How to improve Bitcoin’s programmability?”

Bitcoin L2 is currently 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 touches on interesting entrepreneurial opportunities related to Bitcoin L2.

We encourage startup founders interested in building Bitcoin-focused projects to contact me and apply to join the Alliance.

Defending Permissionless Bitcoin

Since many investors can now gain exposure to Bitcoin through regulated products, they can use Bitcoin in a wide range of traditional financial products, such as leveraged trading, collateralized loans, etc. However, these products do not use native BTC. Instead, they use BTC controlled by the issuer TradFi, while the native BTC is locked by the custodian. Over time, TradeFi BTC can become the main way to hold and use BTC, transforming it from a decentralized, permissionless asset to another asset controlled by Wall Street. Bitcoin-native permissionless products are the only way to resist the control of Bitcoin by the old financial system.

Building Bitcoin-native products

L1 Applications

There have been many attempts to implement additional functionality on L1. These efforts focus on leveraging 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 Tether (USDT) on Bitcoin L1, and then expanded to other chains. Counterparty is the underlying technology for Bitcoin Stamps and SRC-20 tokens. Ordinals is currently the standard for issuing NFTs and BRC-20 tokens on Bitcoin using inscriptions.

Ordinals has been a huge success since its inception, 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 Bitcoin Script, the native programming language of Bitcoin, more complex applications, such as AMM and Lending, are almost impossible to build.

BitVM

A unique effort to extend the functionality of Bitcoin's L1 is BitVM. The concept builds on the Taproot upgrade to Bitcoin. The concept of BitVM is to extend Bitcoin's functionality by executing programs off-chain, with the guarantee that the execution can be challenged on-chain via fraud proofs. While BitVM appears to be useful for implementing arbitrary logic off-chain, in practice the cost of executing fraud proofs on L1 grows rapidly with the size of the off-chain program. This problem limits the applicability of BitVM to specific problems, such as trust-minimized BTC bridges. Many upcoming Bitcoin L2s leverage BitVM for bridge implementations.

Simplified diagram of BitVM operation

Sidechain

Another way to address Bitcoin's limited programmability is to utilize sidechains. Sidechains are fully programmable independent blockchains, e.g., EVM-compatible, that attempt to align with the Bitcoin community and provide services to that community. Rootstock, Blocksteam's Liquid, and Stacks V1 are examples of these sidechains.

Bitcoin sidechains have been around for years, with limited success overall in attracting Bitcoin users. Liquid, for example, has less than 4,500 BTC bridged to its sidechains. However, some DeFi applications built on these chains have seen some success. Examples include Sovryn on Rootstock and Alex on Stacks.

Bitcoin L2

Bitcoin L2 is becoming a focal point for building permissionless applications on top of Bitcoin. They can offer the same advantages as sidechains, but with the security guarantees that come from the Bitcoin base layer. There has been controversy over what really represents Bitcoin L2. In this article, we avoid this debate but discuss the main considerations for making L2 sufficiently coupled 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 expect this security to extend to L2. This is already the case with the Lightning Network, for example.

This is why sidechains are classified as such, they have their own security. For example, the security of Stacks V1 relies on STX tokens.

This security requirement is difficult to achieve in practice. In order for L1 to protect L2, L1 needs to be able to perform certain computations to verify the behavior of L2. For example, Ethereum's rollup gets security from L1 because Ethereum L1 can verify zero-knowledge proofs (zk rollup) or verify fraud proofs (optimistic rollup). The Bitcoin base layer currently lacks the computing power for both. There are proposals to add new opcodes to Bitcoin that allow the base layer to verify zkp submitted by rollup. In addition, proposals such as BitVM attempt to implement methods for fraud proofs without changing L1. The challenge faced by BitVM is that the cost of fraud proofs can be very high (hundreds of L1 transactions), limiting their practical application.

Another requirement for achieving L1-level security for L2 is that L1 has an immutable record of L2 transactions. This is the Data Availability (DA) requirement. It allows observers who only monitor the L1 chain to verify the L2 state. Through inscriptions, records of L2 TXs can be embedded in Bitcoin L1. However, this creates another problem, which is scalability. Bitcoin L1 has a block time limit of about 4MB every 10 minutes and a data throughput limit of about 1.1 KB/s. Even if L2 transactions are highly compressed to about 10 bytes/tx, assuming that all L1 transactions are used to store L2 data, L1 can only support about 100 tx/second of L2 throughput.

Trust minimization from L1 bridging

In Ethereum L2, the bridge to L2 is controlled by L1. Bridging to L2, aka Peg-in, actually means locking an asset on L1 and creating a copy of this asset on L2. In Ethereum, this is achieved through the L2 native bridge smart contract. This smart contract stores all assets bridged to L2. The security of the smart contract comes from the L1 validator. This makes the bridge to L2 secure and trust-minimized.

In Bitcoin, it is not possible to have a bridge that is secured by all L1 miners. Instead, the best option is to have a multi-signature wallet that stores L2 assets. Therefore, the security of the L2 bridge depends on the multi-signature security, i.e. the number of signers, their identities, and how the transfer-in and transfer-out operations are secured. One way to improve the security of the L2 bridge is to use multiple multi-signatures instead of one multi-signature that contains all L2 bridged assets. Examples of this include TBTC, where multi-signature signers must post collateral that can be slashed if they cheat. Similarly, the proposed BitVM bridge requires multi-signature signers to post a security bond. However, in this multi-signature, any signer can initiate a transfer-out transaction. Transfer-out interactions are protected by BitVM fraud proofs. If a signer commits a malicious act, other signers (validators) can submit fraud proofs on L1 that result in the removal of the malicious signer.

Bitcoin L2 Landscape

Bitcoin L2 Project Summary and Comparison

Chainway

Chainway is building a zk rollup on top of Bitcoin. Chainway rollup uses Bitcoin L1 as the DA layer to store the rollup's zkp and state differences. In addition, the rollup leverages proof recursion so that each new proof aggregates the proof published on the previous L1 block. The proof also aggregates "forced transactions", which are L2-related transactions that are broadcast on L1 to force their inclusion on L2. This design has several advantages

1. Mandatory transactions ensure that the rollup sequencer cannot censor L2 transactions and give users the power to include these TXs by broadcasting them on L1.

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

The Chainway team also discussed using BitVM to ensure that proof verification and transfer-in/transfer-out transactions are correctly performed. Using BitVM to verify bridge transactions reduces the trust assumptions of the bridge multi-signature to an honest minority.

Botanix

Botanix is ​​building an EVM L2 for Bitcoin. 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. In addition, L2 uses inscriptions to store the Merkle tree root of all L2 transactions on L1. This provides partial security for L2 transactions, as the L2 transaction log cannot be changed, but does not guarantee the data processing of these transactions.

Botanix handles the bridging of L1 through a decentralized multi-signature system network called Spiderchain. The signers of the multi-signature are randomly selected from a set of business process orchestrators (orchestrators). Orchestrators lock user funds on L1 and sign a proof to generate an equal amount of BTC on L2. Orchestors need to submit a security deposit to be eligible for this position. In the event of malicious behavior, the security deposit can be slashed.

Botanix has already launched a public testnet, with the mainnet scheduled to launch in the first half of 2024.

Bison Network

Bison's Bitcoin L2 adopts a sovereign rollup style. Bison uses STARK to implement zk rollup, and uses Ordinals to store L2 TX data and generated zkp to L1. Since Bitcoin cannot verify these proofs on L1, verification is delegated to users who verify zkp in their devices.

For the BTC bridge to L2, Bison uses a Discrete Log Contract (DLC). DLC is secured by L1 but relies on an external oracle. This oracle reads the L2 state and passes the information to Bitcoin L1. If this oracle is centralized, the oracle could maliciously use locked assets on L1. Therefore, it is important for Bison to eventually move to a decentralized DLC oracle.

Bison plans to support rust-based zkVM. Currently, Bison OS implements many contracts, such as Token contracts, which can be proved using the Bison prover.

Stacks V2

Stacks is one of the earliest projects focused on extending Bitcoin programmability. Stacks is undergoing a transformation to better align with Bitcoin L1. The focus of this discussion is the upcoming Stacks V2, which is expected to be released on the mainnet in April 2024. Stacks V2 implements two new concepts that improve consistency with L1. The first version is the Nakamoto Release, which updates Stacks' consensus to follow Bitcoin blocks and finality. The second is an improved BTC bridge called sBTC.

In the Nakamoto Release, blocks in Stacks are mined by miners who margin trade in BTC on L1. When Stacks miners create a block, the blocks are anchored in Bitcoin L1 and receive confirmations from L1 PoW miners. When a block receives 150 L1 confirmations, the block is considered final and cannot be forked without forking Bitcoin L1. At this point, the Stacks miner who mined the block is rewarded with STX and their BTC margin is distributed to the network Stackers. In this way, any Stacks block older than 150 blocks (~1 day) relies on Bitcoin L1 security. For newer blocks (< 150 confirmations), the Stacks chain can only fork if 70% of Stackers support the fork.

Another Stacks upgrade is sBTC, which provides a more secure way to bridge BTC to Stacks. To bridge an asset to Stacks, users deposit their BTC into an L1 address controlled by L2 Stackers. When the deposit transaction is confirmed, sBTC is minted on L2. To ensure the security of the bridged BTC, Stackers must lock a margin in STX that exceeds the value of the bridged BTC. Stackers are also responsible for executing transfer requests from L2. Transfer requests are broadcast as L1 transactions. Once confirmed, Stackers destroy sBTC on L2 and collaborate to sign L1 tx, releasing the user's BTC on L1. For this work, Stackers are rewarded with the miner security deposit discussed previously. This mechanism is called Proof of Transfer (PoX).

Stacks is consistent with Bitcoin, requiring many important L2 transactions to be executed as L1, such as miner PoX deposits, transfer transactions. This requirement does improve the consistency and security of bridging BTC, but it may lead to a degraded user experience due to the volatility and high fees of L1. Overall, the upgraded stack design solves many problems in V1, but there are still some weaknesses. This includes the use of STX as a native asset in L2 and L2 DA, that is, only the hash value of transactions and smart contract code is available on L1.

BOB

Building on Bitcoin (BOB) is an Ethereum L2 that aims to be consistent 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 a more secure two-way bridge 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 with Bitcoin L1 directly from BOB. The BOB SDK provides a smart contract library that allows 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 BOB to allow simple verification (SPV) submitted transactions to be executed on L1 and included in the block. Another feature is an independent zkVM that allows developers to write rust applications for Bitcoin L1. Proofs of correct execution can be verified on the BOB rollup.

The current BOB design is better described as a sidechain rather than Bitcoin L2. This is mainly because BOB's security relies on Ethereum L1, not Bitcoin's security.

SatoshiVM

SatoshiVM is another project that plans to launch a zkEVM Bitcoin L2. The project suddenly appeared with the launch of the testnet in early January. There are few technical details about the project, and it is unclear who the developers of the project are. The few technical documents about SatoshiVM point to using Bitcoin L1 for DA, censorship resistance by supporting the ability to broadcast transactions on L1, and using BitVM-style fraud proofs to verify L2 zkp.

There is a lot of controversy surrounding the project given its anonymity. Some investigations have revealed that the project has ties to Bool Network, an older Bitcoin L2 project.

Entrepreneurial Opportunities in Bitcoin L2

The Bitcoin L2 space presents several entrepreneurial opportunities. In addition to the obvious opportunity of building the best L2 platform for Bitcoin, there are other entrepreneurial opportunities.

Bitcoin Data Layer

Many upcoming L2s aim to strengthen consistency with L1. One way to do this is to use L1 for DA. However, given the hard limit on Bitcoin block size and the long latency between L1 blocks, L1 will not be able to store all L2 transactions. This creates an opportunity for a Bitcoin-specific data processing layer. Existing networks, such as Celestia, could scale 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 sorters or even to L1 miners. This means that any MEV extraction will be delegated to these entities. Given that Bitcoin miners are not equipped to complete this task, there is an opportunity for a flashbot-like company focused on MEV extraction and Bitcoin L2 private order flow to emerge. MEV extraction is often closely related to the VM used, and given that there is no agreed-upon VM for Bitcoin L2, there may be multiple players in this field. Each one specializes in a different Bitcoin L2.

Bitcoin Earnings Tools

Bitcoin L2 will require the use of Bitcoin collateral for validator selection, DA security, and other functions. This creates opportunities for holding and using Bitcoin. Currently, there are some tools that provide such opportunities. For example, Babylon allows staking Bitcoin to protect other chains. As the Bitcoin L2 ecosystem flourishes, there is a great opportunity for platforms that aggregate Bitcoin native income opportunities.

In summary, Bitcoin is the most recognized, secure, and liquid cryptocurrency. As Bitcoin enters the institutional adoption phase with the launch of a Bitcoin spot ETF, it is more important than ever to maintain Bitcoin’s fundamental nature as a permissionless and censorship-resistant asset. This can only be achieved by expanding the permissionless application space around Bitcoin. Bitcoin L2s and the startup ecosystem that supports these L2s are essential elements to achieve this goal. At Alliance, we want to support founders who are creating these startups.

Thanks to Orkun Mahir Kılıç, Ken Liao for their valuable feedback on this article.