Author: Faust, Geek web3

Since the summer of 2023, Bitcoin Layer2 has always been the highlight of the entire Web3. Although the rise of this field came much later than Ethereum Layer2, with the unique charm of POW and the smooth landing of spot ETF, Bitcoin, which does not need to worry about the "securitization" risk, has attracted the attention of capital to the Layer2 derivative track, drawing billions of dollars in just half a year.

In the Bitcoin Layer2 track, Merlin, with a TVL of billions of dollars, is undoubtedly the largest and most followed one. With clear staking incentives and considerable returns, Merlin has suddenly risen within a few months, creating an ecosystem myth that surpasses Blast. As Merlin becomes increasingly popular, discussions about its technical solutions have also become a topic of increasing concern.

In this article, Geek web3 will focus on the Merlin Chain technical solution and interpret its publicly available documents and protocol design ideas. We are committed to helping more people understand the general workflow of Merlin, have a clearer understanding of its security model, and understand how this "top Bitcoin Layer2" operates in a more intuitive way.

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

For all Layer2 solutions, whether it is Ethereum Layer2 or Bitcoin Layer2, the cost of data availability and data publishing is one of the most important problems to solve. Due to the inherent limitations of the Bitcoin network, which does not support large data throughput, how to utilize the limited space for data availability becomes a challenging problem for Layer2 projects.

One conclusion is obvious: if Layer2 "directly" publishes unprocessed transaction data to the Bitcoin blockchain, it cannot achieve high throughput or low transaction fees. The most mainstream solution is either to compress the data size as much as possible and then upload it to the Bitcoin blockchain, or to directly publish the data on the Bitcoin blockchain.

Among Layer2 solutions that adopt the first approach, Citrea is probably the most well-known. They intend to upload the state changes of Layer2 over a period of time (state diff), along with the corresponding ZK proof, to the Bitcoin blockchain. In this case, anyone can download the state diff and ZKP from the Bitcoin mainnet to monitor the state changes of Citrea. This method can compress the data size uploaded to the blockchain by more than 90%.

Although this can greatly compress the data size, the bottleneck is still obvious. If a large number of accounts undergo state changes in a short period of time, and Layer2 needs to aggregate and upload all these account changes to the Bitcoin blockchain, the final data publishing cost cannot be reduced very low, as seen in many Ethereum ZK Rollup solutions.

Many Bitcoin Layer2 solutions simply take the second path: directly use off-chain DAC solutions on the Bitcoin blockchain, either by building their own DAC layer or using solutions like Celestia, EigenDA, etc. B^Square, BitLayer, and the protagonist of this article, Merlin, have all adopted this off-chain DAC expansion solution.

In a previous article by Geek web3, "Analyzing the New Technical Roadmap of B^2: The Necessity of Bitcoin Off-chain DAC and Verification Layer," we mentioned that B^2 directly imitates Celestia and builds a DAC network called B^2 Hub that supports data sampling functionality off-chain. "DA data" such as transaction data or state diff is stored on the Bitcoin blockchain, and only the datahash/merkle root is uploaded to the Bitcoin mainnet.

This essentially treats Bitcoin as a trustless bulletin board: anyone can read the datahash from the Bitcoin blockchain. After obtaining the DA data from the off-chain data provider, you can check whether it corresponds to the datahash on-chain, i.e., hash(data1) == datahash1? If there is a correspondence, it means that the data provided by the off-chain node is correct.

This process ensures that the data provided by off-chain nodes is associated with certain "clues" on Layer1, preventing off-chain data providers from maliciously providing false data at the DAC layer. However, there is a very important malicious scenario: if the source of the data—Sequencer—does not actually release the data corresponding to the datahash, but only releases the datahash to the Bitcoin blockchain and intentionally withholds the corresponding data, what should be done in this case?

Similar scenarios include but are not limited to: only publishing ZK-Proof and StateRoot, but not publishing the corresponding DA data (state diff or transaction data). Although users can verify the ZKProof and confirm that the calculation process from PrevStateroot to NewStateroot is valid and correct, they do not know which accounts' states have changed. In this case, although users' assets are safe, they cannot determine the actual state of the network, and do not know which transactions have been included on-chain or which contract states have been updated. At this point, Layer2 is essentially equivalent to being offline.

This is actually "data withholding". Dankrad of the Ethereum Foundation briefly discussed a similar issue on Twitter in August 2023, mainly focusing on something called "DAC."

Many Ethereum Layer2 solutions that adopt off-chain DAC solutions often set up a committee of nodes with special permissions, collectively forming a Data Availability Committee (DAC). This DAC committee acts as a guarantor and claims externally that the Sequencer has indeed published complete DA data (transaction data or state diff) off-chain. Then 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 Layer1 will default that the Sequencer has passed the DAC committee's inspection and has indeed published complete DA data off-chain.

The DAC committees of Ethereum Layer2 mostly follow the POA model, allowing only a few nodes that have undergone KYC or are officially designated to join the DAC committee, making the DAC a synonym for "centralized" and "permissioned" chains. In addition, in some Ethereum Layer2 solutions that adopt the DAC model, the sequencer only sends DA data to DAC member nodes and almost never uploads data elsewhere. Anyone who wants to access DA data must obtain permission from the DAC committee, making it no different from a permissioned chain.

Undoubtedly, DACs should be decentralized, and while Layer2 may not directly upload DA data to Layer1, the access permissions of the DAC committee should be open to the public to prevent a few people from colluding to commit fraud. (For discussions on DAC fraud scenarios, refer to Dankrad's previous remarks on Twitter.)

The BlobStream proposed by Celestia is essentially a replacement for centralized DAC, where the sequencer of Ethereum Layer2 can publish DA data to the Celestia chain, and if 2/3 of Celestia nodes sign for it, the Layer2-specific contracts deployed on Ethereum will assume that the sequencer has indeed published the DA data truthfully, effectively making the Celestia nodes guarantors. Considering that Celestia has hundreds of validator nodes, we can consider this large-scale DAC to be relatively decentralized.

The DA solution adopted by Merlin is actually quite similar to Celestia's BlobStream, both of which open access permissions to the DAC in a decentralized manner through a POS mechanism. 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 of BTC, MERL, and even BRC-20 tokens, enabling a flexible staking mechanism, and also support proxy staking similar to Lido. (The POS staking protocol for oracles is essentially one of Merlin's core narratives going forward, offering relatively high staking rates and more.)

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

1. The sequencer receives a large number of transaction requests, aggregates them, and generates a data batch, which is then sent to Prover nodes and Oracle nodes (decentralized DAC).
2. Merlin's Prover nodes are decentralized and use lumoz's Prover as a Service. After receiving multiple data batches, the Prover pool generates corresponding zero-knowledge proofs (ZKPs), which are then sent to Oracle nodes for verification.
3. Oracle nodes verify the ZK Proof sent by lumoz's ZK pool to see if it corresponds to the data batch sent by the sequencer. If the two correspond and do not contain any errors, the verification is successful. During this process, decentralized Oracle nodes generate a multi-signature through threshold signatures, publicly declaring that the sequencer has indeed published complete DA data and that the corresponding ZKP is valid and has passed the verification of the Oracle nodes.
4. The sequencer collects the multi-signature results from the Oracle nodes, and once the signature count meets the threshold requirement, it sends this signature information to the Bitcoin blockchain, along with the datahash of the DA data (data batch) for external verification.

Oracle nodes handle the verification process of the ZK Proof by generating a Commitment, which is then sent to the Bitcoin blockchain, allowing anyone to challenge the "commitment." This process is essentially similar to bitVM's fraud proof protocol. If the challenge is successful, the Oracle node that published the Commitment will be economically penalized. Additionally, the data that Oracle needs to publish to the Bitcoin blockchain includes the current Layer2 state hash—StateRoot, as well as the ZKP itself, to allow external verification.

There are a few details that need to be explained. Firstly, according to Merlin's roadmap, in the future, Oracles will back up DA data to Celestia, allowing Oracle nodes to appropriately eliminate historical data locally without the need to store data permanently. Additionally, the Commitment generated by the Oracle Network is actually the root of a Merkle Tree. Simply disclosing the root is not enough; the complete dataset corresponding to the Commitment needs to be publicly disclosed, requiring a third-party DA platform, which can be Celestia, EigenDA, or another DA layer.

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

Above, we briefly outlined Merlin's workflow, and we believe that everyone now has a basic understanding of its structure. It is not difficult to see that Merlin, B^Square, BitLayer, and Citrea all follow a similar security model—Optimistic ZK-Rollup.

At first glance, this term may seem strange to many Ethereum enthusiasts—what does "Optimistic ZK-Rollup" mean? In the Ethereum community's understanding, the "theoretical model" of ZK Rollup is entirely based on the reliability of cryptographic calculations and does not require the introduction of trust assumptions. However, the term "optimistic" does introduce trust assumptions, meaning that people must optimistically assume that Rollup has not made any errors most of the time and is reliable. And if an error does occur, it can be punished through a fraud proof, which is the origin of "Optimistic Rollup," also known as OP Rollup.

For the Ethereum ecosystem, the concept of optimistic ZK-Rollup may seem out of place, but it actually fits the current state of Bitcoin Layer2. Due to technical limitations, the Bitcoin blockchain cannot fully verify ZK Proofs, and can only verify a specific step of the ZKP calculation in special cases. Under these circumstances, the Bitcoin blockchain can only support fraud proof protocols, where people can point out errors in the ZKP verification process and challenge them through fraud proofs. While this may not be comparable to Ethereum-style ZK Rollup, it is currently the most reliable and secure security model that Bitcoin Layer2 can achieve.

Under the optimistic ZK-Rollup scheme mentioned above, assuming there are N challengers with permission to initiate challenges in the Layer2 network, as long as one of these N challengers is honest and reliable, they can detect errors at any time and initiate a fraud proof, making the state transition of Layer2 secure. Of course, a highly reliable optimistic Rollup needs to ensure that its withdrawal bridge is also protected by a fraud proof protocol. However, almost all Bitcoin Layer2 solutions currently cannot meet this requirement and rely on multi-signature/MPC. Therefore, the selection of a multi-signature/MPC scheme becomes a crucial issue related to the security of Layer2.

Merlin has chosen Cobo's MPC service for its bridging solution, implementing measures such as cold-hot wallet isolation. The bridged assets are jointly managed by Cobo and Merlin Chain, and any withdrawal actions require the participation of MPC participants from Cobo and Merlin Chain, essentially ensuring the reliability of the withdrawal bridge through institutional credit endorsement. However, this is only a temporary measure at this stage. As the project gradually improves, the withdrawal bridge can be replaced by an "optimistic bridge" based on a 1/N trust assumption, by introducing BitVM and fraud proof protocols. However, the implementation difficulty of this approach will be quite high (almost all official Layer2 bridges currently rely on multi-signature).

Overall, we can summarize that Merlin has introduced a POS-based DAC, an optimistic ZK-Rollup based on BitVM, and an MPC asset custody solution based on Cobo, addressing the DA issue by opening DAC permissions; ensuring the security of state transitions by introducing BitVM and fraud proof protocols; and guaranteeing the reliability of the withdrawal bridge by introducing the well-known asset custody platform Cobo's MPC service.

Two-Step Verification ZKP Submission Based on Lumoz

Earlier, we outlined Merlin's security model and introduced the concept of optimistic ZK-Rollup. In Merlin's technical roadmap, it also mentions decentralized Provers. As we all know, the Prover is a core role in the ZK-Rollup architecture, responsible for generating ZKProof for Batches published by the Sequencer. The generation of zero-knowledge proofs is a resource-intensive process and a challenging problem.

To accelerate the generation of ZK proofs, the most basic operation is to parallelize and split the processing tasks. 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 complete proof.

To speed up the process of generating ZK proofs, Merlin will adopt Lumoz's Prover as a service solution, essentially pooling a large number of hardware devices together to form a mining pool, distributing computing tasks to different devices and allocating corresponding incentives, similar to POW mining.

In this decentralized Prover solution, there is a type of attack scenario known as a front-running attack: suppose an Aggregator has assembled a ZKP and sends it out in hopes of receiving a reward. Other Aggregators, upon seeing the content of the ZKP, may attempt to publish the same content ahead of the original Aggregator, claiming that they generated the ZKP first. How can this situation be resolved?

One instinctive solution that may come to mind is to assign specific task numbers to each Aggregator. For example, Task 1 can only be accepted by Aggregator A, and others will not receive a reward even if they complete Task 1. However, this method has a single point of failure. If Aggregator A experiences performance issues or goes offline, Task 1 will remain incomplete. Additionally, this method of assigning tasks to a single entity cannot improve production efficiency through competitive incentive mechanisms and is not a very effective solution.

Polygon zkEVM once proposed a method called Proof of Efficiency in a blog post, suggesting that competitive means should be used to encourage competition among different Aggregators, with rewards allocated on a first-come, first-served basis. The Aggregator that first submits the ZK-Proof to the chain can receive a reward. However, this method does not address the issue of MEV front-running.

Lumoz has adopted a two-step verification ZK proof submission method. After an Aggregator generates a ZK proof, they do not immediately send out the complete content, but only publish the hash of the ZKP. In other words, they publish the hash (ZKP + Aggregator Address). This way, even if others see the hash value, they do not know the corresponding ZKP content and cannot directly front-run.

Even if someone simply copies the entire hash and publishes it first, it is 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 it contains the address of Aggregator X, not A.

Through this two-step verification ZKP submission method, Merlin (Lumoz) can address front-running issues during the ZKP submission process, thereby achieving highly competitive incentives for zero-knowledge proof generation and improving the speed of ZKP generation.

Merlin's Phantom: Cross-Chain Interoperability

According to Merlin's technical roadmap, they will also support interoperability between Merlin and other EVM chains, following a similar implementation path to Zetachain's approach. If Merlin is the source chain and other EVM chains are the target chains, when a Merlin node detects a user's request for cross-chain interoperability, it triggers the subsequent workflow on the target chain.

For example, a controlled EOA account by the Merlin network can be deployed on Polygon. When a user publishes a cross-chain interoperability instruction on the Merlin Chain, the Merlin network first interprets its content, generates transaction data to be executed on the target chain, and then the Oracle Network processes the transaction through MPC signing, generating a digital signature for the transaction. Subsequently, Merlin's Relayer node releases this transaction on Polygon, completing the subsequent operations 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 also allowing direct cross-chain transfers to the Merlin Chain. This approach has several clear advantages: it can avoid the fee erosion associated with traditional asset cross-chain transfers and relies on Merlin's Oracle Network to ensure the security of cross-chain operations, without the need for external infrastructure. As long as users trust the Merlin Chain, they can assume that such cross-chain interoperability actions are reliable.

Conclusion

In this article, we have provided a brief interpretation of Merlin Chain's technical solution, 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 state of the Bitcoin ecosystem, we believe that such technical explanations are valuable and needed by the general public. We will continue to closely follow projects such as Merlin, bitLayer, and B^Square in the future, providing more in-depth analysis of their technical solutions. Stay tuned!

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。