Bitcoin Layer 2: Scaling Solutions, Challenges, and Future Prospects

Author: BlockPunk @Researcher of Trustless Labs

1. Introduction

With the increasing growth of the Bitcoin network and the vigorous development of inscription technology, the BTC ecosystem is at a critical turning point. The demand for scaling solutions in the market is growing, especially with the intensification of network resource competition and the rise in transaction fees driven by inscription technology, which has become an urgent problem to be solved. This research report delves into the development prospects of Bitcoin L2 technology and its potential impact on the market, with a particular focus on how to introduce BTC assets and enhance security through L2 technology. We will analyze in detail the different implementation methods of BTC L2 technologies such as sidechains, Rollup, and DA layer (Data Availability layer), and how they can attract the deposit of L1 BTC and the ability to create new assets.

At the same time, with the establishment of a new wave of asset distribution based on inscription technology, we are about to face new challenges and opportunities. The upper limit of market value that can be achieved through fair distribution or meme narratives highlights the urgency of further development to break through the ceiling. In this process, the provision of functionality and the definition of underlying assets become more critical. Sidechains based on inscription can not only lower the entry barrier for users, but also introduce new gameplay such as DeFi, SocialFi, and GameFi by providing complete smart contract capabilities. The concept of programming towards indexers proposes a new way of thinking about functionality and business expansion based on the native properties of inscription itself, which can not only alleviate server pressure but also potentially lead to the creation of a completely new inscription chain.

Four Waves of Impact

The Bitcoin ecosystem is undergoing a series of transformative impacts, which not only define the consensus process of the community but also drive significant technological and cultural developments. From the consensus on fair distribution to the cultural renaissance of BTC, to the outbreak of "inscription-based" scaling solutions, and ultimately the pursuit of more comprehensive expansion solutions, the Bitcoin ecosystem is rapidly evolving.

The first wave is the community's consensus on fair distribution, where BRC20 created a new type of asset that is completely different from FT and NFT, representing the rise of a civilian culture in the blockchain. The second wave that we are experiencing is the cultural renaissance of BTC, with large funds and exchanges participating in the consensus. At the same time, more developers are joining the world of inscription, launching many excellent protocols that have spilled over to more chains. BTC's culture is overwhelming everything, which of course has also led to some other problems. The third wave may be the outbreak of "inscription-based" scaling solutions. The significant development of the second wave has promoted the prosperity of the BTC ecosystem, but it has also led to competition for BTC network resources, ultimately causing conflicts with BTC conservatives. Meanwhile, poor user experience has hindered more users from entering the market. Therefore, the need for scaling inscription itself (rather than scaling BTC) is urgent and necessary, but directly developing second-layer scaling solutions based on BTC (such as Bitvm) is difficult and time-consuming. Therefore, compromise solutions will be adopted first, and in the next six months, we may see a large number of new sidechains of BTC that use inscription as the native asset (different from stx) and introduce main chain inscription through cross-chain methods. The fourth wave represents the complete maturity of "BTC-based" final expansion solutions, which includes complete smart contract capabilities, better performance, and strong security shared with BTC. High-value inscription assets will demand more security, making second-layer scaling solutions that are more native, more orthodox, and more secure important. This requires the second layer to use the BTC chain as the DA layer, upload proof, and even allow the BTC network to verify, such as the AVM of BitVM and Atomicals protocol. With strong orthodoxy guarantees, BTC will be more integrated into the inscription ecosystem. Ultimately, we will have an experience, performance, and smart contract functionality that is almost indistinguishable from ETH and its L2, but backed by the massive community and funds of BTC, while embracing "fair distribution" as the core culture and creating a completely new ecosystem based on "inscription" as the native asset.

Challenges and Opportunities Coexist

The significant development of inscription has promoted the prosperity of the BTC ecosystem, but it has also intensified competition for BTC network resources, with excessively high fee costs and the foreseeable future rise of BTC, continuously increasing the entry barrier for BTC ecosystem players. This has prompted more discussions on BTC's scaling solutions and attracted the attention of the community and investors. Of course, people tacitly avoid direct upgrades to BTC L1 scaling solutions, and the most radical discussions are no more than lifting some OP script seals and continuing to explore the remaining potential of BTC under Taproot (such as discussions on CTV and CAT). With the development and theoretical achievements of ETH's Rollup and modularity, BTC Layer2 has become the mainstream of scaling discussions and the most effective solution. The first batch of projects will also go live in the next two to three months and become the absolute mainstream narrative of speculation. Due to the highly decentralized governance of BTC, without a "church" guiding the community, its L2 design is also diverse. This article will start with typical BTC L2 and related protocol projects on the market to explore the possibilities of BTC scaling from an implementation perspective. Here, BTC L2 is roughly divided into sidechains, Rollup, DA layer, decentralized index, and other methods, grouping similar projects together. Since no one has the right to define BTC's scaling solutions, my actual classification is not rigorous. This article focuses on the perspective of implementation solutions, and many designs are still at the conceptual stage. In the competition for second-layer assets, technology and security determine the lower limit of the project. Technology is the ticket, and there is the possibility of first-class, economy class, or even standby tickets. However, from the perspective of assets, one is the ability of L2 itself to create assets, whether by introducing inscription or pulling its own market, which cannot be evaluated solely from a technical perspective; the second is whether it can attract the deposit of L1 BTC, which is a core competitive advantage and is closely related to the design of the solution.

Will the adoption of the BTC ecosystem surpass ETH in the future? This article may provide you with some reference.

Before delving into the technical analysis of BTC L2, it is necessary to introduce the changes brought about by the Taproot upgrade:

Schnorr signatures have introduced a method for BTC to have up to 1000 participants in multi-signature, which is the foundation for many L2 bridges.
MAST allows the combination of scripts for multiple UTXOs through a Merkle tree, enabling more complex logic, providing the possibility for proof systems on L2.
Tapscript has upgraded Bitcoin scripts, allowing the verification of a series of scripts to determine whether UTXOs can be spent, providing the possibility for operations such as withdrawals and forfeitures on L2.

2. Overview of BTC L2 Technologies

Sidechains

Scaling is achieved by creating parallel chains to the main chain. Sidechains can have their own consensus mechanism and block generation rules, and can interoperate with the BTC main chain through cross-chain bridges.
Everything is for usability, and usability is everything. The advantage of sidechains is mainly focused on the rapid development of business logic. Its security is basically related to its own network and is like a "standby ticket" on the train of BTC security. The most important part is the cross-chain bridge of BTC, which is the only connection point.

@BTClayer2 BEVM

Actually, most BTC L2 solutions, like BEVM, continue the approach of sidechains in ETH scaling. BEVM deploys a multi-signature address on BTC's L1 through Taproot's capabilities and runs an EVM sidechain, deploying smart contracts in EVM to accept BTC withdrawal requests. BEVM uses GAS that is cross-chain BTC. When recharging, the bridge operator synchronizes BTC data and notifies the sidechain, and BEVM nodes also run a light client to synchronize BTC block headers to verify recharges. When withdrawing, the bridge custodian signs and, after collecting a certain number of signatures (threshold), the transaction to withdraw BTC is initiated. This achieves interoperability between the sidechain and BTC assets. Unlike traditional RSK and STX solutions, BEVM uses Taproot's BTC multi-signature to achieve threshold signatures, theoretically allowing more bridge operators, adding a certain fault tolerance to BTC cross-chain, and increasing decentralization. However, BEVM does not use any security guarantees of BTC, only achieving interoperability of BTC assets. Its nodes run their own internal consensus and EVM, do not upload proof to the BTC network, and therefore do not have an L1 DA. The network's transaction censorship resistance relies on the network itself, so if nodes refuse to package your BTC withdrawal transaction, you will not be able to obtain BTC from L1, which is a potential risk. The advantage of this approach is the ability to quickly implement and verify. BEVM's self-implemented Taproot multi-signature also enhances the security of the bridge and is one of the few BTC sidechains currently live on the mainnet.

Map Protocol

Map is also an EVM architecture inscription sidechain that chooses to cross-chain BTC L1's BRC20 to EVM to run some low-cost businesses. Map runs an enhanced BRC20 indexer, where users cross-chain BRC20 from BTC, needing to insert information such as the target chain and address in a new transaction in JSON to be indexed by Map and appear on the sidechain. Withdrawals of BRC20 are initiated by a multi-signature committee under Map's PoS mechanism, and the BRC20 ledger actually runs in the index, with BTC L1 essentially being its data source. Utilizing the lower fees of the sidechain, Map runs the LessGas Mint tool for BRC20 on the chain, trades SATSAT in the inscription market, and cross-chains BRC20 through Roup. The inscription-centric approach has attracted a group of users. Map uses the classic PoS consensus mechanism to upload checkpoint data to BTC L1 to enhance its security and prevent long-range attacks.

Merlin Chain

A BTC sidechain released by BRC420. Merlin Chain chooses to use the MPC solution of the cobo wallet to achieve BTC cross-chain, which seems to be a relatively conservative choice: MPC has fewer signers, and compared to BTC multi-signatures after the Taproot upgrade, there is still some gap in security, but MPC has been well-verified. Merlin uses ParticleNtwrk's account abstraction, allowing continued interaction with BTC wallets and addresses on the sidechain without changing user habits, which is commendable. In comparison, designing interactions for BTC users to return to Metamask seems lazy and straightforward. With high popularity for BRC420 and Bitmap, Merlin has accumulated a large user base. Merlin continues to conduct business around inscription, supporting diverse inscription assets for cross-chain from L1 and providing inscription engraving services on the sidechain.

ckBTC

ckBTC is the integration of BTC through pure cryptographic methods in ICP, without relying on any third-party bridges or custody. ICP is an independently operated L1 blockchain, with consensus guaranteed by its unique BLS threshold signature scheme. The ChainKey technology bound to the consensus algorithm allows the entire ICP network to collectively manage a threshold signature address for BTC, accept BTC, and control BTC under the aggregate signature through consensus, achieving withdrawals. ICP also recreates all BTC UTXOs in its network using an account model, and smart contracts in the network can read the state of BTC, essentially running a full BTC node in the ICP network.

As this threshold signature is directly tied to the consensus algorithm of the ICP network, the security of ckBTC is only related to the ICP network and BTC network, without introducing additional third-party trust assumptions. Therefore, the ChainKey threshold signature scheme used by ICP is currently the most secure BTC bridge approach. However, for withdrawers, if the IC network crashes or refuses transactions, they cannot forcibly withdraw from BTC L1. At the same time, ICP, as an independent L1, guarantees its own security and has no relationship with BTC.

DA Layer

The DA layer stores data on the BTC chain but outsources computation to off-chain or other chains to utilize BTC's security while increasing processing power. BTC is one of the most stable and trusted data sources in the world, so it is very natural to use Bitcoin as a trusted data source. Similarly, with CelestiaOrg's DA theoretical basis, although BTC's data storage is very expensive, it has become the consensus basis for the DA layer. Essentially, Ordinals and the entire inscription ecosystem are using BTC as the DA, and almost all "BTC L2" will send data to BTC, but this is more like a formality, representing a beautiful vision. Below are some distinctive designs.

Nubit

Nubit is a DA protocol designed to expand the data availability scenario for BTC, and it has attracted attention due to funding from Bounce Finance and domo. In simple terms, Nubit organizes a DA chain similar to Celestia through POS consensus and regularly uploads Nubit's own DA data, such as block headers and transaction Merkle tree roots, to BTC L1. In this way, Nubit itself is saved by BTC L1 for its DA, and Nubit sells its storage space on its own chain as DA to users and other Rollup chains (DA nesting). Nubit itself does not have smart contract capabilities and requires Rollup to be built on its DA. Users upload data to Nubit's own DA layer, and after confirmation by Nubit's POS consensus, the data enters a "soft confirmation" state. After a period of time, Nubit uploads the chain's data root to BTC L1, and only after the BTC transaction is completed will the data initially uploaded to Nubit by the user enter the final confirmation state. After this, users need to upload data tags to BTC L1, which are used to query the original data in the Merkle tree of Nubit's full node. The early POS consensus of the Nubit network was supported by Babylon's BTC POS staking (to be introduced below). Users pay storage fees using BTC, and for this, Nubit uses the Lightning Network to accept BTC, avoiding bridge issues with state channels. Users can make emergency withdrawals by closing channels without needing to transact with Nubit's POS network itself. Nubit seems to be a Bitcoin ecosystem version of Celestia, without adding complex smart contract functionality, and it uses the decentralized Lightning Network for BTC payments, which is relatively simple. Although the Lightning Network is trustworthy, the user experience is not ideal and it is difficult to support large fund inflows and outflows (state channel exhaustion issues). The relationship between Nubit and BTC L1 is relatively weak, as the chain's security is not guaranteed by BTC, and the data on BTC is only verified by Nubit's node client. Why do Rollup and inscription data need to go through Nubit as an intermediary layer instead of being directly uploaded to BTC? This may be the most important question that Nubit needs to answer, as low fees may not be the core driver. The biggest advantage of Nubit's DA may be that it supports sampling data verification for light nodes (DAS), which BTC network cannot achieve, meaning that verifying DA no longer requires users to download the full BTC node. Can inscription still gain community consensus without being fully on Bitcoin? Nubit attempts to use its own chain's DA to replace the DA of the BTC L1 chain, facing not just technical challenges but also significant challenges in community consensus. Of course, this also presents a huge opportunity.

Veda

The Veda protocol reads specific Ordinals inscriptions on BTC L1 and executes them as transaction requests in the EVM under the BTC chain. Users sign a transaction on BTC L1 with a BTC private key that complies with the EVM, and then mint it as an inscription on BTC. Veda's EVM nodes scan BTC blocks, and once the transaction is confirmed on BTC, the EVM executes the request, causing a state change. In essence, this treats BTC as a pending transaction pool for the Veda EVM. However, because BTC's performance is much lower than ETH's EVM, and the data written to BTC blocks is limited over a certain period, the Veda EVM will definitely be able to execute all EVM requests uploaded to BTC. BTC is the data source for all Veda states, and anyone can reconstruct the complete state of the EVM by scanning all Veda requests in BTC blocks. Therefore, Veda EVM can be optimistically trusted, without any complex security assumptions. However, Veda cannot enhance BTC's performance. Veda can be seen as a network with 10-minute block intervals, 5 TPS, but with tens of thousands of nodes and huge PoW computing power, extending the functionality of BTC and adding smart contract capabilities. This does not fundamentally solve the problem of resource competition.

Babylon

Babylon is a protocol designed to help other blockchains share the security of BTC, consisting of two parts: Bitcoin staking services and Bitcoin timestamp services. Babylon allows staking BTC to provide economic security for POS chains (similar to ETH's restake) in a cryptographic manner without relying on any third-party bridges or custodians. BTC stakers can stake by sending a transaction with two UTXO outputs on BTC, with one UTXO writing a time-locked script that allows the staker to unlock BTC with their private key after expiration, and the other UTXO transferring to a temporary BTC address with a public-private key pair that meets the cryptographic standard of "extractable one-time signature EOTS." When a BTC staker runs a node for a POS chain and verifies a unique valid block, they sign it with the EOTS private key. If the staker (also a validator of this POS chain) remains honest and signs only one valid block at a time, they will receive the validator reward for the POS chain. If they attempt to act maliciously and sign two blocks at the same block height, their EOTS private key will be reverse-engineered, allowing anyone to use it to transfer the staked BTC on the BTC chain, resulting in forfeiture. This encourages stakers to remain honest. Babylon also provides BTC timestamp services, uploading checkpoint data from any blockchain to BTC's op_return to enhance security. Nubit plans to use Babylon's BTC staking services to enhance security. Babylon uses purely cryptographic solutions for handling BTC storage, forfeiture, and has high security. However, for chains using staking services, this imposes economic constraints, and there is still some distance to go in terms of verifiability compared to ETH's Rollup approach. Although the timestamp service uploads L2 data to BTC, directly checking all BTC blocks requires downloading the full node, which has a high barrier to entry. Additionally, BTC L1 does not have smart contracts and cannot verify the correctness of this data.

Rollup

Rollup uses BTC's data layer to store state and transaction data, but processes computation and state changes off-chain, ensuring security by submitting proof or data changes back to the BTC main chain.
The core issue of BTC Rollup lies in verification. Through Ordinals, Bitcoin can store various data, becoming a highly secure database. Uploading Rollup's proof data to the BTC network can indeed ensure that it cannot be tampered with, but it does not guarantee the validity and correctness of internal Rollup transactions. Most BTC Rollups may choose a sovereign rollup (client verification) approach, where validators synchronize all Rollup data off-chain and verify it themselves. However, this does not fully utilize Bitcoin's strongest capability, the consensus of tens of thousands of nodes through POW, to guarantee Rollup's security. The ideal state would be for the BTC network to actively verify Rollup proofs, similar to ETH, and reject invalid block data. At the same time, it should ensure that assets in Rollup can be trustlessly withdrawn to the BTC network in extreme situations, even if Rollup nodes/sorters are constantly down or refuse to accept transactions, through a secure escape route. For Bitcoin, which lacks smart contracts and only has script execution, it may be possible to use MAST to combine scripts into logical circuits for verification, although this is challenging, it aligns with the most native approach of BTC.

@ZeroSync_ BitVM

BitVM is the most prominent extension protocol on BTC, representing an Optimistic Rollup for BTC. BitVM innovatively proposes a way to challenge fraud on BTC, where the prover and challenger both deposit an equal amount of BTC as input in a transaction, and the output of this transaction will contain a logical circuit. BTC scripts can be seen as processing the simplest logic gates, which are the basic components of a computer. If these logic gates are combined in a tree-like manner, they can form a circuit that includes specific logic. BitVM writes a fraud proof into a circuit composed of a large number of BTC scripts, and the structure of this proof circuit is determined by a series of nodes packed by the sorter in Rollup. The challenger can continuously upload hash values to this fraud proof circuit, and the verifier continuously runs the corresponding scripts and reveals the output to confirm its correctness. Through a series of transactions, the challenger can continuously challenge the prover until the prover confirms that each gate of the circuit is correct. In this way, the BTC network verifies Rollup, and the prover can claim their funds. Otherwise, the challenger will receive the BTC staked by the prover. In a more understandable way, BitVM's relationship with BTC is similar to OP's relationship with the ETH network, with its security being the highest among all scaling solutions. BitVM generates a large number of transactions, which are costly, and requires a significant amount of pre-signing before on-chain verification by both parties. Unlike ETH's Optimistic/ZK Rollup, BitVM does not have an emergency BTC withdrawal channel, and at least one honest node in the L2 network is required for a normal exit. However, this is currently the highest level of security that BTC L2 can achieve, with DA uploaded, BTC L1 verifying the validity of Rollup data, and a minimally trusted BTC bridge, lacking only an "emergency escape route." Therefore, the implementation of BitVM seems distant, but the recent discussions in the BTC community about unlocking the opcat script may bring new possibilities for BitVM's development. The opcat opcode can concatenate two strings, supporting a maximum length of 520 bytes. This concatenation of data can enable more complex calculations on Bitcoin. For example, BitVM can concatenate hundreds of logic gates under the same script using it, allowing BitVM to handle more binary circuits in fewer transactions, achieving nearly a hundredfold increase in speed. BitVM's complex combination of Bitcoin scripts has also inspired many L2 projects to propose new approaches for "fraud proof" challenges on BTC.

@Bison_Labs Bison Network

Bison Network is a ZK-STARK sovereign Rollup (client verification) based on Bitcoin. In a sovereign Rollup, L1 is used as a public display board (DA) for Rollup's block data, without verifying the correctness of Rollup transactions, which are verified by Rollup's own nodes. Bison submits Rollup's ZK proofs to BTC Ordinals, and users can download the proofs from BTC and run their own clients to verify Rollup transactions. Full node synchronization is required to verify the entire state of Rollup. Bison's feature lies in its implementation with the BTC L1 bridge. When a user deposits BTC into Bison Rollup, the BTC is divided into multiple multi-signature wallets that support DLC (Discreet Log Contracts), a technology based on the Taproot upgrade that uses simple logical contracts with BTC multi-signatures and time-locked scripts. When users deposit BTC, they need to sign relevant execution transactions for all future scenarios with the Bison network, such as: a. transferring to others; b. extracting back to the BTC mainnet; c. long periods without extraction. After signing, these transactions are not published to BTC blocks, and if they need to be executed, an oracle is required to drive them. There are three controllers for the multi-signature wallet: the user, Bison Rollup, and the oracle. Obtaining signatures from any two of them grants control of the BTC.

DLC is like an "if-do" statement on Bitcoin, with the oracle inputting the condition for "if," and the execution part being the sending of transactions signed for the three scenarios mentioned above. The oracle is linked to Bison Rollup's bridge contract, and if the bridge receives a user request to transfer BTC to others, the oracle sends the signed transactions for scenario a. transferring to others, granting control to the Bison network for further distribution; if the bridge receives a user request to extract back to the BTC mainnet, control is transferred to the user; if no messages are received for a long time, control returns to the user when the time lock expires. Thus, Bison enables the extraction of BTC from Rollup and sets up a simple escape route. However, the weakness of this system lies in the oracle; if it transmits incorrect information, it can lead to the loss of user assets, so it may be worth considering introducing decentralization, such as Chainlink. The "trustless bridge" implemented by DLC is an exploration of the potential of BTC scripts, and http://DLC.link uses it to bridge BTC to other chains such as ETH and STX. Although Bison Rollup has implemented a simple "escape route" by introducing a new third party, it still has not achieved BTC L1 verification of Rollup proofs.

@BsquaredNetwork B² Network

B² Network is a ZK Rollup on BTC that incorporates "commitment challenges." The network is divided into two layers: the Rollup layer and the DA layer. The Rollup layer uses zkEVM to run smart contract logic and includes multiple modules for transaction acceptance, sorting and packaging, ZK proof generation, support for BTC address account abstraction, and synchronized reading of BTC L1 data (BTC and BRC20 balances). The DA layer provides data storage for Rollup, with storage nodes performing off-chain zk verification of Rollup transactions. After verification, DA layer nodes write Rollup data into BTC's Ordinals inscription, including the Rollup data's location in the DA layer, the Merkle tree root of transactions, ZK proof data, and the hash of the previous BTC proof inscription. Verification of the proof is crucial. In ETH, bridge contracts directly verify ZK proofs on L1, but BTC does not have smart contract functionality, and due to the complexity of ZK verification, it cannot be achieved through a combination of BTC scripts (which would incur significant costs and may exceed the BTC block limit). Therefore, B² introduces more off-chain computation in the verification process, transforming L1's direct verification of ZK proofs into a "fraud proof" challenge similar to Optimistic. B² decomposes the ZK proof into different scripts and overlays these scripts to form a Mast binary tree. B² nodes send BTC through this transaction as a reward for the fraud challenge.

Once a transaction containing the "fraud proof challenge" is confirmed on BTC L1, the challenger can download the original data from the DA layer and execute the above-mentioned scripts off-chain. If the final output does not match what was submitted by the B² node, indicating malicious behavior, the challenger can gain control of the BTC locked in the script root, and all Rollup transactions will be rolled back. If there is no challenge within the lock time, the node can retrieve the locked BTC, and Rollup receives final confirmation. In B² Network, the first transaction of sending BTC confirms the tamper resistance of the ZK proof. Although BTC still cannot verify ZK transactions, by indirectly completing L1 verification through the implementation of the "fraud proof challenge" in the second transaction, B² Network ensures the validity of Rollup transactions, enhancing security. This is indeed an impressive innovation. B² Network has introduced account abstraction, allowing users to directly interact with BTC wallets and Rollup transactions without changing their habits, which is highly commendable. However, the extraction of BTC assets from L2 still uses a multi-signature address bridge and does not introduce an "escape route."

@SatoshiVM SatoshiVM

SatoshiVM is also a ZK Rollup based on BTC, with a logic similar to B² Network. After generating a ZK proof in Rollup, the prover uploads the proof data to the BTC network and then sends a "fraud proof challenge" containing BTC, with the challenger receiving a BTC reward for a successful challenge. The difference is that SatoshiVM adds two time locks to the "fraud proof challenge," corresponding to the start and end of the challenge, allowing the comparison of how many blocks have passed since the BTC transfer occurred, enabling the determination of the correctness and validity of the ZK proof. The cross-chain bridge part only uses a multi-signature scheme and does not have any highlights.

@chainway_xyz Chainway

Chainway is a ZK sovereign rollup on BTC that not only uses Bitcoin as a data publishing layer but also as the source for generating ZK proofs. Chainway's provers need to scan every BTC block without exception. They read block headers, the previous zk proof, and "mandatory transactions" inscribed in the block to generate a complete ZK proof. In each BTC block, Chainway submits a transaction inscribing the ZK proof, creating a recursive proof.

The "mandatory transactions" inscribed in BTC blocks in Ordinals inscription form are Chainway's "anti-censorship transaction sending method." If a Chainway Rollup node is down or continuously refuses to accept withdrawal transactions from users, users can inscribe withdrawal requests directly into the Bitcoin block. The node must include these "mandatory transactions" in Rollup blocks; otherwise, it will fail to satisfy the constraints of the ZK circuit, and proof generation will fail. In a recent tweet, Chainway claims to have found a way to verify ZK proofs on Bitcoin, inspired by BitVM, to achieve BTC L1 settlement. Clearly, Chainway's design is based on client-side verification of sovereign Rollup. Although "mandatory transactions" to some extent address the issue of resistance to node censorship in Rollup transactions, true BTC L1 asset settlement is still not achieved.

@QEDProtocol QED Protocol

QED Protocol is a ZK rollup on BTC that runs on zkEVM. Unlike other ZK Rollups, QED does not choose to generate ZK proofs for the entire Rollup transactions but only creates ZK proofs for withdrawal transactions from Rollup to BTC L1. Similar to BitVM's approach, QED Protocol composes scripts into logical circuits, enabling the verification of withdrawal transaction ZK proofs on BTC L1. These logical circuits will include 1000 UTXOs. Although direct verification is achieved, it incurs significant costs.

3. Inscription L2 — Rethinking BTC Scalability

After experiencing the grand wave of new asset distribution, the main narrative of Inscription has been established, and we are about to face new opportunities and challenges. Relying solely on fair distribution or meme narratives, it seems that a market cap of 200 million is a hurdle that is difficult to overcome without continuing to build solidly (the end of fair distribution is PUA). In the process of returning to rationality, utility becomes more important. Either provide more capabilities or be treated as a base asset. "Sidechains based on Inscription" may become an important next step. They are called sidechains rather than L2 because these "L2" do not use the security of BTC. However, this is similar to Polygon's relationship with ETH, as Inscription L2 effectively lowers the barrier for users to enter Inscription and compromises with BTC conservatives. Most importantly, complete smart contract capabilities also introduce more possibilities for Inscription, such as DeFi, SocialFi, GameFi, and more. BRC20 and its derivatives in Inscription write token information in human-readable JSON, providing high flexibility. This flexibility is very suitable for interacting with Inscription L2 because once the L2 reads the JSON and restores the BRC20 state, subsequent DeFi and other businesses are easy to conduct. As a new type of asset distinct from NFTs and FTs, Inscription L2's business can also revolve around Inscription itself, and it is best to use Inscription as the native asset. If Inscription L2 only splits Inscription into FT after cross-chain and then replicates Ethereum's DeFi gameplay, it will lack appeal because for current traders, the cost-effectiveness of trading FT is already low. The index of BRC20 is the ledger, and after reading the index, an EVM chain is created, continuing Inscription's attributes, and continuously introducing a large number of innovative paradigm applications distinct from FT DeFi.

Programming for Indexers

Will the BRC20 and its Json inscription sidechains necessarily follow the pattern of ETH? In fact, EVM sounds very boring, and we don't need to reinvent a series of L2s. Perhaps it would be more interesting to think about the expansion of functionality and business from the native properties of Inscription itself.

BRC20 is a token system for on-chain records, with BTC used for storage. Therefore, for such scalability, it may be possible to implement more business logic in off-chain indexing servers. For example, introducing new primitives under the "op" field in Json, in addition to "mint," "deploy," and "transfer," to perform operations such as placing orders, staking, burning, authorizing, etc. The combination of these "op" can further evolve into Inscription-Fi (Inscription Finance) functionalities such as swap, lending, and even more complex SocialFi and GameFi. This is essentially programming for indexers, more like programming interfaces for servers in Web2, with low implementation difficulty and significant impact, possibly starting directly from an indexing server. Currently, UniSat's swap functionality, including protocols such as BRC100, ORC20, and Tap, are pioneers of this type of Json expansion, with the potential to bring about rapid change. The attempt to add cryptographic primitives is exciting, but decentralization is always a consideration. Programming for indexers will inevitably lead to increasing server pressure and make community operations more difficult. Complex businesses also require consensus, ultimately leading to the development of smart contract platforms. Therefore, if the ledger in the indexer is decentralized, could it innovate a new Inscription chain? In fact, the subsequent business based on $sats launched by @unisat_wallet follows this approach, with swap and pool functionalities implemented in its indexer. Decentralization is a necessary process to achieve consensus on fund security. There are also projects like @RoochNetwork that do not obtain assets from L1 but only run indexing and BTC full nodes, providing read-only L2 for use by on-chain smart contracts.

A More Native Approach

The issuance of BTC L1 can be divided into two major factions. In addition to the Json faction mentioned above, there is the unique UTXO faction of Atomicals (the definition of Rune is still somewhat vague and will not be discussed for now). The ARC20 tokens of Atomicals directly represent BTC's UTXO itself, without any updates in Json. Therefore, operations based directly on UTXO can enable arc20 tokens to achieve many interesting capabilities, such as swapping arc20 tokens with BTC, consuming arc20 tokens to produce another type of arc20 token, and more. Control over transaction inputs and outputs can also enable simple DeFi functionalities, but this places higher demands on developers and increases complexity. The benefits are also very clear, as all logic is directly handled by the BTC network, sharing the highest level of security and consensus. It can seamlessly absorb BTC assets, but it needs to rely on third-party BTC bridges like a sidechain, after all, "not your keys, not your coins." Obviously, ARC20 itself is not Turing complete, so after absorbing the design ideas of Bitvm, the Atomicals protocol also proposes the AVM Bitcoin Layer 2 solution, which is an L2 that submits proofs on BTC L1 and is verified by BTC script circuit logic. ARC20, as a representation of UTXO assets, naturally serves as collateral for fraud proofs in the AVM Layer 2. This will be the ultimate narrative of BTC scalability, achieving smart contract capabilities while sharing the security of BTC DA. This may only truly land in the fourth wave of L2, but the development service provider @wizzwallet of Atomicals seems to have provided some information about AVM in a recent update, perhaps progressing faster than imagined.

4. Conclusion and Outlook

The industry is constantly changing, with new BTC L2 solutions emerging every second, but the inevitable trend is the development of the BTC ecosystem towards the second layer. BTC is a train that everyone wants to board, and in terms of solutions, sidechains are passengers who have bought tickets, only connecting with BTC through cross-chain bridges, but they are the first to be used. DA-type projects are attempting to establish BTC versions of Celestia and Eigenlayer, with catchy gimmicks and opportunities under modular consensus. Rollups, by uploading DA and using BTC scripts to implement some simple on-chain mechanisms (mostly borrowing from BitVM's bit commitment approach), have barely stepped into the carriage of BTC security. Who says that a sovereign Rollup relying on self-verification is not a Rollup? (We must thank Celestia for its long-term CX in sovereign Rollup.) The gem on the crown of BTC L2 is the use of BTC script logic to verify the proofs uploaded by Rollup, and currently only BitVM and Atomicals' AVM are attempting this, which is infinitely close to the security relationship between ETH and its Rollup. It may seem out of reach at the implementation level, but the unlocking of new operators like op_cat seems to further accelerate its progress, and BitVM may be implemented faster than expected.

Through in-depth analysis and discussion of BTC L2 technology, we realize that despite the challenges, the future of the BTC ecosystem is full of infinite possibilities. From consensus on fair distribution to Inscription-based scalability solutions, and to fully mature expansion solutions that seek to share strong security with BTC, the Bitcoin ecosystem is undergoing a historic transformation. These technologies not only have the potential to significantly improve the scalability and efficiency of the BTC network but also introduce new asset types and trading methods, opening up new opportunities for users and developers. However, achieving these goals requires the collective efforts of community consensus, technological maturity, and practical verification. In the process of exploring the most effective L2 solutions, security, decentralization, and optimizing user experience will remain top priorities. Looking ahead, with technological advancements and community collaboration, BTC L2 technology is expected to unleash the new potential of the Bitcoin ecosystem, bringing more innovation and value to the cryptocurrency world.