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，无法通过去信任的合约逻辑来处理资产的跨链转移，从侧链跨回比特币时，需要依赖一组验证人完成操作，存在信任假设，有欺诈风险。

Sidechain cannot inherit the mainchainSafetySecurity: The sidechain runs completely independently from the main network and cannot inherit the security of the main network. Malicious block reorganization and other events may occur.

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 与激励模型，采用质押桥方式，允许最多 150 个主网验证者。所谓质押桥，验证者需要质押 STX 代币以获取批准存款与取款的权限。质押桥的安全性严重依赖于质押资产的价值，在质押资产价值剧烈波动时，BTC 跨链的安全性容易受损。如果质押资产的价值低于跨链资产的价值，则验证者有作恶的动机。

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.

To ensure the security of the sidechain, Spacechain uses blind merged mining, where other users use ANYPREVOUT (APO) to publicly bid for the right to build blocks. Bitcoin miners only need to commit to the block header of Spacechain in the block, without verifying the sidechain block. However, the launch of Spacechain requires the support of Covanent, and the Bitcoin community is still discussing the necessity of adding Covanent opcodes through soft forks.

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.

However, 2/2 multi-signatures will cause activity problems, that is, if the other party does not cooperate, the user cannot transfer any assets from the multi-signature address, resulting in the loss of the original funds. Time locks can solve the activity problem. By pre-signing a contract with a time lock to return funds, it can ensure that even if one party is inactive, the other party can recover the initial funds.

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. 广播最新状态。通道的任何一方都可以随时将最新的承诺交易广播到区块链上,以提取自己的资金份额。为了防止对方广播旧的状态,每个承诺交易都有一个相应的「惩罚交易」,如果对方作弊,自己就可以获得对方的全部资金。

5. 关闭通道。当双方决定关闭通道时,他们可以合作生成一个「结算交易」,将最终的资金分配状态广播到区块链上。这样,锁定在多签地址中的资金就被释放回双方的个人地址。

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.

Optimistic Rollup 的优点是实现相对简单，对主链的修改较少。但它的交易确认时间较长 ( 取决于异议期 )，而且需要较高的数据可用性。Validity Rollup 交易确认快，不依赖异议期，而且交易数据可以保持隐私，但是生成和验证零知识证明需要较高的计算开销。

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 要求法定货币支持的稳定币必须有足够的流动性储备，并获得「电子货币许可证」。 撰文：Aiying 艾盈 近日，欧盟即将实施的《加密资产市场》（MiCA）法规引发了广泛关注。该法规对加密货币行业，尤其是稳定币市场，带来了深远影响。MiCA 要求法定货币支…