Written by: Haotian
What do you think of the secure cross-chain cooperation between Merlin Chain and BitcoinOS? Based on a purely technical perspective, let’s share some knowledge:
1) Recently, MerlinChain released its semi-annual report, which showed impressive data such as TVL of over 1.2 billion US dollars, 16 billion in bridged assets and more than 200 ecological partners. This does not seem bad considering the market has been turbulent for half a year.
I remember that it was hastily launched with the halo of Bitcoin layer2, the strongest consensus in the universe, and experienced a lot of criticism and blame. The most criticized issue was the "decentralization" of the "cross-chain bridge".
However, due to the inherent lack of "security" of L2 in the Bitcoin scripting language, the "decentralization" issue and "security" are in opposition in the early stage, and the intervention of centralized custodians can be a stopgap solution. Therefore, most of the early BTC layer2 projects deal with cross-chain security issues in a simple and crude way in the form of CeDeFi, especially most EVM-compatible BTC layer2s.
However, in the pursuit of Crypto decentralized geekism, a sufficiently technology-native solution that can simultaneously solve the problems of "security" and "decentralized trust" is the ultimate solution.
2) Due to the limited UTXO script space and verification logic of the Bitcoin mainnet, it is difficult for the mainnet to store all the data status of layer2, and it is also impossible to use smart contracts to verify the correctness of layer2 status proof. Therefore, there are currently only two fair Bitcoin layer2 cross-chain security consensus methods on the market (EVM-Compatible direction):
1. ZK Proof verification method: Based on the ZK framework, a virtual machine that can verify Proof is built. Layer2 generates Proof in the form of SNARKs proof, and the virtual machine verifies Proof. Finally, the mainnet script verifies the final "asset" lock and unlock. In this way, ZK technology is used as a medium to ensure that the data status of layer2 can interact with the mainnet under the premise of trust.
For example: @ProjectZKM built the zkMIPs program instruction set, used zkVM as a general data verification virtual machine, and built the Entangled Rollup Network to achieve cross-chain interactive communication of assets and message status. Finally, it implemented a trusted cross-chain security mechanism without cross-chain bridges on @GOATRollup, as well as the first decentralized Sequencer BTC layer2.
For example: @BTC_OS has built a VM virtual machine system specifically for SNARK - BitSNARK, and built a cross-chain bridge called Grail Bridge for the VM verification system to securely transmit asset transfers and state changes from the main network to layer2. The general logic is to use ZK as a verification medium to maximize the state locking and verification capabilities of the limited space of the main network to ensure the asset security of the Rollup layer2 network.
Both solutions use ZK zero-knowledge proof technology. ZKM uses the more general zkVM solution, so it has broader technical support when application projects such as GOAT Network are implemented. In contrast, BitcoinOS is more focused on SNARKs verification and cross-chain bridge services, focusing on the secure transfer of cross-chain assets.
The two are identical in the verification logic of Proofs, the locking logic of mainnet assets Peg-in and Peg-out, and the challenger mechanism of BitVM, so they are compared together for easier understanding.
2. Cryptographic algorithm security reinforcement method: The goal is to maximize the space and verification capabilities of the Bitcoin mainnet UTXO script. The script itself uses the contract to define a set of staking, unbinding, and withdrawal logic, and ultimately relies on the EOTS signature scheme and the final round of multi-signature consensus to achieve the external commercial output of the security of the mainnet assets and the security consensus capability.
Without further explanation, everyone must have guessed that this is @babylonlabs_io's method for implementing secure consensus. The core logic is to lock assets firmly within the jurisdiction of the main network, and then the node Validators of the second-layer POS chain form a set of management consensus to maintain order (anyway, assets are locked in the main network, and things will be done in accordance with the rules on the second layer).
Compared with the verification capabilities based on the ZK technology protocol, if BitcoinOS and GOAT both need to verify the "correctness" of every transaction on layer 2, the ability of Babylon to grant a second-layer security consensus is more like a social security consensus with economic constraints.
End
As for MerlinChain, the current data on the chain, such as users, transaction volume, and ecological activity, still prove that its consensus and influence in the Bitcoin layer2 ecosystem cannot be underestimated.
Based on this, MerlinChian makes sense by combining various excellent technical security solutions that are constantly evolving in the ecosystem to make up for its shortcomings. In addition, many micro-innovations in the Bitcoin layer 2 protocol market are emerging in an endless stream, and most of them lack the ability to go-to-market. Only by complementing each other's strengths and weaknesses and advancing together to eventually form a combined force can the scattered BTC layer2 market improve its cohesion and accelerate its development.
