The solution that simultaneously addresses the issues of "security" and "decentralized trust" is the ultimate solution.
Author: Haotian
How do you view the secure cross-chain collaboration between Merlin Chain and BitcoinOS? From a purely technical perspective, let's share some knowledge:
1) Recently, MerlinChain released its semi-annual report data, with over $1.2 billion in TVL, $16 billion in bridged assets, and over 200 ecosystem partners, which seems quite impressive considering the market's turbulent six months.
Back in the day, with the aura of the strongest universal consensus Bitcoin layer2, it was hastily launched and faced much criticism and condemnation, with the most criticized being the "decentralization" issue of the "cross-chain bridge."
Given the inherent lack of security in the Bitcoin script language on the mainnet, early "decentralization" issues and "security" were at odds, and the intervention of centralized custodial institutions could provide a temporary solution. Therefore, most early BTC layer2 projects dealt with cross-chain security issues directly and simply in the form of CeDeFi, especially with most EVM-Compatible BTC layer2 projects adopting this approach.
However, under the pursuit of Crypto's decentralized geek idealism, a solution that is sufficiently technically native, addressing both "security" and "decentralized trust" issues simultaneously, is the ultimate solution.
2) Hindered by the limited space and verification logic of Bitcoin's mainnet UTXO script, the mainnet is unable to store all the data states of layer2 and cannot use smart contracts to verify the correctness of layer2's state proof. Therefore, there are currently only two fair Bitcoin layer2 cross-chain security consensus methods in the market (in the EVM-Compatible direction):
- ZK Proof verification method: Building a virtual machine based on the ZK framework to verify proof, with layer2 generating proof in the form of SNARKs proof and the virtual machine verifying the proof, ultimately verifying the locking and unlocking of assets by the mainnet script. In this way, using ZK technology as a medium to ensure the data state of layer2 interacts with the mainnet in a trustworthy manner.
For example: @ProjectZKM has built the zkMIPs program instruction set, based on zkVM for general data verification virtual machine, and has built the Entangled Rollup Network to achieve cross-chain interactive operation communication of asset and message states, ultimately landing a trustworthy cross-chain security mechanism on @GOATRollup, as well as the first decentralized Sequencer BTC layer2.
Another example: @BTC_OS has built a VM virtual machine system specifically for SNARKs verification—BitSNARK, and has also built a cross-chain bridge named Grail Bridge to securely transfer assets from the mainnet to layer2 and change states. Its general logic is also to use ZK as a verification medium to maximize the mainnet's limited space for state locking and verification capabilities, ensuring the security of Rollup layer2 network assets.
Both solutions use ZK zero-knowledge proof technology, with ZKM adopting a more general zkVM approach, thus having broader technical support when applied in projects like GOAT Network. In comparison, BitcoinOS focuses more on SNARKs verification and cross-chain bridge services, focusing on the secure transfer of cross-chain assets.
Both have identical verification logic for Proofs and the locking logic of mainnet assets Peg-in and Peg-out, as well as BitVM's challenger mechanism, so they are compared together for better understanding.
- Cryptographic algorithm security reinforcement method: The goal is to maximize the exploration of Bitcoin's mainnet UTXO script space and verification capabilities, with the script itself defining a set of pledging, unbundling, and withdrawal logic, ultimately relying on the EOTS signature scheme, multi-signature consensus in the final round, etc., to achieve the security and consensus capabilities of mainnet assets for commercial output.
Without going into too much detail, everyone must have thought of @babylonlabs_io's security consensus implementation. The core logic is to lock the assets firmly within the jurisdiction of the mainnet, and then have a set of management consensus formed by the nodes Validators of the second-layer POS chain to maintain order (after all, the assets are locked in the mainnet, so the second layer operates in an orderly manner).
Compared to the verification capabilities based on ZK technology protocols, if BitcoinOS and GOAT both verify the "correctness" of every transaction on layer2, Babylon's endowment of second-layer security consensus capabilities is more like a form of social security consensus with economic constraints.
The above
As for MerlinChain, the data of users, transaction volume, ecosystem activity, etc., still prove its consensus and influence in the Bitcoin layer2 ecosystem cannot be underestimated.
Based on this, MerlinChain's continuous evolution of various excellent technical security solutions to make up for its own shortcomings makes a lot of sense. Many micro-innovations in the Bitcoin layer2 protocol market are also emerging, but most of them lack Go-To-Market capabilities. By complementing each other's strengths and weaknesses and working together, a combined force can be formed to enhance the cohesion and accelerate the development of the seemingly fragmented BTC layer2 market.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
