Merlin Chain, the Bitcoin expansion plan, may be one of the most disappointing airdrops this year. Users had huge expectations for Bitmap and the BRC-420 team, but it broke as soon as it went online, bottoming out from about $1 to $0.15. In addition to the so-called BTC L2 "uploading transaction proof to the main network for verification" is generally falsified by technical personnel because "the Bitcoin main network does not have smart contract functions." Some KOLs also questioned the Bitmap team’s original use of activities such as “treasure boxes” to collect airdrop points, which was essentially cutting leeks and exchanging left hands for right hands. However, the research organization Messari recently published a complete report on Merlin Chain.

How to define Merlin? Messari: BTC native asset EVM side chain

Different from the community generally calling Merlin Chain BTC Layer 2, Messari believes that Merlin Chain is the EVM side chain of Bitcoin’s native assets. This positioning is consistent with the author's idea. If we define Layer 2, the transaction is executed outside the main network and then uploaded to the main network for verification. Merlin's mechanism is not like this, because the BTC main network cannot execute smart contracts, so how to verify it?

Merlin Chain has partnered with RaaS (Rollup-as-a-service) protocol Lumoz to develop its architecture using Polygon’s CDK. This enables Merlin Chain to implement zk-validium technology, enhancing scalability and transaction efficiency while maintaining security. (The author adds that the concept of the impossible triangle of blockchain is that only two of them can be chosen: decentralization, security, and scalability. Merlin’s choice here is already obvious)

The architecture consists of zkEVM and the Data Availability Committee (DAC). DAC ensures the validity and availability of off-chain transaction data. The DAC node fetches data from the sequencer, validates it, and stores it in the database, making it accessible to the network while maintaining its integrity. The Polygon CDK validium architecture defines the Merlin Chain as zkValidium, which leverages Polygon's zkEVM's off-chain prover to produce zero-knowledge proofs published as proofs of validity.

Blockchain Impossible Triangle

However, Merlin Chain has not yet released a Bitcoin proof, which is why the Bitcoin mainnet mentioned earlier cannot be verified. Achieving true ZK-rollup requires publishing proofs and ensuring they can be verified, but currently generally BTC Layer 2 operations are limited by this verification. Merlin Chain intends to complete the transition once the verification process is fully developed. Merlin Chain has partnered with BitcoinOS and Nubit to develop the technology required for Bitcoin ZKP verification, but their solution is still under development.

"BTC Layer 2" is a marketing term and has not yet been technically achieved.

At present, it seems that Merlin Chain is actually still running as a side chain for native Bitcoin assets such as Ordinals and Runes. The biggest obstacle is technical problems. Once overcome, it will transition to BTC Layer 2. Specifically, what is the difference between side chains and Layer 2? Messari also pointed out that the term “BTC Layer 2” is currently more of a marketing term than a technical reality.

First of all, sidechains do not inherit the security of Bitcoin. They rely on their own consensus mechanism and introduce trust assumptions. Secondly, the sidechain allows withdrawals, which means users must trust the validator to withdraw money. Finally, as of September 27, 2024, Bitcoin’s language Script lacks the ability to support rollups and complex smart contracts, which means that Layer 2 cannot be verified on the Bitcoin mainnet.

zkProver generates zero-knowledge proofs and aims to generate certifications on the Bitcoin mainnet

Merlin Chain partners with BitcoinOS, which aims to solve Bitcoin’s scalability and computational limitations. BitcoinOS launched the validator BitSNARK, which focuses on zkSNARK verification, allowing verification directly on the Bitcoin blockchain with minimal computational cost. This integration enables Merlin Chain to leverage secure and decentralized Layer 2 roll-ups to build more efficient and scalable Bitcoin-native solutions.

Merlin Chain utilizes recursive STARKs to ensure scalability, allowing the system to load large-scale user demands and ensuring fast transaction finalization. At present, Merlin Chain's verification architecture is mainly divided into three types: node, zkProver and database

Node: Responsible for processing and transmitting transaction data. Transfer Merkle tree data to database storage, input transactions into zkProver for processing, and interact with zkProver to ensure the validity and correctness of transactions.

zkProver: zkProver uses zkSNARK technology to generate ZKP and verify the validity of transactions. Interact with nodes and repositories to collect information and produce verifiable proofs, including Merkle Roots, sibling keys, and hashes. zkProver transmits the transaction proof back to the node for verification and recording to ensure the legality and security of the transaction.

Supplement: Sibling keys refer to hash values ​​between two nodes from the same parent node. Simply put, when you have two or more child nodes (such as hash A and hash B), and they share the same parent node, then the two child nodes are brothers, and their hash values ​​are sibling keys. . Sibling keys are essential for performing Merkle Proof quickly and efficiently. Allows users to verify that specific data is present in a block without downloading the entire tree.

Database: The database stores key data, including Merkle tree content and transaction information.

The database receives and stores the Merkle tree data transmitted by the nodes. It provides zkProver with the information needed to generate transaction proofs.

Merlin Chain has partnered with Nubit to integrate Nubit’s Bitcoin-native data availability layer into Merlin Chain. This would allow full and light nodes to be used to improve scalability and data integrity, but this solution is still under development and has not yet been implemented. Their goal is to enhance the decentralization and security of Merlin Chain.

Multi-signature wallet ensures the security of asset bridging, and uses account abstraction to realize the possibility of interaction between BTC wallet and EVM

As for how to achieve interoperability between Merlin Chain and the Bitcoin mainnet specifically? First, Merlin Chain collaborates with Cobo to use MPC-TSS (Multi-Party Computing – Threshold Signature Scheme) to protect assets bridged from the Bitcoin mainnet to Merlin Chain. The technology shares private keys between Cobo and Merlin Chain, ensuring that no one party has full control of the keys. The co-managed MPC multi-signature wallet protects assets bridged to Merlin Chain by preventing single points of failure. This partnership enhances the security and integrity of bridged assets on Merlin Chain.

Merlin Chain, on the other hand, has partnered with Particle Network on BTC Connect to enable Bitcoin-native wallets to interact with EVM-compatible dApps without having to switch wallets. This is achieved through Account Abstraction (AA), which uses the Paymaster contract to pay gas fees for users to ensure smoother transactions. This integration enhances asset transfers between Bitcoin and Merlin Chain, allowing Bitcoin native wallets to interact directly with EVM dApps. For explanations and participation of account abstraction and Particles, please refer to this link.

Is this article Bitcoin Layer 2 disproven? Introduction Messari Report: How institutions view Merlin Chain first appeared on Chain News ABMedia.