The first ring of the bull market: BTC L2 will create the king of alpha

Author: blockpunk2077; Source: Twitter

As mentioned in the last long tweet, the great development of "Inscription" has promoted the prosperity of the BTC ecosystem, but it has also intensified the competition for BTC network resources, excessive fee costs, and the foreseeable future of BTC. The rise is also constantly increasing the entry threshold for BTC ecological players.

This prompted people to start discussing BTC's expansion plan, which also attracted the attention of the community and investors.

Of course, people have 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. Continue to explore 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 we roughly divide BTC L2 into side chains, rollup, DA layer, decentralized index, etc., and put together projects that I think are similar. No one has the authority to define BTC’s scaling plan yet, so my actual classification is not rigorous.

This article focuses on discussing 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 first class, economy class, or even register a ticket. If you want to speculate on assets, it only needs to reach a passing level.

But from an asset perspective, one is L2’s own ability to create assets, whether it is Introducing inscriptions or pulling the strings yourself cannot be evaluated from a technical perspective alone; secondly, whether it can attract L1’s BTC deposits will be its core competitiveness, which places great importance on the security of the bridge. After all, “not my keys not "my Bitcoins" is the core doctrine, which is very relevant in program design.

Will the adoption of the BTC ecosystem surpass ETH in the future? Maybe it can give you some reference.

First of all, we need to introduce the front-end technology, the two changes brought about by the Taproot upgrade:

< li>

Schnorr signature introduces a multi-signature method of up to 1,000 participants to BTC, which is the basis for the implementation of many L2 bridges;

• MAST allows a bunch of UTXO scripts to be combined through Merkle trees to implement more complex logic, which provides the possibility for L2 proof systems;

  < /li>

• Tapscript has upgraded the Bitcoin script to allow verification of a series of scripts to determine whether the UTXO can be spent, which facilitates L2 withdrawals, slashing and other operations. Possibility is provided.

Side chain

Everything is for usability. Use 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.

BEVM

In fact, most BTC L2 is like BEVM, continuing the expansion of ETH The idea of ​​mid-side chain.

BEVM deploys a multi-signature address on BTC's L1 through Taproot's capabilities, runs an EVM side chain, and is deployed in EVM to accept BTC withdrawal requests. smart contract. 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 to synchronize the BTC block header to verify the recharge; withdrawal When, the custodian of the bridge signs, and after a certain number of signatures are collected (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. In theory, there can be more bridge managers. This 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 transaction censorship resistance of the network relies on the network itself, so if the node refuses to package your BTC withdrawal transaction, you will no longer be able to obtain BTC from L1. This 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 and is currently one of the few online The BTC sidechain of the mainnet.

Map Portocol

Map is also an inscription side chain of the EVM architecture, choosing to use BTC L1's BRC20 cross-chains to EVM to run some low-cost services.

Map runs an enhanced BRC20 indexer. Users cross-chain Brc20 from BTC and need to send new transactions to insert the target chain, target address and other information in json. , thus being indexed by Map and appearing on the side chain; withdrawal of BRC20 is multi-signed by the signature committee under the Map Pos mechanism to initiate a BTC transaction.

BRC20’s ledger actually runs in 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. However, in addition to preventing long-range attacks, Map still does not have the security guarantees of using BTC, and there is no enhancement in censorship-resistant withdrawals, status change verification, and data reliability.

Merlin Chain

A side chain of BTC 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 MCP 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. This 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.

ckBTC

ckBTC is a cross-chain BTC that is implemented in ICP through a pure cryptography scheme. Chain integration and does not rely on any third-party bridge or hosting.

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 aggregated signature under consensus to achieve withdrawals.

ICP also uses the account model to restore all UTXOs of BTC in its own network. The smart contracts in the network can read the status of BTC, which is approximately equal to A BTC full node is run on 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 and does not introduce additional third parties. Three-party trust hypothesis.

Therefore, the ChainKey threshold signature scheme used by ckBTC's ICP is currently the safest 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.

Data availability

BTC is the most stable and trusted data source in the world, and there is no other One, therefore using Bitcoin as a source of trusted data becomes very natural.

Similarly, there is a theoretical basis for Celestia's DA. Although BTC's data storage is very expensive, it also has a consensus basis as a DA layer.

Essentially speaking, Ordinals and the entire Inscription ecosystem actually use BTC as DA. Almost all "BTC L2" will transmit data to BTC, but This is more of a formalism, representing a beautiful vision. Below are some of the more distinctive designs.

Nubit

Nubit is a DA protocol that extends data availability scenarios for BTC because of its The financing attracted attention due to the participation of Bounce Finance and domo.

Simply put, Nubit organizes a DA chain similar to Celestia by running POS consensus, and regularly updates Nubit's own DA data such as block headers and transaction defaults. Kerr tree roots, etc. are uploaded 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 matryoshka). 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 these data are confirmed by Nubit's POS consensus, they will enter the "soft confirmation" state, and Nubit will After a period of time, the data root of the chain is uploaded to BTC L1. After the BTC transaction is completed, the data uploaded by the initial user to Nubit will 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 pledge (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 seems to be a Bitcoin ecological version of Celestia, without adding complex smart contract functions, and it is also used for the most decentralized Lightning Network. BTC payment 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 light node sampling data verification (DAS), 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.

Veda

The Veda protocol reads the specific Ordinals burn on BTC L1 and uses it as Transaction requests are executed in the EVM off the BTC chain.

Users sign an EVM-compliant transaction with the BTC private key on BTC L1, and then cast 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 fact, this is using 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 just expands the functions of BTC and adds smart contract capabilities. This does not essentially solve the problem of resource competition.

Babylon

Babylon is a set of protocols that help other blockchains share the security of BTC , which covers two parts, the Bitcoin pledge service and the Bitcoin timestamp service.

Babylon allows to provide economical security for the PoS chain by pledging BTC (similar to ETH's restake). The staking process is completely run cryptographically and does not require Rely on any third-party bridge and custodian.

BTC pledgers can send a transaction with two UTXO outputs on BTC to realize the pledge. The first UTXO is written with a time lock script and expires Later pledgers can use their own private keys to unlock BTC; another UTXO is transferred to a temporary Bitcoin address, 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 checkpoint data of any blockchain to BTC's op_return, thereby increasing 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 staking 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

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.

The core problem of BTC Rollup is verification. 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 trustlessly extracted into the BTC network under the most extreme circumstances, even the nodes/ordering of Rollup Even if the server is down or refuses to accept transactions, it can still be taken out through the safe escape channel.

For BTC, which has no smart contracts and only script execution, it may be possible to use the ability of MAST to combine scripts into logical circuits to achieve verifiability, although it is difficult It is relatively high, but it is the most original idea of ​​BTC.

BitVM

BitVM is the most popular extension protocol on BTC and is a part of BTC. kind of optimistic rollup.

BitVM innovatively proposes a way to conduct fraud challenges on BTC. Both the prover and the challenger deposit the same amount of money in one transaction. BTC is gambled (as input), and the output of this transaction 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 human computer in the Three-Body Problem).

BitVM has written a fraud proof in a circuit composed of a large number of BTC scripts. This The circuit structure of the 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.

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 plans. 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. Only at least one honest node in the L2 network can Complete a 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, except for the lack of an "emergency escape channel."

So 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 can concatenate two strings, supporting a maximum 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. .

Bison Network

Bison Network is a ZK-STARK sovereign rollup based on Bitcoin (Client side verification).

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, and the Rollup transaction is used by Rollup itself. node verification.

Bison has submitted Rollup’s zk certificate to BTC Ordinals. Users can download the certificate from BTC and run their own client to verify Rollup transactions. If you need to verify the entire status of Rollup, you need to synchronize the full node.

Bison features the implementation of an 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: transfer to others and withdrawals Return to the BTC main network when no one withdraws it for a long time.

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 the if-do statement on Bitcoin. The oracle machine enters the if condition, and the execution part of do is to send the three types of signatures mentioned above. transaction under the circumstances.

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 be sent before sending. For signed transactions, the multi-signature address control rights are given to the Bison network for further distribution; if the user's request is received, it is sent and the control rights are transferred to the user; if no message is received for a long time, the time lock expires and the control rights return. user.

Thus, Bison has 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 is to tap the potential of BTC scripts, http://DLC.link Use it to transfer BTC across Used in 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.

B² Network

B² Network is a zk rollup on BTC mixed with "commitment challenge" . 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 proves Output, support the account abstraction of BTC addresses, and simultaneously read BTC L1 data (BTC and BRC20 balances).

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 the core. 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 in verification, directly verifying L1 versus ZK pairs, transforming it into a "fraud proof" similar to Optimistic "challenge. 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 evil. The challenger can obtain control of the BTC locked in the script root of the node and rollup the transaction at the same time. All will be rolled back.

If there is no challenge within the locking time, then the node can retrieve the locked BTC, and the Rollup obtains final confirmation.

In B² Network, the first transaction to send BTC confirmed that the zk certificate 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. The place. However, when withdrawing BTC assets from L2, the multi-signature address bridge method is still used and no "escape channel" is introduced.

SatoshiVM

SatoshiVM is also a ZK Rollup based on BTC, and its logic is similar to B² Network. After generating the zk proof in Rollup, the prover uploads the proof data to the BTC network and then sends a "fraud proof" challenge containing BTC. The successful challenger 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, so that by comparing BTC How many blocks have you waited for the transfer to occur? You can personally tell whether the ZK proof is correct and valid.

The cross-chain bridge part actually just uses a multi-signature solution and has no highlights.

Chainway

Chainway is a ZK sovereign rollup of BTC, not only using Bitcoin as The data publishing layer also uses BTC data as the source for producing ZK certificates.

Chainway's prover needs 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 "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 claimed to be inspired by BitVM and they have found a way to verify zk proofs on Bitcoin to achieve settlement of BTC L1.

Obviously, the current design of Chainway is based on client-side local verification of sovereign Rollup. Although "forced transactions" solve the problem of anti-node censorship of Rollup transactions to a certain extent, it still cannot achieve true settlement of BTC L1 assets.

QED Protocol

QED Protocol is a ZK rollup on BTC and runs based on zkevm. Unlike other zk rollups, QED does not choose to generate zk proof for the transactions of the entire rollup, but only creates ZK proof for the withdrawal transaction from the rollup to BTC L1.

Similar to BitVM's idea, QED Protocol organized scripts into logical circuits to verify the ZK proof of withdrawal transactions on BTC L1. This type of logic The circuit will contain 1000 UTXOs. Although direct verification is achieved, the cost is huge.

Index-oriented programming

If you trace the source, Brc20 is essentially a kind of BTC L2. All Brc20 transaction data are recorded on BTC, and the ledger actually runs in an off-chain indexer.

Although the current Brc20 ledger itself is completely centralized, we rarely worry about its security because the Ordinals of the BTC network cannot be tampered with. Anyone can scan all transaction records on the BTC network to recover the status of Brc20.

However, this expansion only adds new features to BTC and does not help expand its performance. 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 obtain funds Secure consensus and decentralization are inevitable processes.

There are also companies like @RoochNetwork that do not obtain assets from L1 at all, but only run indexes and BTC full nodes, and only read data for use by smart contracts on their chain. Read-only L2.

Finally

Of course, there are many projects that I have not introduced, partly because of their descriptions Unknown, partly because I have limited energy.

The industry is changing rapidly, and new BTC L2 is 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, sidechains are just passengers who have bought tickets. Chain bridges are related to BTC, but they can be used 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.

The rollups uploaded DA and used BTC scripts to implement some simple BTC on-chain mechanisms (mostly borrowing BitVM’s bit commitment ideas), reluctantly It can be said that one has half a foot in the carriage of Bitcoin security. Who says that a sovereign Rollup that relies on self-verification is not a Rollup? (You all need to thank Celestia for its long-term CX for sovereign Rollup)

The crown jewel of BTC L2 is to use BTC script logic to verify the proof of Rollup upload. Currently Only BitVM and #Atomicals' AVM are trying, which is infinitely close to the security relationship of ETH with its Rollup. 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.