What do you think of the secure cross-chain cooperation between @MerlinLayer2 and @BTC_OS? Based on a purely technical perspective, let’s share some knowledge: 1) Recently, MerlinChain released its semi-annual report, which included 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 to be bad considering the market has been turbulent for half a year. I remember that it was hastily launched with the halo of Bitcoin Layer 2, the strongest consensus in the universe, and it experienced a lot of criticism and blame. The most criticized issue was the "decentralization" of the "cross-chain bridge". However, due to the lack of "security" of L2 in the Bitcoin scripting language, the "decentralization" problem 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 layer2 adopts this approach. 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 the Proof is built. Layer2 generates Proof in the form of SNARKs proof, and the virtual machine verifies Proof, and 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 mainnet 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 mainnet 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 mainnet, 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 mainnet, 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 have to verify the "correctness" of every transaction in layer2, the ability of Babylon to grant a second-layer security consensus is more like a social security consensus with economic constraints. As for MerlinChain, the current data on users, transaction volume, ecological activity, etc. on the chain still proves 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 Go-To-Market capabilities. Only by complementing each other's strengths and weaknesses, advancing in groups, and finally forming a combined force, can the scattered BTC layer2 market improve its cohesion and accelerate its development. Note: If you find the article useful, please support it with "one-click triple-like" as a thank you. Friends who recognize my continuous input of valuable content can visit my Twitter homepage and click on the Substack column to subscribe (currently free). More in-depth and professional investment research and analysis content, especially content that is not suitable for public sharing on Twitter, will be seen there.