Bitcoin Layer2: Expansion Plans, Challenges and Future Prospects

1 Introduction

With the growing growth of the Bitcoin network and the booming development of inscription technology, the BTC ecosystem is at a critical turning point. The market demand for expansion solutions is growing day by day, especially driven by inscription technology. The intensified competition for network resources and rising transaction costs have become urgent problems that need to be solved. This research report deeply explores the development prospects of Bitcoin L2 technology and its potential impact on the market, especially focusing on how to introduce BTC assets and improve security through L2 technology. We will analyze in detail the different implementations of BTC L2 technologies such as sidechains, rollups, DA layers (data availability layers), and how they attract the ability to deposit and create new assets in L1 BTC.

At the same time, after inscription technology has established a new wave of asset distribution, we are about to face new challenges and opportunities. The upper limit of market capitalization that can be achieved by relying on fair distribution or meme narratives highlights the urgency of further building to break through the ceiling. In this process, the provision of functions and the definition of underlying assets become more critical. The side chain based on Inscription not only lowers the entry barrier for users, but also introduces new gameplay methods such as DeFi, SocialFi, and GameFi to Inscription by providing complete smart contract capabilities. The concept of indexer-oriented programming proposes a new idea that starts from the native properties of the inscription itself and considers functional and business expansion. This can not only reduce the pressure on the server, but may also lead to the creation of a new inscription chain.

Four waves of impact

The Bitcoin ecosystem is undergoing a series of transformative shocks that not only define the community’s consensus process, but also drive substantial technological and cultural developments. From the consensus of fair distribution to the renaissance of BTC culture, to the explosion of "inscription-based" expansion plans, and ultimately the pursuit of more complete expansion plans, the Bitcoin ecosystem is in the midst of rapid evolution.

The first wave is the community consensus process on fair distribution. BRC20 creates a new type of asset that is completely different from FT and NFT. This is the first innovation on the blockchain and represents the rise of civilian culture.

We are experiencing the second wave, which is the renaissance of BTC culture. Big funds and exchanges are also participating in the consensus. At the same time, more developers have joined the Inscription World and launched many excellent protocols, which have spilled over to more chains. The culture of BTC is overwhelming, which of course raises some other questions.

The third wave may be the outbreak of "inscription-based" expansion plans. The second wave of great development promoted the prosperity of the BTC ecosystem, but competition for BTC network resources eventually led to conflicts with BTC conservatives. At the same time, poor user experience prevents more users from entering the market. Therefore, the expansion of Inscription itself (rather than the expansion of BTC) is urgent and necessary, but directly developing a second-layer expansion solution based on BTC (such as Bitvm) is difficult and time-consuming. Therefore, the compromise solution will be adopted first, and probably in the next six months, we will see a large number of new side chains of BTC that use inscriptions as their native assets (different from stx) and introduce main chain inscriptions through cross-chain and other methods.

The fourth wave represents the full maturity of the final "BTC-based" scaling solution, which includes complete smart contract capabilities, better performance, and strong security shared with BTC. High-value inscribed assets will put forward more requirements for security, and a more native, more orthodox, and safer second-layer expansion solution will become 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 BitVM and AVM of the Atomics protocol. Under the strong guarantee of legitimacy, BTC will be more drawn into the inscription ecology.

In the end, we will get almost the same experience, performance and smart contract functions as ETH and its L2, but backed by the huge community and funds of BTC, with "fair distribution" as the core culture and "inscription" as the native asset a new ecology.

Challenges and opportunities coexist

The great development of Inscription has promoted the prosperity of the BTC ecosystem, but it has also intensified the competition for BTC network resources. The excessive fee costs and the foreseeable rise of BTC in the future are also constantly increasing the entry barriers for players in the BTC ecosystem. This prompted people to discuss BTC’s expansion plan more and attracted the attention of the community and investors. Of course, people have very tacitly avoided the expansion plan of directly upgrading BTC L1. The most radical discussions are nothing more than lifting the seals of some OP scripts and continuing to tap the remaining potential of BTC under Taproot (such as the discussion between CTV and CAT).

In terms of the development and theoretical results of ETH's rollup and modularization, BTC Layer2 has become the mainstream of expansion discussions and is also the fastest-effective solution. The first batch of projects will also go online in the next two or three months and become the absolute mainstream narrative of hype. Due to the high degree of decentralization of BTC governance, there is no "church" to guide the community, so its L2 design is also flourishing. This article will start with the typical BTC L2 and related protocols on the market to get a glimpse of the possibility of BTC expansion.

Here, BTC L2 is roughly divided into side chains, rollup, DA layer, decentralized index, etc., and projects that I think are similar are explained together. No one has the authority to define BTC’s scaling plan yet, so my actual classification is not rigorous.

This article focuses on discussing it from the perspective of partial implementation solutions. Many designs are still in the paper stage. In the competition for second-tier assets, technology and security determine the lower limit of the project. Technology is a ticket, and it is possible to travel in first class, economy class or even registered tickets. But from the perspective of assets, one is L2’s ability to create assets, whether it is introducing inscriptions or pulling the market itself, which cannot be evaluated from a technical perspective alone; second, whether it can attract L1’s BTC deposits will be the core Competitiveness, which attaches great importance to the security of the bridge. After all, "not my keys not my Bitcoins" is the core doctrine, which is very relevant to the solution design.

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

Before launching the technical analysis of BTC L2, we first need to introduce the front-end technology and several changes brought about by the Taproot upgrade:

1. Schnorr signature introduces a multi-signature method for BTC with up to 1000 participants, which is the basis for many L2 bridges;

2. MAST allows multiple UTXO scripts to be combined through Merkle trees to implement more complex logic, which provides the possibility for L2 proof systems;

3. Tapscript upgrades Bitcoin scripts to allow verification of a series of scripts to determine whether UTXO can be spent, which provides the possibility for L2 withdrawals, slashing and other operations.

2. BTC L2 Technical Overview

side chain

Expansion is achieved by creating a chain parallel to the main chain. The side chain can have its own consensus mechanism and block generation rules, and implement asset interoperability with the BTC main chain through a cross-chain bridge.

Everything is for usability, and usability is everything. The advantage of side chains is that they are quick to produce results and focus on rapid development of business logic. Its security is basically only related to its network itself. It is the "ticket" on the BTC security train. The most important part is BTC's cross-chain bridge, which is the only connection point.

1. @BTClayer2 BEVM

In fact, most BTC L2, like BEVM, continues the idea of ​​sidechains in ETH expansion. BEVM deploys a multi-signature address on BTC's L1 through Taproot's capabilities and runs an EVM side chain, deploying smart contracts in EVM that accept BTC withdrawal requests. BEVM's GAS uses cross-chain BTC. When recharging, the operator of the bridge synchronizes BTC data and notifies the side chain. The BEVM node also runs a light client and synchronizes the BTC block header to verify the recharge; when withdrawing money, the custodian of the bridge signs, and after collecting a certain number of signatures ( threshold), the transaction to withdraw BTC will be issued. This enables asset interoperability between the side chain and BTC.

Different from the traditional $RSK $STX solution, BEVM uses Taproot's BTC multi-signature to implement threshold signatures. The bridge managers can theoretically be more, which adds a certain degree of fault tolerance to BTC cross-chain and makes it more decentralized. However, BEVM does not use any security guarantee of BTC and only realizes the interoperability of BTC assets. Its nodes run their own internal consensus and EVM and do not upload proofs in the BTC network, so there is no L1 DA. The network's transaction censorship-resistant properties rely on the network itself, so if a node refuses to package your BTC withdrawal transaction, you will no longer be able to obtain BTC from L1, which is a potential risk.

The advantage of this method is that it can be quickly implemented and verified. BEVM’s self-implemented Taproot multi-signature also goes a step further in the security of the bridge. It is currently one of the few BTC side chains online on the main network.

2. @MapProtocol Map Portocol

Map is also an inscription side chain of the EVM architecture. It chooses to cross-chain the BRC20 of BTC L1 to the EVM to run some low-cost businesses. Map runs an enhanced BRC20 indexer. When users cross-chain BRC20 from BTC, they need to send a new transaction to insert the target chain, target address and other information in Json, so that it is indexed by Map and appears on the side chain; when withdrawing BRC20, BTC transactions are initiated by the multi-signature signature committee under the Map Pos mechanism. BRC20’s ledger actually runs on an index, and BTC L1 is essentially its available data source.

Taking advantage of the lower fees of side chains, the Map chain runs BRC20’s Mint tool LessGas and the inscription market SATSAT, and performs BRC20 cross-chain through Roup. The idea of ​​​​taking inscriptions as the core is quite unique and 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.

3. @BitmapTech Merlin Chain

BTC sidechain released by BRC420. Merlin Chain chose to use the cobo wallet's MPC solution to implement BTC cross-chain, which seems to be a relatively conservative choice: MPC has a smaller number of signers, and compared to Taproot's upgraded BTC multi-signature, there are still some security issues There is a gap, but fortunately MPC has been proven for a long time.

Merlin uses ParticleNtwrk's account abstraction and can continue to use Bitcoin wallets and addresses to interact with side chains without changing user habits, which is worthy of praise. In comparison, if Bitcoin users return to Metamask for interaction, this design seems lazy and simple.

BRC420 and Bitmap are very popular and have accumulated a large user base. Merlin continues to develop business around inscriptions, supporting the cross-chain of diverse inscription assets from L1, and providing inscription services for new inscriptions on side chains.

4. @dfinity ckBTC

ckBTC is a cross-chain integration of BTC implemented in ICP through a pure cryptography solution and does not rely on any third-party bridge or custody. ICP is an independently operating L1 blockchain, and consensus is guaranteed by its unique BLS threshold signature scheme. The ChainKey technology bound to the threshold signature of the consensus algorithm allows the entire ICP network to jointly manage a BTC threshold signature address, accept BTC, and control the BTC under this address through the aggregate signature under consensus to achieve withdrawals. ICP also uses the account model to restore all UTXOs of BTC in its own network. Smart contracts in the network can read the status of BTC, which is approximately equivalent to running a BTC full node in the ICP network.

Since this threshold signature is directly strongly bound 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's ICP is currently the most secure BTC bridge idea. But for withdrawals, there is no way to force withdrawals from BTC L1 if the IC network goes down or refuses transactions. At the same time, as an independent L1, ICP's security is guaranteed by itself and has nothing to do 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. Similarly, with the theoretical basis of @CelestiaOrg's DA, although BTC's data storage is very expensive, it also has a consensus basis as a 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 Get married

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 Nubit's own DA layer. After the data is confirmed by Nubit's POS consensus, it will enter the "soft confirmation" state, and Nubit will upload the chain's data root to BTC L1 after a period of time, and the BTC transaction is completed. Only then will the data initially uploaded to Nubit by the user enter the final confirmation state. After this, users need to go to the BTC L1 tag to upload data, which is used to query the original data in the Merkle tree of the Nubit full node.

The Nubit network's PoS consensus was early supported by Babylon's BTC POS staking (to be introduced below). Users pay storage fees through BTC. For this reason, Nubit uses the Lightning Network to accept BTC. There is no bridge problem in the state channel. Users can make emergency withdrawals through the cancellation channel without the need to trade with Nubit's PoS network itself. It seems that Nubit is a Bitcoin ecological version of Celestia, without adding complex smart contract functions. It is also used for BTC payments on the most decentralized Lightning Network, which is relatively simple. Although the Lightning Network is trustworthy enough, the user experience is not good enough to support the entry and exit of large funds (state channel exhaustion problem). The relationship between Nubit and BTC is relatively weak. 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 inscription data need to be packaged in Nubit instead of directly uploaded to BTC? This may be the question that Nubit needs to answer most. Low cost may not be the core driver. The biggest advantage over BTC DA may be that Nubit's DA supports data sampling (DAS) for light nodes, which is not possible on the BTC network. This means that verifying DA no longer requires users to download the full node of BTC. Can inscriptions that are no longer fully-on-Bitcoin still gain community consensus? Nubit attempts to use the DA of its own chain to replace the DA of the BTC L1 chain. What it faces may not be technical doubts, but a huge challenge to community consensus. Of course, this is also a huge opportunity.

2. @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.

3. @babylon_chain Babylon

Babylon is a set of protocols that help other blockchains share the security of BTC. This includes two parts, the Bitcoin pledge 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 pledgers can send a transaction with two UTXO outputs on BTC to realize pledge. The first UTXO is written with a time lock script. After expiration, the pledger can use his own private key to unlock BTC; the other UTXO is transferred to A temporary Bitcoin address is obtained, and the public and private key pairs of this address meet the cryptographic standards of "Extractable One-time Signature EOTS". When a BTC staker runs a node of a POS chain, after verifying the only valid block, it signs it using the EOTS private key.

If the staker (who is also the validator of this POS chain) remains honest and only signs one valid block at a time, then it will receive the validator reward of the POS chain; if it tries to do evil and signs two at the same block height at the same time block, then its EOTS private key will be deduced, and anyone can use this private key to transfer the pledged BTC on the BTC chain to achieve forfeiture. This urges pledgers to remain honest. Babylon also provides a BTC timestamp service, which means uploading the checkpoint data of any blockchain to BTC's op_return to increase security.

Nubit, mentioned above, plans to use Babylon’s BTC staking service to enhance security. Babylon uses a pure cryptography solution to handle BTC deposits, withdrawals, and forfeitures, which is highly secure. But for chains that use pledge services, this is restricted at the economic level. Compared with ETH's Rollup method, there is still some distance in terms of verifiability. Although the timestamp service uploads L2 data to BTC, directly checking all BTC blocks requires downloading the full node, which has a high threshold. At the same time, BTC L1 does not have smart contracts and cannot verify the correctness of these data.

Rollup

Rollup utilizes BTC's data layer to store state and transaction data, but handles calculations and state changes off-chain, ensuring security by submitting proof or state change data back to the BTC main chain.

The core problem of BTC Rollup is verification. Through Ordinals, Bitcoin can store various data and become a highly secure database. Uploading Rollup's proof data to the BTC network does ensure that it cannot be tampered with, but this does not ensure the validity and correctness of Rollup's internal transactions. Most BTC Rollups may choose the sovereign rollup (client-side verification) method, where the verifier synchronizes all the rollup data off-chain and checks it on its own. But this cannot take advantage of Bitcoin's strongest capability, namely the POW consensus of hundreds of thousands of nodes, to ensure the security of Rollup. The most ideal situation is, of course, for the BTC network to actively verify the proof of Rollup, like ETH, and reject invalid block data. At the same time, it is also necessary to ensure that the assets in Rollup can be withdrawn to the BTC network trustlessly under the most extreme circumstances. Even if the node/orderer of Rollup has been down or refuses to accept transactions, it can still be withdrawn through a safe escape channel. For BTC, which does not have smart contracts and only executes scripts, it may be possible to use MAST's ability to combine scripts into logical circuits to achieve verifiability. Although it is difficult, it is the most native idea of ​​​​BTC.

1. @ZeroSync_ BitVM

BitVM is the most popular scaling protocol on BTC and is an Optimistic Rollup of BTC. BitVM innovatively proposes a way to conduct fraud challenges on BTC. The prover and the challenger both deposit the same amount of BTC in a transaction for betting (as input), and the transaction output will contain a logic circuit. BTC scripts can be seen as logic gates that process the simplest logic. Logic gates are the most basic components of computers. If logic gate circuits are combined with each other in a tree-like manner, they can form a circuit that contains specific logic (you can imagine Qin Shihuang's humanoid computer in the Three-Body Problem).

BitVM writes a fraud proof in a circuit composed of a large number of BTC scripts. The circuit structure of this proof is determined based on a series of nodes packed by the sequencer in Rollup. The challenger can continuously upload hash values ​​to this fraud proof circuit, and the verifier continuously runs the corresponding script and reveals the output to confirm that the result is correct. Under a series of transactions, the challenger can continue to challenge the prover until the prover confirms that each circuit gate is correct. As a result, the BTC network has completed the verification of the Rollup, and the prover can access his own funds. Otherwise, the challenger gets the BTC staked by the prover. To put it in an easy-to-understand way, the relationship between BitVM and BTC is like OP to the ETH network, and its security is the highest among all expansion solutions. The number of transactions that BitVM will generate is very large and costly, and a large number of pre-signatures are required before the two parties involved can conduct on-chain verification, which means a large amount of off-chain calculations are required.

Of course, unlike ETH's Optimistic/ZK Rollup, BitVM does not have an emergency BTC withdrawal channel. At least one honest node in the L2 network can complete the normal exit. However, this is already the highest security guarantee that BTC L2 can achieve at present. DA is uploaded, and BTC L1 verifies the validity of the Rollup data. The trust of the BTC bridge is minimized, but it lacks an "emergency escape channel." Therefore, the implementation of BitVM seems far away, but the recent discussion in the BTC community about unbanning the op_cat script may bring new possibilities to the development of BitVM. The op_cat opcode concatenates two strings up to a length of 520 bytes. This concatenation of data enables more complex calculations on Bitcoin. For example, BitVM can use it to connect hundreds of logic gates in series under the same script. This allows BitVM to process more binary circuits in fewer transactions, achieving almost a hundred-fold growth rate. BitVM's complex combination of Bitcoin scripts has also inspired many L2 projects, and based on this, they have proposed new ideas for "fraud proof" challenges on BTC.

2. @Bison_Labs Bison Network

Bison Network is a ZK-STARK sovereign rollup (client-side verification) based on Bitcoin. The so-called sovereign Rollup, that is, L1 is used as Rollup's block data announcement board (DA). It does not verify whether the Rollup transaction is correct. The Rollup transaction is verified by Rollup's own node. Bison submitted Rollup's ZK proof to BTC Ordinals. Users can download the proof from BTC and run their own clients to verify Rollup transactions. If you need to verify the entire status of Rollup, you need to synchronize the full node.

Bison features an implementation of the L1 bridge to BTC. When a user deposits BTC to Bison Rollup, the BTC will be divided into multiple multi-signature wallets that contain BTC. These multi-signature wallets all support DLC (Discreet Log Contracts). This technology is based on Taproot upgrade and is a simple logic contract that utilizes BTC multi-signature and time-locking scripts. When users deposit BTC, they need to work with the Bison network to sign relevant execution transactions for all future situations, such as: a. Transfer to others; b. Withdrawal back to the BTC main network; c. Long-term inactivity The situation of human extraction. After signing, these transactions will not be published into the BTC block. If the transaction wants to be executed, it needs an oracle to drive it. There are three controllers of the multi-signature wallet, namely the user, the Bison Rollup, and the oracle. If you obtain any two of the signatures, you can gain control of these BTC.

DLC is like an if-do statement on Bitcoin. The oracle machine inputs the conditions of the if, and the execution part of the do is to send the transactions signed in the above three situations. The oracle here is linked to the bridge contract of Bison Rollup. If the bridge receives the user's request to transfer BTC to others, the oracle will send the transaction signed in case a. Transfer to others, multi-signature address control rights to the Bison network for further distribution; if the user's request is received, b. In the case of withdrawal back to the BTC main network, control is transferred to the user; if no message is received for a long time, the time lock expires and control returns to the user . From this, Bison realized the withdrawal of BTC from Rollup and set up a simple escape channel. However, the weak point of the system here is the oracle machine. If wrong information is transmitted, the user's assets will be lost, so the introduction of decentralized parts, such as Chainlink, can be considered. The "trustless bridge" implemented by DLC taps into the potential of BTC scripts. http://DLC.link uses it to cross BTC to chains such as ETH and STX. Although Bison Rollup has achieved a simple "escape channel" by introducing a new third party, it still has not implemented the BTC L1 verification Rollup proof.

3. @BsquaredNetwork B² Network

B² Network is a ZK Rollup mixed with "Commitment Challenge" on BTC. The network is divided into two layers, Rollup layer and DA layer. The Rollup layer uses zkEVM to run smart contract logic. This layer contains multiple modules, including transaction acceptance, sorting and packaging, ZK proof output, account abstraction that supports BTC addresses, and synchronous reading of BTC L1 data ( BTC and BRC20 balance). The DA layer provides data storage for Rollup, and the storage node performs off-chain zk verification of Rollup transactions. After completing the verification, the DA layer node writes the Rollup data into the Ordinals inscription of BTC, which includes the position of the Rollup data in the DA layer, the Merkel tree root of the transaction, the ZK proof data, and the hash of the previous BTC proof inscription. .

Verification of proofs is central. In ETH, the bridge contract directly verifies the ZK proof on L1, but there is no smart contract function on BTC. Due to the complex logic of ZK verification, the verification logic circuit cannot be realized by combining BTC scripts (the cost is huge and may exceed the BTC block upper limit). Therefore, B² introduces more off-chain calculations into the verification, transforming the direct verification of L1 versus ZK into a "fraud proof" challenge similar to Optimistic. B² decomposes the proof of ZK into different scripts, and superimposes these scripts to form a Mast binary tree. The B² node sent BTC through this transaction as a reward for the fraud challenge.

Once the 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 script off-chain. If the final output of the execution is inconsistent with that submitted by the B² node, it means that the node is doing evil. The challenger can obtain control of the BTC locked in the script root of the node, and the rollup transaction will be rolled back. If there are no challenges within the locking time, then the node can retrieve the locked BTC and the Rollup gets final confirmation.

In B² Network, the first transaction to send BTC confirmed that the ZK proof cannot be tampered with. Although BTC still cannot verify the ZK transaction, by implementing the "Fraud Proof Challenge" in the second transaction, the L1 verification is indirectly completed, ensuring the validity of the transaction under Rollup and increasing security. This is indeed eye-catching. of innovation. B² Network has introduced account abstraction, allowing everyone to directly use BTC wallets to interact with Rollup without changing user habits, which is very commendable. However, when withdrawing BTC assets from L2, the multi-signature address bridge method is still used and no "escape channel" is introduced.

4. @SatoshiVM SatoshiVM

SatoshiVM is also a ZK Rollup based on BTC. Its logic is similar to B² Network. After generating the zk proof in the Rollup, the prover uploads the proof data to the BTC network and then sends a "fraud proof" challenge containing BTC. The challenge is successful. Those who win will be rewarded with BTC. The difference is that SatoshiVM added two time locks to the "Fraud Proof" challenge, corresponding to the challenge start time and the challenge end world. In this way, by comparing how many blocks the BTC transfer has waited for, the ZK proof can be distinguished personally. Is it correct and effective? Its cross-chain bridge part actually just uses a multi-signature solution and has no highlights.

5. @chainway_xyz Chainway

Chainway is a BTC ZK sovereign rollup that not only uses Bitcoin as the publishing layer for data, but also uses BTC data as the source for producing ZK proofs. Chainway's provers need to scan every BTC block without missing a beat. A complete ZK proof can be generated by reading the block header, the previous zk proof, and the "forced transaction" engraved in the block from the BTC block. In every BTC block, Chainway will submit a transaction that burns ZK proof, thus forming a recursive proof.

In the BTC block, the "forced transaction" engraved 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 engrave 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.

6. @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 expansion

After experiencing a magnificent 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, a total market value of 200 million seems to be a hurdle. If we do not continue to build steadily, it will be difficult to break through the ceiling (the end of fair distribution is PUA). In the process of returning to rationality, utility becomes more important, either providing more capabilities or being treated as an underlying asset.

“Inscription-based” side chains may become an important next step. The reason why they are called sidechains instead of L2 is because these "L2" do not use the security of BTC. But just like Polygon to ETH, Inscription L2 can effectively lower the threshold for users to enter Inscription and compromise with BTC conservatives. Most importantly, the complete smart contract capabilities will also introduce more gameplay methods to Inscription, such as DeFi, SocialFi, GameFi, etc.

BRC20 and its derivative inscriptions choose to write the token information in human-readable Json. The advantage of this is extremely high flexibility, and the inscription can be split into any number under the "amt" field. This flexibility is very suitable for interacting with the second layer of Inscription, because as long as the second layer reads Json and restores the BRC20 state, subsequent DeFi and other businesses are very easy to carry out. Inscription is a new type of asset that is different from NFT and FT. The business of Inscription L2 can also be developed around the inscription itself. Even the native assets themselves are best to use inscriptions. If Inscription L2 just cross-chains Inscription and splits it into FT, and then replicates the Ethereum DeFi gameplay, it will be unattractive, because for current traders, the cost-effectiveness of trading FT is already very low. The index book of BRC20 is the ledger. After reading the index, an EVM chain is created to continue the attributes of the inscription. And continue to launch a large number of innovative paradigm applications that are different 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 expansion 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 expansion 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, destruction, 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 expansion 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 consensus 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?

In fact, the follow-up business based on $sats launched by @unisat_wallet 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 read-only L2s like @RoochNetwork that do not obtain assets from L1 at all, but only run indexes and BTC full nodes by only reading data for use by smart contracts on their chain.

More original thinking

The issuance method of the first layer of BTC is actually divided into two major genres. In addition to the Json genre introduced above, it is the UTXO genre unique to Atomics (the definition of Rune is still vague, so we will not discuss it yet). Atomics' ARC20 token is directly represented by BTC's UTXO itself, without Json updates. Therefore, operations based directly on UTXO can enable arc20 tokens to achieve many interesting capabilities, such as realizing swap exchange and consumption between Arc20 tokens and BTC. Arc20 tokens yield another Arc20 token, and so on. Controlling transaction input and output can also implement simple DeFi functions, but this places higher requirements on developers and is more difficult. The benefits are also very obvious. All logic is processed directly by the BTC network, sharing maximum security and consensus. At the same time, BTC assets can be seamlessly absorbed, and you need to rely on a third-party BTC bridge like a side chain. After all, "not your keys not your coins".

Obviously, ARC20 itself is not Turing complete. Therefore, after absorbing the design ideas of Bitvm, the Atomics protocol also proposed AVM's Bitcoin second-layer solution. This is a proof that is submitted at the first layer of the BTC network and is verified by the BTC script. L2 as verified by circuit logic. As an asset represented by UTXO, ARC20 is naturally suitable to be used as collateral for AVM’s second-layer fraud proof. This will be the ultimate narrative of BTC scaling, the ability to implement smart contracts with shared security using BTC DA. This may be the fourth wave of L2 that will actually land, but @wizzwallet, the developer of Atomics, seems to have given some information about AVM in a recent update, and perhaps progress is faster than imagined.

4. Conclusion and outlook

The industry is changing rapidly, and new BTC L2s are born every second, but what remains unchanged is the inevitable trend of the BTC ecosystem developing towards the second layer. BTC is a train that everyone wants to get on. From a plan perspective, side chains are just passengers who bought tickets. They only use cross-chain bridges to connect with BTC, but they can be used at the earliest. DA-type projects are trying to build a BTC version of Celestia and Eigenlayer. They have enough gimmicks and there are opportunities under the broad consensus of modularity. By uploading DA and using BTC scripts to implement some simple BTC on-chain mechanisms (mostly borrowing from BitVM’s bit commitment ideas), Rollups have barely stepped into the BTC security compartment. Who says that a sovereign Rollup that relies on self-verification is not a Rollup? (You need to thank Celestia for its long-term CX for sovereign Rollup) The crown jewel of BTC L2 is the use of BTC script logic to verify the proof of Rollup upload. Currently, only BitVM and Atomicals' AVM are trying, which is infinitely close to ETH. Rollup's safe relationship. At present, it seems out of reach at the implementation level, but the unblocking of new operators such as op_cat seems to further accelerate its process. BitVM may be implemented faster than everyone expects.

After 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 the consensus of fair distribution to the inscription-based expansion plan, to the pursuit of a fully mature expansion plan that shares strong security with BTC, the Bitcoin ecosystem is undergoing historic changes. Not only are these technologies expected to significantly improve the scalability and efficiency of the BTC network, they will also introduce new asset types and transaction methods, opening up new opportunities for users and developers. However, successfully achieving these goals requires a concerted effort of community consensus, technical maturity, and practical validation. In the search for the most effective L2 solutions, security, decentralization, and optimizing user experience will remain top priorities. Looking to the future, with technological advancement and community collaboration, BTC L2 technology is expected to unleash new potential in the Bitcoin ecosystem and bring more innovation and value to the cryptocurrency world.