Source: View on the Chain
Recently, BTC layer2 is springing up like mushrooms after a rain. According to incomplete statistics, there are hundreds of projects on the horizon, and the entire extended ecosystem is prosperous and chaotic.
Because of this, when new chains enter the BTC layer2 track, they must find a suitable card position. Next, the heart of @MapProtocolAll in the Bitcoin ecosystem that we want to talk about is already known to everyone, but its ending may not be layer 2, but the interoperability layer of BTC. Why?
Because in my opinion, the BTC layer2 ecosystem currently does not have a clear "standard" and "norm": the mature EVM Compatible chain can be regarded as BTC layer2; The side chain is regarded as BTC layer 2; some performance new chains with similar UTXO account models can also be regarded as BTC layer 2, etc., of course, including more native BTC layer 2 such as state channel lightning network and client verification RGB.
Theoretically, as long as this chain can access BTC ecological related assets and can promote the secondary prosperity of BTC assets, it can be classified into the category of BTC layer 2. It sounds disrespectful to the definition and boundaries of "layer2", but when faced with Ethereum's layer2 involution war a while ago, didn't Vitalik also jump out and propose giving up the layer2 concept?
To a certain extent, the chaotic and disordered (Entropy) state currently presented by BTC layer 2 is a form that is not controlled by any individual’s subjective will and requires a long period of consensus friction and technical stranglehold. It will gradually become clear that only through competition, market involution, and survival of the fittest can it become clearer.
I previously wrote an article analyzing the particularity of @BSquaredNetwork in the bitVM challenge mechanism, and also mentioned the abstract design of @ParticleNtwrk and @BitmapTech on BTC Connect. MAP Protocol has been on Twitter for a long time. There are quite a lot of calls online, and many friends asked me to analyze it.
To be honest, I didn’t understand it at first. Because, a chain that originally aimed at layerZERO for full-chain interoperability suddenly promoted All in Bitcoin layer2 ecology, which always makes people feel a little committed to "narrative". After all, it is clearly possible to create a full-chain narrative, but if it is positioned on BTC layer 2, doesn’t it mean that it is self-limiting?
With this question, let us first briefly analyze the technical logic framework of MAP Protocol:
MAP positioning is a point-to-point full-chain infrastructure based on light clients and ZK, focusing on Go to third-party hubs for peer-to-peer interoperability. How to do it? MAP’s plan is actually to build a MAP relay chain, which is equivalent to a chain within a BOB chain. This relay chain will pre-compile the signature algorithms of different isomorphic chains in the contract. Based on this, cross-chain communication and zero-friction asset transfer capabilities can be obtained.
Taking BTC as an example, MAP first deploys the ZK light client on the BTC chain. The light client does not need to download the full node historical data and can perform some operations on the BTC main network: for example, verification area The Merkle proof related to the block header and transaction can realize that when making a coin withdrawal request on the second-layer chain, the mainnet light client only needs to verify part of the data related to the specific transaction to complete the operation safely.
This actually originated from the simple payment verification standard SPV (Simplified Payment Verification) technology defined in the Bitcoin white paper.
If the BTC main network is regarded as the asset settlement layer, the use of light node clients can significantly improve the security of cross-chain asset transfers, while also avoiding the resource loss and cost of full node verification. The reason why ZK technology is used is to ensure that the operation of the layer2 side chain is consistent with the main network verification consensus.
(It needs to be clarified that the light client can only verify the payment type and cannot verify the validity of the status on the layer2 chain. That is, the main network can verify whether it is unlocked based on part of the data submitted by layer2. UTXO unlocking conditions for asset transfer, and cannot verify more complex states on the layer2 chain)
It should be said that the ZK light client + relay chain method can indeed achieve safe cross-chain and synchronization of assets. Chain wear-free conversion. The relay chain will deploy smart contracts that adapt to the entire chain environment (those without smart contracts such as BTC use light clients for safe asset migration) and follow a set of standards for cross-chain communication, coupled with a set of POS-based interactions to effectively sexual verification mechanism. Achieving these constitutes a full-chain interoperable solution.
Precisely because MAP Protocol has the gene for full-chain interoperability, its development path will be different when positioned as BTC layer 2:
1) MAP will focus on the main network of BTC Features, to enrich its layer2 functions, so that BTC assets, in addition to BTC main assets, such as many inscription assets, can also be safely cross-chained to layer2.
Because of the strong consensus-driven asset circulation of single BTC, it is difficult for any layer 2 expansion plan to leverage the consensus of BTC holders. It is different if it is an inscription asset. BTC layer2 can manage and circulate these BTC derivative assets at lower cost and low loss, achieving layer2’s goal of expanding the value of the BTC main network;
To achieve this goal, it is not simply about wrapping BTC assets into The layer2 chain is so simple, involving the ledger consistency management of the indexer, the liquidity compatibility and management of different BTC derivative inscription assets, etc. Obviously, the key is to focus on the characteristics of BTC derivative assets and develop more scalable properties that are in line with the native characteristics of BTC.
2) MAP will become the interoperable layer (layer 0) of other BTC layer2. Imagine that BTC layer2 is connected to a batch of mature EVM chains and a batch of Non-EVM performance chains. These chains can all be connected to the BTC main chain in some way, but isn’t the core issue interoperability? Obviously, a chain-in-chain that is fully heterogeneous with the characteristics of the BTC main network and is compatible with other full-chain environments will become the key.
MAP can choose not to compete for the C position of the layer2 chain, wait and see other layer2 chains compete with each other, and then when they tear the market into pieces, based on the interoperability of its own chain Operational features to integrate and manage liquidity.
In my opinion, this may be a great move.
Of course, in the wild period of the BTC layer 2 competition, everyone was scrambling to grab the C position. Among them, there were many active plans that ignored the objective flaws of the BTC main chain and failed to understand the core value of the second layer chain. In the market, under this background, if a BTC layer2 can settle down and find its own ecological position, it is the ultimate key to victory.