As mentioned in the last long tweet, the great development of "Inscription" has promoted the prosperity of the BTC ecosystem, but it has also enhanced competition for BTC network resources, high costs, and the foreseeable rise of BTC in the future, which has been increasing. The determination of BTC ecosystem players to enter.
This prompted people to start discussing BTC's expansion plan, which also attracted the attention of the community and investors.
Of course, people have very tacitly noticed 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 discussions on CTV and CAT).
In terms of the development and theoretical results of ETH rollup and upgrade, BTC Layer2 has become the mainstream of expansion discussions and the fastest effective solution. The National Project will also be launched in the next two or three months and will become the absolute mainstream narrative of hype.
Due to the high degree of centralization of BTC governance, there is no "church" to guide the community, so its L2 design is also flourishing. This article starts with the typical BTC L2 and related protocols to get a glimpse of the possibility of BTC expansion.
Here, BTC L2 is roughly divided into side chains, rollups, DA layers, decentralized indexes, etc., and I put together projects that I think are similar. BTC’s expansion plan still cannot be defined accordingly, and my actual classification is not rigorous.
This article focuses on the discussion from the perspective of partial implementation solutions. Many designs are still in the paper stage. In the competition for second-tier assets, technology and safety determine the lower limit of the project. Technology is tickets, first class, economy class and even tickets. It's all possible. If it's asset speculation, it just needs to reach a passing level.
But from the perspective of assets, one is L2’s ability to create assets, whether it is introducing inscriptions or pulling the market by itself, which cannot be evaluated from a technical perspective alone. Second, whether it can attract L1’s BTC deposits will be the core , in comparison, this attaches great importance to the security of the bridge. After all, "It's not my key, it's not my Bitcoin" is the core doctrine, which is very relevant to the solution design.
Will adoption of the BTC ecosystem surpass ETH in the future? Maybe I can give you some references.
First, we need to introduce the front-end technology, the two changes brought about by the Taproot upgrade:
Schnorr signature introduces a stake signing method for BTC with up to 1000 participants, which is the basis for many L2 bridges;
MAST allows a large number of UTXO scripts to be combined through Merkle trees to implement more complex logic, which provides the possibility for L2 proof systems;
Tapscript has upgraded the Bitcoin script to allow a series of verification scripts to determine whether the UTXO can be occupied, which provides the possibility for L2 withdrawals, slashing and other operations.
1 side chain
The advantage of side chains is that they are quick to produce results and are dominated by rapid development of business logic. Its security is basically only related to its network itself. It is a "ticket" on the BTC security train. The most important part is the cross-chain of BTC. The bridge is the only connection point.
BEVM
In fact, most BTC L2, like BEVM, extols the idea of sidechains in ETH expansion.
BEVM deploys a multi-label address on BTC's L1 through Taproot's capabilities, and runs an EVM side chain. A smart contract that accepts BTC withdrawal requests is deployed in EVM. 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 of withdrawing BTC can be issued, which realizes the asset interoperability between the side chain and BTC.
Different from traditional RSK and STX solutions, BEVM uses Taproot's BTC multi-signature to implement threshold signatures. The bridge manager theory can be more, which adds a certain fault tolerance to BTC cross-chain and makes it more decentralized.
However, BEVM does not use any security of BTC and only realizes the interoperability of BTC assets. Its nodes run their own internal public opinion 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 reserve 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. The Taproot multi-signature implemented by BEVM itself 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.
Map Protocol
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 bottom-level services.
Map runs an enhanced BRC20 indexer. Users cross-chain BRC20 from BTC and 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 issued by the signature committee under the Map Pos mechanism.
The BRC20 ledger actually runs on an index, and BTC L1 is essentially its available data source.
Taking advantage of the lower fees of side chains, BRC20's Mint tool LessGas and the inscription market SATSAT are run on the mapping chain, and BRC20's cross-chain is carried out through Roup. With inscription as the core idea, it 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. However, in addition to defending against long-range attacks, Map still does not use the security guarantees of BTC in terms of censorship-resistant withdrawals, status change verification, and data There is no enhancement in reliability.
BitmapTech Merlin Chain
For the BTC side chain released by BRC420, Merlin Chain chose to use the MPC solution of the Cobo wallet to realize the cross-chain of BTC. This seems to be a relatively conservative choice: the number of signers of MPC is very small, compared to the number of BTC after Taproot upgrade. There are still some gaps in security, but fortunately MPC has been proven for a long time.
Merlin uses Particle Network'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, allowing Bitcoin users to return to Metamask for interaction is This design is lazy and simplistic.
BRC420 and Bitmap are popular enough and have accumulated a large user base. Merlin continues to develop business around inscriptions, supports multiple inscription assets across L1 cross-chains, and provides inscription services for new inscriptions on side chains.
ckBTC
ckBTC is a pure cryptography solution in ICP that realizes cross-chain integration of BTC and does not rely on any third-party bridge or custody.
ICP is an independently operating L1 blockchain. The 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 and accept BTC. And through the aggregated signature under consensus, the BTC under this address is controlled to realize withdrawals.
ICP also uses the account model to copy all UTXOs of BTC in its own network. Smart contracts in the network can read the status of BTC, which is approximately equivalent to all nodes running BTC in the ICP network.
Since this threshold signature is directly strongly bound to the decision-making 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 safest BTC bridge idea. However, for withdrawals, if the IC network is down or refuses transactions, they cannot be forced to withdraw money from BTC L1. At the same time, , As an independent L1, ICP's security is guaranteed by itself and has nothing to do with BTC.
2. Data availability
BTC is the most solid trusted data source in the world, so it becomes very natural to use the source of Bitcoin’s trusted data.
Similarly, with the theoretical basis of Celestia's DA, BTC's data storage, although very expensive, also creates 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 before that it was a formalism, representing a beautiful vision, and some were more interesting. Featured design.
He is getting 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 stores its DA in 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 have a system based on its DA. rollup build.
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. After that, the data initially uploaded by the 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 PoS consensus of the Nubit network was initially supported by Babylon's BTC POS pledge (to be introduced below). Users pay storage fees through BTC, so Nubit uses the Lightning Network to accept BTC. There is no bridge problem in the state. Users can cancel the channel To make an emergency withdrawal, there is no need to transact with Nubit's PoS network itself.
It seems that Nubit is a Bitcoin ecological version of Celestia. It does not add complex smart contract functions. It is also used in the most decentralized Lightning Network for BTC payment. It is relatively simple. Although the Lightning Network is trustworthy enough, the user experience is poor. It is not good enough to support the entry and exit of large funds (state channel elderly problem).
The relationship between Nubit and BTC levels 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 go to the Nubit packaging layer instead of directly uploading to BTC? ? This may be the biggest question Nubit needs to answer, and its fees may not be a 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 Inscription, which is no longer entirely based on Bitcoin, still gain community consensus? Nubit's attempt to use its own chain's DA to replace the BTC L1 chain's DA may not face technical doubts, but a huge challenge to community consensus. Of course, this is also a huge opportunity.
VedaVeda
The VedaVeda protocol reads the specific Ordinals burning on BTC L1, uses it as a transaction request, and executes it in the EVM under the BTC chain. The user signs an EVM-compliant transaction on BTC L1 through the BTC private key, and then mints it on BTC. inscription.
Veda's EVM node will scan the BTC block. Once the transaction is confirmed by BTC, the EVM will execute the request and generate a state change. In fact, this is using BTC as Veda EVM's pending transaction pool.
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 of all Veda states. Anyone can recover the complete state of EVM by scanning Veda requests in all BTC blocks. Therefore, Veda EVM can be optimistically trusted without any complex security assumptions.
However, Veda cannot expand the performance of BTC. Veda can be regarded as an Ethereum network with a block interval of 10 minutes, TPS of 5, but with tens of thousands of nodes and huge POW computing power. It only expands the functions of BTC. , adding smart contract capabilities, which 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. This includes 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 need to rely on 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, and 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 the POS chain, after verifying the only valid block, he uses the EOTS private key to sign it. If the staker (who is also the verifier of this POS chain) remains honest, only one valid block will be signed at a time. block, then it will receive the validator reward of the POS chain. If it tries to do evil and signs two blocks at the same block height at the same time, then its EOTS private key will be deduced and anyone can use it. This private key is used to transfer the pledged BTC to the BTC chain and realize the forfeiture, thereby urging the pledger 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 above plans to use Babylon's BTC pledge service to enhance security. Babylon uses a pure cryptography solution to handle BTC deposits, withdrawals, and confiscations. The security is very high, but for chains that use pledge services , which is restricted at the economic level, and 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.
Three Rollup
Through Ordinals, Bitcoin can store various data and become a highly secure database. Uploading Rollup's proof data to the BTC network can indeed ensure that it cannot be tampered with, but this cannot ensure the validity and correctness of Rollup's internal transactions. .
The core problem of BTC Rollup is verification. Most BTC Rollup may choose the sovereign Rollup (client-side verification) method. The verifier synchronizes all the Rollup data off-chain and checks it by itself.
But this cannot take advantage of Bitcoin's strongest capability, that is, the POW consensus of hundreds of thousands of nodes, to ensure the security of Rollup. The most ideal state is of course to allow 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.
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 Circuits and 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 packaged by the sequencer in Rollup. The challenger can continuously upload hash values to this fraud proof circuit, and the verifier Continuously run the corresponding script and reveal the output to verify that the results are correct.
Under a series of transactions, the challenger can continue to challenge the prover until the prover confirms that each circuit gate is correct. From this, the BTC network completes the verification of Rollup, and the prover can receive his own funds. , otherwise, the challenger will obtain the BTC pledged 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. Its security is the highest among all expansion plans. The number of transactions that BitVM will generate is very large, the cost is high, and it is carried out by both parties involved. Before on-chain verification, a large amount of pre-signing is required, 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 can link two strings and supports up to 520 bytes. Length, 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 hundredfold growth rate. BitVM’s impact on Bitcoin scripts The complex combination 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 (client verification) based on Bitcoin. The so-called sovereign rollup, that is, L1 is used as the block data announcement board (DA) of the rollup. It does not verify whether the rollup transaction is correct. The rollup transaction Verified by Rollup's own node.
Bison submitted Rollup's ZK certificate to BTC Ordinals. Users can download the certificate from BTC and run their own clients to verify Rollup transactions. If they need to verify the full status of Rollup, they need to synchronize the full node.
The feature of Bison lies in the implementation of the BTC L1 bridge. 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:
Transferring money to others
Withdrawal back to BTC mainnet
When no one picks it up 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. Obtain any two of them. With one signature, 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 machine 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 machine will send the transaction signed under the situation ① and the multi-signature address control will be given to the Bison network. Further, Allocation; if the user's request is received, ② is sent, and 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.
As a result, Bison has realized the extraction of BTC from Rollup and set up a simple escape channel. However, the weak point of the system here is the oracle. If wrong information is transmitted, the user's assets will be lost, so the introduction of The decentralized part, such as Chainlink.
The "trustless bridge" implemented by DLC is to tap the potential of BTC scripts. DLC.link uses it to cross BTC to chains such as ETH and STX. Although Bison Rollup achieves a simple "escape" by introducing a new third party Channel", but still has not implemented the BTC L1 verification Rollup proof.
B² Network
B² Network is a ZK Rollup mixed with "Commitment Challenge" on BTC. The network is divided into two layers, the Rollup layer and the DA layer. The Rollup layer uses zkEVM to run smart contract logic. This layer contains multiple modules, including transactions. The acceptance, sorting and packaging, the output of ZK proof, support the account abstraction of BTC address, and synchronous reading of BTC L1 data (BTC and BRC20 balance).
The DA layer provides data storage for Rollup. The storage node performs off-chain ZK verification on the Rollup transaction. After completing the verification, the DA layer node writes the Rollup data into the Ordinals inscription of BTC, which includes the location 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, the verification of the proof 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 into the verification, transforming the direct verification of L1 versus ZK into a "fraud proof" challenge similar to Optimistic.
B² decomposes ZK's proof into different scripts, and superimposes these scripts to form a Mast binary tree. The B² node sends 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 by the node. At the same time, the rollup transaction will be rolled back. If there is no challenge within the locking time, the node can take the Returning the locked BTC, Rollup received final confirmation.
In B² Network, the first transaction that sent 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, L1 was indirectly completed. Verification ensures the validity of transactions under Rollup and increases security. This is indeed a brilliant innovation.
B² Network has introduced account abstraction, allowing everyone to directly use BTC wallets to interact with Rollup without changing user habits. This is very commendable, but it still uses a lot of methods to withdraw BTC assets from L2. The method of signing the address bridge does not introduce an "escape channel".
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. Whether it is correct and effective, the cross-chain bridge part actually just uses a multi-signature solution and has no highlights.
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 prover needs to scan every BTC block without missing a beat, read the block header from the BTC block, the previous ZK Proof, and the "forced transaction" engraved in the block to generate a complete ZK Proof, in every BTC block, Chainway will submit a transaction to burn 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, the user can engrave the withdrawal request directly into the Bitcoin block. The node must include these "forced transactions" into the Rollup block, otherwise it will not be able to Proof generation will fail if the constraints of the ZK circuit are met.
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 the 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 BTC L1 asset settlement.
QED Protocol
QED Protocol is a ZK rollup on BTC, running based 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 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. .
4. Index-oriented programming
If you trace the source, Brc20 is essentially a kind of BTC L2. All transaction data of Brc20 are recorded on BTC, and the ledger actually runs in the off-chain indexer.
Although the current Brc20 ledger itself is completely centralized, we seldom worry about its security, because all transaction records are immutably recorded in Ordinals of the BTC network, and anyone can recover them by scanning the BTC network. 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 a consensus on fund security, decentralization is an inevitable process.
There are also read-only L2s such as 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.
Five finally
Of course, there are many projects that I have not introduced, partly because their descriptions are unclear, partly because my energy is limited, and the industry is changing rapidly. New BTC L2 is born every second, but what remains unchanged is the inevitable development of the BTC ecosystem towards the second layer. trend.
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 with half a foot. Who said relying on What about a self-verifying sovereign Rollup that is not a Rollup? (All thanks to Celestia for its long-term CX on 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. This is infinitely close to the security relationship between ETH and its Rollup. At present, it seems that at the implementation level It's far out of reach, but the unblocking of new operators such as op_cat seems to further accelerate its progress, and BitVM may be implemented sooner than everyone expects.
IC content you care about
Technology Progress | Project Information | Global Events
Collect and follow IC Binance Channel
Stay up to date with the latest information
