Technical Interpretation: How does Merlin Chain operate?

Original Author: Faust, Geek Web3

Since the summer of inscriptions in 2023, Bitcoin Layer 2 has always been the focal point of the entire Web3. Although the rise of this field came much later than Ethereum Layer 2, Bitcoin, with its unique charm of POW and the smooth landing of spot ETFs, has attracted capital attention of hundreds of billions of dollars to the Layer 2 derivative track in just six months, without worrying about the "securitization" risk.

Among Bitcoin Layer 2 projects, Merlin, with a TVL of several billion dollars, is undoubtedly the largest and most followed one. With clear staking incentives and considerable yields, Merlin has almost suddenly risen within a few months, creating an ecological myth that surpasses Blast. As Merlin becomes increasingly popular, discussions about its technical solutions have also become a topic of interest for more and more people.

In this article, Geek Web3 will focus on the technical solution of Merlin Chain, interpreting its publicly available documents and protocol design ideas. We aim to help more people understand the general workflow of Merlin and have a clearer understanding of its security model, allowing everyone to grasp how this "leading Bitcoin Layer 2" operates in a more intuitive way.

Merlin's Decentralized Oracle Network: An Open Off-chain DAC Committee

For all Layer 2 solutions, whether Ethereum Layer 2 or Bitcoin Layer 2, data availability (DA) and data publishing costs are among the most pressing issues to solve. Due to various problems inherent in the Bitcoin network, which does not support large data throughput, how to utilize this precious DA space has become a challenge that tests the imagination of Layer 2 project teams.

One conclusion is evident: if Layer 2 "directly" publishes unprocessed transaction data to the Bitcoin block, it can neither achieve high throughput nor low fees. The most mainstream solutions either compress the data size as much as possible before uploading it to the Bitcoin block or publish the data directly off-chain.

Among Layer 2 solutions that adopt the first approach, the most famous might be Citrea, which plans to upload a state change (state diff) of Layer 2 over a period, along with the corresponding ZK proof, to the Bitcoin chain. In this case, anyone can download the state diff and ZKP from the Bitcoin mainnet to monitor the changes in Citrea's state. This method can compress the on-chain data size by over 90%.

Although this can greatly compress data size, the bottleneck is still quite apparent. If a large number of accounts undergo state changes in a short period, Layer 2 must aggregate all these changes and upload them to the Bitcoin chain, making it impossible to keep the final data publishing costs low. This is evident in many Ethereum ZK Rollups.

Many Bitcoin Layer 2 projects simply take the second path: using off-chain DA solutions, either by building their own DA layer or using Celestia, EigenDA, etc. B^Square, BitLayer, and the protagonist of this article, Merlin, have all adopted this off-chain DA expansion solution.

In a previous article by Geek Web3 titled "Analyzing the New Technical Roadmap of B^2: The Necessity of Off-chain DA and Verification Layer for Bitcoin," we mentioned that B^2 directly mimics Celestia by building an off-chain DA network that supports data sampling, called B^2 Hub. Transaction data or state diff and other "DA data" are stored off-chain, only uploading the datahash / merkle root to the Bitcoin mainnet.

This essentially treats Bitcoin as a trustless bulletin board: anyone can read the datahash from the Bitcoin chain. When you obtain DA data from an off-chain data provider, you can check whether it corresponds to the datahash on-chain, i.e., hash(data 1) == datahash 1? If there is a correspondence, it indicates that the data provided by the off-chain data provider is correct.

The above process ensures that the data provided by off-chain nodes is associated with certain "clues" on Layer 1, preventing the DA layer from maliciously providing false data. However, there is a very important malicious scenario: what if the source of the data—the Sequencer—does not send out the data corresponding to the datahash at all, only sending the datahash to the Bitcoin chain while deliberately withholding the corresponding data from anyone?

Similar scenarios include, but are not limited to: only publishing the ZK-Proof and StateRoot without releasing the corresponding DA data (state diff or transaction data). Although people can verify the ZKProof and confirm that the computation process from PrevStateroot to NewStateroot is valid, they still do not know which accounts' states have changed. In this case, although users' assets are safe, no one can ascertain the actual state of the network, unaware of which transactions have been packaged on-chain and which contracts' states have been updated. At this point, Layer 2 is essentially equivalent to being offline.

This is essentially "data withholding." Dankrad from the Ethereum Foundation briefly discussed a similar issue on Twitter in August 2023, primarily targeting something called "DAC."

Many Ethereum Layer 2 solutions that adopt off-chain DA schemes often set up a few special permissioned nodes to form a committee, known as the Data Availability Committee (DAC). This DAC committee acts as a guarantor, publicly claiming that the Sequencer has indeed published complete DA data (transaction data or state diff) off-chain. The DAC nodes collectively generate a multi-signature, and as long as the multi-signature meets the threshold requirement (e.g., 2/4), the relevant contracts on Layer 1 will assume that the Sequencer has passed the DAC committee's inspection and has truthfully published the complete DA data off-chain.

The DAC committees of Ethereum Layer 2 generally follow a POA model, allowing only a few KYC-verified or officially designated nodes to join the DAC committee, which makes DAC synonymous with "centralization" and "consortium chains." Additionally, in some Ethereum Layer 2 solutions that adopt the DAC model, the sequencer only sends DA data to DAC member nodes and rarely uploads data elsewhere. Anyone wanting to obtain DA data must get permission from the DAC committee, which is not fundamentally different from a consortium chain.

Undoubtedly, DAC should be decentralized. Layer 2 can choose not to upload DA data directly to Layer 1, but the admission criteria for the DAC committee should be open to the public to prevent collusion among a few individuals. (For discussions on DAC malicious scenarios, refer to Dankrad's previous comments on Twitter.)

Celestia's previously proposed BlobStream essentially replaces centralized DAC with Celestia, allowing Ethereum L2's sequencer to publish DA data to the Celestia chain. If 2/3 of the Celestia nodes sign it, the Layer 2 exclusive contract deployed on Ethereum will consider that the sequencer has truthfully published the DA data, effectively making Celestia nodes the guarantors. Considering that Celestia has hundreds of validator nodes, we can regard this large DAC as relatively decentralized.

The DA solution adopted by Merlin is actually quite similar to Celestia's BlobStream, both opening DAC admission rights through a POS mechanism to make it more decentralized. Anyone who stakes enough assets can run a DAC node. In Merlin's documentation, these DAC nodes are referred to as Oracles, and it is noted that they will support staking assets such as BTC, MERL, and even BRC-20 tokens, implementing a flexible staking mechanism that also supports proxy staking similar to Lido. (The POS staking protocol for oracles is one of Merlin's core narratives moving forward, with relatively high staking rates provided.)

Here we briefly outline Merlin's workflow (images below):

• The sequencer receives a large number of transaction requests, aggregates them, and produces a data batch, which is sent to the Prover nodes and Oracle nodes (decentralized DAC).

• Merlin's Prover nodes are decentralized and utilize Lumoz's Prover as a Service. The Prover pool generates the corresponding zero-knowledge proofs after receiving multiple data batches, and then the ZKP is sent to the Oracle nodes for verification.

• The Oracle nodes will verify whether the ZK proof sent by Lumoz's Prover pool corresponds to the data batch sent by the sequencer. If they correspond and contain no other errors, the verification passes. During this process, the decentralized Oracle nodes will generate a multi-signature through threshold signing, declaring that the sequencer has fully issued the DA data and that the corresponding ZKP is valid and has passed the Oracle nodes' verification.

• The sequencer collects the multi-signature results from the Oracle nodes, and when the number of signatures meets the threshold requirement, it sends this signature information to the Bitcoin chain, along with the datahash of the DA data (data batch), for external reading and confirmation.

The Oracle nodes perform special processing on the verification of the ZK Proof, generating a Commitment and sending it to the Bitcoin chain, allowing anyone to challenge the "commitment." The process here is essentially consistent with the fraud proof protocol of bitVM. If the challenge is successful, the Oracle node that published the Commitment will face economic penalties. Of course, the data that the Oracle must publish to the Bitcoin chain also includes the current Layer 2 state hash—StateRoot—and the ZKP itself, all of which must be published to the Bitcoin chain for external verification.

There are a few details that need to be elaborated. First, Merlin's roadmap mentions that in the future, Oracles will back up DA data to Celestia, allowing Oracle nodes to appropriately eliminate local historical data without needing to store data permanently. Additionally, the Commitment generated by the Oracle Network is essentially the root of a Merkle Tree; merely disclosing the root is insufficient; the complete dataset corresponding to the Commitment must also be made public, which requires finding a third-party DA platform, which could be Celestia, EigenDA, or another DA layer.

Security Model Analysis: Optimistic ZKRollup + Cobo's MPC Service

We have briefly outlined Merlin's workflow, and I believe everyone has a basic understanding of its structure. It is not difficult to see that Merlin, along with B^Square, BitLayer, and Citrea, essentially follows the same security model—Optimistic ZK-Rollup.

At first glance, this term may seem strange to many Ethereum enthusiasts. What is "Optimistic ZK-Rollup"? In the Ethereum community's understanding, the "theoretical model" of ZK Rollup is entirely based on the reliability of cryptographic computations, requiring no trust assumptions. However, the term "optimistic" introduces a trust assumption, meaning that people must generally assume that the Rollup is reliable and has not made errors. Once an error occurs, it can be punished through fraud proofs, which is the origin of the name Optimistic Rollup—also known as OP Rollup.

For the Ethereum ecosystem, which is the home of Rollups, Optimistic ZK-Rollup may seem out of place, but it precisely fits the current state of Bitcoin Layer 2. Due to technical limitations, the Bitcoin chain cannot fully verify ZK Proofs and can only verify certain computational processes of ZKP under special circumstances. Under this premise, the Bitcoin chain can only support fraud proof protocols, allowing people to point out errors in a specific computational step during the off-chain verification of ZKP and challenge it through fraud proofs. While this cannot match Ethereum-style ZK Rollups, it is currently the most reliable and secure model that Bitcoin Layer 2 can achieve.

Under the aforementioned Optimistic ZK-Rollup scheme, assuming there are N authorized challengers in the Layer 2 network, as long as one of these N challengers is honest and reliable, capable of detecting errors and initiating fraud proofs, the state transitions of Layer 2 are secure. Of course, a more complete Optimistic Rollup needs to ensure that its withdrawal bridge is also protected by fraud proof protocols, but currently, almost all Bitcoin Layer 2 solutions cannot meet this requirement and must rely on multi-signatures/MPC. Thus, how to choose a multi-signature/MPC solution becomes a matter closely related to the security of Layer 2.

Merlin has chosen Cobo's MPC service for its bridging solution, employing measures such as cold and hot wallet isolation. The bridged assets are jointly managed by Cobo and Merlin Chain, and any withdrawal actions require the participation of both Cobo and Merlin Chain's MPC participants, essentially ensuring the reliability of the withdrawal bridge through institutional credit endorsement. Of course, this is merely a stopgap measure at this stage. As the project matures, the withdrawal bridge can be replaced with an "optimistic bridge" based on 1/N trust assumptions by introducing BitVM and fraud proof protocols, although the implementation difficulty will be relatively high (currently, almost all Layer 2 official bridges rely on multi-signatures).

Overall, we can summarize that Merlin introduces a POS-based DAC, a BitVM-based Optimistic ZK-Rollup, and a Cobo-based MPC asset custody solution, addressing the DA issue through open DAC permissions; ensuring the security of state transitions by introducing BitVM and fraud proof protocols; and guaranteeing the reliability of the withdrawal bridge by incorporating the MPC service of the well-known asset custody platform Cobo.

Two-Step Verification ZKP Submission Scheme Based on Lumoz

Earlier, we outlined Merlin's security model and introduced the concept of Optimistic ZK-rollup. In Merlin's technical roadmap, there is also discussion about decentralized Provers. As we know, Provers are a core role in the ZK-Rollup architecture, responsible for generating ZKProofs for the batches published by the Sequencer, and the process of generating zero-knowledge proofs is very resource-intensive, posing a tricky problem.

To accelerate the generation of ZK proofs, parallelizing the tasks is a fundamental operation. The so-called parallelization involves dividing the task of generating ZK proofs into different parts, which are completed by different Provers, and then aggregated by an Aggregator into a whole.

To speed up the ZK proof generation process, Merlin will adopt Lumoz's Prover as a Service solution, which essentially gathers a large number of hardware devices to form a mining pool, distributing computational tasks to different devices and assigning corresponding incentives, somewhat similar to POW mining.

In this decentralized Prover scheme, there exists a type of attack scenario known as a race attack: suppose an Aggregator has assembled a ZKP and sends it out to claim a reward. Other Aggregators see the content of the ZKP and rush to publish the same content ahead of him, claiming that they generated this ZKP first. How should this situation be resolved?

One instinctive solution that might come to mind is to assign each Aggregator a specific task number, for example, task 1 can only be accepted by Aggregator A, and others will not receive rewards even if they complete task 1. However, this method has a problem: it cannot guard against single-point risks. If Aggregator A experiences a performance failure or goes offline, task 1 will be stuck and cannot be completed. Moreover, this approach of assigning tasks to a single entity cannot enhance production efficiency through competitive incentive mechanisms, making it not a very good solution.

Polygon zkEVM once proposed a method called Proof of Efficiency in a blog, which pointed out that competitive means should be used to encourage different Aggregators to compete, distributing incentives on a first-come, first-served basis, where the first Aggregator to submit the ZK-Proof on-chain can receive a reward. Of course, they did not mention how to solve the MEV race attack problem.

Lumoz adopts a two-step verification ZK proof submission method. When an Aggregator generates a ZK proof, it does not immediately send out the complete content but only publishes the hash of the ZKP, in other words, publishes hash(ZKP + Aggregator Address). This way, even if others see the hash value, they do not know the corresponding ZKP content and cannot directly race ahead;

If someone simply copies the entire hash and publishes it first, it is also meaningless because the hash contains the address of a specific Aggregator X. Even if Aggregator A publishes this hash first, when the original hash is revealed, everyone will see that the included Aggregator address is X, not A.

Through this two-step verification ZKP submission scheme, Merlin (Lumoz) can resolve the race attack issue during ZKP submission, thereby achieving highly competitive incentives for zero-knowledge proof generation and improving the speed of ZKP generation.

Merlin's Phantom: Multi-Chain Interoperability

According to Merlin's technical roadmap, they will also support interoperability between Merlin and other EVM chains, with the implementation path being quite similar to the previous Zetachain approach. If Merlin is used as the source chain and other EVM chains as target chains, when Merlin nodes detect cross-chain interoperability requests from users, they will trigger subsequent workflows on the target chain.

For example, a user can deploy an EOA account controlled by the Merlin network on Polygon. When a user issues a cross-chain interoperability instruction on Merlin Chain, the Merlin network first parses its content, generates a transaction data to be executed on the target chain, and then the Oracle Network processes this transaction for MPC signing, generating a digital signature for the transaction. After that, Merlin's Relayer nodes release this transaction on Polygon, completing subsequent operations through the assets in the EOA account on the target chain.

Once the requested operation is completed, the corresponding assets will be directly forwarded to the user's address on the target chain, theoretically allowing them to cross back to Merlin Chain. This solution has some obvious advantages: it can avoid the fee erosion caused by traditional asset cross-chain operations with cross-chain bridge contracts, and it is directly secured by Merlin's Oracle Network, eliminating the need to rely on external infrastructure. As long as users trust Merlin Chain, they can assume that such cross-chain interoperability actions are problem-free.

Conclusion

In this article, we have briefly interpreted the general technical solution of Merlin Chain, which we believe can help more people understand the general workflow of Merlin and have a clearer understanding of its security model. Considering the current thriving Bitcoin ecosystem, we believe that such technical popularization efforts are valuable and needed by the public. We will continue to follow Merlin, bitLayer, B^Square, and other projects in the future, providing more in-depth analysis of their technical solutions, so stay tuned!