BRC20
The first is the difference between the classic BRC20 protocol. BRC20 was born out of the Ordinals protocol. Complete functions similar to ERC20 Token were written into the BTC output instruction code, and BRC20 was born. As shown in the picture below, the BRC20 token information is burned into the command code data of Segregated Witness under the BTC transaction. First of all, the BRC20 protocol has written the BRC20 standard method on BTC, which includes "deployment", "minting" and "transfer".
- In "Deployment", BRC20 registers the name, total amount and quantity limit of this token.
- When users create new BRC20, they send a transaction to write data into the script, which includes the number of tokens.
- When BRC requires users to transfer money, they need to first send a transaction to write the result of aggregating the number of tokens into the Bitcoin instruction code, and then send a second transaction to send the aggregated balance to a specific address. Similarly Write the command code.
First, you can first understand the three major parts of the BTC layer protocol:
- The protocol sets out the rules for writing data on Bitcoin
- Indexers provide the ability to query and parse this data
- The ledger records token balances and processes transfers
For BRC20, the index server first needs to identify each BRC20 deployment to read the token information. This part is called "index".
At the same time, since the balance of BRC20 is engraved into the script and cannot be recognized by the BTC network itself, the index server of BRC20 must build a local ledger to record the balance of BRC20. Every time a transfer occurs, whether the transaction can be carried out (there are enough coins), the local ledger needs to be checked and updated.
Each transfer of brc20 based on ordinals requires two transactions to be transmitted. That is, first query and calculate the balance in the local ledger, and then transfer the money.
Ordinals is essentially designed for NFT. Based on its improved BRC20, the transfer complexity increases recursively. The BRC20 indexer also takes over the work of the ledger, which is completely separate from Bitcoin. The indexer must accurately record every balance change to ensure the integrity of the ledger.
Therefore, as time accumulates, the indexer ledger will accumulate, and the pressure on the nodes will increase. If the sequencer ledger is no longer in service, brc20 will become unusable. Fortunately, unisat has open sourced the code of the indexer node very early. BRC20 has been built by multiple technical teams including OKX, and the infrastructure is very robust. However, the ledger of BRC20 still needs to be decentralized. A decentralized ledger is equivalent to making a chain. In other words, it is inevitable to make a chain decentralized ledger outside BRC20.
ARC20
The method used by the Atomics protocol to issue FT is called BRC20. This is a Bitcoin native asset issuance protocol that registers token information in the transaction instruction code, uses Sat, the smallest unit of Bitcoin, as the basic unit, and implements a ledger based on UTXO.
Back to Arc20, Arc20 is a colored currency model. The registration information is engraved into the transaction instruction code, the balance is represented by the sat quantity of UTXO, and the transfer function is completely handled by the BTC mainnet.
- When deploying Arc20, the token name, total amount, quantity limit, difficulty setting, starting block, image and other information.
- When users create a new ARC20, they write the name of the token into the UTXO instruction code. The amount is directly determined by the number of sats in uxto, 1 sat = 1 token
- To transfer ARC20, users no longer need to deposit any information into BTC. They only need to use the UXTO that continues to hold the token as transaction input and output it to other addresses.
Therefore, in ARC20, we do not need any off-chain system to calculate the balance of ARC20 tokens, because the token balance is consistent with the number of Sat in UTXO. We only need an index to help us read the token registration information and identify mint transactions to confirm and verify which UTXOs are ARC20.
Therefore, the calculation of Arc20 token transfer itself is handled by the BTC network, without any off-chain ledger, and only one transaction needs to be sent. Therefore, based on the performance of BTC L1, the transfer performance of ARC20 is twice that of BRC20.
This brings many benefits:
- The cost of the index server is greatly reduced, almost anyone can access it, and the system is highly decentralized.
- The transfer completely relies on the BTC network and will not repeatedly create junk transactions. The security of Arc20 transfer itself is guaranteed by BTC.
- The atomicity of RC20 is consistent with the atomicity of BTC and is suitable for implementing many native applications.
Another update that has to be mentioned is bitwork, which adds the CPU calculation link to the token minting process. This is similar to BTC's POW. Minting can only be carried out after calculating the POW. "One CPU, one mint opportunity."
Of course, the design of colored coins also brings some disadvantages, because the balance is not written in the data, but is tied to sat. The minimum split precision of the ARC20 balance is 1 (currently set to avoid being regarded as a spam transaction) higher lower limit). Therefore, the issuance of meme tokens with a total amount of several trillion based on ARC20 seems to be outweighing the gains because it requires a large amount of BTC. This needs to wait for future Atomicals protocol upgrades to be improved.
At the same time, the infrastructure of ARC20 is very poor, and wallets and markets often crash. Therefore, the community calls on more users to build their own Atomics index, and more developers are needed to participate in the construction of infrastructure.
