What are the security risks arising from the incomplete infrastructure of Bitcoin and BRC-20?

With the recent fervor in the BRC-20 market, related security issues stemming from the Ordinals mechanism have once again been brought to the forefront for community discussion. What are the security issues with BRC-20? What are the absolute must-knows for holders?

BRC-20 Background Knowledge

Before discussing the security issues related to BRC-20, it is necessary to have a basic understanding of the Ordinals protocol and the operation principle of BRC-20, which will facilitate a deeper comprehension.

Ordinals

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 tracking unit being the smallest unit of Bitcoin known as "satoshi".

The Ordinals protocol allows users and creators to write any information into the satoshi transaction memo field, enabling specific satoshis to be associated with external metadata such as images or text, thus ushering in the NFT era on Bitcoin. This action of recording corresponding data is referred to as "inscribe".

Since the Bitcoin network does not have native virtual machines or smart contract systems, this data is managed by linking to off-chain servers. However, everything changed with the introduction of BRC-20.

BRC-20

In March of this year, a project called BRC-20 standard was created by @domodata using the Ordinals protocol. This standard involves recording token data in the form of a JSON file, as shown below:

As mentioned earlier, the Bitcoin network lacks smart contract systems, and all information is actually stored in the transaction memo field. Therefore, defining the mechanism for minting, transferring, and burning BRC-20 tokens by writing text on them does not have real effect. Other mechanisms are needed to assist with computation and settlement. Currently, off-chain servers and indexers are used to track and manage all records.

For example, if Xiao Ming wants to transfer 10 PEPE tokens to Xiao Mei, he needs to write the PEPE transfer information in JSON format into the memo field of the transaction involving satoshis. After the block is successfully mined, the indexer will track the information in the JSON file and deduct Xiao Ming's PEPE tokens while adding the same amount to Xiao Mei'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

BRC-20 Derived Issues

It is evident that the mechanism of BRC-20 presents significant security challenges. Holders need to trust the indexer to complete these transactions. If the indexer behaves maliciously, abnormally, or is hacked, users' assets could face security risks.

This mechanism may lead to scenarios where someone buys tokens with non-existent assets or engages in double-spending with fixed amounts of tokens. The following explains each situation.

Non-Existent Assets

Community member Sam provided an example on X Twitter here. Suppose a hacker wants the A tokens held by Xiao Ming. If the hacker gains control of a well-known indexer and can manipulate it for an hour, during that period, they could create token B out of thin air by tampering with the indexer's database and then transfer token B to Xiao Ming.

Xiao Ming, seeing the token B in his browser, then confidently transfers token A to the hacker. When the hour is up, and the indexer detects the intrusion and resynchronizes the data, Xiao Ming will find that token B has disappeared, and token A as well.

Why does this happen? Here are the reasons:

• The hacker and Xiao Ming are connected to the same indexer server, so what they see on the frontend remains the same, including the period before and after the hack, and during the hack.
• The transaction of token B from the hacker to Xiao Ming did not occur on the Bitcoin chain. This transaction information only exists within the indexer server, which the hacker can manipulate. Since Xiao Ming trusts this indexer, he believes that the transaction of token B is completed upon seeing the updated data in the indexer's browser.
• Even if Xiao Ming checks the blockchain directly, the hacker can still create a transaction with JSON information that the indexer will not approve, preventing Xiao Ming from verifying it.
• The transaction of token A from Xiao Ming to the hacker did occur on the chain, and because Xiao Ming indeed has enough token A, even if the indexer rolls back after discovering the hack, Xiao Ming's transaction will still be executed successfully.

Why did the transaction succeed when the hacker did not have token B? This is because the Bitcoin network lacks a virtual machine and smart contracts, only recording data, and the entire legitimacy check is completed by the indexer, which is already under the hacker's control.

Double-Spending Issue

In addition to hacker-related problems, there have been instances in the past where differences in multiple indexer versions led to the risk of double-spending. This means that due to disparities in different indexer versions, an asset may be subject to multiple transactions. However, when these mainstream indexers reach a consensus after synchronization, holders who acquired non-consensus assets could suffer losses.

How to Protect Oneself at Present

Stay informed about community updates, with Twitter messages being the most timely, to ensure that the indexer you use for asset transactions is trustworthy.

Looking forward to future improvements in infrastructure to mitigate the security risks associated with BRC-20.

Community Potential Solutions

The current ecosystem faces a shortage of indexers, leading to the aforementioned problems. If there were 100 indexers, for example, the hacker would not know which indexer Xiao Ming used, and Xiao Ming could switch to other indexers for multiple verifications at any time, thus increasing the cost for the hacker to engage in malicious activities to a point where it becomes almost unfeasible.

Economic mechanisms are needed to address the issue. The number of running indexers actually depends on how much profit indexer operators can make. If the profit is high enough, they will naturally operate more, similar to the operational model of most decentralized network nodes nowadays, where a sufficient number ensures decentralization and trustlessness, without worrying about node failures or malicious activities.

ORDI as Governance Token Creating Corresponding Protocols

Some community members have proposed using the earliest BRC-20 token - ORDI, and establishing a governance mechanism where all indexers need to stake ODRI tokens to operate. Successful transactions will be rewarded with tokens, while malicious behavior will result in token confiscation.

However, making significant changes to the ORDI token's economic model at this stage is not easy to maintain community consensus, making it challenging to promote.

There is more anticipation for new protocols and tokens with sufficient consensus to address this problem. Some teams have started working on solutions, with TRAC being proposed by some.

TRAC Decentralized Indexer Network Protocol

The TRAC protocol includes a decentralized network, corresponding client, and token governance economic model, aiming to establish a decentralized indexer network and enhance BRC-20 network security through token rewards and penalties.

However, whether the project's consensus is sufficient to drive the vision remains unknown, as it requires the willingness of most mainstream indexers to join and respond.

Looking Forward to Further Development of BRC-20 Infrastructure

The aforementioned derived issues and risks faced by assets ultimately stem from:

Therefore, there is a need to rebuild a decentralized network and provide secure indexer execution layers with incentive mechanisms.

However, since starting from scratch, why not create a decentralized virtual machine execution layer specifically for Bitcoin at once? It would be more cost-effective. Rebuilding a decentralized network requires a new economic model to maintain, as seen in the development history from blockchains and decentralized storage networks to the oracle field. It is evident that building a decentralized network and consensus from scratch is a very challenging task. Author believes that consensus is more valuable and harder to achieve than technology. If there is the ability to consolidate consensus, then focus on supplementing the technology.

Expect to see the emergence of smart contract layers for Bitcoin in the future.

Regardless of the future direction and outcome of BRC-20, many are striving to optimize the existing ecosystem, looking forward to a more mature BRC-20 in the future.