Bitcoin Layer2 network Merlin has already accumulated billions of dollars in Total Value Locked (TVL), making it the largest and most followed one. This article will focus on the technical solutions of Merlin Chain and interpret its publicly available documents and protocol designs to help readers understand how this “top Bitcoin Layer2” operates.
(Table of Contents:
Merlin’s Decentralized Oracle Network: Open Chain DAC Committee
Security Model Analysis: Optimistic ZKRollup + Cobo MPC Service
Two-Factor Authentication ZKP Submission Scheme based on Lumoz
Merlin’s Phantom: Multi-chain Interoperability
Conclusion)
From the summer of 2023 to the present, Bitcoin Layer2 has always been the highlight of the entire Web3. Although the rise of this field is much later than Ethereum Layer2, Bitcoin, with its unique charm of Proof of Work (POW) and the successful launch of spot ETFs, has attracted billions of dollars in capital attention to Layer2 in just six months without worrying about the risk of “securitization”.
Among the Bitcoin Layer2 field, Merlin, with billions of dollars in TVL, is undoubtedly the largest and most followed one. With clear staking incentives and significant returns, Merlin has quickly emerged within a few months, creating an ecosystem myth that surpasses Blast. As Merlin gradually heats up, discussions about its technical solutions have become an increasingly popular topic.
In this article, GeekWeb3 will focus on the technical solutions of Merlin Chain, interpret its publicly available documents and protocol designs, and strive to help 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 Chain DAC Committee
For all Layer2 solutions, whether Ethereum Layer2 or Bitcoin Layer2, the cost of Data Availability (DA) and data release is one of the most critical issues to solve. Due to many inherent problems in the Bitcoin network itself and its lack of support for larger data throughput, it becomes a challenging problem for Layer2 projects to utilize the limited DA space.
One conclusion is obvious: if Layer2 “directly” releases unprocessed transaction data into the Bitcoin blockchain, it cannot achieve high throughput or low transaction fees. The most popular solution is either to compress the data size as much as possible and upload it to the Bitcoin blockchain or release the data directly in the Bitcoin chain.
In Layer2 solutions that adopt the first approach, the most well-known one is Citrea. They plan to upload the state changes of Layer2 within a certain period (state diff), which are the results of state changes on multiple accounts, along with the corresponding ZK proofs, to the Bitcoin chain. In this case, anyone can download the state diff and ZKP from the Bitcoin mainnet, and 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 apparent. If a large number of accounts undergo state changes in a short period, and Layer2 needs to upload the change information of these accounts to the Bitcoin chain, the final data release cost cannot be reduced significantly. This can be seen in many Ethereum ZK Rollup solutions.
Many Bitcoin Layer2 solutions simply take the second path: directly use DA solutions in the Bitcoin chain, either by building a DA layer themselves or using solutions like Celestia and EigenDA. B^Square, BitLayer, and Merlin, the protagonist of this article, all follow this chain-based DA scaling solution.
B^2 directly imitates Celestia and builds a DA network called B^2 Hub on the chain, which supports data sampling. The “DA data” such as transaction data or state diff is stored in the Bitcoin chain and only uploads the datahash/merkle root to the Bitcoin mainnet.
In fact, this treats Bitcoin as a trusted bulletin board: anyone can read the datahash from the Bitcoin chain. After obtaining the DA data from the off-chain data provider, you can check whether it corresponds to the datahash on the chain, i.e., hash(data1) == datahash1? If there is a correspondence, it means 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 related to certain “clues” on Layer1, preventing the DA layer from providing false data. However, there is an important malicious scenario: if the source of the data, the Sequencer, does not release the data corresponding to the datahash but only releases the datahash on the Bitcoin chain and deliberately withholds the corresponding data, what should be done in this case?
Similar scenarios include but are not limited to: only releasing ZK-Proof and StateRoot without releasing the corresponding DA data (state diff or transaction data). Although people can verify the ZK-Proof and confirm that the calculation process from Prev_Stateroot to New_Stateroot is valid, they do not know which accounts’ states have changed.
In this situation, although users’ assets are safe, no one can determine the actual state of the network, such as which transactions have been packaged and included on-chain, and which contract states have been updated. At this point, Layer2 is essentially equivalent to being offline.
This is actually “data withholding.” Dankrad from the Ethereum Foundation has briefly discussed similar issues on Twitter in August 2023, mainly focusing on something called “DAC.”
Many Ethereum Layer2 solutions that adopt off-chain DA often set up a committee composed of nodes with special permissions, known as the Data Availability Committee (DAC). This DAC committee serves 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 multisignature, and if the multisignature meets the threshold requirements (such as 2/4), the relevant contracts on Layer1 will default that the Sequencer has passed the verification of the DAC committee and has truthfully published complete DA data off-chain.
The DAC committees in Ethereum Layer2 solutions generally follow a Proof of Authority (POA) model, only allowing a few nodes that have undergone KYC or are officially designated to join the DAC committee. This makes DAC synonymous with “centralization” and “consortium chain.” In addition, in some Ethereum Layer2 solutions that adopt the DAC model, the Sequencer only sends DA data to DAC member nodes and hardly uploads data elsewhere. To obtain DA data, anyone must obtain permission from the DAC committee, similar to a consortium chain.
Undoubtedly, the DAC should be decentralized, and Layer2 may not directly upload DA data to Layer1. However, the admission rights of the DAC committee should be open to the public to prevent a few people from colluding and acting maliciously. (For discussions on malicious scenarios in DAC, refer to Dankrad’s previous tweets.)
BlobStream proposed by Celestia essentially replaces the centralized DAC and allows the Sequencer of Ethereum Layer2 to release DA data to the Celestia chain. If 2/3 of Celestia nodes sign the data, the Layer2-specific contracts deployed on Ethereum will assume that the Sequencer has truthfully published DA data off-chain, making Celestia nodes the guarantors. Considering that Celestia has hundreds of validator nodes, we can consider this large-scale DAC as relatively decentralized.
Merlin’s DA solution is actually closer to Celestia’s BlobStream, both of which use Proof of Stake (POS) to open the admission rights of the DAC, making it more decentralized. Anyone who stakes enough assets can operate a DAC node. In Merlin’s documentation, these DAC nodes are called Oracles, and it is mentioned that asset staking for BTC, MERL, and even BRC-20 tokens will be supported, achieving a flexible staking mechanism and supporting proxy staking similar to Lido. (The POS staking protocol of the oracle will be one of Merlin’s core narratives in the future, with higher staking rates provided, etc.)
Here is a brief description of Merlin’s workflow (see image below):
The Sequencer receives a large number of transaction requests and aggregates them to generate a data batch, which is then sent to Prover nodes and Oracle nodes (decentralized DAC).
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 and sends them to Oracle nodes for verification.
Oracle nodes verify the ZK proofs sent by lumoz’s ZK Prover, whether they correspond to the data batches sent by the Sequencer. If they correspond and do not contain other errors, the verification is passed. In this process, decentralized Oracle nodes generate a multisignature through threshold signatures, publicly declaring that the Sequencer has fully published DA data and the corresponding ZKP is valid, passing the verification of Oracle nodes.
The Sequencer collects multisignature results from Oracle nodes. When the number of signatures meets the threshold requirements, it sends the signature information to the Bitcoin chain, along with the datahash of the data batch, for external reading and confirmation.
Oracle nodes process the calculation process of verifying the ZK proofs and generate commitments, which are sent to the Bitcoin chain. Anyone can challenge the “commitment” and verify its validity.The process here is basically the same as the fraud-proof protocol of bitVM. If the challenge is successful, the Oracle node releasing the Commitment will be economically penalized. Of course, Oracle needs to release the data on the Bitcoin chain, including the hash of the current Layer2 state – StateRoot, as well as the ZKP itself, for external verification.
There are several details that need to be explained. First of all, the Merlin roadmap mentions that in the future, Oracle will back up the DA data to Celestia, so that Oracle nodes can appropriately eliminate local historical data and do not need to keep the data permanently. At the same time, the Commitment generated by the Oracle Network is actually the root of a Merkle Tree. It is not enough to only disclose the root externally. The complete dataset corresponding to the Commitment needs to be made public. This requires finding a third-party DA platform, which can be Celestia or EigenDA, or other DA layers.
Security model analysis: Optimistic ZK-Rollup + Cobo’s MPC service
We have briefly described the workflow of Merlin, and I believe everyone has a basic understanding of its structure. It can be seen that Merlin, B^Square, BitLayer, and Citrea all follow the same security model – Optimistic ZK-Rollup.
At first glance, the term “Optimistic ZK-Rollup” may seem strange to many Ethereum enthusiasts. In the Ethereum community’s understanding, the “theoretical model” of ZK-Rollup is completely based on the reliability of cryptographic calculations and does not require the introduction of trust assumptions. However, the term “optimistic” precisely introduces trust assumptions, which means that people need to optimistically believe that Rollup does not have errors most of the time and is reliable. Once an error occurs, the Rollup executor can be punished through fraud-proof to challenge it. This is Optimistic Rollup, also known as OP Rollup.
For the Ethereum ecosystem, Optimistic ZK-Rollup may be somewhat different, but it fits the current situation of Bitcoin Layer2. Due to technical limitations, the Bitcoin chain cannot fully verify ZK Proofs. It can only verify a certain step of the ZKP calculation process under special circumstances. In this premise, the Bitcoin chain can only support fraud-proof protocols. People can point out errors in a certain calculation step during off-chain verification of ZKP and challenge them through fraud-proof. Of course, this cannot be compared to Ethereum-style ZK-Rollup, but it is the most reliable and secure security model that Bitcoin Layer2 can currently achieve.
In the optimistic ZK-Rollup scheme mentioned above, assuming that there are N people in the Layer2 network with the authority to initiate challenges, as long as one of these N challengers is honest and reliable, they can detect errors and initiate fraud-proof, and the state transition of Layer2 is secure. Of course, a highly reliable optimistic Rollup needs to ensure that its withdrawal bridge is also protected by the fraud-proof protocol. Currently, almost all Bitcoin Layer2 solutions cannot meet this premise and rely on multi-signature/MPC. Therefore, how to select the multi-signature/MPC scheme becomes a question closely related to the security of Layer2.
Merlin chooses Cobo’s MPC service in the bridge solution, which uses measures such as cold and hot wallet isolation. The bridged assets are jointly managed by Cobo and Merlin Chain. Any withdrawal action requires the participation of Cobo and Merlin Chain’s MPC participants. Essentially, it guarantees the reliability of the withdrawal bridge through the credit endorsement of institutions. Of course, this is only a temporary solution at this stage. With the gradual improvement of the project, the withdrawal bridge can be replaced by a “optimistic bridge” based on 1/N trust assumptions by introducing BitVM and fraud-proof protocols. However, the difficulty of implementing this approach will be greater (currently, almost all official bridges of Layer2 rely on multi-signature).
Overall, we can summarize that Merlin introduces a POS-based DAC, an optimistic ZK-Rollup based on BitVM, and an MPC asset custody solution based on Cobo. It solves the DA problem by opening DAC permissions, ensures the security of state transitions by introducing BitVM and fraud-proof protocols, and guarantees the reliability of the withdrawal bridge by introducing Cobo’s well-known asset custody platform.
Based on Lumoz’s two-step verification ZKP submission scheme
In the previous section, we summarized the security model of Merlin and introduced the concept of optimistic ZK-Rollup. In Merlin’s technical roadmap, it also mentions the decentralized Prover. It is well known that the Prover is a core role in the ZK-Rollup architecture, responsible for generating ZKProof for the batches released by the Sequencer. The process of generating zero-knowledge proofs is very resource-intensive and a challenging problem.
To accelerate the generation of ZK proofs, the basic operation is to parallelize and divide the tasks. Parallelization means splitting the task of generating ZK proofs into different parts and having different Provers complete them separately. Finally, the Aggregator aggregates multiple proofs into one.
To speed up the generation of ZK proofs, Merlin will adopt Lumoz’s Prover as a service solution, which is actually to gather a large number of hardware devices together to form a mining pool and distribute the computing tasks to different devices, along with the corresponding incentives, similar to POW mining.
In this decentralized Prover scheme, there is a type of attack scenario known as front-running attack. Suppose an Aggregator has assembled a ZKP and sends it out in order to receive rewards. When other Aggregators see the content of the ZKP, they can front-run and release the same content claiming that they generated the ZKP first. How can this situation be resolved?
One intuitive solution is to assign each Aggregator a specific task number. For example, only Aggregator A can accept Task 1, and others cannot receive rewards even if they complete Task 1. However, this method has a problem: it cannot withstand single-point risks. If Aggregator A experiences a performance failure or goes offline, Task 1 will be stuck and cannot be completed. Moreover, this method of assigning tasks to a single entity cannot improve production efficiency with competitive incentive mechanisms, so it is not a good solution.
Polygon zkEVM proposed a method called Proof of Efficiency in a blog post, which pointed out that competitive means should be used to promote competition among different Aggregators, and incentives should be allocated on a first-come, first-served basis. The Aggregator who submits the ZK-Proof first can receive rewards. However, he did not mention how to solve the MEV front-running problem.
Lumoz adopts a two-step verification ZKP submission method. After an Aggregator generates a ZK proof, instead of immediately sending out the complete content, only the hash of the ZKP is released, in other words, the hash(ZKP+Aggregator Address) is released. In this way, even if others see the hash value, they do not know the corresponding ZKP content and cannot directly front-run it.
If someone simply copies the entire hash and releases it first, it is also meaningless because the hash contains the address of a specific Aggregator X. Even if Aggregator A releases this hash first, when the pre-image of the hash is revealed, everyone will see that the address contained in it is X’s, not A’s.
Through this two-step verification ZKP submission scheme, Merlin (Lumoz) can solve the front-running problem in the ZKP submission process and achieve highly competitive incentives for zero-knowledge proof generation, thereby 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, which is basically in line with the previous Zetachain’s approach. If Merlin is the source chain and other EVM chains are the target chains, when the Merlin node detects a cross-chain interoperability request from the user, it will trigger subsequent workflows on the target chain.
For example, a EOA account controlled by the Merlin network can be deployed on Polygon. When a user releases a cross-chain interoperability instruction on the Merlin Chain, Merlin network first parses its content and generates a transaction data to be executed on the target chain. Then, Oracle Network processes the transaction through MPC signature and generates a digital signature for the transaction. Afterwards, Merlin’s Relayer node releases this transaction on Polygon, and the subsequent operation is completed in the assets of the EOA account controlled by Merlin on the target chain or even directly across to Merlin Chain. This solution has some obvious advantages: it can avoid the transaction fees incurred by traditional asset cross-chain bridges and is directly guaranteed for cross-chain operations by Merlin’s Oracle Network, without relying on external infrastructure. As long as users trust Merlin Chain, they can default to such cross-chain interoperability actions as being problem-free.
In conclusion, in this article, we have provided a brief interpretation of Merlin Chain’s technical solutions, 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 booming Bitcoin ecosystem, we believe that this kind of technical popularization is valuable and needed by the general public. We will continue to follow up on projects such as Merlin, bitLayer, and B^Square in the future and provide more in-depth analysis of their technical solutions. Please stay tuned!
Related Reports
Merlin Chain airdrop is here! How to claim MERL tutorial, current OTC price
MerlinStarter announces the end of $MSTAR subscription, raising a total of approximately 400 million yuan, oversubscribed by 20,000%
Merlinchain’s first launch platform – MerlinStarter’s token “$MSTARD” IDO starts, with 50 million tokens available for subscription