Reported by Diamond Hands
At present, Ordinals (Inscriptions), a full-on-chain NFT, is popular in Bitcoin, but token issuance itself on Bitcoin has been around for about 10 years with protocols such as Open Asset Protocol, Omni, and Counterparty. I came. Among them, Tether (USDT) using Omni was successful, but Tether on Bitcoin has become a minority due to the rise in Bitcoin fees in 2017 and the subsequent increase in use in Defi.
With the maturity of the Lightning Network, which realizes fast and cheap remittances, it is said that the demand for stablecoins on Bitcoin is increasing again. In connection with this, projects such as Taro and RGB have become a hot topic, so a report entitled “Overview and Possibility of Token Issuance on Bitcoin” from Diamond Hands, a community of Lightning Network users and developers in Japan announced.
Click here for the Japanese version of the report
What kind of form is token issuance on “modern” bitcoin such as Taro and RGB, and what kind of idea is it being developed?
Emphasis on scalability creates secondary benefits
Scalability is closely related to UX, as assets such as Tether, which were originally used on Bitcoin, and joke tokens issued by Counterparty became obsolete due to soaring fees. Indeed, scalability is part of the motivation for major additions to Bitcoin in recent years, such as Segwit and Taproot, and is a major reason for the existence of the Lightning Network.
Protocols such as Taro and RGB introduced in the report adopt a mechanism called client-side validation (CSV). This is a scalable approach that reduces the burden on the network by verifying only between the users involved in the transaction, rather than verifying the contents of the transaction across the network.
Advantages of client-side validation
For example, in general smart contract chains such as Ethereum, token issuance and transfer are performed by smart contracts, and smart contract verification is performed by the entire network, so transactions involving tokens are more expensive than Ether remittances.
On the other hand, with client-side validation on bitcoin, token remittances can only be seen as bitcoin remittances to third parties, and only the parties themselves know the actual content. In addition to not requiring verification by other users on the network, there are privacy and fee benefits for token users.
However, this approach requires each user to hold data that proves the authenticity of the tokens they own, and the development of wallets, backup services, proxy reception services, etc. for that purpose is a prerequisite for widespread use. I will come. The environmental maintenance around here is still from now on.
The difference in thinking between Taro and RGB that I felt after researching the technology
In writing this report, I was researching Taro and RGB, which are client-side validation protocols that have been a hot topic in recent years. I was.
First of all, as a technical difference, RGB focuses on on-chain usage that fully enjoys the benefits of scalability and privacy through client-side validation as described above. As a result, the abstraction of the mechanism is high and the learning cost is high. On the other hand, Taro is easy to use, but it has the characteristics of inefficient transaction size and leaving on-chain traces indicating where to send tokens. Please see the report for a detailed comparison.
RGB and Taro are explained in the report, starting with their mechanism.
For example, for RGB, the software stack required for implementation is divided into parts and released to the public, and there is a strong awareness that we are creating an open protocol. Developers who want to use it can use it by incorporating only the parts they like into their own software, probably because it has a major goal of being a protocol that can write and verify smart contracts off-chain, not just token issuance.
It’s been improving recently, but the documentation is scattered, and there are issues where the main developers don’t agree. is.
On the other hand, Taro seems to focus on usage on Lightning and off-chain rather than pursuing scalability and formulating specifications. For example, while specific proposals have been made regarding how to relay using Lightning, interoperability is key to how wallets create transactions when transferring Taro assets on-chain. part is not specified. This background is probably related to the position of Lightning Labs, the developer of Taro.
Lightning Labs is the developer of the node implementation called Lnd, which is used by more than 90% of Lightning nodes. . Among them, rather than creating an open specification for third parties to implement, it may be a feeling that they are developing a single function called Taro Wallet that will be built into Lnd.
How Token Issuance Affects Bitcoin
As mentioned in this report, issuing tokens on Bitcoin and using them on Lightning will have certain advantages. In addition to issuing tokens, RGB may contribute to improving the functionality of Bitcoin through smart contract functions.
If there is a point of concern, if the influence of stablecoins increases too much, it may also have influence over Bitcoin and Lightning. In particular, Taro has a great influence on the direction of the Lightning Network through Lightning Labs, and I can only hope that the spread of Taro assets will further strengthen the enclosure of Lightning implementations and will not undermine the openness of the network.
One of the nice things about Bitcoin is that you can choose the software you run and opt out of changes that you feel are inappropriate, but the confusion in the process greatly undermines usability and is something you want to avoid if possible. For that reason, we also expect the evolution of Bitcoin-native financial solutions that do not require centralized tokens.
Click here for the Japanese version of the report
The post Considering the Token Issuance Protocol on Bitcoin and the Ideas Behind It|Contributed to Bitcoin Research Institute appeared first on Our Bitcoin News.