From the earliest colored coins and OmniLayer, to last year's inscriptions, and to this year's runes and RGB++, the Bitcoin community has never stopped trying to issue assets on the Bitcoin network, despite many controversies among Bitcoin maximalists, who believe that Bitcoin should play the role of currency in a minimalist way and worry that complexity will introduce potential risks.
The main reason is that the security and volume of the Bitcoin network itself are very attractive. As a natural high-quality infrastructure, it can bring a lot of narrative space to the assets issued on it. And avoiding proposals on the Bitcoin network and only using the existing on-chain space to explore asset issuance methods is open to the community. At present, these explorations of asset issuance methods are blooming everywhere, but the final outcome is still uncertain.
Bitroot, which we are going to talk about today, also proposed a new way of issuing assets using the Bitcoin network, and supports the embedding of smart contracts. It is also the L2 layer of Bitcoin.
The evolution of asset issuance on the Bitcoin network
Let’s start with the way assets are issued on Bitcoin.
The earliest colored coins used Bitcoin's UTXO. By adding some specific information to Bitcoin UTXO, it can be distinguished from other UTXOs, thereby achieving the "coloring" effect, and the "colored" UTXO carries new assets. The metadata related to these assets is mainly stored in the OP_RETURN opcode of the Bitcoin transaction script. OP_RETURN was originally designed to terminate the script and return the value at the top of the stack, similar to the return function in programming languages. Later, it became a way to embed data in Bitcoin transactions. The biggest feature is that the data added to the Bitcoin transaction by OP_RETURN is verifiable but not consumable for the Bitcoin network. The upper limit of the amount of data allowed to be stored has increased from 40 bytes in the early version to the current 80 bytes. More representative projects, such as Open Assets.
At the same time when colored coins were hot, many upgraded asset issuance methods appeared, such as OmniLayer (formerly Mastercoin), which is more like what we now call Layer2, placing transaction logic under the Bitcoin chain. The Bitcoin chain acts as a log function and also uses OP_RETURN to add OmniLayer transaction metadata. There is also Counterparty, as a protocol layer on top of Bitcoin, which also aims to realize decentralized asset exchange functions. Counterparty initially used the Bitcoin opcode OP_CHECKMULTISIG to include Counterparty related data in the Bitcoin blockchain, but because the use of OP_CHECKMULTISIG was considered a hacker attack, it later switched to using the OP_Return opcode to store data.
Other early storage methods include: using the nSequence field issuance method. nSequence is a reserved field in Bitcoin transactions with 32 bits of space. The advantage of using nSequence is that it does not add additional storage. The representative project is EPOBC (enhanced, padded, order-based coloring). EPOBC stores additional information about assets in the nSequence field in Bitcoin transactions. However, the disadvantage is that there is no asset numbering, so when trading, it is necessary to trace back to the original creation transaction, which is cumbersome.
It can be seen that using the OP_RETURN opcode to store data was almost the mainstream practice for issuing assets on BTC in the early days.
After Bitcoin's Segregated Witness and Taproot upgrades, new storage space was created for asset issuance. Ordinals was born. It uses P2TR (a type of Bitcoin transaction output) introduced after the Taproot upgrade to engrave metadata in the transaction's witness data (witness field). The advantage is that the storage space is larger: the upper limit of a single Taproot message is 520 bytes, and the amount of data accommodated can be expanded by combining multiple messages; the storage cost of witness data is also relatively cheaper. Therefore, after the experimental launch of Ordinals, it caused market hype and also attracted the community's attention to the asset issuance method on the Bitcoin chain. Inspired by Ordinals, various improved asset issuance protocols have emerged in an endless stream. Popular ones, such as Atomicals, borrow the logic of colored coins to correspond the number of each ARC-20 token to the number of sats, so there is no need for an off-chain indexer like BRC-20, because asset information is all in UTXO.
However, the way the inscription is issued has also been opposed by many OGs in the Bitcoin community, mainly because they are worried that it will make the Bitcoin block bloated and BRC-20 is prone to dust attacks. In addition, the inscription location is in the witness data area, and some community members are worried that this part of the space will be cancelled after future upgrades.
The recently popular Runes protocol has returned to tradition and chooses to store asset metadata in OP_RETURN. It also combines Atomicals' UTXO-based mechanism to include any number of Runes tokens in UTXO.
It can be seen that the asset issuance method has gone through rounds of iterations, but in the end more protocols still choose to use OP_RETURN in Bitcoin to store asset data.
Bitroot’s new asset issuance plan
Back to Bitroot, Bitroot launched BRT20, a new asset issuance protocol on the Bitcoin chain. Bitroot calls it the root protocol, and the location chosen for data storage is also OP_RETURN.
Specifically, bitcoin transactions containing OP_RETURN outputs can be created through the bitcoinlib library (a popular library for handling bitcoin-related operations). Similar to other bitcoin asset issuance and trading methods, Bitroot can also implement asset issuance and trading by creating bitcoin transactions in a specific format. When a user needs to issue a new asset, the user needs to construct a bitcoin transaction that contains special metadata that defines the asset name, total amount, and other properties. Once such a transaction is confirmed by the Bitcoin network and added to the blockchain, the node of the Bitroot protocol will parse the data and record the corresponding asset creation and allocation in its internal database.
It is worth mentioning that the data stored by Bitroot in OP_RETURN is not only asset issuance and transaction data, but also smart contracts.
However, the smart contracts here are different from the smart contracts of EVM in the usual sense, because Bitroot's smart contracts are built on the Bitcoin blockchain and implemented using Bitcoin's scripting language (a basic language for Bitcoin transactions). For security reasons, Bitcoin's scripting language is designed to be non-Turing complete and only contains some regular opcodes, such as OP_ADD, OP_EQUAL, OP_CHECKSIG, OP_CHECKMULTISIG, etc., which are designed for a single payment purpose. There are no loop statements, which avoids the risk of infinite loops, but this also means that it cannot perform complex computing tasks. The main application scenario is to verify transaction signatures and ensure the authenticity of transactions. Therefore, smart contracts on Bitcoin are more limited than EVM smart contracts.
Bitroot also recognizes this feature of the Bitcoin scripting language, and the solution is to expand the functionality of the Bitcoin scripting language by adding additional operation codes and functions to support more complex smart contracts. The following are the basic features of Bitroot's implementation of smart contracts:
1. Bitcoin-based scripting language
Bitroot expands functionality by adding additional operation codes and functions based on the Bitcoin scripting language.
2. Embed data in transactions
Bitroot’s smart contract data is embedded in the OP_RETURN output in Bitcoin transactions, and Bitroot nodes can implement data parsing and execution. 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, the Bitroot node will parse the data in these transactions and perform corresponding operations based on the embedded smart contract code. This includes the transfer of assets, the execution of contracts, 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 agreements and asset management.
5. Future Expansion
The Bitroot community is already 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 features, Bitroot can realize the issuance of new assets and embed smart contract logic into transactions, thereby realizing more complex financial use cases than traditional issuance/transactions without modifying the core protocol of Bitcoin.
Bitroot runs on two code bases: Bitcoin Core and Bitroot's own software, so Bitroot transactions must be confirmed by the Bitcoin network. At the same time, Bitroot can also inherit the security and decentralization of the Bitcoin network.
In addition, Bitroot provides the developer community with a series of tools and wallet applications that enable developers and users to easily use the Bitroot protocol for asset management, transactions, and smart contract interactions. Bitroot also supports automated and integrated APIs to maximize user convenience.
Bitroot embeds smart contract functions into the Bitcoin network and defines a parsing system to make the contract logic more open and transparent. While inheriting the security of the Bitcoin network, it also brings more gameplay to assets on the Bitcoin network. In addition to asset issuance and trading, Defi services such as lending, Dex, derivatives, and launch platforms, as well as asset transactions such as in-game items, virtual characters, and artworks can also be put on the chain.
Bitroot Testing Experience
Currently, Bitroot is open for testing, the test network address is: https://app.bitroot.co/.
Get BRT test coins: https://forms.gle/Ghge9r18EqHghCLo6BTC;
BTC test coin faucet: https://coinfaucet.eu/en/btc-testnet/;
Purchase BTC test coins: https://buytestnet.com/.
After entering, create a wallet first, and then you can test the asset issuance after receiving the test token.
It is relatively simple to create an asset with alphabetic names. Enter the Token Name, Description (this information can be modified at any time), quantity (issued quantity, the default is that additional issuance is possible), and click create token to create it.
To create a sub-asset of an asset, you need to create the parent asset first. You can select the asset you just created and enter the Token Name and quantity to create it.
When creating a free digital name asset, a string starting with A will be randomly assigned as the token name (the number after A can be customized). You can still enter the description information and quantity to create it.
Simply click the arrow on the asset to transfer assets, view information, issue additional assets, lock assets and stop issuing additional assets, etc.
The asset trading interface is on the left side of the function area. The interface will display the current popular trading pairs and the trading pairs with pending orders in the current market. You can complete the buy and sell orders by searching for the corresponding trading pairs, which is simple and convenient.
Summarize
BRT20 launched by Bitroot has deeply explored the available functions of the Bitcoin chain and provided 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 see whether it can be widely recognized by the community in the future.
