Interpretation of Merlin Technical Scheme: How does it work?

Author: Faust, Geek web3

Since the summer of 2023, Bitcoin Layer2 has been the highlight of the entire Web3.Although the rise in this field is far later in Ethereum Layer2, with the unique charm of POW and the smooth landing of spot ETFs, Bitcoin, which is not necessary to worry about the risk of “securitization”, is in just half a year. This is Layer2.The derivative track has attracted the capital attention of tens of billions of dollars.

In the Bitcoin Layer2 track, Merlin, which has billions of dollars in TVL, undoubtedly is undoubtedly the one with the largest volume and the most followers.With clear pledge incentives and considerable yields, Merlin suddenly burst into the ground within a few months, creating an ecological myth that surpassed Blast.With the gradual fiery Merlin, the discussion on its technical solution has also become a topic of more and more attention.

In this article, Geek WEB3 will focus onMerlin Chain technical solution, interpret its public document and protocol design ideas,We are committed to letting more people understand Merlin’s general workflow, and have a clearer understanding of its security models, so that everyone can understand how this “head Bitcoin Layer2” works in a more intuitive way.

Merlin’s decentralized prophecy network: open DAC committee under the open chain

For all Layer2, whether it is Ethereum Layer2, or Bitcoin Layer2, DA and data release costs are one of the most important issues.Because there are many problems in the Bitcoin network itself, it is natural that it does not support larger data throughput. How to use this inch of gold in DA space has become a problem to test the imagination of the Layer2 project party.

There is a conclusion that it is obvious: if Layer2 “directly” publishes the processing data that is not processed into the Bitcoin block, it can neither achieve high throughput, nor low fees.The most mainstream solution is either by height compression to compress the data size as small as possible, and then upload it to the Bitcoin block, or directly publish the data under the Bitcoin chain.

In Layer2, which is used in the first idea, the most famous may be citrea. They intend to make the state of Layer2 in a period of time, that is, the status change results on multiple accounts. Together with the corresponding ZK proof, upload together upload togetherGo to the Bitcoin chain.In this case, anyone can download the State Diff and ZKP from the Bitcoin main network, and then monitor the changes in the status of the Citrea.This method can reduce the data size of the chain by more than 90%.

Although this can greatly compress the data size, the bottleneck is still obvious.If a large number of account changes in a short period of time, Layer2 will summarize the change of these accounts to the Bitcoin chain.ZK Rollup is evident.

Many Bitcoin Layer2 simply take the second path: directly use the DA solution under the Bitcoin chain, either build a DA layer by yourself, or use Celestia, EIGENDA, etc.B^Square, Bitlayer, and Merlin, the protagonist of this article, all use the DA expansion scheme under this chainEssence

In the previous article in Geek Web3–“Analysis B^2 new version of the technical roadmap: the necessity of DA and verification layers under the Bitcoin chain”In, we mentioned that B^2 directly imitates CELESTIA and built a DA network that supports data sampling functions under the chain, named B^2 HUB.”DA data” such as transaction data or State Diff is stored under the Bitcoin chain, and only uploads Datahash / Merkle Root to Bitcoin’s main online online.

This is actually a bred board that treats Bitcoin as a trustworthiness: anyone can read Datahash from the Bitcoin chain.When you get DA data from the data provider under the chain, you can check whether it corresponds to the Datahash on the chain, That is, Hash (data1) == Datahash1?EssenceIf there is a corresponding relationship between the two, it means that the data provider under the chain gives you is right.

(Layer2 schematic diagram of the DA layer exists under the Bitcoin chain

Picture source: Geek Web3)

The above process can ensure the data provided by the nodes under the chain, which is associated with some “clues” on Layer1 to prevent false data from malicious DA layers.But there is a very important evil scene here: if the source of the data -SEQUENCER, does not send out the Datahash corresponding Datahash at all, only send Datahash to the Bitcoin chain, but deliberately deduct the corresponding data from allowing anyone to read.Take, what should I do at this time?

Similar scenes include, but not limited to: only publish ZK-Proof and Staticoot, but do not release the corresponding DA data (State Diff or Transaction Data).But I don’t know what accounts have changed.In this case, although the assets of the user are safe, everyone cannot determine the actual state of the network at all. I do n’t know which transactions have been packed and the state of the contract is updated. At this time, Layer2 is basically equivalent to the shutdown.

This is actually“Data detention”The Ethereum Foundation’s Dankrad used to discuss similar issues on Twitter in August 2023. Of course, he mainly targeted something called “DAC”.

Many of the Ethereum Layer2 adopt a DA solution under the chain, oftenSet several nodes with special permissions to form a committee, and the full name is Data Availability Community (DAC).This DAC committee has played the role of the guarantorThe outside claim: Sequencer has indeed published a complete DA data (Transaction Data or State Diff) under the chain.Then the DAC node collectively generates a multi -sign. As long as you sign more to meet the threshold requirements (such as 2/4), the relevant contracts on Layer1 will default. The Sequencer passed the DAC Commission’s inspection.Essence

The DAC Committee of Ethereum Layer2 basically follows the POA mode, and only allows a few to join the DAC committee through KYC or officially designated nodes.This has made DAC synonymous with “centralization” and “alliance chain”.In addition, in some Ethereum Layer2 in some DAC mode, the sorter only sends DA data to the DAC member node, and it will hardly upload data to other places. If anyone wants to obtain DA data, it must get the permission of the DAC committee.There is no essential difference between the alliance chain.

There is no doubt that DAC should be decentralized. Layer2 may not upload DA data to Layer1 directly, but the access authority of the DAC Commission should be open to the public to prevent a few people from seeking evil.(Discussion on DAC’s evil scenes, you can refer to Dankrad’s previous speeches on Twitter)

The Blobstream previously proposed by Celestia is essentially a centralized DAC with Celestia replaced by Celestia for replacing DAC, Ethereum L2’s sorter can publish DA data to the Celestia chain. If there are 2/3 CELESTIA nodes signed, the Layer2 exclusive contract deployed on Ethereum believes that the sorter has released DA data truthfully.Let the Celestia node be the guarantor.Considering that Celestia has hundreds of Validator nodes, we can think that this large DAC is more decentralized.

The DA solution adopted by Merlin is actually closer to Celestia’s Blobstream. It is all open the access authority of DAC through the form of POS to make it decentralized.Anyone can run a DAC node as long as he pledged enough assets.In Merlin’s documentation, the above DAC node is called Oracle, and it is pointed out that it will support BTC, Merl, and even BRC-20 token asset pledge to achieve flexible pledge mechanisms and support agent pledge similar to LIDO.(The POS pledge protocol of the prediction machine is basically one of Merlin’s next core narrative, and the pledge interest rate provided is relatively high)

Here we will briefly describe Merlin’s workflow (the picture is below):

After receiving a large number of transaction requests, the sorter Sequencer will summarize it and generate DATA BATCH (data batch), pass it to the PROVER node, and Oracle node (decentralized DAC).
Merlin’s Prover node is decentralized and uses Lumoz’s Prover as a Service service.After receiving multiple Data BATCH, the PROVER Mining Pond will generate corresponding zero knowledge proof. After that, ZKP will be sent to the Oracle node and will be verified by the latter.
Oracle nodes verify whether the ZK Proof from the ZK mining pool of LMUOZ can correspond to the Data Batch sent by Sequencer.If the two can correspond to it and do not include other errors, they pass the verification.In this process,The decentralized Oracle node will generate multiple signatures through the threshold signature, and the external statement -the sorter is completely issued DA data, and the corresponding ZKP is effective and passed the verification of the Oracle node.
The sorter collects multiple signing results from the Oracle node. When the number of signatures meets the threshold requirements, the signature information is sent to the Bitcoin chain, and DATAHASH with DA data (DATA BATCH) is read and confirmed by the outside world.

(Merlin working schematic diagram: Geek web3)

Oracle nodes are specially processed to verify the computing process of ZK Proof, and generate the commission promise to send it to the Bitcoin chain to allow anyone to challenge the “commitment”.The process in which is basically the same as the Bitvm fraud certificate agreement.If the challenge is successful, the Oracle node of the Commitment will be punished by economic punishment.Of course, the data that Oracle is published on the Bitcoin chain also includes the current Layer2 status Hash -Sttersoot, and ZKP itself, all must be published on the Bitcoin chain to allow external detection.

Reference materials:“Minimalist interpretation BITVM: how to verify the fraud certificate on the BTC chain”

There are several details that need to be elaborated. First of all, the Merlin route diagram mentioned that in the future, Oracle will back up DA data to CELESTIA. In this way, Oracle nodes can eliminate local historical data appropriately.Data forever exists local.At the same time, the Commitment generated by Oracle Network is actually a Merkle Tree ROOT. It is not possible to disclose ROOT alone. To make all the complete data sets corresponding to the Commitment, you need to find a third -party DA platform. This platform can be.Celestia or EIGENDA can also be other DA layers.

Reference materials:“Analysis B^2 new version of the technical roadmap: the necessity of DA and verification layers under the Bitcoin chain”

Security model analysis: optimistic ZKroll’s MPC service

We briefly describe Merlin’s workflow. I believe that everyone has mastered their basic structures.It is not difficult to see that Merlin and B^Square, Bitlayer, and Citrea basically follow the same security model-optimistic ZK-Rollup.

When reading this word, it may make many Ethereum enthusiasts weird. What is “optimistic ZK-Rollup”?In the cognition of the Ethereum community, ZK Rollup’s “theoretical model” is completely based on the reliability of cryptographic computing. There is no need to introduce the assumptions of trust.Most of the time, it is reliable to think that there is no error in ROLLUP.Once an error occurs, the Rollup operator can be punished by fraudulent proof. This is optimistic Rollup -OPTIMISTIC ROLLUP, also known as the name of OP Rollup.

For the Ethereum ecosystem of the Rollup base camp, the optimistic ZK-Rollup may be a bit uncomfortable, but this exactly the status quo of Bitcoin Layer2.Due to technical restrictions, the unable to verify the ZK Proof on the Bitcoin chain, which can only verify the calculation process of ZKP under special circumstances. Under this premiseYou can point out that during the verification process of ZKP, a certain calculation step is wrong and challenged through the method of fraud. Of course, this cannot be aligned with the Ethereum -style ZK Rollup, but it is the most at the end of the Bitcoin Layer2 that it can be achieved.Reliable and most stable security model.

Under the above optimistic ZK-Rollup scheme,Suppose there are n people who have the authority in the Layer2 network, as long as one of the N challengers is honest and reliable, it can detect errors at any time and initiate fraud.EssenceOf course, the optimistic Rollup with a high degree of completion needs to ensure that its withdrawal bridge is also protected by the fraudulent proof. At present, almost all Bitcoin Layer2 cannot achieve this premise.The signing/MPC solution has become a question that is closely related to Layer2’s security.

Merlin chose Cobo’s MPC service on the bridge, andAdopting measures such as hot and cold wallet isolation, bridge assets are jointly managed by COBO and Merlin Chain. Any withdrawal of MPCs of Cobo and Merlin Chain requires the joint processing.EssenceOf course, this is only the right measure of the current stage. As the project gradually improves, the withdrawal bridge can be used to introduce the “optimistic bridge” of 1/N trust assumption by introducing BITVM and fraud.Big (currently almost all Layer2 official bridges depend on multiple signing).

On the whole, we can sort out,Merlin introduced POS-based DAC, Bitvm-based optimistic ZK-Rollup, COBO-based MPC asset custody solutionThe DA problem is solved by opening DAC permissions; the security of status conversion is guaranteed by introducing the Bitvm and the fraud proof protocol; the MPC service of the well -known asset custody platform COBO is introduced to ensure the reliability of the withdrawal bridge.

Two -step verification ZKP submission plan based on Lumoz

Earlier we sorted out Merlin’s security model and introduced the concept of optimism ZK-Rollup.In Merlin’s technical roadmap, I also talked about decentralized Prover.As we all know, Prover is a core role in the ZK-Rollup architecture. It is responsible for generating ZKProof for Batch released by Sequencer, and the generating process of zero-knowledge proof is exactly very hard-consuming, which is a very difficult problem.

It is the most basic operation to accelerate the generation of ZK proof and divide the task parallelization.EssenceThe so -called parallelization is actually cutting the generating task proven by ZK into different parts, which are completed separately by different proVers, and finally the aggregator aggregation aggregates multiple proofs into a whole.

In order to accelerate the generation process of ZK,Merlin will adopt Lumoz’s Prover as a Service solutionIn fact, it is to gather a large amount of hardware equipment to form a mining pool together, then allocate the computing task to different devices, and allocate the corresponding incentives, which is similar to POW mining.

In this decentralized Prover solution, there is a type of attack scene, commonly known as running attack: Assuming that a polymer Aggregator has formed ZKP, it sends ZKP out to get a reward.After seeing the content of ZKP, other aggregates ran the same content in front of him, claiming that this ZKP was made up by himself. How can this situation be solved?

Maybe one of the most instinctive solutions everyone thinks is to allocate the specified task number to each Aggregator. For example, the task 1 can only be connected by Aggregator A, and even if others complete the task 1, they cannot get the reward.But there is a problem with this method that cannot resist the risk of a single point.If Aggregator A has a performance failure or a drop, task 1 will always be stuck and cannot be completed.Moreover, this method that assigns tasks to a single entity cannot improve production efficiency with a competitive incentive mechanism, which is not a good way.

Polygon Zkevm has proposed a method called Proof of Efficience in a blogIt pointed out that competition should be promoted by competitive means, and competition between different aggregator should be assigned to allocate incentives in the way to get first. The first Aggregator submitted by ZK-PROOF can be rewarded.Of course, he did not mention how to solve the problem of MEV running.

Lumoz uses two -step verification ZK certification method. After a certain Aggregator generates ZK proof, you do n’t need to send out the complete content, but only publish the Hash of ZKP. In other words, the Hash (ZKP+Aggregator Address) is published.In this way, even if others saw the HASH value, they did not know the corresponding ZKP content, and could not run directly;

If someone simply copy the entire Hash copy of the first release, it is meaningless, because Hash contains the address of a specific aggregate X. Even if the aggregate A first releases this hash, when the original image of HASH is revealed, everyone will also be everyone.See the address of the aggregation in which is X, not A.

Through this two -step verification ZKP submission scheme, Merlin (Lumoz) can solve the problem of grabbing during the ZKP submission process, thereby achieving a highly competitive zero -knowledge proof to generate incentives, thereby increasing the speed of ZKP.

Merlin’s Phantom: Multi -chain operation

According to Merlin’s technical roadmap, they will also support the interoperability between Merlin and other EVM chainsThe implementation path is basically the same as the previous idea of ZetAChain. If Merlin is used as the source chain, other EVM chains are used as the target chain. When the Merlin node perceives the cross -chain interoperability request from the user, the subsequent work will be triggered on the target chain on the target chainprocess.

For example, you can deploy an EOA account controlled by Merlin network on Polygon,When users issue cross -chain interoperability instructions on Merlin Chain, Merlin network first analyzes its content, generates a transaction data executed on the target chain, and then signed the MPC signature of the transaction by Oracle Network to generate the number of the transaction.sign.After Merlin’s Relayer node released the transaction on PolygonThe follow -up operation of the assets in the EOA account through Merlin on the target chain is.

When the user’s required operation is completed, the corresponding assets will be directly forwarded to the address of the user on the target chain, and theoretically, it can also be directly across the Merlin Chain.There are some obvious benefits of this scheme: it can avoid the wear of the fees generated by the cross -chain contract when the traditional asset cross -chain is cross -chain, and it is directly to ensure the security of cross -chain operations by the Oracle Network of Merlin.Infrastructure.As long as the user trusts Merlin Chain, there is no problem with such cross -chain interoperability.

Summarize

In this article, we briefly interpreted the general technical solution of Merlin Chain. I believe that more people can understand Merlin’s general workflow and have a clearer understanding of its security model.Considering that the current Bitcoin ecosystem is in full swing, we believe that the popular science behavior of such technology is valuable and the masses need.We will conduct long -term follow -up of projects such as Merlin and Bitlayer, B^SquareFor more in -depth analysis of its technical solutions, please stay tuned!