Today we are going to talk about Merlin chain, a flagship Bitcoin layer 2 project that was launched yesterday. We have actually talked about its staking activities before, so those who did the tasks yesterday also received airdrops, because it was quite rewarding. Because Merlin currently has a TVL of 3 billion US dollars, far exceeding other BTC layer2 projects, so today we will take a look at what Merlin’s technical strengths are and what price point is more appropriate?
Overview
Merin chain is a Bitcoin layer 2 solution developed by the team behind Bitmap Jech (formerly known as Recursiverse). It integrates ZK-Rollup network, decentralized Oracle network, data availability and on-chain BTC fraud proof module. Merin chain is committed to empowering Bitcoin's native assets, protocols and products through its second-layer network. It supports multiple Bitcoin protocols such as BRC-20, BRC-420, Atomicals, Pipe, etc. Merin Chain is also compatible with EVM and operates with low fees and high scalability.
Merlin Chain utilizes zero-knowledge proofs submitted to Bitcoin for commitment verification, providing enhanced support for the Bitcoin network. It allows challengers to present fraud proofs on controversial matters, leveraging Bitcoin’s robust consensus mechanism to ensure the security of the Merlin Chain network. This ensures that users within the ecosystem are in a secure, practical, comprehensive and cost-effective network environment.
Architecture
Merlin Chain’s infrastructure is built on Polygon’s ZK technology, providing a decentralized oracle network through Celestia for data availability, and its computing power is supported by Lumoz’s decentralized ZK computing power network for zero-knowledge proof computing.
Merlin Chain provides Bitcoin's leading zero-knowledge (ZK) expansion solution with the following advantages:
- Security: Inherits the security of Bitcoin while providing additional advantages in L2 batch scalability.
- EVM compatibility: Supports most existing smart contracts, developer tools, and wallets, ensuring seamless interoperability.
- Low cost: Using ZK proof combined with zkSNARK to reduce space consumption in L1 and optimize transaction costs for users.
- High Performance: Fast network finality through frequent validity proofs and ultimate scalability through recursive STARKs.
Zero-knowledge proof generation and commitment verification
Merlin Chain’s ZK-L2 utilizes Polygon CDK technology, and zero-knowledge proof is supported by Lumoz’s decentralized ZK computing power network.
Proof Generation
Similar to other Polygon CDK chains, Merlin Chain handles proof generation and verification of transactions through a component called zkProver, which is a zero-knowledge proof generator. All rules for valid transactions are implemented and enforced in zkProver.
zkProver performs complex mathematical calculations in the form of polynomials and assembly language, and then verifies them on the smart contract. These rules can be seen as constraints that transactions must follow in order to modify the state tree or exit the tree.
Interaction with nodes and database (DB)
zkProver mainly interacts with two components, the node and the database. Below is a flowchart that clearly explains the process.
As shown in the flowchart above, the entire interaction is divided into four steps.
1 → The node sends the contents of the Merkle tree to the database and stores it
2 → The node then sends the input transaction to zkProver
3 → zkProver accesses the database and obtains the information required for verifiable proof of the transaction sent by the node. This information includes the Merkle root, related sibling keys, and hash values.
4 → zkProver then generates transaction proofs and sends these proofs back to the nodes.
state machine
zkProver adopts a modular design. In addition to some components, it mainly consists of a group of finite state machines. It has a total of 13 finite state machines.
Main finite state machine
Auxiliary finite state machine → Binary SM, Storage SM, Memory SM, Arithmetic SM, Keccak function SM, PoseidonG SM
Auxiliary finite state machine → Pad-PG SM, Pad-KK SM, Bit Field SM, Memory Alignment SM, Byte4 SM, ROM SM
Due to the modular design of zkProver, the main finite state machine can delegate as many tasks as possible to other specialized finite state machines. This greatly improves the efficiency of the main SM.
Auxiliary finite state machine
The master SM executor directly instructs each auxiliary finite state machine by sending appropriate instructions (called “actions”), as shown in the following figure.
Zero-knowledge assembly
As an assembly language, the zero-knowledge assembly (or zkASM) language is specifically designed to map instructions in the zkProver master finite state machine to other finite state machines. For finite state machines with firmware, zkASM is the interpreter of the firmware.
The specified assembly code is generated from the zkASM code, using instructions from the main finite state machine to specify how a given SM executor must perform the computation. The executor strictly follows the logic and conventions of the zkASM code, making computation verification simple.
Polynomial Identity Language
The Polynomial Identity Language (or PIL) is designed specifically for zkProver. Almost all finite state machines use polynomials to express computations. Therefore, the state transitions in a finite state machine must satisfy the computation of a specific polynomial identity.
Polygon zkEVM is creating the most effective solution to the blockchain trilemma of privacy, security, and scalability. The background is an efficient zero-knowledge commitment scheme. So far, the most reliable and efficient commitment scheme is the polynomial commitment scheme.
Prove correctness of execution
zkProver’s final state machine is designed to execute programs and ensure that they are executed correctly.
Therefore, each auxiliary state machine contains its own executor and a PIL program that can be used to check whether all instructions sent by the main SM executor are executed correctly.
The components of zkProver include the following four parts.
- Executor or Master FSM Executor
-STARK recursive component
-CIRCOM library
-Zk-SNARK Prover
In short, zkProver generates verifiable proofs using these four components. Therefore, the constraints that each proposed batch must satisfy are either polynomial constraints or polynomial identities. All valid batches must satisfy a specific polynomial constraint.
Actuator
The executor, or main finite state machine executor, handles the execution of the zkEVM. This is where the new zero-knowledge assembly language (or zkASM), developed specifically by the Polygon zkEVM team, is used to interpret the EVM bytecode.
It takes as input; transaction, old and new state, ChainID of Sequencer, etc. The Executor also needs
PIL, which stands for Polynomial List, Register List, and ROM, stores and executes instruction lists
The executor setup must satisfy polynomial constraints for each valid batch of transactions. Another language specially developed by the team called Polynomial Identity Language (or PIL) is used to encode all polynomial constraints.
The executor executes all instructions on the PIL hardware and generates the submitted polynomial; this is the thin state machine loop, or the list of all states. It also generates some common data that forms part of the input to the zk-SNARK validator.
Decentralized Oracle Network
In Merlin Chain's L2 architecture, sequence nodes collect and batch transactions, generating compressed transaction data, ZK state roots, and proofs through zkEVM. The decentralized Oracle network compiles this L2 data and uploads it to the taproot of the Bitcoin mainnet, making it publicly accessible to the entire network.
The workflow of Merlin Chain can be summarized as follows: ZK L2 collects and batches transactions, and then zkProver generates proofs. At the same time, transaction raw data, Merkle trees, Bitcoin status, and other data are aggregated to form a joint proof and synchronized with the Oracle network.
Upon receiving this L2 data, the Oracle network performs circuit compilation, submitting the compressed data and commitment to the taproot of the Bitcoin mainnet, making this data publicly verifiable and accessible to all participants.
Oracle nodes play an important role in the Merlin chain. They are not only responsible for verifying zero-knowledge proofs in the Merlin chain, but also for uploading layer 2 (L2) data to the taproot of the Bitcoin mainnet.
ZKP Final Settlement:
Oracle nodes assist proof aggregators in preparing zero-knowledge proofs (ZKP) and submitting them to the taproot of a Bitcoin block. This proof confirms the validity of the batched transactions and updates the chain state on layer 2 without revealing the details.
Decentralized Verification:
As a decentralized entity, the Oracle node network ensures joint verification of data availability (DA) and zk proofs. This means that each node participates in the verification process independently, enhancing the security and decentralization of the entire system.
Oracle nodes not only participate in transaction verification and confirmation, but also interact with the Bitcoin mainnet to ensure seamless integration and security of layer 2 solutions with the Bitcoin network. This design enhances Merlin Chain's ability to serve as an efficient, secure and decentralized blockchain platform.
Oracle Node Staking Mechanism
In the multi-token staking system of Merlin Chain, the staking mechanism is a key component to maintain network security, incentivize participants and ensure decentralization. This mechanism allows users to participate in the governance and data verification process of Merlin Chain by staking different crypto assets or proxy staking to existing Oracle nodes.
Asset security and transparency
In order to protect the assets pledged by users, the system uses multi-signature and cold storage technology to ensure the security of assets. All staking and reward distribution processes are open and transparent, and users can check their staking status and expected returns at any time. In addition, the use of smart contracts ensures the immutability and automation of the staking process, further improving the credibility of the system.
Staking Rewards
The staking rewards for Oracle nodes are mainly composed of two parts: block rewards and transaction fees. Block rewards are Merl tokens issued at a certain inflation rate and distributed according to the node's staking weight and network performance. Transaction fees are BTC tokens, which extract a certain percentage of transaction fees from each transaction in the Merlin chain.
The staking rewards will be distributed according to the type and amount of the staked assets. BTC stakers will receive 40% of the rewards, Merl stakers will also receive 40% of the rewards, and the remaining 20% of the rewards will be distributed to stakers of other mainstream assets (such as BRC20).
To ensure the fairness of reward distribution, we will use a weighted average algorithm based on market value and staked amount. This algorithm will take into account the market value and liquidity of different assets, as well as the staked amount of each Oracle node, to calculate the rewards that each node should receive.
Safety measures
Node selection and elimination
The selection of Oracle nodes will be based on a series of criteria, including the amount of stake, online duration, verification success rate, etc. The system will evaluate Oracle nodes regularly, and nodes with poor performance will be eliminated. New nodes will be selected based on their performance and community evaluation.
The process of ZKP to BTC network
The decentralized oracle network combines data availability (DA) and zk proof verification. The specific process can be broken down as follows:
Batch Formation:
User transactions are collected and organized into batches by the sequencer.
Batch Verification:
Once a batch is formed, it is validated and the batch data and its hash value are transmitted to the Oracle node.
Data Validation and Storage:
Each Oracle node independently verifies the batch of data and stores the verified hash value in the local database for future use.
Signature generation:
Each Oracle node generates a signature for the batch hash to confirm the integrity and authenticity of the batch.
Communicating with Bitcoin:
The sequencer collects the signatures and original batch hashes of the oracle members and submits them to the taproot of the Bitcoin network.
Bitcoin Threshold Signature Verification:
The sequencer verifies the submitted signature against a list of valid Oracle network members and confirms that sufficient approvals are provided for the batch hash.
Celestia: Public DA Layer
Merlin Chain will use Celestia as the data availability layer to ensure that block data is verifiably published so that anyone can understand and store the state of Merlin Chain.
Through Celestia, Merlin Chain allows anyone to access historical data so that new Rollup nodes can reconstruct the latest state by replaying historical blocks. Once the data is published on Celestia and guaranteed to be available, Rollups and applications are responsible for storing their historical data. Specifically, when nodes receive a new block added to the chain, they will verify the availability of the data. The node will try to download all transaction data of the new block to verify availability. If the node can download all transaction data, it has successfully verified the availability of the data, proving that the block data has indeed been published to the network.
Future upgrades: Bitcoin’s on-chain fraud proof mechanism
Merlin Chain's Beta mainnet relies on a decentralized Oracle network to provide its ZK-L2 data availability (DA) and zero-knowledge proof (ZKP) verification. However, due to the Turing incompleteness of the Bitcoin network, it is not feasible to perform zero-knowledge proof verification directly on the Bitcoin mainnet. Therefore, traditional methods of verifying zero-knowledge proofs on first-layer blockchain networks (as seen in ZK-Rollup solutions) are not applicable to Bitcoin.
Merlin Chain solves this challenge by leveraging Taproot to write aggregated zero-knowledge proofs and Rollup data to the Bitcoin mainnet. This process ensures that the ZK-Rollup data is anchored to Bitcoin and remains tamper-proof. However, this alone cannot guarantee the validity and correctness of transactions within the ZK-Rollup, nor can it fully utilize Bitcoin's powerful consensus mechanism to ensure the security of the Layer 2 ZK-Rollup.
In future upgrades, Merlin Chain plans to introduce a fraud proof mechanism on the Bitcoin chain: nodes in the decentralized Oracle network must pledge BTC on the Bitcoin network in advance, forming the basis of the challenge mechanism on the Bitcoin chain. Users can initiate challenges to ZK-Rollup based on compressed transaction data, ZK state roots, and ZK proofs on the Bitcoin mainnet. If there is an inconsistency between the challenge proof data and the proof, the user can request assets that were pledged in advance on the Bitcoin mainnet, and the ZK-Rollup will roll back to the last verified state.
Merlin Chain uses the Bitcoin chain fraud proof mechanism to ensure the correctness of the data submitted by the decentralized Oracle network and ZKP. Compared with the optimistic Rollup, the Bitcoin mainnet no longer conducts fraud proofs on the entire transaction volume, but focuses on verifying the security of the ZK state root and ZK proof. This greatly improves the speed.
Token Economy
The total number of tokens is 2,100,000,000, of which 245,700,000 are in circulation, with a circulation rate of 11.7%. The current price is around $1.1, and the overall FDV is $2.2 billion. Unfortunately, the distribution of tokens has not been found.
In conclusion, this project is indeed ahead of other BTC layer2 projects in terms of technology, ecology, and overall TVL. In particular, the TVL speaks for itself (3 billion USD), while arb is only 2.6 billion USD. Compared to other BTC layer2 projects, such as stacks, the TVL is only 100 million USD, while stacks’ FDV is currently 4 billion USD. The market value of the top layer2 projects of EVM is 8-10 billion USD in FDV, so Merlin is still undervalued.