Wealth cryptography in Bitcoin Layer 2

Author: Mohamed Fouda, Medium; Compiled by: Deng Tong, Golden Finance

Bitcoin spot ETFs have dominated discussions in the past few weeks. After the dust settled, the community's attention returned to the development of 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 L1 and discusses some of the most promising Bitcoin L2 projects. The article then discusses interesting entrepreneurial opportunities related to Bitcoin L2.

Defending Permissionless Bitcoin

As many investors can now acquire Bitcoin through regulated products currency exposure, so they can use BTC in many TradFi products such as leveraged trading and mortgage loans. However, these products do not use native BTC. Instead, they use TradeFi’s BTC, which is controlled by the issuer, while native BTC is locked by a custodian. Over time, TradeFi BTC may become the primary way to hold and use BTC, shifting it from a decentralized, permissionless The asset transforms into another asset controlled by Wall Street. Permissionless products native to Bitcoin are the only way to resist the capture 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 enable 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 technology underlying Bitcoin Stamps and SRC-20 tokens. Ordinals are currently the de facto standard for issuing NFTs 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. More complex applications such as AMMs and lending are nearly impossible to build due to the limitations of Bitcoin Script, Bitcoin’s native programming language.

BitVM

BitVM is a unique effort to extend the functionality of Bitcoin L1. 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 and ensuring that execution can be challenged on-chain through fraud proofs. Although BitVM appears to be useful for implementing 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 BitVM’s applicability to specific problems, such as trust-minimized BTC bridges. Many upcoming Bitcoin L2s utilize BitVM for their bridging implementation.

BitVM operation simplified diagram

Sidechains

Solve the limited programmability of Bitcoin Another approach is to utilize sidechains. Sidechains are fully programmable independent blockchains, e.g. EVM-compatible, that attempt to align with and serve the Bitcoin community. Rootstock, Blocksteam’s Liquid, and Stacks V1 are all examples of these sidechains.

Bitcoin sidechains have been around for years but have generally had limited success in attracting Bitcoin users. For example, Liquid bridges less than 4,500 BTC to the sidechain. However, some DeFi applications built on top of 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 benefits as sidechains, but with the security guarantees derived from Bitcoin’s base layer. There has been debate over what Bitcoin L2 truly represents. In this article, we 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 expect security to extend to L2. This is already the case with the Lightning Network, for example.

This is why sidechains are classified, 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 secure L2, L1 needs to be able to perform certain calculations to verify L2's behavior. For example, Ethereum 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 the computing power to perform any of the above operations. It has been suggested that new opcodes be added to Bitcoin to allow the base layer to validate ZKPs submitted by Rollup. Additionally, proposals such as BitVM attempt to achieve fraud proof without changing L1. The challenge faced by BitVM is that the cost of fraud proof can be very high (hundreds of L1 transactions), limiting its practical application.

Another requirement for L2 to achieve L1 level security is for L1 to have an immutable record 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, records of L2 TX can be embedded into Bitcoin L1. However, this creates another problem, namely scalability. Due to the 4MB block time limit every 10 minutes, Bitcoin L1 has 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 a combined L2 throughput of about 100 tx/second, assuming all L1 transactions are used to store L2 data.

Trust-minimized bridging from L1

In Ethereum L2, the bridge to L2 is provided by L1 control. Bridging to L2, aka roll-in, essentially means locking an asset on L1 and minting a copy of that asset on L2. In Ethereum, this is achieved via L2 native bridge smart contracts. This smart contract stores all assets bridged to L2. Smart contract security comes from L1 validators. This makes bridging to L2 secure and trust-minimized.

In Bitcoin it is not possible to have a bridge secured by a full set of L1 miners. Instead, your best option is to have a multi-signature wallet that stores L2 assets. Therefore, the security of the L2 bridge depends on the security of the multisig, i.e. the number of signers, their identities, and the security of the hook-in and hook-out operations. One way to improve L2 bridge security is to use multiple multisigs instead of using a single multisig to hold all L2 bridge assets. Examples of this include TBTC, where multi-signers must post collateral, which may be slashed if they cheat. Likewise, the proposed BitVM bridge requires security guarantees from multi-signers. However, in this multi-signature, any signer can initiate a transfer-out peg transaction. Hook-out interactions are protected by BitVM fraud proofs. If a signer commits malicious behavior, other signers (verifiers) can submit fraud proofs on L1, causing the malicious signer to be slashed.

Bitcoin L2 Picture

Bitcoin L2 project summary comparison

Chainway

Chainway is on top of Bitcoin Build zk rollup. 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 issued on the previous L1 block. The proof also aggregates "forced transactions", which are L2-related transactions broadcast on L1 to force their inclusion on L2. This design has several advantages.

Forcing transactions guarantees that the rollup sequencer cannot review L2 transactions and gives users the power to include these TXs 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 guarantees that invalid proofs are not included in L1.

The Chainway team also discussed using BitVM to ensure proof verification and correct execution of transfer-in/out transactions. Validating bridged transactions using BitVM reduces the trust assumptions that bridged multisigs place on the honest minority.

Botanix

Botanix is ​​building 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 DA for these transactions is not guaranteed.

Botanix handles bridging from L1 via a network of decentralized multi-signature systems called Spiderchain. The signers of a multi-signature are randomly selected from a set of coordinators. Orchestrator locks user funds on L1 and signs a certificate minting an equivalent amount of BTC on L2. Conductors are required to pay a bond to be eligible for this role. In the event of malicious behavior, the security deposit will be significantly reduced.

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

Bison Network

h3>

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 into L1. Since Bitcoin cannot verify these proofs on L1, verification is delegated to users who verify ZKP in their devices.

For BTC bridging with L2, Bison uses the Discreet Log Contract (DLC). DLC is protected by L1 but relies on an external oracle. The oracle reads the L2 state and passes the information to Bitcoin L1. If this oracle is centralized, the oracle can maliciously spend the assets locked 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 Bison provers.

Stacks V2

h3>

Stacks was 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 are improving consistency with L1. The first version is the Nakamoto version, which updates the Stacks consensus to adhere to Bitcoin blocks and finality. The second is an improved BTC bridge called sBTC.

In Nakamoto’s release, blocks in Stacks are mined by miners who have pledged BTC bonds on L1. When Stacks miners create a block, these blocks will be anchored in Bitcoin L1 and receive confirmations from L1 PoW miners. When a block receives 150 L1 confirmations, it is considered final and cannot be forked without forking Bitcoin L1. At this point, the Stacks miners who mined the block will be rewarded with STX and their BTC bonds will be 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 when 70% of Stackers support the fork.

Another of Stacks The upgrade is sBTC, which provides a more secure way to bridge BTC to Stacks. To bridge assets to Stacks, users deposit their BTC to an L1 address controlled by L2 Stackers. When the deposit transaction is confirmed, sBTC will be minted on L2. To secure bridged BTC, Stackers must lock bonds in STX that exceed the value of bridged BTC. The stacker is also responsible for executing rollout requests from L2. Hook-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 bond reward. This mechanism is called Proof of Transfer (PoX).

Stacks, consistent with Bitcoin, requires many important L2 transactions (e.g. miner PoX bonds, pegged transactions) to be executed as L1. 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 updated Stacks design resolves many of the issues in V1, but there are still some weaknesses. This includes using STX as a native asset in L2 and L2 DA, i.e. only hashing of transaction and smart contract code is available on L1.

BOB

Bulid-on-Bitcoin (BOB) is an Ethereum L2 designed 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 will allow users to interact directly with BOB’s Bitcoin L1. 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 the BOB to allow Simple Verification (SPV) that the submitted transaction has been executed on L1 and included in the block. Another feature is standalone zkVM, which allows developers to write Rust applications for Bitcoin L1. Proof of correct execution can be verified on BOB rollup.

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

Bulid-on-Bitcoin (BOB) is an Ethereum L2 designed 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 will allow users to interact directly with BOB’s Bitcoin L1. 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 the BOB to allow Simple Verification (SPV) that the submitted transaction has been executed on L1 and included in the block. Another feature is standalone zkVM, which allows developers to write Rust applications for Bitcoin L1. Proof of correct execution can be verified on BOB rollup.

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

SatoshiVM

SatoshiVM is another project planning to launch zkEVM Bitcoin L2. The project burst onto the scene with the launch of its testnet in early January. There are few technical details about the project, and it's unclear who the developers behind it are. SatoshiVM's handful of technical documentation states using Bitcoin L1 for DA, being censorship-resistant by supporting the ability to broadcast transactions on L1, and using BitVM-style fraud proofs to verify L2 ZKPs.

Given its anonymity, the project has been controversial. Some investigations indicate that the project has ties to Bool Network, an older Bitcoin L2 project.

Entrepreneurial opportunities in the Bitcoin L2 paradigm

The space of Bitcoin L2 has brought some entrepreneurial opportunities . Setting aside the obvious opportunity to build the best L2 for Bitcoin, there are several other entrepreneurial opportunities.

Bitcoin DA Layer

Many upcoming L2s are designed to enhance consistency with L1. One approach is to use L1 for DA. However, given the strict limitations on Bitcoin block size and the long delays between L1 blocks, L1 will not be able to 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 off-chain DA solutions that rely on Bitcoin security or BTC collateral could improve alignment with the Bitcoin ecosystem.

MEV extraction

In addition to using Bitcoin L1 for DA, some L2 may choose to use L2 Transaction ordering is delegated to BTC-bound sequencers and even to L1 miners. This means that any MEV extractions will be delegated to these entities. Given that Bitcoin miners are not equipped for this task, there is an opportunity for companies like Flashbot that focus on MEV withdrawals and private order flow for Bitcoin L2. MEV extraction is often closely tied to the virtual machine used, and given that Bitcoin L2 does not have an agreed-upon virtual machine, there are likely to be multiple players in this space. Each focuses on a different Bitcoin L2.

Bitcoin income tool

Bitcoin L2 requires BTC collateral to select validators and DA security sexual and other functions. This creates revenue opportunities for holding and using Bitcoin. Currently, there are tools that provide such an opportunity. For example, Babylon allows staking BTC to secure other chains. As the Bitcoin L2 ecosystem flourishes, there is a huge opportunity for platforms that aggregate BTC’s native revenue opportunities.