This article is for technical sharing only and does not constitute any investment advice.
Will BTC also have its own smart contracts?
Recently, in the Bitcoin ecosystem, after undergoing multiple testnets, Fractal BTC finally went live on the mainnet in September. One major feature of Fractal is its ability to support "smart contracts," and almost simultaneously with the mainnet launch, it introduced a new token protocol called CAT20. What clever technical designs does CAT20 have? What can we learn from it?
Fractal Bitcoin
Before understanding CAT20, we need to briefly understand Fractal Bitcoin. Their relationship is similar to that of ERC20 and ETH, where the CAT20 protocol is deployed on Fractal Bitcoin.
Fractal Bitcoin, also known as "Fractal BTC," is a "layer 2" network that is fully compatible with BTC. Compared to BTC, it has a faster block confirmation time, taking only 1 minute. Its basic principle is, as its name suggests, to replicate the BTC network multiple times, with each chain processing transactions. With more nodes able to process transactions, the speed naturally increases. However, specific details such as how different chains communicate with each other are not very clear at the moment, and there are no corresponding technical documents from the official source for reference.
If it were just a second-layer chain with faster transactions, it might not be very exciting. However, in Fractal, the use of the OP_CAT operation code, which was abandoned long ago in BTC due to security reasons, has elevated the capabilities of Fractal Bitcoin. Some say that OP_CAT can give BTC the ability to support smart contracts, which opens up more possibilities.
Now, someone has implemented a protocol similar to ERC20 on Fractal Bitcoin.
Regarding why OP_CAT was abandoned and how it can be used on Fractal Bitcoin, this can be discussed in more detail later. Here, we focus on CAT20.
CAT Protocol
The following content refers to the white paper: Introduction | CAT Protocol (https://catprotocol.org/)
And the GitHub repository:
GitHub - CATProtocol/cat-token-box: A monorepo for packages implementing CAT protocol (https://github.com/CATProtocol/cat-token-box)
With the underlying support of OP_CAT, a corresponding protocol, CAT Protocol, was quickly developed. Currently, a protocol that is already running is the CAT20 protocol, and a corresponding panel has also been added on Unisat: https://explorer.unisat.io/fractal-mainnet/cat20.
When you see the name CAT20, you should be able to infer that it is similar to ERC20. Compared to the mature ERC20 protocol, deploying a token is already very convenient. How does CAT20 achieve a lifecycle similar to ERC20?
Deploy
Before deployment, users need to specify their wallet address and the basic information of the token, which is similar to ERC20:
There are some differences: CAT20 can set pre-mining and quantity limits for each mint. Of course, ERC20 can also achieve these capabilities through the contract.
During the deployment phase, two transactions will be initiated, which can be considered as two stages: "commit" and "reveal." Referring to the official diagram, the deployment phase is as follows:
In the "commit" phase, the basic information of the token, such as the name and symbol, will be written into the output script of the transaction. The hashId of the transaction initiated in the "commit" phase will serve as the identifier for the token, used to distinguish it from other tokens.
In the "reveal" phase, there are two UTXO inputs corresponding to the first two outputs of the commit phase. This transaction will first output an OP_RETURN, which will store the initial state hash of CAT20. Then, it will output a Minter, which will play an important role in maintaining the state changes during the subsequent minting process.
Looking back at the entire deployment process, "commit" and "reveal" follow the common practice of submitting and revealing two steps on the blockchain, which is a common way to deploy projects, where some data will only be revealed in the "reveal" phase.
Mint
Let's first take a look at the transaction when minting tokens.
In the above image, the minting process has the following characteristics:
- The input of the mint is a minter, which was initially generated during deployment.
- Each mint has only one minter as input and any number of minters as output (a bit problematic).
- Each mint has only one token as output (a bit problematic).
- The order of the outputs is important, with the minter always followed by the token.
Understanding the minting process, we can actually discover some special cases that make the entire minting process interesting.
For example, as the output of the mint transaction, the minter can be 1, multiple, or even 0. If it is set to 1 each time, the number of minters available in the entire network will remain unchanged (1), making minting crowded as everyone needs to compete for this minter. To avoid this situation, the quantity of minters output each time needs to be set to more than 1, so that after minting, the number of available minters will increase.
However, for each additional minter output, you need to pay an additional UTXO. For economic reasons, more people would be willing to set the minter to 0, inevitably causing the minter to become deflationary, requiring some people to make contributions and voluntarily pay for the extra minters.
In version 2, by default, two minters are generated, and the states of the two minters will be as similar as possible.
Transaction Construction
Some may have noticed a problem: why can minter's UTXO be used to construct transactions? To understand this issue, we need to analyze the source code of the "contract."
1. reveal UTXO
First, let's analyze the transactions in the reveal process. We find that it uses the output commit of the previous transaction as input. Why can we use a UTXO that is not our address to construct the transaction input?
Normally, one private key corresponds to one public key, and the public key derives the address. When verifying whether an input UTXO is valid, it is generally determined by comparing whether the signature decrypted with the public key is consistent with the original transaction. This logic is written in the Bitcoin script. So, we can cleverly rewrite the logic of the script. The public-private key pair written in the script is our own address, so we can control UTXOs from two different addresses.
By looking at the source code, we can understand what is happening:
Another question arises: if one private key corresponds to one public key, why does the generated commit address differ from our address? From the source code, we can see that our private key will adjust the public key according to an ISSUE_PUBKEY, which is also a feature of P2TR addresses.
2. minter UTXO
During the reveal process, we use different UTXOs as inputs, but in fact, the encrypted keys are the same, i.e., the deployer's private key. However, in the minter phase, everyone can use these UTXOs as inputs. How is this achieved?
I speculate that this is related to the previously mentioned ability of OP_CAT, which is the ability of smart contracts. Each minter is a smart contract. However, the source code for this part has not been publicly released, so the specific implementation is currently unknown.
Transaction State (V2)
In the minter, the state is also retained. This state exists in two places: one is the OP_RETURN of the transaction output, and the other is stored in the smart contract, i.e., the Minter and Token mentioned above.
The OP_RETURN stores the hash of the current transaction output state, while the contract stores the remaining minting times of the Token. After each mint, the mint quantity of the newly generated Minter will be equal to the remaining mintable quantity divided by two. This is represented in the diagram:
When all minting is completed, the remaining quantity of all minters will be 0.
Returning to the first image, besides Minter being a smart contract, the generated Token is also a smart contract, i.e., CAT20. CAT20 has two basic states: quantity and the address of the Token's owner. Unlike previous BRC20 or plaintext, your CAT20 is not on your address's UTXO.
Transfer
During a transfer, the quantities inside the token inputs and outputs need to remain consistent. Of course, within the same transaction, there can be multiple different tokens, as long as the input and output quantities of different tokens remain consistent.
Burn
To burn a Token, simply transfer the Token to a regular address.
Summary
As can be seen, all operations are constructed by the user, providing great flexibility. Therefore, a lot of validation logic needs to be implemented in the contract. Some of the currently reported vulnerabilities are due to negligence in the validation logic.
This design has some benefits:
- If you want to find out the holdings of all Tokens, you only need to check the UTXOs of the token, without the need to continue searching upwards.
- If you want to see the current minting situation, you can search for transactions with data containing "cat" in the OP_RETURN.
ZAN is offering no-threshold water rewards!
Tip: You can claim 0.01 ETH free testnet tokens once every 24 hours to support your experience and testing of Web3 projects within the Ethereum ecosystem. Click to claim now: https://zan.top/faucet?chInfo=ch_WZ
More public chains will be supported soon.
This article was written by Yeezo from the ZAN Team (X account @zan_team) (X account @GaoYeezo75065)
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
