From sidechains to ZL Layer2, how did Merlin Chain get to this point?

Messari A systematic review of the solution that Merlin transitioned from BTCSidechain to BTCZK layer2, after reading it, combined with personal understanding, summarized here:

The birth of Merlin Chain seems to be in line with the trend, and each step is unexpected. With the support of a large community foundation such as BRC-20, BRC-420, Blue Box, Bitmap Game, etc., Merlin Chain has chosen a technology route of continuous integration and iteration. In fact, there is no other way.

Because the native BTC network has inherent programmability issues in terms of data availability (DA), smart contract Turing completeness (SC), etc., the BTC ecosystem has seen a flurry of innovative projects that have not yet been fully delivered for over a year.

RGB++ (Nervos), BitVM (BitLayer), zkVM (ZKM), AVM (Atomicals Protocol), DA (B² Network, Nubit) Merlin Chain’s idea is to draw on the strengths of others and constantly enrich and improve its own technical framework.

2. According to the content of Messari’s report, the original Merlin Chain was a pure sidechain architecture, built by Lumoz based on Polygon’s CDK RaaS service, equivalent to a Validium architecture chain, which means that the transaction data of the chain is completely stored off-chain, and only the validity proof is published to L1, and the L1 mainnet cannot verify the accuracy of the L2 data. Moreover, the original data of this Validium architecture is all stored in the local database, and the Data Availability Committee (DAC) is responsible for obtaining, sorting, and verifying the data.

Obviously, this requires the ‘trust’ of the chain itself as a prerequisite, which is difficult to scale up on a large scale. In the ETH layer2 system, Validium is replaced by Rollup for this reason.

To address this fundamental deficiency, Merlin has made iterative enhancements from two aspects:

1. Collaborate with BTCOS to improve Native cross-chain bridges, address the verifiability of L2 data on BTC Mainnet, and build a verifiable Proof Virtual Machine-BitSNARK based on the ZK framework. Combined with the Grail Bridge cross-chain bridges, BitcoinOS updates the asset transfer and state changes on L2. The entire process uses the ZK intermediate network to synchronize the state between L2 and Mainnet, ultimately achieving trustworthy interaction through Mainnet asset time lock + BitVM challenge mechanism.

2. Collaborate with Nubit to build verifiable data availability (DA) capability. The general logic is as follows: deploy full nodes off-chain to synchronize BTC’s full state data and change state data proofs. Use light nodes deployed on the BTC mainnet for state verification and Finality confirmation. This improves the transparency and verifiability issues in the previous off-chain DAS, thus enhancing its required DA capability (currently under development).

In the end, the goal of Merlin Chain is to become a BTCZK-Rollup network composed of components such as Node, zkProver, Database, etc., and then through a Decentralization Oracle Machine network similar to Ordinals protocol indexing, make it an EVM-Compatible BTClayer2 that is balanced in terms of Decentralization (Node distribution without permission), transparency (public data accessibility), and verifiability (Mainnet can verify L2 data status and have challenger mechanism to ensure).