Will the second-layer network be the end of Bitcoin expansion?

Written by Chakra Research

In addition to the native expansion solution mentioned in the first part, another way to expand Bitcoin is to build an additional layer of protocol on top of Bitcoin, called Layer 2. The most critical points of the Layer 2 solution are:SafetyA two-way bridge and inherits Bitcoin's consensusSafetysex.

Sidechain

The origin of the sidechain concept can be traced back to "Enabling Blockchain Innovations with Pegged Sidechain" submitted by blockStream in 2014, which is a relatively simple expansion solution.

working principle

The sidechain runs completely independently from the mainchainBlockchain, has its own consensus protocol, and can serve as a test bed for main chain innovation. When a malicious incident occurs on the side chain, the damage is completely limited to the side chain itself and has no impact on the main chain. The side chain can use a consensus protocol with a higher TPS, increase the programming capabilities on the chain, and achieve BTC enhancement.

Sidechains can be implemented through two-way peg or one-way peg to realize Bitcoin in differentBlockchainOf course, in reality BTC can only stay on the Bitcoin network, so we need an anchoring mechanism to connect the BTC in the side chain with the BTC in the Bitcoin network.

One-way peg requires users to send BTC on the mainnet to an unavailable address for destruction, and then they will get the corresponding amount of BTC on the sidechain, but the process cannot be reversed. Two-way peg is a further upgrade of one-way peg, allowing BTC to move back and forth between the mainchain and the sidechain. Unlike sending to an unavailable address for destruction, two-way peg will lock BTC through control scripts such as multi-signatures and mint new BTC on the sidechain. When the user wants to return to the mainnet, the BTC on the sidechain will be burned and the previously locked B TC will be released on the mainnet.

The implementation of one-way peg is much simpler than two-way peg because there is no need to manage the relevant status on the Bitcoin network. However, the side chain assets generated by one-way peg may be worthless due to the lack of a reverse anchoring mechanism.

There are different schemes and different verification methods for locking transactions on the main chain and destroying transactions on the side chain.SafetyThe simplest method is to use external verification by multi-signature participants, but the risk of centralization is high. A better option is to use SPV Proof to achieve decentralized verification. Of course, since the Bitcoin mainnet lacks the necessary programming capabilities, it cannot perform SPV verification and can only choose other methods, usually multi-signature custody.

Problems and ideas

There are two main issues that sidechains are criticized for:

Asset cross-chain reliance on validators: Since the Bitcoin mainnet is not yet smartcontract, cannot be trustedcontractThe logic is used to handle the cross-chain transfer of assets. When crossing back from the side chain to Bitcoin, it is necessary to rely on a group of validators to complete the operation. There is a trust assumption and a risk of fraud.

侧链无法继承主链安全性：侧链完全独立于主网运行，无法继承主网的安全性，可能发生恶意区块重组等事件。

In this regard, the ideas of side chains include relying on authority (alliance type), relying on economic security (PoS), relying on decentralized Bitcoin miners (Merged Mining), and relying on hardware security modules (HSM). The custody of funds on Bitcoin and the block production of the side chain can be the responsibility of different roles, thereby introducing more complex security mechanisms.

Case Introduction

Liquid

The first form of sidechain was the consortium sidechain, where multiple pre-selected entities acted as validators and were responsible for the custody of mainnet funds and block generation on the sidechain.

Liquid is a representative of the alliance side chain, with 15 participants acting as validators. The private key management method is not public, and 11 signatures are required for verification. The blocks on the Liquid side chain are also jointly maintained by 15 participants. The alliance chain with a low number of nodes can achieve a higher TPS and achieve the expansion goal. The main application scope is DeFi.

The alliance side chain approach has significant centralized security risks.

Rootstock (RSK)

RSK also has 15 nodes acting as the mainnet fund custodian, and only 8 signatures are required for verification. The difference from Liquid is that the multi-signature key is managed by the hardware security module HSM, and the peg-out instruction is signed according to the PoW consensus to prevent the validator holding the key from directly manipulating the custodial funds.

In terms of sidechain consensus, RSK uses Merged Mining to ensure the security of transactions on the sidechain with the help of the mainnet computing power. When the proportion of merged mining computing power to the mainnet is high, it can better prevent double-spending attacks on the sidechain. RSK has made improvements to Merged Mining to ensure the security of the sidechain under low hash rates, and adopts a fork-aware method to intervene in the off-chain consensus on fork behavior to reduce the probability of double spending.

However, Merged Mining changes the incentives of miners and increases the risk of MEV, which may eventually shake the stability of the system. In the long run, Merged Mining may increase the centralization of mining.

Stacks

Stacks anchors the Stacks chain history to Bitcoin by submitting the block hash of the side chain to the Bitcoin block, and has the same Finality as Bitcoin. The fork of Stacks can only be caused by the fork of Bitcoin, which improves the ability to resist double spending.

sBTC introduces newToken STX and the incentive model use a pledge bridge method, allowing up to 150 mainnet validators. The so-called pledge bridge requires validators to pledge STX TokenTo obtain the permission to approve deposits and withdrawals. The security of the pledge bridge depends heavily on the value of the pledged assets. When the value of the pledged assets fluctuates drastically, the security of the BTC cross-chain is easily damaged. If the value of the pledged assets is lower than the value of the cross-chain assets, the validator has the motivation to do evil.

There are also some sidechain proposals in progressCommunitywas widely discussed.

Drivechain

The most popular one is Drivechain proposed by Paul Sztorc in 2015. The key technologies in the solution have been assigned BIP 300 (pegging mechanism) and BIP 301 (blind merge mining). BIP 300 defines the logic of adding a new sidechain in detail. Activating a new sidechain is similar to activating a soft fork through miner signals. BIP 301 allows Bitcoin miners to become block producers of sidechains without verifying the specific transaction content.

Bitcoin miners are also responsible for approving withdrawal transactions. Miners first need to create an OP_RETURN output in the coinbase transaction of the block they mined to propose a withdrawal transaction. After that, miners can vote on the proposal. They can vote for or against the proposal when each block is mined. Once a withdrawal transaction exceeds the threshold (13150 blocks), the withdrawal transaction is officially executed and confirmed by the Bitcoin main chain.

In fact, miners have full control over the funds on Drivechain.stealIn the event of a crash, users can only save themselves through UASF (user-activated soft fork), but it is very difficult to reach consensus. In addition, the unique position of miners in Drivechain exacerbates the risk of MEV, which has been verified in Ethereum.

Spacechain

Spacechain takes a different approach and uses Perpetual 1 way peg (P1WP), where users burn BTC to obtain tokens on Spacechain, directly skipping the issue of fund security. This token can only be used to auction block space on Spacechain, and does not have any value storage function.

为保证侧链的安全，Spacechain 采用盲合并挖矿，由其他用户使用 ANYPREVOUT（APO）公开出价竞争构建区块的权利，比特币矿工只需在区块中承诺 Spacechain 的区块头，无需验证侧链区块。不过，Spacechain 的启动需要 Covanent 的支持，现在比特币Community仍在讨论软分叉添加 Covanent 操作码的必要性。

In general, Spacechain can realize a side chain with the same decentralization and anti-censorship properties of Bitcoin and more programmability through the block auction function on Bitcoin.

Softchain

Softchain is a 2wp sidechain proposal proposed by Ruben Somsen, the author of Spacechain. It uses the PoW FP consensus mechanism to ensure the security of the sidechain. Under normal circumstances, a full Bitcoin node only needs to download the block header of the softchain to verify the proof of work. When a fork occurs, the orphan block and the corresponding UTXO set commitment are downloaded to verify the validity of the block.

For the 2wp mechanism, a deposit transaction is created on the main chain during peg-in, and the main chain transaction is referenced on the softchain to obtain funds; a withdrawal transaction is created on the softchain during peg-out, and the main chain references the transaction to retrieve BTC, and the withdrawal process needs to wait for a long challenge period before it can be completed. The specific peg-in and peg-out mechanisms require soft fork support, so the solution is called Softchain.

The Softchain solution creates additional verification costs for the full nodes of the Bitcoin mainnet. The split of the Softchain consensus may affect the achievement of the mainnet consensus and become a possible means of attack on the Bitcoin mainnet.

Lightning Network

The Lightning Network released its white paper in 2015 and was officially launched in 2018. As a Layer2 p2p payment protocol on Bitcoin, it aims to transfer a large number of small, high-frequency transactions to off-chain processing. For a long time, it has been considered the most promising expansion solution for the Bitcoin network.

Core Modules

The implementation of Lightning Network is inseparable from several important modules in Bitcoin, which together ensure the security of Lightning Network transactions.

The first is pre-signed transactions. Pre-signed transactions only become safe and available after the SegWit upgrade. SegWit separates signatures from the rest of the transaction data, solving potential circular dependencies, third-party transaction tampering, and second-party transaction tampering. The security of off-chain computing in the Lightning Network is guaranteed by the irrevocable commitment given by the other party, and this commitment is achieved through pre-signed transactions. After receiving the pre-signed transaction given by the other party, the user can broadcast the transaction to the chain at any time to fulfill the commitment.

The second is multi-signature. Frequent off-chain fund transfers between two parties require a carrier, which requires both parties to have certain control rights, so multi-signature is required, generally using 2/2 multi-signature, which ensures that the transfer of funds can only be carried out with the mutual consent of both parties.

但是 2/2 多重签名会产生活性问题，即对方不配合的情况下，用户无法从多签地址中转移任何资产，导致原有资金的损失。时间锁能够解决活性问题，通过预先签署一个带时间锁的返还资金的contract，能够保证即使在一方失活的情况下，另一方也能够收回初始资金。

Finally, there is the hash lock, which can connect multiple state channels and build a network. The original image of the hash will serve as a communication medium to coordinate the correct operation of multiple entities.

Running the process

Two-way channel

The two parties using the Lightning Network to conduct transactions first need to open a two-way payment channel on Bitcoin. Both parties can conduct any number of transactions off-chain. After all transactions are completed, the latest status is submitted to the Bitcoin chain to complete the settlement and close the payment channel.

Specifically, the implementation of the payment channel involves the following key steps:

1. Create a multi-signature address. Both parties in the channel first need to create a 2-of-2 multi-signature address as the channel's fund lock address. Both parties hold a signature private key and provide their own public key.

2. Initialize the channel. Both parties broadcast a transaction on the chain, locking a certain amount of Bitcoin into a multi-signature address as the initial funds for the channel. This transaction is called the "anchor" transaction of the channel.

3. Update channel status. When making payments in a channel, both parties update the channel status by exchanging pre-signed transactions. Each update generates a new "commitment transaction" representing the current state of funds allocation. The commitment transaction has two outputs, corresponding to the funds share of both parties.

4. Broadcast the latest status. Any party in the channel can broadcast the latest commitment transaction toBlockchainIn order to prevent the other party from broadcasting the old state, each commitment transaction has a corresponding "penalty transaction". If the other party cheats, you can get all the other party's funds.

5. When both parties decide to close the channel, they can collaborate to generate a "settlement transaction" to broadcast the final funds allocation status toBlockchainIn this way, the funds locked in the multi-signature address are released back to the personal addresses of both parties.

6. On-chain arbitration. If the two parties cannot reach an agreement on closing the channel, either party can unilaterally broadcast the latest commitment transaction to start the on-chain arbitration process. If there is no objection within a certain period of time (such as 1 day), the funds will be sent to both parties according to the allocation of the commitment transaction.

Payment Network

Payment channels can be connected to form a network, supporting multi-hop routing, which is achieved through HTLC. HTLC uses hash lock as a direct condition and signature payment with time lock as a backup condition. Users can interact around the original image of the hash before the time lock expires.

When there is no direct channel between two users, the payment can be completed with the help of HTLC between routers. The hash original image R plays a key role in the whole process, ensuring the atomicity of the payment. At the same time, the time lock of HTLC is set to decrease along the way, ensuring that each hop has enough time to process and forward the payment.

Problems

In essence, the Lightning Network circumvents the external trust assumption of asset bridging through the p2p state channel, and uses time-lock scripts to provide the ultimate guarantee of assets and provide fault protection. In the case of the other party losing activity and not cooperating, a unilateral exit can be completed. Therefore, the Lightning Network has a high use value in payment scenarios, but it also has many limitations, mainly including:

• Channel capacity limitation. The capacity of the payment channel in the Lightning Network is limited by the initial locked funds and cannot support large payments that exceed the channel capacity. This may limit certain application scenarios, such as commodity trading.

• Online and synchronous. In order to receive and forward payments in a timely manner, the nodes of the Lightning Network need to remain online. If the node is offline for a long time, some channel status updates may be missed, resulting in status out of sync. This may be a challenge for individual users and mobile devices, and also increases the cost of node operation.

• Liquidity management. The routing efficiency of the Lightning Network depends on the liquidity distribution of the channel. If the funds are unevenly distributed, some payment paths may fail, affecting the user experience. Managing the liquidity balance of the channel requires certain technical and financial costs.

• Privacy leakage. In order to find available payment paths, the Lightning Network's routing algorithm needs to know the capacity and connectivity information of the channel to a certain extent. This may leak the privacy of some users, such as fund distribution, counterparties, etc. The opening and closing of payment channels may also expose the information of related participants.

RGB

The original conception of the RGB protocol was inspired by the concepts of client verification and one-time sealing proposed by Peter Todd. It was proposed by Giacomo Zucco in 2016 and is a scalable, privacy-preserving Bitcoin layer 2 protocol.

main idea

Client verification

The verification process of blockchain is to broadcast the blocks consisting of transactions to all parties, so that each node can calculate the transactions in the blocks and complete the verification. This actually creates a public good, that is, the nodes of the entire network help each individual who submits the transaction to complete the verification, and the user provides BTC as a handling fee as an incentive to help with the verification. Client verification is more individual-centric, and the state verification is not performed globally, but by the individuals involved in the specific state transition. Only when the parties who generate the transaction verify the validity of the state transition, this significantly improves privacy, reduces the burden on nodes, and improves scalability.

One-time seal

There is a hidden danger in peer-to-peer state transitions. If users cannot collect the complete state transition history, they may be defrauded and double spending may occur. One-time sealing is proposed to solve this problem. Through a special object that can only be used once, double spending is ensured not to occur, thereby improving security. Bitcoin's UTXO is the most suitable one-time sealing object, which is guaranteed by Bitcoin's consensus mechanism and the computing power of the entire network. Therefore, RGB assets can inherit the security of Bitcoin.

Cryptographic Commitment

One-time sealing needs to be combined with cryptographic commitments to ensure that users clearly know when state transitions have occurred and to avoid double-spending attacks. A commitment is to inform others that something has happened and cannot be modified afterwards, but there is no need to expose the specific event until the moment of verification. We can use hash functions to make commitments. In RGB, the content of the commitment is the state transition. Through the spending of UTXO, the recipient of the RGB asset will receive a signal of state transfer, and then verify the commitment against the specific data transmitted off-chain by the spender of the asset.

work process

RGB uses Bitcoin's consensus to ensure double-spending security and censorship resistance, and all state transfer verification work is transferred off-chain and only verified by the client that accepts the payment.

For the issuer of RGB assets, it is necessary to create an RGB contract by initiating a transaction, and the commitment of specific information will be stored in the OP_RETURN script of a spending condition in the Taproot transaction.

When the holder of RGB assets wants to spend, he needs to obtain relevant information from the recipient of the assets, create an RGB transaction, commit to the details of the RGB transaction, place the committed value into the UTXO specified by the asset recipient, and issue a transaction to spend the original UTXO and create the UTXO specified by the recipient. When the recipient of the assets observes that the UTXO that originally stored the RGB assets has been spent, the validity of the RGB transaction can be verified through the commitment in the Bitcoin transaction. Once the verification is valid, it is considered that they have indeed received the RGB assets.

For the recipient of RGB assets, the payer needs to provide the initial state and state transition rules of the contract, the Bitcoin transaction used for each transfer, and the amount of each Bitcoin.exchangeThe promised RGB transaction and the evidence of the validity of each Bitcoin transaction are verified by the recipient's client based on these data to verify the validity of the RGB transaction. Among them, Bitcoin's UTXO is used as a container to store the status of the RGB contract. The transfer history of each RGB contract can be represented as a directed acyclic graph. The recipient of the RGB asset can only obtain the history related to the RGB asset he holds, but cannot obtain other branches.

Advantages and Disadvantages

Lightweight verification

Compared with the complete verification of the blockchain, the RGB protocol greatly reduces the cost of verification. Users do not need to traverse all historical blocks to obtain the latest status. Instead, they only need to synchronize the historical records related to the assets they receive to verify the validity of the transaction.

This lightweight verification makes peer-to-peer transactions easier, further eliminating the need for centralized service providers and increasing the level of decentralization.

Scalability

The RGB protocol only needs to inherit the security of Bitcoin through a hash commitment, and through the Taproot script, it consumes almost no additional space on the Bitcoin chain, which makes complex programmability of assets possible. Due to the use of UTXO as a container, the RGB protocol has natural concurrency, and RGB assets on different transfer branches will not block each other and can be spent at the same time.

Privacy

Unlike general protocols, only the recipient of RGB assets can obtain the historical transfer of RGB assets. Once the spending is completed, the future transfer status cannot be obtained, which significantly guarantees the privacy of users. The transaction of RGB assets is not related to the transfer of Bitcoin UTXO, and others cannot obtain traces of RGB transactions on the Bitcoin chain.

In addition, RGB also supports blind spending, and the payer cannot clearly determine which UTXO the RGB assets will be paid to, further improving privacy and enhancing anti-censorship capabilities.

insufficient

When RGB assets have been transferred many times, the new user receiving the assets will be forced to verify the lengthy transfer history, resulting in a heavy verification burden, which may take a long time to verify and lose the ability to quickly confirm. For nodes that keep running in the blockchain, since they are always synchronizing the latest status, the time to receive the new zone fast verification status transfer is limited.

The community is discussing the possibility of reusing historical computations, and recursive ZK Proof has the opportunity to achieve state verification with constant time and size.

Rollup

Overview

Rollup is the best scaling solution that the Ethereum ecosystem has come up with after years of exploration, evolving from state channels to Plasma and finally to Rollup.

Rollup is an independent blockchain that collects transactions outside the Bitcoin chain, packages multiple transactions into a batch and executes them, and submits the data and status commitments of this batch to the main chain, realizing off-chain transaction processing and status updates. In order to maximize capacity expansion, Rollup currently usually uses a centralized sequencer to improve execution efficiency without sacrificing security, because security is guaranteed by the verification of Rollup state transitions on the main chain.

As the Ethereum ecosystem's Rollup solution matures, the Bitcoin ecosystem has also begun to experiment with Rollup. However, the most critical difference between Bitcoin and Ethereum is the lack of programming capabilities, and the inability to perform the calculations required to build Rollup on the chain, which means that people can only try to implement sovereign Rollup and OP Rollup.

Classification

Depending on the verification method of state transfer, Rollup can be divided into two categories, Optimistic Rollup and Validity Rollup (ZK Rollup).

Optimistic Rollup uses an optimistic verification method. During the dispute period after each transaction batch is submitted, anyone can check the off-chain data, object to the problematic transaction batch, submit fraud proof to the main chain, and fine the Sequencer. If there is no valid fraud proof after the dispute period, the transaction batch is considered valid and the status update is confirmed on the main chain.

Validity Rollup uses Validity Proof to complete the verification, and Sequencer usesZero knowledge proofThe algorithm generates a concise validity proof for each transaction batch, proving that the state transfer of the batch is correct. Each update needs to submit the validity proof of the transaction batch to the main chain. The main chain verifies the proof and confirms the status update.

The advantage of Optimistic Rollup is that it is relatively simple to implement and requires fewer modifications to the main chain. However, its transaction confirmation time is longer (depending on the objection period) and requires higher data availability. Validity Rollup has fast transaction confirmation, does not rely on the objection period, and transaction data can remain private, but generation and verification are time-consuming.Zero knowledge proofRequires high computational overhead.

Celestia also proposed the concept of a sovereign Rollup, where the transaction data of the Rollup is published to a dedicated DA layer blockchain, which is responsible for data availability, while the sovereign Rollup itself is responsible for execution and settlement.

Explore and discuss

Rollup on Bitcoin is still in its early stages. Due to the differences in accounting models and programming languages from Ethereum, it is difficult to directly copy Ethereum's practical experience. The Bitcoin community is actively exploring innovative solutions.

Sovereign Rollup

On March 5, 2023, Rollkit announced that it had become the first framework to support Bitcoin sovereign Rollups, allowing builders of sovereign Rollups to publish availability data on Bitcoin through Rollkit.

Rollkit is inspired by Ordinals and publishes data through Taproot transactions. A standard Taproot transaction through the public memory pool can contain up to 390 KB of data, and a non-standard Taproot transaction directly published by miners can contain nearly 4 MB of arbitrary data.

The actual work of Rollkit is to provide an interface for sovereign Rollup to read and write data on Bitcoin, provide middleware services to customers, and turn Bitcoin into a DA layer.

The idea of a sovereign Rollup has been questioned by many, with many opponents claiming that a sovereign Rollup on Bitcoin is nothing more than using Bitcoin as a bulletin board and cannot inherit Bitcoin's security at all. In fact, if transaction data is only submitted to Bitcoin, it can only improve activity, that is, all users can obtain the corresponding data through Bitcoin for verification, while security can only be defined by the sovereign Rollup itself and cannot be inherited. In addition, block space on Bitcoin is very valuable, and submitting the full amount of transaction data may not be a good decision.

OP Rollup & Validity Rollup

Although many Bitcoin second-layer projects call themselves ZK Rollup, they are essentially closer to an OP Rollup, except that the Validity Proof technology is involved in the process. However, Bitcoin's programming capabilities are not yet sufficient to support direct Validity Proof verification.

Currently, Bitcoin's opcode set is very limited, and even multiplication cannot be calculated directly. Verification of Validity Proof requires the expansion of opcodes, and also largely depends on the implementation of recursive contracts. The community is hotly discussing OP_CAT, OP_CHECKSIG, OP_TXHASH, etc. Of course, if we can directly add an OP_VERIFY_ZKP, maybe we don't need any other modifications, but this is obviously unlikely. In addition, the limitation of stack size also hinders the efforts to verify Validity Proof in Bitcoin scripts, and many attempts are being explored.

So how does Validity Proof work? Most projects publish the statediff and Validity Proof of the transaction batch on Bitcoin in the form of an inscription, and use BitVM for optimistic verification. The BitVM bridge replaces the traditional multi-signature scheme here. The bridge's Operator will form an N-person alliance to schedule user deposits. Before the user makes a deposit, the alliance will be required to pre-sign the UTXO to be generated to ensure that the deposit can only be legally collected by the Operator. After obtaining the pre-signature, BTC will be locked to an N/N multi-signature Taproot address.

When a user issues a withdrawal request, Rollup will send the Validity Proof with the withdrawl Root to the Bitcoin chain. The Operator will first meet the user's withdrawal request out of his own pocket, and then verify the validity through the BitVM contract. If each Operator believes that the proof is valid, the Operator will be reimbursed through multi-signature; as long as anyone believes that there is fraud, a challenge process will be carried out, and the wrong party will be slashed.

This process is actually the same as OP Rollup. The trust assumption is 1/N. As long as there is one honest validator, the protocol is secure.

However, the technical implementation of this solution may be difficult. In Ethereum’s OP Rollup project, Arbitrum has been developed for many years, and the current Fraud Proof is still submitted by permissioned nodes; Optimism only recently announced support for Fraud Proof, which shows the difficulty of implementation.

As for the pre-signature operation in the BitVM bridge, it can be implemented more efficiently with the support of Bitcoin Covanent.Xiaobai NavigationWaiting for community consensus.

In terms of security attributes, by submitting the Rollup block hash to Bitcoin, anti-reorganization and anti-double-spending properties are achieved, and the optimistic bridge brings a 1/N security assumption. However, the bridge's anti-censorship properties can still be further improved.

Conclusion: Layer 2 is not a panacea

Looking at so many Layer 2 solutions, it is easy to find that each solution has limited capabilities. Under certain trust assumptions, the effects that Layer 2 can achieve depend largely on Layer 1, which is the native capabilities of Bitcoin.

Without SegWit upgrade and time lock, the Lightning Network cannot be built smoothly; without Taproot upgrade, RGB commitment cannot be submitted smoothly; without OP_CAT and other Covanent, Validity Rollup on Bitcoin cannot be built smoothly...

Many Bitcoin Maxi believe that Bitcoin should never be changed, new features should not be added, and all defects should be solved by Layer 2. This is impossible. Layer 2 is not a panacea. We need a more powerful Layer 1 to build a more secure, efficient, and scalable Layer 2.

In the next article, we will introduce attempts to improve programmability on Bitcoin, so stay tuned.

The article comes from the Internet:Will the second-layer network be the end of Bitcoin expansion?

Related recommendations: EU MiCA regulations are about to take effect: Bitstamp and Binance are the first to remove non-compliant stablecoins

MiCA requires that stablecoins backed by fiat currencies must have sufficient liquidity reserves and obtain an "electronic money license". Written by: Aiying Aiying Recently, the EU's upcoming "Markets in Crypto-Assets" (MiCA) regulations have attracted widespread attention.cryptocurrencyThe industry, especially the stablecoin market, has far-reaching impacts. MiCA requires fiat currency payments…