From the earliest colored coins, OmniLayer, to last year's Ordinals, and this year's Runes and RGB++, the Bitcoin community has never stopped trying to issue assets on the Bitcoin network. Despite the many controversies among Bitcoin maximalists, who believe that Bitcoin should play a simple role as a currency and are concerned that complexity may introduce potential risks.

The main reason is that the security and scale of the Bitcoin network itself are very tempting, as a natural high-quality infrastructure, it can bring a lot of narrative space for the assets issued on it. And avoiding proposals for the Bitcoin network and only using existing on-chain space to explore asset issuance methods is open to the community. Currently, these explorations of asset issuance methods are blooming everywhere, but the final outcome is uncertain.

Today, we are going to talk about Bitroot, which has proposed a new way of issuing assets using the Bitcoin network and supports the embedding of smart contracts, while also being the L2 layer of Bitcoin.

Evolution of asset issuance methods on the Bitcoin network

Let's start with the asset issuance methods on Bitcoin.

The earliest colored coins used Bitcoin's UTXO to distinguish them from other UTXOs by adding specific information to the Bitcoin UTXO, thus achieving the "coloring" effect, and the "colored" UTXOs carried the new assets. The metadata related to these assets is mainly stored in the OP_RETURN operation code of Bitcoin transactions. OP_RETURN was originally designed to terminate the script and return the top of the stack, similar to a return function in programming languages. Later, it became the main way to embed data in Bitcoin transactions. The most representative project is Open Assets.

During the same period when colored coins were popular, many upgraded asset issuance methods appeared, such as OmniLayer (formerly Mastercoin), which is more like what is now called Layer2, placing the transaction logic under the Bitcoin chain, with the Bitcoin chain acting as a log function, also using OP_RETURN to add OmniLayer transaction metadata. There is also Counterparty, as a protocol layer above Bitcoin, aiming to achieve decentralized asset exchange functionality. Counterparty initially used the Bitcoin opcode OP_CHECKMULTISIG to include Counterparty-related data in the Bitcoin blockchain, but because using OP_CHECKMULTISIG was considered a type of hacking attack, it later switched to using the OP_RETURN operation code to store data.

Some other early storage methods include: using the issuance method of the nSequence field, where nSequence is a reserved field in Bitcoin transactions with a 32-bit space. The advantage of using nSequence is that it does not add additional storage. A representative project is EPOBC (enhanced, padded, order-based coloring), which stores additional information about assets in the nSequence field of Bitcoin transactions. However, the disadvantage is that it does not number the assets, so when trading, it is necessary to trace back to the original genesis transaction, which is quite cumbersome.

It can be seen that using the OP_RETURN operation code to store data is almost the mainstream practice for asset issuance on early BTC.

After the SegWit and Taproot upgrades of Bitcoin, new storage space was brought to asset issuance. At this time, Ordinals (runic inscriptions) emerged. It uses P2TR (a type of transaction output in Bitcoin) introduced after the Taproot upgrade to engrave metadata in the witness data of transactions, with the advantage of larger storage space: the maximum limit for a single piece of Taproot information is 520 bytes, and the data capacity can be extended by combining multiple pieces of information; the storage cost of witness data is also relatively cheaper. Therefore, after the experimental launch of Ordinals, it caused a speculative sentiment in the market and re-attracted the community's attention to the asset issuance methods on the Bitcoin chain. Inspired by Ordinals, various improved asset issuance protocols have emerged, such as Atomicals, which borrows the logic of colored coins, matching the quantity of each ARC-20 token with satoshis, thus not requiring a off-chain indexer like BRC-20, because asset information is all located in the UTXO.

However, the issuance method of runic inscriptions has also faced opposition from many OGs in the Bitcoin community, mainly due to concerns that it will make Bitcoin blocks bloated, and BRC-20 is also prone to dust attacks. Moreover, the engraving position is in the witness data area, and some community members are concerned that this space will be removed after future upgrades.

The recent popular Runes protocol has returned to tradition, choosing to store asset metadata in OP_RETURN and combining the UTXO-based mechanism of Atomicals, where any amount of Runes tokens can be included in the UTXO.

It can be seen that the asset issuance methods have gone through rounds of iterations, but ultimately, more protocols still choose to use OP_RETURN in Bitcoin to store asset data.

Bitroot's new asset issuance solution

Returning to Bitroot, Bitroot has introduced BRT20, a new asset issuance protocol on the Bitcoin chain. Bitroot calls it the root protocol, and it also chooses to store data in OP_RETURN.

Specifically, using the bitcoinlib library (a popular library for handling Bitcoin-related operations), one can create Bitcoin transactions containing OP_RETURN outputs. Similar to other Bitcoin asset issuance and trading methods, Bitroot can also issue and trade assets by creating Bitcoin transactions in a specific format that includes special metadata defining the asset name, total supply, and other properties. Once such transactions are confirmed by the Bitcoin network and added to the blockchain, Bitroot protocol nodes will parse the data and record the corresponding asset creation and allocation in their internal database.

It is worth mentioning that the data stored in OP_RETURN by Bitroot is not only for asset issuance and trading, but also for smart contracts.

However, the smart contracts here are different from the usual EVM smart contracts, because Bitroot's smart contracts are built on top of the Bitcoin blockchain, using Bitcoin's script language (a basic language for Bitcoin transactions) to implement. For security reasons, Bitcoin's script language is designed to be non-Turing complete, containing only some regular opcodes, such as OP_ADD, OP_EQUAL, OP_CHECKSIG, OP_CHECKMULTISIG, etc., designed for single payment purposes. There are no loop statements, avoiding the risk of infinite loops, but this also means that it cannot perform complex computational tasks, and its main application scenario is to verify transaction signatures to ensure the authenticity of transactions. Therefore, smart contracts on Bitcoin are more restricted compared to EVM smart contracts.

Bitroot also recognizes this characteristic of Bitcoin's script language, and the solution is to extend the functionality of Bitcoin's script language by adding additional opcodes and features to support more complex smart contracts. The following are the basic features of Bitroot's implementation of smart contracts:

1. Based on Bitcoin's script language

Bitroot extends the functionality of Bitcoin's script language by adding additional opcodes and features.

2. Embedding data in transactions

The smart contract data of Bitroot is embedded in the OP_RETURN output of Bitcoin transactions, and Bitroot nodes can parse and execute the data. Therefore, the logic and state changes of smart contracts can be encoded and stored in this data.

3. Analysis and Execution of Smart Contracts

When the Bitcoin network confirms transactions containing OP_RETURN data, Bitroot nodes will parse the data in these transactions and execute corresponding operations based on the embedded smart contract code. This includes asset transfers, contract execution, etc. Each Bitroot node independently verifies and executes these operations to maintain network consistency.

4. Limitations and Features

Although Bitroot enhances the functionality of smart contracts in this way, its functionality is limited by the non-Turing completeness of Bitcoin scripts. Therefore, Bitroot's smart contracts are more suitable for applications that do not require complex logic, such as simple financial protocols and asset management.

5. Future Expansion

The Bitroot community is exploring more ways to expand the functionality of smart contracts, including possible protocol upgrades and integration with other blockchain technologies to provide broader application support.

Based on the above characteristics, Bitroot can issue new assets and embed smart contract logic into transactions, enabling more complex financial use cases than traditional issuance/trading, without modifying the core protocol of Bitcoin.

Bitroot runs on two code repositories: Bitcoin Core and Bitroot's own software, so Bitroot transactions must be confirmed by the Bitcoin network. At the same time, Bitroot can inherit the security and decentralization of the Bitcoin network.

In addition, Bitroot provides a range of tools and wallet applications to the developer community, enabling developers and users to easily manage assets, trade, and interact with smart contracts using the Bitroot protocol. Bitroot also supports automated and integrated APIs to provide maximum convenience for user usage.

By embedding smart contract functionality into the Bitcoin network and defining a parsing system, Bitroot makes contract logic more open and transparent, inheriting the security of the Bitcoin network while bringing richer gameplay to assets on the Bitcoin network. In addition to asset issuance and trading, DeFi services such as lending, Dex, derivatives, launch platforms, as well as asset trading for in-game items, virtual characters, and art assets can also be conducted on-chain.

Bitroot Test Experience

Currently, Bitroot is open for testing, with the testnet address: https://app.bitroot.co/.

Obtain BRT test tokens: https://forms.gle/Ghge9r18EqHghCLo6BTC;

BTC testnet faucet: https://coinfaucet.eu/en/btc-testnet/;

Purchase BTC testnet coins: https://buytestnet.com/.

After entering, create a wallet first, then claim the test tokens to start testing asset issuance.

Currently, there are three types of assets that can be created: assets with letter names, sub-assets of existing assets, and free digital name assets.

Creating assets with letter names is relatively simple. Enter the Token Name, Description (which can be modified at any time), quantity (default is expandable), and click "create token" to create.

Creating sub-assets of existing assets requires creating the parent asset first, then selecting the newly created asset, entering the Token Name and quantity to create.

When creating free digital name assets, a string starting with "A" will be randomly assigned as the token name (the numbers after "A" can be customized). Enter the description, quantity, and create.

Simply click on the arrow on the asset to transfer, view information, increase the quantity, or lock the asset from further issuance.

The left side of the interface is the asset trading interface. The interface displays the current popular trading pairs and the trading pairs with pending orders in the market. Search for the corresponding trading pair to complete buying and selling orders, making it simple and convenient.

Conclusion

Bitroot's introduction of BRT20 delves into the available functionality of the Bitcoin chain, providing an intelligent way to issue native assets on the Bitcoin chain. However, the protocol is still in its early stages, and it will take time to be widely accepted by the community.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。