How to resist the old financial system’s takeover of Bitcoin
Bitcoin spot ETFs have dominated discussions over the past few weeks. With everything settled, the community's attention is back on 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.
Startup founders interested in building Bitcoin-focused projects are encouraged to contact me and apply to join the Alliance.
Defending permissionless Bitcoin
Since many investors now have access to Bitcoin exposure through regulated products, they can use Bitcoin across a host of traditional financial products, such as leveraged trading, mortgages, and more. However, these products do not use native BTC. Instead, they use BTC controlled by issuer TradFi, while native BTC is locked by custodians. Over time, TradeFi BTC could become the primary way to hold and spend BTC, converting it from a decentralized, permissionless asset into another asset controlled by Wall Street. Permissionless products native to Bitcoin are the only way to resist the old financial system’s control over Bitcoin.
Building Bitcoin-native products
L1 application
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 are currently the standard for issuing NFT 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, Bitcoin’s native programming language, more complex applications, such as AMM and Lending, are nearly impossible to build.
BitVM
A unique effort to extend Bitcoin L1 functionality is BitVM. This concept builds on Taproot’s upgrade to Bitcoin. The concept of BitVM is to extend the functionality of Bitcoin by executing programs off-chain, with guarantees that execution can be challenged on-chain through fraud proofs. While BitVM appears to be useful for implementing arbitrary logic off-chain, in practice the cost of performing fraud proofs on L1 grows rapidly with the size of the off-chain program. This issue limits BitVM’s applicability to specific problems, such as trust-minimized BTC bridges. Many of the upcoming Bitcoin L2s utilize BitVM for their bridging implementation.
BitVM operation simplified diagram
side chain
Another way to get around Bitcoin’s limited programmability is to utilize sidechains. Sidechains are fully programmable independent blockchains, e.g., EVM compliant, that attempt to align with and provide services to the Bitcoin community. Rootstock, Blocksteam’s Liquid, and Stacks V1 are examples of these sidechains.
Bitcoin sidechains have been around for years and have generally had limited success in attracting Bitcoin users. For example, Liquid has just under 4,500 BTC bridged to the sidechain. However, some DeFi applications built on these chains have achieved some success. Examples include Sovryn on Rootstock and Alex on Stacks.
Bitcoin L2
Bitcoin L2 is becoming the focus for building permissionless applications based on Bitcoin. They can offer the same advantages as sidechains, but with the security guarantees that come from Bitcoin’s base layer. There has been debate as to what Bitcoin L2 truly represents. In this article, we avoid this debate but 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 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, Stacks V1 relies on STX tokens for security.
This security requirement is difficult to achieve in practice. In order for L1 to protect L2, L1 needs to be able to perform certain calculations to verify L2's behavior. For example, Ethereum's rollup gets its 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 both of these computing capabilities. It has been proposed to add new opcodes to Bitcoin that would allow the base layer to verify rollup submitted zkp. Additionally, proposals such as BitVM attempt to implement fraud-proof methods without changing L1. The challenge with 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 TX can be embedded into Bitcoin L1. However, this creates another problem, which is scalability. Bitcoin L1 has a block time limit of approximately 4MB every 10 minutes and a data throughput limit of approximately 1.1 KB/s. Even if L2 transactions are highly compressed to about 10 bytes/tx, L1 can only support L2 throughput of about 100 tx/second, assuming all L1 transactions are used to store L2 data.
Trust minimization from L1 bridge
In Ethereum L2, the bridge of L2 is controlled by L1. Bridging to L2, aka Peg-in, essentially means locking an asset on L1 and creating a copy of this asset 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 trust-minimized.
In Bitcoin, it is impossible to have a bridge secured by all L1 miners. Instead, your best option is to have a multi-signature wallet that stores L2 assets. Therefore, the security of an L2 bridge depends on multi-signature security, i.e. the number of signers, their identities and how transfer-in and transfer-out operations are protected. One way to improve L2 bridge security is to use multiple multisigs instead of one multisig that contains all L2 bridge assets. Examples of this include TBTC, where multisig signers must provide collateral, which can be slashed if they cheat. Similarly, the proposed BitVM bridge requires multi-signature signers to provide a security deposit. 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 (verifiers) can submit fraud proofs on L1, causing the malicious signer to be removed.
Bitcoin L2 pattern
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 rollup’s zkp and state differences. Additionally, rollup exploits proof recursion so that each new proof aggregates the proofs published on the previous L1 block. The proof also aggregates "forced transactions", i.e. L2-related transactions that are broadcast on L1 to force their inclusion on L2. This design has several advantages
1. Forced transactions guarantee that the rollup sequencer cannot review L2 transactions and give users the power to include these TXs by broadcasting these TXs 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/out transactions are performed correctly. Validating bridged transactions using BitVM reduces the trust assumptions of bridging multisigs to an honest few.
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. 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 changed, but does not guarantee the data processing of these transactions.
Botanix handles L1 bridging through a network of decentralized multi-signature systems called Spiderchain. Signers of multi-signatures are randomly selected from a set of orchestrators. Orchestrators lock user funds on L1 and sign a certificate that generates an equivalent amount of BTC on L2. Orchestrators are required to submit a bond to be eligible for this position. Security deposits can be reduced in the event of malicious behavior.
Botanix has launched a public testnet, with the mainnet scheduled to launch in the first half of 2024.
Bison Network
Bison’s Bitcoin L2 adopts the sovereign rollup style. Bison uses STARK to implement zk rollup and 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 its BTC bridge to L2, Bison uses Discrete Log Contracts (DLC). DLC is protected by L1 but relies on external oracles. This oracle reads the L2 state and passes the information to Bitcoin L1. If this oracle is centralized, the oracle may maliciously use locked assets on L1. Therefore, it is important for Bison to finally 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 first projects focused on extending Bitcoin’s programmability. Stacks is being revamped to better align with Bitcoin L1. This discussion focuses on the upcoming Stacks V2, expected to be released on mainnet in April 2024. Stacks V2 implements two new concepts that improve consistency with L1. The first release, the Nakamoto Release, updates Stacks’ consensus to adhere to 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, these 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 miners who mined the block are rewarded with STX and their BTC deposits are distributed to network Stackers. 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 assets to the stack, users deposit their BTC into L1 addresses controlled by L2 Stackers. When the deposit transaction is confirmed, sBTC is minted on L2. To ensure the security of bridged BTC, Stackers must lock up a deposit in STX that exceeds the value of bridged BTC. Stackers are also responsible for executing rollout requests from L2. Transfer-out requests are broadcast as L1 transactions. After confirmation, Stackers destroy sBTC on L2 and collaborate to sign L1 tx, releasing the user’s BTC on L1. For this work, Stackers receive the previously discussed miner deposit reward. This mechanism is called Proof of Transfer (PoX).
Stacks, consistent with Bitcoin, requires many important L2 transactions to be executed as L1 methods, such as miner PoX margin, transfer-out transactions. This requirement does improve the consistency and security of bridging BTC, but may result in a degraded user experience due to L1’s volatility and high fees. Overall, the upgraded stack
