What are the security risks arising from the incomplete infrastructure of Bitcoin | BRC-20?
Under the recent popularity of the BRC-20 market, the related security issues of the Ordinals mechanism have been brought up for discussion by the community. What are the security issues with BRC-20? What do holders absolutely need to know?
Table of Contents:
Toggle
Background knowledge of BRC-20
Ordinals
BRC-20
Derived issues of BRC-20
Creating something out of nothing
Double-spending problem
How to protect yourself at this stage
Potential community solutions
ORDI as a governance token creates corresponding agreements
TRAC decentralized index network protocol
Expect more development of BRC-20 infrastructure
Before discussing the security issues of BRC-20, it is necessary to have a basic understanding of the Ordinals protocol and the operation principle of BRC-20 in order to understand it in depth.
Ordinals is a project developed and open-sourced by software engineer Casey Rodarmor in January of this year. The protocol can track all bitcoins on the Bitcoin network, with the unit of tracking being the smallest unit of bitcoin, “satoshi.”
The Ordinals protocol allows users and openers to write any information into the transaction note field of satoshi, so that specific satoshis can be associated with external metadata such as images or text, opening up the era of NFTs on Bitcoin. This action of recording corresponding data is called inscription.
Because the Bitcoin network does not have a native virtual machine and smart contract system, these data are managed by off-chain servers. This is fine, but then BRC-20 emerged.
Subsequently, in March of this year, a person named @domodata used the Ordinals protocol to create the BRC-20 standard, which is to record the text inscribed on the token as a JSON file. An example of token data recording is as follows:
JSON information for minting ORDI tokens
(Source of data)
As mentioned above, since the Bitcoin network does not have a smart contract system, all information is actually stored in the transaction note field. Therefore, defining the minting, transferring, and burning mechanisms of BRC-20 is just writing text and does not have any practical effect. It requires other mechanisms to assist in calculation and settlement. At this stage, off-chain servers and indexers are used to track and manage all records.
For example, if Xiaoming wants to transfer 10 PEPE tokens to Xiaomei, he needs to write the transfer information of PEPE in JSON format into the note field of the transfer transaction and wait for it to be packaged into a block. Then, the indexer tracks the information in the JSON file from its ledger, deducts Xiaoming’s PEPE tokens, and increases Xiaomei’s PEPE token record.
Therefore, there is a need for exchanges and wallets that can track BRC-20 token transaction information. The following services currently support BRC-20 tokens:
OKX Wallet
UniSat Wallet
Magic Eden
It can be seen that the BRC-20 mechanism has obvious security issues. Holders need to trust the indexer in order to complete these transactions. If these indexers act maliciously, abnormally, or are hacked, user assets will face security risks.
Using this mechanism can lead to situations where someone buys tokens with nothing (creating something out of nothing), or someone makes multiple transactions with a fixed amount of tokens (double-spending problem), as explained below.
Community member Sam on X (Twitter) gave an example. Suppose a hacker wants the A token held by Xiaoming. If the hacker happens to have the ability to hack into a well-known indexer and control it for an hour, during this hour, the hacker first increases the B token out of thin air (by tampering with the indexer database), and then transfers token B to Xiaoming.
Xiaoming is cautious, and he can also see that he has received token B in his browser, so he confidently transfers token A to the other party. After an hour, when the indexer discovers the intrusion and resynchronizes the data, Xiaoming will find that token B has disappeared when he refreshes the browser, and token A has also disappeared.
Why did this happen? The reasons are as follows:
The hacker and Xiaoming are connected to the same indexer server, and the front-end data seen by Xiaoming and the hacker are always the same, including before and after being hacked and the process of being hacked.
The transfer of token B from the hacker to Xiaoming did not occur on the Bitcoin chain. This transaction information only occurred in the indexer server, and the hacker can modify the data in the database. Because Xiaoming trusts this indexer, he believes that the transaction of token B has been completed when he sees the updated data in the indexer browser.
Even if Xiaoming directly checks the inscription on the Bitcoin network, the hacker can simply send a transaction with JSON information written by the hacker (which the indexer will not recognize) for Xiaoming to check.
The transaction of token A given by Xiaoming to the hacker did indeed occur on the chain, and because Xiaoming does have enough token A, even if the indexer discovers the hack and rolls back, Xiaoming’s transaction will still be successfully executed.
The hacker does not have token B at all, so why did this transaction succeed? The reason is that the Bitcoin network does not have a virtual machine or smart contract. It only records data, and the entire validity verification is completed by the indexer. At this time, the indexer has been controlled by the hacker.
In addition to the hacker issue, there have also been instances of double-spending risks due to differences in versions of multiple indexers, which means that due to differences in different indexer versions, an asset has the possibility of multiple transactions. However, when these mainstream indexers reach consensus after synchronization, it will result in the loss of assets for holders who bought non-consensus assets.
Further reading:
Asset Security | BRC-20 version discrepancy, some platforms suspend related transactions
Pay attention to the community’s updates, usually Twitter messages are the most timely, to ensure that the indexer is trustworthy when trading assets.
Looking forward to better infrastructure in the future to reduce the security risks of BRC-20.
The aforementioned problems are due to the scarcity of ecological indexers at this stage. If there are 100 indexers, the hacker will not know which indexer Xiaoming will use, and Xiaoming can switch to other indexers for multiple verifications at any time. The cost for the hacker to do bad things will increase to the point where they almost don’t want to do it.
Economic mechanisms are needed to solve the problem. In fact, the number of indexers in operation depends on how much profit the indexer operators can obtain. If the profit is high enough, they will naturally operate, and the number will increase. This is similar to the operating mode of most decentralized network nodes now. With a sufficient number, decentralization and trustlessness can be achieved, without worrying about node failures or malicious behavior.
A community member proposed using the earliest BRC-20 token, ORDI, and constructing a governance mechanism where all indexers need to pledge ODRI tokens to operate. If they complete transactions successfully, they will be rewarded with tokens, and if they do bad things, their tokens will be confiscated.
However, at the current stage, it is difficult to change the token economy of ORDI, which has developed until now, and it is challenging to promote it.
It is more anticipated that there will be new protocols and tokens with sufficient consensus to solve this problem. Some teams have started trying, and TRAC has been proposed.
TRAC Protocol
It includes a decentralized network, corresponding clients, and a token governance economic model. The goal is to build a decentralized indexer network and strengthen the security of the BRC-20 network using token rewards and punishment mechanisms.
However, whether the consensus of this project is sufficient to promote its vision is still unknown because it requires most mainstream indexers to be willing to join and respond.
In fact, the above-mentioned derived issues and risks faced by assets are ultimately caused by:
BRC-20 not having smart contract support.
Therefore, there is a need to build a new decentralized network and provide secure indexer execution layers with incentive mechanisms.
But since we’re starting from scratch, why not do it all at once and create a decentralized virtual machine layer specifically for Bitcoin execution? This would be more cost-effective. Because starting from scratch to build a decentralized network requires a new economic model to maintain it. Looking at the development history of blockchain, decentralized storage networks, and oracle domains, it can be seen that building a decentralized network and consensus from scratch is a very difficult task. Compared to technology, the author believes that consensus is more valuable and harder to achieve. If there is the ability to gather consensus, then complement the technology.
It is expected that in the future, there will be a smart contract layer for Bitcoin.
Regardless of the future development and results of BRC-20, many people are working hard to optimize the existing ecosystem, and we look forward to a more mature BRC-20 in the future.
BRC-20
Indexer
Ordinals
Further reading
Sora Summit | Bitcoin OGs Gather! Discussing L2 Development, Predicting Bitcoin Market Cap Reaching 4 Trillion?
Bitcoin NFTs on Sotheby’s Auction! Three images sold for $450,000, five times the estimated price.
