Decentralized Oracle Network
In Merlin Chain's L2 architecture, the sequencer node collects and batches 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 outlined as follows: The ZK L2 collects and batches transactions, then zkProver generates proof. Simultaneously, transaction raw data, Merkle trees, Bitcoin state, and other data are aggregated to form a joint proof, which is synchronized with the Oracle network.
Upon receiving this L2 data, the Oracle network performs circuit compilation, uploading the compressed data and commitment commitments to the Bitcoin mainnet, writing them into taproot for public and verifiable access by everyone.
Oracle nodes play a crucial 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 taproot on the Bitcoin mainnet.
The following are the specific responsibilities of Oracle nodes in this process:
L2 data compile : The Oracle node is responsible for compiling the transaction data collected and batch processed by the sequencer node, including compressed transaction data, ZK state root, and Proof. This step ensures the correct format and uploadability of the data.
Circuit compile operation : After receiving L2 data from the sequencer, the Oracle node will perform a circuit compile operation, which involves converting complex computational logic into a form that can be verified in Bitcoin taproot.
Upload to Bitcoin mainnet : Oracle nodes upload the compiled data and Commitment commitments to taproot on the Bitcoin mainnet. This operation allows all participants on the network to publicly verify and access this data.
Batch verification and hash transfer : Oracle nodes are responsible for verifying the integrity and authenticity of batch data after forming batches, and transmitting batch data and its hash value to other Oracle nodes in the network.
Signature generation and submission : Each Oracle node generates a signature for the batch hash to confirm the integrity and authenticity of the batch. Subsequently, the sequencer collects the signatures and original batch hashes of all Oracle nodes and submits them to the taproot of the Bitcoin network.
Bitcoin Threshold Signature Verification : Oracle nodes participate in the Bitcoin Threshold Signature Verification process, ensuring that submitted signatures meet the network's security requirements and provide sufficient approval for bulk hashing.
ZKP Final Settlement : Oracle nodes assist the proof aggregator in preparing a zero-knowledge proof (ZKP) and submitting it to the taproot of the Bitcoin block. This proof confirms the validity of the batch transaction and updates the chain state of Layer 2 without revealing details.
Decentralized verification : The Oracle node network, as a decentralized entity, ensures the combined verification of DA (data availability) and zk proof. This means that each node independently participates in the verification process, 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, ensuring seamless integration and security of Layer 2 solutions with the Bitcoin network. This design strengthens Merlin Chain's ability 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 in maintaining cyber security, incentivizing participants, and ensuring decentralization. This mechanism allows users to obtain the qualification of Oracle nodes by staking different encrypted assets, or proxy staking to existing Oracle nodes, thereby participating in the governance and data verification process of Merlin Chain.
Diverse staking options
In order to meet the needs and risk preferences of different users, the system supports the staking of BTC, MERL, and other mainstream BRC20 assets. This diversified asset selection not only provides users with flexibility, but also enhances the network's risk resistance. Users can choose the most suitable assets for staking based on their confidence and understanding of the market.
The staking weight of the system is dynamically adjusted based on the market value and liquidity of each asset. This means that even small investors who are willing to take certain risks and choose the right assets for staking may qualify for Oracle nodes. In addition, the system will regularly adjust the staking weight based on the volatility and market performance of the assets to ensure the fairness and rationality of reward distribution.
The amount of user's staking will directly affect the rewards they receive. The larger the staking amount, the higher the user's influence in Oracle nodes, and correspondingly, the more rewards they will receive. This mechanism encourages users to actively participate in network maintenance and governance, while also providing additional guarantees for network stability and security.
Stake Delegation
Merlin Chain's staking mechanism not only allows users to directly stake assets to become Oracle nodes, but also provides a flexible proxy staking option, allowing users to choose to entrust their assets to existing and reputable Oracle nodes for management. This mechanism aims to provide users with more participation options while enhancing the decentralization and security of the entire network.
Selecting a proxy node : The user first needs to select one or more reputable Oracle nodes in the network as proxies.
Asset delegation : The user sends their assets to the selected Oracle node to complete the process of proxy staking.
Participation in reward distribution : The entrusted Oracle node will represent the verification and governance work of the customer engagement network, and users will receive corresponding reward shares based on the performance of the proxy node.
Supervision and adjustment : Users can monitor the performance of proxy nodes at any time and adjust their proxy staking strategies as needed.
By introducing a proxy staking mechanism, Merlin Chain further enriches its staking system, enabling more users to easily participate in the maintenance and governance of the blockchain, while also providing strong support for the stability and decentralization of the network.
Assets Security and Transparency
In order to protect users' pledged assets, the system adopts multi-signature and cold storage technology to ensure the security of assets. All pledge and reward distribution processes are open and transparent, and users can check their pledge status and expected returns at any time. In addition, the use of smart contracts ensures the immutability and automation of the pledge process, further improving the credibility of the system.
Smart contract management : All proxy staking and reward distribution will be automatically executed through smart contracts, ensuring the immutability and fairness of the process.
Real-time monitoring : Users can view their own proxy pledge status and income situation in real time, as well as the performance records of proxy nodes.
Exit mechanism : The system provides a flexible exit mechanism, users can withdraw their assets at any time to ensure the liquidity of funds.
Staking Rewards
The staking reward of Oracle nodes mainly consists of two parts: block reward and transaction fee. The block reward is Merl tokens issued at a certain inflation rate, distributed according to the staking weight and network performance of the node. The transaction fee is BTC tokens, and a certain percentage of the transaction fee is extracted from each transaction in the Merlin Chain.
The staking reward will be distributed according to the type and quantity of staked assets. BTC stakers will receive 40% of the reward, Merl stakers will also receive 40% of the reward, and the remaining 20% of the reward will be distributed to stakers of other mainstream assets such as BRC20.
In order to ensure the fairness of reward distribution, we will adopt a weighted average algorithm based on market value and pledge amount. This algorithm will consider the market value and liquidity of different assets, as well as the pledge amount of each Oracle node, in order to calculate the reward that each node should receive.
Security measures
Node selection and elimination
The selection of Oracle nodes will be based on a series of criteria, including staking amount, online duration, verification success rate, etc. The system will regularly evaluate Oracle nodes, and nodes with poor performance will be eliminated. New nodes will be selected based on their performance and community evaluation.
Protection of pledged assets
In order to protect the security of pledged assets, we will implement multi-signature technology and cold storage solutions. In addition, all pledged assets will be protected by smart contracts to ensure their immutability and transparency.
ZKP to the BTC Network
Decentralized Oracle network combines DA and zk proof verification. The specific process can be broken down as follows:
Batch formation: User transactions are collected by the sequencer and organized into batches.
Batch validation: Once a batch is formed, it is validated and the batch data and its hash value are transmitted to the Oracle node.
Data verification and storage: Each Oracle node independently verifies batch data and stores the verified hash value in the local database for future use.
Signature generation: Each Oracle node generates a signature for batch hashing to confirm the integrity and authenticity of the batch.
Communicating with Bitcoin: The sorter collects the signatures and original batch hashes of Oracle members and submits them to the taproot of the Bitcoin network.
Bitcoin Threshold Signature Verification: The sorter verifies the submitted signature against a valid list of Oracle network members and confirms that sufficient approval is provided for batch hashing.
ZKP final settlement: The proof aggregator prepares a zero-knowledge proof for this batch and submits it to the taproot of the Bitcoin block. This proof confirms the validity of the batch transaction, updates the chain state of Layer 2 without revealing detailed information. Before Bitcoin verifies ZKP, the threshold signature of the Oracle network ensures the validity of ZKP.
This design achieves the processing, verification, and storage of transactions and data through the collaboration of the sequencer and Oracle network, and ultimately completes settlement and updates the state of the L2 chain through ZKP, while taking into account security and decentralization.
Celestia: Public DA Layer
Merlin Chain will use Celestia as the data availability layer to ensure that block data is provably published so that anyone can know and store the state of Merlin Chain.
With Celestia, Merlin Chain allows anyone to access historical data so that new Rollup nodes can rebuild the latest state by replaying historical blocks. Once data is published on Celestia and guaranteed to be available, Rollups and applications are responsible for storing their historical data. Specifically, nodes will verify data availability when they receive new blocks added to the chain. Nodes will attempt to download all transaction data of the new block to verify availability. If nodes can download all transaction data, they have successfully verified data availability, proving that the block data has indeed been published to the network.
Moreover, Merlin Chain encourages various types of participants to store historical data. Some of these include:
Block explorers that provide access to past transaction data.
Indexers that provide API queries for past data.
Applications or aggregators that require historical data for certain processes.
Users who want to ensure access to their transaction history.
Last updated
