Bitcoin Layer2: Scalability Solutions, Challenges, and Future Prospects

1 Introduction

As the Bitcoin network continues to grow and the technology of layering thrives, the BTC ecosystem is at a crucial turning point. There is a growing demand in the market for scalability solutions, especially with the intensified competition for network resources and the rising transaction costs driven by layering technology. This research report delves into the development prospects of Bitcoin L2 technology and its potential impact on the market, particularly focusing on how to introduce BTC assets and enhance security through L2 technology. We will analyze in detail the different implementations of BTC L2 technologies such as sidechains, Rollups, and DA layers (Data Availability layer), and how they attract deposits of L1 BTC and create new assets.

At the same time, as layering technology establishes a new wave of asset distribution, we are about to face new challenges and opportunities. The market value ceiling achievable through fair distribution or meme narratives highlights the urgent need for further construction to break through the bottleneck. In this process, the provision of functionalities and the definition of underlying assets become more critical. Sidechains based on layering not only lower the entry barriers for users but also introduce new gameplay such as DeFi, SocialFi, and GameFi into layering by providing complete smart contract capabilities. The concept of indexer-driven programming proposes a new approach that starts from the native attributes of layering itself, considering functionality and business expansion, which can not only alleviate server pressure but also potentially lead to the creation of a completely new layering 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 developments in technology and culture. From the consensus on fair distribution to the cultural renaissance of BTC, to the outbreak of scalability solutions based on layering, and finally the pursuit of more comprehensive expansion solutions, the Bitcoin ecosystem is rapidly evolving.

The first wave is the consensus process on fair distribution within the community. BRC20 has created a new type of asset entirely different from FT and NFT, which is a first-order innovation on the blockchain and represents the rise of the commoner culture.

We are currently experiencing the second wave, which is the cultural renaissance of BTC, with large funds and exchanges participating in the consensus. At the same time, more developers are joining the layering world, launching many excellent protocols that spill over to more chains. The BTC culture is dominating everything, which, of course, also brings about some other problems.

The third wave may be the outbreak of scalability solutions based on layering. The significant development in the second wave has promoted the prosperity of the BTC ecosystem, but the competition for BTC network resources has ultimately led to contradictions with BTC conservatives. At the same time, poor user experience hinders more users from entering the market. Therefore, the scalability of layering itself (rather than the scalability of BTC) is urgent and necessary. However, direct development of layering scalability 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 layerings of BTC with layering as the native asset (different from stx) and introduced into the main chain through cross-chain means.

The fourth wave represents the complete maturity of “BTC-based” expansion solutions, including full smart contract capabilities, better performance, and strong security shared with BTC. High-value layering assets will demand more security, and second-layer scalability solutions that are more native, more orthodox, and more secure become important. This requires the second layer to use the BTC chain as a DA layer, upload proof, and even allow the BTC network to verify it, such as BitVM and the AVM of Atomicals protocol. With strong orthodoxy guarantees, BTC will be more integrated into the layering ecosystem.

Ultimately, we will achieve an experience, performance, and smart contract functionality almost identical to ETH and its L2, but backed by the massive community and funds of BTC, while maintaining “fair distribution” as the core culture and layering as the native asset of the new ecosystem.

Challenges and opportunities coexist

The significant development of layering has promoted the prosperity of the BTC ecosystem but has also intensified the competition for BTC network resources. High transaction fees, along with the foreseeable rise in BTC’s value, continue to increase the entry barriers for players in the BTC ecosystem. This has led to more discussions on Bitcoin’s scalability solutions, attracting attention from both the community and investors. Of course, people tacitly avoid direct upgrades to BTC L1 for scalability solutions. The most radical discussions revolve around unlocking some OP scripts and continuing to explore BTC’s remaining potential under Taproot (such as discussions on CTV and CAT).

With the development and theoretical achievements of Rollup and modularization in Ethereum, BTC Layer2 has become the mainstream topic of scalability discussions and the fastest effective solution. The first batch of projects is also expected to go live in the next two to three months, becoming the absolute mainstream narrative for speculation. Due to the highly decentralized governance of BTC, without a “church” guiding the community, its L2 design is also diverse. This article will explore the possibilities of Bitcoin scalability from the perspective of typical BTC L2 projects and related protocols in the market.

Here, I categorize BTC L2 into sidechains, Rollups, DA layers, decentralized indexing, and other methods, grouping similar projects together for explanation. Since no one has the authority to define BTC’s scalability solutions, my classification may not be rigorous.

This article focuses on exploring from the perspective of implementation solutions, and many designs are still in the conceptual stage. In the competition for second-layer assets, the project’s floor is determined by technology and security. Technology is the ticket, and there may be first-class, economy class, or even stand-by tickets. However, from the perspective of assets, one is the ability of L2 itself to create assets, whether by introducing layering or by its own creation, which cannot be evaluated solely from a technical perspective. Second, whether it can attract deposits of L1 BTC will be the core competitiveness, which highly values the security of bridging, as “not my keys, not my Bitcoins” is a core doctrine, closely related to the design of the solution.

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

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

1. Schnorr signatures introduce a multi-signature method for BTC with up to 1000 participants, which forms the foundation for many L2 bridges.
2. MAST allows the combination of multiple UTXO scripts through Merkle trees, enabling more complex logic, which provides possibilities for proof systems on L2.
3. Tapscript upgrades Bitcoin scripts, allowing verification of a series of scripts to determine whether UTXOs can be spent, which provides possibilities for operations such as withdrawals and penalties on L2.

2. BTC L2 Technical Overview

Side chain

Through the creation of chains parallel to the main chain to achieve scalability, sidechains can have their own consensus mechanism and block generation rules, enabling asset interoperability with the BTC main chain through cross-chain bridges. Everything is for usability, and usability is everything. The advantage of sidechains lies in their quick effectiveness, focusing primarily on rapid business logic development. Their security is primarily related to their own network and is akin to a “ticket” attached to the security train of BTC. The most important part is the cross-chain bridge of BTC, which is the only connection point.

1.@BTClayer2 BEVM

In fact, most BTC L2 solutions, such as BEVM, follow the sidechain approach in Ethereum’s scalability. BEVM deploys a multisig address on BTC’s L1 through Taproot capabilities and runs an EVM sidechain. Smart contracts accepting BTC withdrawal requests are deployed in the EVM. BEVM uses GAS on the BTC sidechain. During recharge, the bridge operator synchronizes BTC data and notifies the sidechain. BEVM nodes also run light clients to synchronize BTC block headers to verify recharges. During withdrawal, the bridge custodian signs and, after collecting a certain number of signatures (threshold), initiates the BTC withdrawal transaction. This achieves asset interoperability between sidechains and BTC.

Unlike traditional $RSK $STX solutions, BEVM uses Taproot’s BTC multisig to implement threshold signatures. The bridge operator theoretically can have more, which adds a certain fault tolerance and decentralization to BTC cross-chain. However, BEVM does not utilize any security guarantees of BTC but only achieves asset interoperability with BTC. Its nodes run their own internal consensus and EVM and do not upload proof to the BTC network, so there is no L1 DA. The network’s transaction censorship-resistance relies on the network itself, so if nodes refuse to package your BTC withdrawal transactions, you will not be able to retrieve BTC from L1, which is a potential risk.

The benefit of this approach is its ability to be quickly implemented and verified, and the Taproot multisig implemented by BEVM further enhances the security of the bridge. It is one of the few BTC sidechains currently online.

1. @MapProtocol Map Orange

Map is also an EVM-based textual sidechain that chooses to cross-chain BTC L1’s BRC20 to EVM to run some low-cost businesses. Map runs an enhanced BRC20 indexer. Users who cross-chain BRC20 from BTC need to send new transactions and insert information such as the target chain and address in Json, which is then indexed by Map and appears on the sidechain. Withdrawals of BRC20 are initiated by multisig BTC transactions under the Map Pos mechanism’s signing committee. The ledger of BRC20 actually runs in the index, and BTC L1 is essentially its available data source.

Using the lower fees of sidechains, Map runs the BRC20 Mint tool LessGas and the textual market SATSAT, and performs BRC20 cross-chain via Roup. The approach centered around the text is quite distinctive and has attracted a group of users. Map uses the classic PoS consensus mechanism and uploads checkpoint data to BTC L1 to enhance its security and prevent long-range attacks.

1. @BitmapTech Merlin Chain

A sidechain for BTC released by BRC420. Merlin Chain chooses to use the MPC scheme from Cobo wallet to achieve cross-chain interoperability with BTC, which seems to be a relatively conservative choice: the number of signers in MPC is relatively small, and there is still some gap in security compared to the BTC multisig after the Taproot upgrade, but fortunately, MPC has been well-verified.

Merlin uses ParticleNtwrk’s account abstraction, allowing continued interaction between Bitcoin wallets and addresses with the sidechain without changing user habits, which is commendable. In comparison, designing interactions for Bitcoin users to return to Metamask seems lazy and rudimentary.

With high popularity for BRC420 and Bitmap, Merlin continues to develop business around text and supports the cross-chain of various textual assets from L1, while also providing inscription services for new texts on the sidechain.

1. @dfinity ckBTC

ckBTC is a cross-chain integration of BTC implemented through pure cryptographic schemes within ICP, without relying on any third-party bridges or custodians. 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’s threshold signature allows the entire ICP network to collectively manage a threshold signature address for BTC, accepting BTC and controlling the BTC under this address through aggregate signatures under consensus, enabling withdrawals. ICP also reconstructs all BTC UTXOs using an account model within its network, and smart contracts in the network can read the state of BTC, effectively running full BTC nodes within the ICP network.

Since 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 the BTC network, without introducing additional third-party trust assumptions. Therefore, the ChainKey threshold signature scheme used by ckBTC within the ICP network 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, as an independent L1, the security of ICP is guaranteed by itself and has no relationship with BTC.

DA layer

The DA layer aims to leverage the security of BTC while increasing processing power by storing data on the BTC chain but outsourcing calculations to off-chain or other chain processing.

BTC is the most stable trusted data source in the world, so using Bitcoin as a source of trusted data becomes very natural. Likewise, there is (@CelestiaOrg) the theoretical basis of DA, although BTC data storage is very expensive, it also has a consensus basis as the DA layer. In essence, Ordinals and the entire Inscription ecosystem actually use BTC as DA. Almost all “BTC L2” will transmit data to BTC, but this is more like a formalism and represents a beautiful vision. Below are some of the more distinctive designs.

1. @nubit_org Nubit

Nubit is a DA protocol that expands data availability scenarios for BTC. It has attracted attention because of the participation of Bounce Finance and domo in its financing. Simply put, Nubit organizes a DA chain similar to Celestia by running POS consensus, and regularly uploads Nubit’s own DA data such as block headers, transaction Merkle tree roots, etc. to BTC L1. In this way, Nubit itself saves its DA by BTC L1, and Nubit sells the storage space on its own chain as DA to users and other Rollup chains (DA nesting dolls). Nubit itself does not have smart contract capabilities and needs to be built with Rollup based on its DA. Users upload data to the DA layer of Nubit itself. After these data are confirmed by Nubit’s POS consensus, they enter the “soft confirmation” state. Later, Nubit will upload the chain’s data root to BTC L1 after a period of time. Once the BTC transaction is completed, the data initially uploaded to Nubit by the user will enter the final confirmation state. After this, users need to upload the data label again in BTC L1, which is used to query the original data in the Merkle tree of Nubit’s full nodes.

The early Pos consensus of the Nubit network was supported by Babylon’s BTC POS staking (to be introduced below). Users pay storage fees with BTC, for which Nubit uses the Lightning Network to accept BTC. There are no bridge issues with state channels, and users can withdraw funds urgently by closing the channel without needing to transact with Nubit’s Pos network itself. It seems that Nubit is a Bitcoin ecosystem version of Celestia, without adding complex smart contract functionality, and also uses the Lightning Network for BTC payments in a relatively simple manner. Although the Lightning Network is sufficiently trustless, the user experience is not good enough to support large capital inflows and outflows (state channel depletion issues). The relationship between Nubit and the Bitcoin layer is relatively thin, as the security of the chain itself is not guaranteed by BTC, and the data on BTC is only verified by Nubit’s node client.

Why do Rollup and encrypted data need to be packaged in a layer of Nubit instead of being uploaded directly to BTC? This may be the question Nubit needs to answer most, as low fees may not be the core driver. Relative to the biggest advantage of BTC DA, perhaps Nubit’s DA support for light node sampling verification (DAS) is the key. This is something that the BTC network cannot achieve, meaning that verifying DA no longer requires users to download the full nodes of BTC. Can Rollup, which is no longer fully-on-Bitcoin, still gain community consensus? Nubit is attempting to use its own chain’s DA to replace BTC L1 chain’s DA, facing not only technical challenges but also significant community consensus challenges. Of course, this is also a huge opportunity.

1. @Veda_bitcoin Veda

The Veda protocol reads specific Ordinals burned on BTC L1 and uses them as transaction requests to be executed in the EVM off the BTC chain. The user signs an EVM-compliant transaction on BTC L1 with the BTC private key, and then mints it as an inscription on BTC. Veda’s EVM node will scan the BTC block. Once the transaction is confirmed by BTC, the EVM will execute the request and produce a state change. In effect, this is treating BTC as a pending transaction pool for Veda EVM. However, because the performance of BTC is much lower than that of ETH’s EVM, and the data written to BTC blocks is limited within a certain period of time, Veda EVM must be able to execute all EVM requests uploaded to BTC.

BTC is the data source for all Veda states. Anyone can restore the complete state of the EVM by scanning Veda requests in all BTC blocks. Veda EVM can therefore be trusted optimistically without any complex security assumptions. However, Veda cannot scale the performance of BTC. Veda can be thought of as an Ethereum network with a block interval of 10 minutes and a TPS of 5, but with tens of thousands of nodes and huge POW computing power. It simply expands the functionality of BTC and adds smart contract capabilities. This does not essentially solve the problem of resource competition.

1. @babylon_chain Babylon

Babylon is a set of protocols that help other blockchains share the security of BTC. This includes two parts, the Bitcoin staking service and the Bitcoin timestamp service. Babylon allows staking BTC to provide economical security for the PoS chain (similar to ETH’s restake). The staking process is completely run cryptographically and does not require any third-party bridges and custodians.

BTC stakers can stake by sending a transaction on the BTC chain with two UTXO outputs. The first UTXO contains a time-locked script, allowing the staker to unlock BTC with their private key after expiration. The second UTXO is transferred to a temporary Bitcoin address with a public-private key pair that satisfies the cryptographic standard of “Extractable One-Time Signatures (EOTS).” When a BTC staker (also a validator of the POS chain) runs a node of the POS chain and verifies the only valid block, they sign it with the EOTS private key.

If the staker (also the validator of the POS chain) remains honest and only signs one valid block each time, they will receive rewards as a validator of the POS chain. However, if they attempt malicious behavior by signing two blocks at the same block height, their EOTS private key will be revealed, allowing anyone to use it to transfer the staked BTC on the BTC chain, resulting in penalties. This mechanism incentivizes stakers to remain honest. Babylon also provides BTC timestamping services, uploading checkpoint data of any blockchain to BTC’s op_return to enhance security.

Nubit, mentioned earlier, plans to use Babylon’s BTC staking service to enhance security. Babylon’s use of pure cryptography in handling BTC access and penalties ensures high security. However, from an economic perspective, this imposes constraints on chains using staking services, and compared to methods like ETH’s Rollup, there is still some distance in verifiability. While timestamping services upload L2 data to BTC, directly verifying all BTC blocks requires downloading the entire node, which poses a high threshold. Additionally, BTC L1 lacks smart contracts and cannot verify the correctness of this data.

Rollup

Rollup utilizes the BTC data layer to store state and transaction data but processes computations and state changes off-chain. It ensures security by submitting proofs or data changes back to the BTC main chain.

The core issue with 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 indeed ensures its immutability, but it does not guarantee the validity and correctness of internal Rollup transactions. Most BTC Rollups may choose the sovereignty rollup (client-side verification) approach, where validators sync all Rollup data off-chain and independently verify it. However, this approach fails to leverage Bitcoin’s strongest capability, the POW consensus of hundreds of thousands of nodes, to secure Rollup. The ideal scenario would be for the BTC network to actively verify Rollup proofs, similar to Ethereum, and reject invalid block data. At the same time, it should ensure that assets in Rollup can be withdrawn to the BTC network in the most extreme circumstances, even if Rollup nodes/sorters are consistently down or refuse to accept transactions, ensuring secure exit channels are available. For Bitcoin, which lacks smart contracts and only has script execution, perhaps leveraging the capabilities of MAST to combine scripts into logical circuits for verification is possible, although it is challenging, it belongs to the most native thinking of Bitcoin.

1. @ZeroSync BitVM

BitVM is the most anticipated expansion protocol on BTC and is 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 (as a bet), and the output of this transaction will contain a logical circuit. BTC’s script can be seen as processing the simplest logic gates, which are the most 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 (you can imagine a computer in The Three-Body Problem by Cixin Liu).

BitVM writes a fraudulent proof into a circuit composed of a large number of BTC scripts. The structure of this proof circuit is determined by a series of nodes packaged by sorters in Rollup. Challengers can continuously upload hash values to this fraudulent proof circuit, and validators continuously run corresponding scripts and reveal outputs to confirm their correctness. Under a series of transactions, challengers can continuously challenge the prover until the prover confirms that each circuit gate is correct. Thus, the BTC network completes the verification of Rollup, and the prover can claim their funds. Otherwise, the challenger will receive the BTC staked by the prover. In an easily understandable analogy, 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, incurring significant costs, and requires a considerable amount of pre-signing before both parties participate in on-chain verification, which involves a substantial amount of off-chain computation.

Of course, unlike Optimistic/ZK Rollup on ETH, BitVM does not have an emergency BTC withdrawal channel, requiring at least one honest node in the L2 network to facilitate a normal exit. Nevertheless, this currently represents the highest level of security assurance achievable for BTC L2 networks, with DA uploaded, BTC L1 validating the effectiveness of Rollup data, and a trust-minimized BTC bridge, lacking only an “emergency escape route”. Therefore, while BitVM’s implementation may seem distant, recent discussions in the BTC community about unlocking the op_cat script may bring new possibilities to BitVM’s development. The op_cat 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 in the same script, allowing it 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, who have proposed new approaches to “fraudulent proof” challenges on BTC based on this concept.

1. @Bison_Labs Bison Network

Bison Network is a Bitcoin-based ZK-STARK sovereign Rollup (client verification). In a sovereign Rollup, L1 is used as the block data availability board (DA) for Rollup, without verifying whether Rollup transactions are correct; Rollup transactions are verified by Rollup’s own nodes. Bison submits the ZK proof of Rollup to BTC Ordinals, and users can download the proof from BTC and run their own clients to verify Rollup transactions. To verify the entire state of Rollup, syncing the entire node is required.

Bison’s uniqueness lies in its implementation with the BTC L1 bridge. When a user deposits BTC into Bison Rollup, the BTC is divided into multiple multisig wallets containing BTC. These multisig wallets all support Discreet Log Contracts (DLC), a technology based on the Taproot upgrade that uses BTC multisig and time-locked scripts for simple smart contracts. When users deposit BTC, they need to sign relevant execution transactions for all future scenarios with Bison Network, such as: a. transfer to others; b. withdrawal back to BTC mainnet; c. scenarios where no one withdraws for a long time. After signing, these transactions are not published to the BTC blockchain. If transactions need to be executed, an oracle is required. There are three controllers for the multisig wallet: the user, Bison Rollup, and the oracle. With any two signatures among them, control of the BTC can be obtained.

DLC is like an if-do statement on Bitcoin, where the oracle inputs the condition for “if” and the execution part is sending transactions signed for the three scenarios mentioned above. Here, the oracle is linked to Bison Rollup’s bridge contract. If the bridge receives a user request to transfer BTC to someone else, the oracle sends the transaction signed for scenario to transfer to others, transferring control of the multisig address to the Bison network for further distribution. If the bridge receives a user request to withdraw back to the BTC mainnet, control is transferred to the user. If there is no activity for a long time, the time lock expires, and control returns to the user. Thus, Bison implements a simple escape route for extracting BTC from Rollup. However, the weakness in this system lies in the oracle. If incorrect information is transmitted, it can lead to loss of user assets, so it may be worth considering introducing decentralization, such as Chainlink. The “trustless bridge” realized by DLC is an exploration of the potential of BTC scripts, and http://DLC.link uses it to bridge BTC to chains such as ETH and STX. Although Bison Rollup implements a simple “escape route” by introducing a new third party, it still does not verify Rollup proofs on the BTC L1.

1. @BsquaredNetwork B² Network

The B² Network is a ZK Rollup on BTC that incorporates “fraud proof challenges.” The network is divided into two layers: the Rollup layer and the DA layer. The Rollup layer utilizes zkEVM to execute smart contract logic, including transaction acceptance, sorting, and packaging, producing ZK proofs, supporting BTC address accounting abstraction, and synchronously reading BTC L1 data (BTC and BRC20 balances). The DA layer provides data storage for Rollup, with storage nodes performing zk verification of Rollup transactions off-chain. After verification, DA layer nodes write Rollup data into BTC’s Ordinals ledger, including the Rollup data’s position in the DA layer, the Merkle root of transactions, ZK proof data, and the hash of the previous BTC proof ledger.

Verification of proofs is critical. In ETH, bridging contracts directly verify ZK proofs on L1, but BTC lacks smart contract functionality. Due to the complexity of ZK verification logic, it’s not feasible to implement verification logic circuits by combining BTC scripts (costly and may exceed BTC block limits). Therefore, B² introduces more off-chain calculations in verification, transforming L1 verification of ZK into a “fraud proof challenge” similar to Optimistic. B² decomposes ZK proofs into different scripts, overlaying these scripts to form a Mast binary tree. B² nodes send BTC through this transaction as rewards for fraud challenges.

Once transactions containing “fraud proof challenges” are confirmed on BTC L1, challengers can download original data from the DA layer and execute the above scripts off-chain. If the final output differs from what B² nodes submitted, indicating malicious behavior, challengers can gain control of BTC locked in the script root, and Rollup transactions will be rolled back. If no challenges occur within the locking period, nodes can retrieve the locked BTC, achieving final confirmation for Rollup.

In the B² Network, the first BTC transaction confirms the tamper-proof nature of ZK proofs. Although BTC cannot directly verify ZK transactions, by implementing “fraud proof challenges” in the second transaction, indirect L1 verification is achieved, ensuring the validity of transactions under Rollup, thereby enhancing security, which is indeed an innovative approach. B² Network also introduces account abstraction, allowing users to interact directly with BTC wallets and Rollup without changing user habits, which is commendable. However, for extracting BTC assets from L2, the multisig address bridge approach is still used without introducing an “escape route.”

1. @SatoshiVM SatoshiVM

SatoshiVM is also a BTC-based ZK Rollup, similar to the logic of B² Network. After generating ZK proofs within Rollup, the prover uploads proof data to the BTC network and sends a “fraud proof challenge” containing BTC. Successful challengers receive BTC rewards. The difference is that SatoshiVM adds two time locks in the “fraud proof challenge,” corresponding to the start and end of the challenge, allowing verification of the correctness and effectiveness of ZK proofs by comparing how many blocks BTC transfers have waited. The cross-chain bridge part mainly uses a multisig scheme without any highlights.

1. @chainway_xyz Chainway

Chainway is a BTC ZK sovereign Rollup that not only uses Bitcoin as the data publishing layer but also uses BTC data as the source for generating ZK proofs. Chainway’s provers need to scan every BTC block without omission. By reading block headers, the previous zk proof, and “forced transactions” inscribed in blocks, a complete ZK proof can be generated. In each BTC block, Chainway submits a transaction inscribing ZK proof, forming a recursive proof.

In the BTC block, the “forced transaction” inscribed in the form of Ordinals inscription is the “censorship-resistant transaction sending method” set by Chainway. If the Chainway Rollup node goes down, or continues to refuse to accept withdrawal transactions from users, users can inscribe the withdrawal request directly into the Bitcoin block. Nodes must include these “forced transactions” into Rollup blocks, otherwise the constraints of the ZK circuit will not be satisfied and proof generation will fail.

In the latest tweet, Chainway claims to be inspired by BitVM. They have found a way to verify ZK proof on Bitcoin to achieve settlement of BTC L1. Obviously, the current design of Chainway is based on client-side local verification of sovereign rollups. Although “forced transactions” solve the problem of anti-node censorship of Rollup transactions to a certain extent, it still cannot achieve true BTC L1 asset settlement.

1. @QEDProtocol QED Protocol

QED Protocol is a ZK rollup on BTC, running on zkEVM. Unlike other ZK Rollups, QED does not choose to generate ZK proof for the entire Rollup transaction, but only creates ZK proof for the withdrawal transaction from the Rollup to BTC L1. Similar to BitVM’s idea, QED Protocol organizes scripts into logical circuits to verify the ZK proof of withdrawal transactions on BTC L1. This type of logical circuit will contain 1,000 UTXOs. Although direct verification is achieved, the cost is huge.

3. Inscription L2 - Rethinking BTC Scaling

After experiencing the tumultuous wave of new asset distribution, the main narrative of inscription has been established, and we are about to face new opportunities and challenges. Simply relying on fair distribution or meme narratives seems to be a hurdle at a total market value of 200 million, and without continued solid construction, it is difficult for Inscription to break through (the end of fair distribution is PUA). In the process of returning to rationality, utility becomes even more important, either providing more capabilities or being treated as underlying assets.

Sidechains based on inscription may become an important step next. They are called sidechains rather than L2 because these “L2” do not utilize the security of BTC. But this is like Polygon to ETH, inscription L2 can effectively reduce the threshold for users to enter inscription and compromise with BTC conservatives. Most importantly, full smart contract capabilities will introduce more gameplay for inscription, including DeFi, SocialFi, GameFi, and more.

BRC20 and its derivatives choose to write token information in human-readable JSON, which has the advantage of extreme flexibility, allowing Memo to be split into any number under the “amt” field. This flexibility is very suitable for interacting with inscription Layer2, as long as the Layer2 reads JSON and restores the BRC20 state, subsequent DeFi and other businesses are easy to develop. 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 itself. If inscription L2 only splits inscription into FT after cross-chain transfer, and then replicates Ethereum DeFi gameplay, it will lack attractiveness because trading FTs is already low in cost-effectiveness for current traders. The indexing of BRC20 is the ledger itself. After reading the index, create an EVM chain to continue inscription’s attributes and continuously introduce a large number of innovative paradigm applications that are distinct from FT DeFi.

Programming for indexers

Will BRC20 and its Json inscription side chain definitely continue the ETH model? Actually, EVM sounds very boring, we don’t need to reinvent a series of L2s. But perhaps, it would be more interesting to think about the scaling of functions and business based on the native attributes of inscriptions.

BRC20 is a token system that is recorded on the chain and processed off-chain, using BTC as storage. Therefore, this type of scaling may be achieved by adding more business logic to the off-chain index server. For example, directly introduce new primitives in addition to “mint”, “deploy”, and “transfer” under the “op” field of Json to perform operations such as pending orders, mortgages, burning, and authorization. The combination of these “op” can further Inscription-Fi (Inscription Finance) such as swap and lending has evolved, and even more complex SocialFi and GameFi have evolved. This is essentially indexer-oriented programming, which is more like programming the server interface in Web2. It is less difficult to implement and you can even start directly from an index server, but the effect is very significant. Currently, UniSat’s swap and other functions, including BRC100, ORC20, and Tap protocols, are the forerunners of this type of Json scaling genre, and have the opportunity to bring about changes quickly. The attempt to add encryption primitives is exciting. Of course, decentralization is an issue that always needs to be considered. Indexer-oriented programming will inevitably lead to increasing pressure on the server and make it more difficult for the community to run; complex businesses must also require the same consensus, which will eventually lead to the development of smart contract platforms. So, if the ledger in the indexer is decentralized, can an inscription chain be innovated?

Actually, the follow-up business launched by @unisat_wallet based on $sats is based on this idea. Swap and pool are implemented in its indexer. If you want to gain a consensus on fund security, decentralization is an inevitable process. There are also types like @RoochNetwork, which do not acquire assets from L1 at all, but only run indexes and BTC full nodes, providing data for their on-chain smart contracts to use in a read-only L2 manner.

An idea apt to a more native way

The issuance method of BTC Layer 1 actually falls into two main schools. In addition to the Json-based approach mentioned above, there is the unique UTXO-based approach of Atomicals (the definition of Rune is still relatively vague, and we’ll not discuss it here). Atomicals’ ARC20 tokens are directly represented by BTC’s UTXO itself, without Json updates. Therefore, operations directly based on UTXOs enable ARC20 tokens to achieve many interesting capabilities, such as swapping between Arc20 tokens and BTC, consuming Arc20 tokens to produce another type of Arc20 token, and so on. Control over transaction inputs and outputs can also achieve simple DeFi functions, but this imposes higher requirements and greater difficulty on developers. The benefits are also very obvious—all logic is directly handled by the BTC network, sharing the maximum security and consensus. At the same time, it can seamlessly absorb BTC assets, albeit relying on third-party BTC bridges like sidechains. After all, “not your keys, not your coins.”

Clearly, ARC20 itself is not Turing complete. Therefore, after incorporating the design ideas of Bitvm, the Atomicals protocol also proposes the AVM Bitcoin Layer 2 solution. This is a Layer 2 solution where proofs are submitted to the BTC network Layer 1 and verified by BTC script circuit logic. ARC20, as an asset represented by UTXOs, naturally lends itself to being used as collateral for fraud proofs in the AVM Layer 2. This will be the ultimate narrative of BTC scalability: the ability to implement smart contracts while sharing the security of BTC DA. This may be the L2 that will be truly implemented in the fourth wave, but Atomicals’ development service provider, @wizzwallet, seems to have provided some information on AVM in their recent updates, suggesting progress may be faster than imagined.

4. Conclusion and outlook

The industry is ever-changing, with new BTC Layer 2 solutions emerging every second, but the inevitable trend remains the development of the BTC ecosystem towards Layer 2. BTC is like a train everyone wants to board. In terms of solutions, sidechains are like passengers who bought tickets but only have contact with BTC through cross-chain bridges, yet they can be used earliest. Projects of the DA type attempt to establish BTC versions of Celestia and Eigenlayer, embellishing their gimmicks, with opportunities existing under modular consensus. Meanwhile, Rollups upload DAs and use BTC scripts to implement some simple mechanisms on the BTC chain (mostly borrowing from BitVM’s bit commitment approach), barely stepping into the carriage of BTC security. Who says Rollups relying on self-verification aren’t Rollups? (We all need to thank Celestia for its long-term contribution to sovereign Rollups.) The gems on the BTC L2 crown are the use of BTC script logic to verify proofs uploaded by Rollups. Currently, only BitVM and Atomicals’ AVM are attempting this, which is getting closer to the security relationship of ETH with its Rollups. It may seem far-fetched in terms of implementation, but the unlocking of new operators like op_cat seems to further accelerate its progress, and BitVM may be realized faster than everyone anticipates.

After an in-depth analysis and discussion of BTC Layer 2 technology, we realize that despite facing challenges, the future of the BTC ecosystem is full of infinite possibilities. From consensus on fair distribution to scalability solutions based on tokens, and then to fully mature scaling 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 enhance the scalability and efficiency of the BTC network but also introduce new asset types and transaction methods, opening up new opportunities for users and developers. However, achieving these goals successfully requires the collective efforts of the community in building consensus, maturing technologies, and verifying through practice. In the process of exploring the most effective Layer 2 solutions, security, decentralization, and optimizing user experience will remain paramount. Looking ahead, with technological advancements and community collaboration, BTC Layer 2 technology is poised to unlock new potential for the Bitcoin ecosystem, bringing more innovation and value to the cryptocurrency world.

Disclaimer：

1. This article is reprinted from [deep tide]. All copyrights belong to the original author [BlockPunk@Researcher of Trustless Labs]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.