Author: Olaoluwa Osuntokun 2022-04-08 17:30:51
Published on: 2022-04-08T17:30:51+00:00
Laolu, the creator of Taro protocol, responded to a feedback from Ruben. He acknowledged Ruben's analysis on RGB which shares a lot of similarities with Taro. However, he had difficulty extracting details from RGB developers in the past. Laolu explained that double spending or duplicate assets are resolved by strongly binding all assets to Bitcoin UTXOs, but assets can be burnt if a user doesn't supply a valid witness. Laolu also explained that asset histories can be compressed through compatibility with the LN layer without relying on another trust model. There are two possible designs for token history: tokens can either remain separate or get merged. Mechanically, both are expressible. To prevent containing more than one Taro tree, he suggested three options. He explained that the sparse merkle tree performs non-inclusion proofs, tracks issuance events, ensures uniqueness of certain items/commitments, and simplifies validation. Laolu answered Ruben's second question about transferring Taro token ownership. For interactive transfers, the UTXOs generated are just the ones part of the MIMO transaction. When sending via the address format, a new non-dust output is created which holds the new commitment and uses an internal key provided by the receiver. He admitted that he is not familiar with how the RGB "teleport" technique works and would like to know more. Finally, Laolu thanked Ruben for his feedback and will be updating the draft.Ruben Somsen, an expert who has examined RGB protocol extensively, has raised concerns about Taro protocol's scripting expectations and asset divisibility. He believes that Taro's scripting capabilities cannot handle conditional payments, which is the basis of any meaningful script other than self-encumbering covenants. This is because Taro has two levels of scripting, and the satisfaction of the condition needs to be recorded publicly on-chain, which makes it fundamentally impossible. Ruben also highlights that Taro's token history may cause problems for fungible tokens, as token fragmentation can lead to many tiny fragments, while linked transaction graphs may create bottlenecks. Additionally, Ruben points out some smaller issues with Taro's design, including the location of the Taro tree inside the Taproot tree and the purpose of the sparse merkle tree. Finally, he concludes by asking two questions about Taro's design, clarifying the purpose of the sparse merkle tree and questioning the ability to teleport tokens to an existing UTXO.Taro is a scripting system that supports integration with the Lightning Network. It can be used to emulate the existing HTLC structure, allowing for multi-hop transfers of Taro assets. The Taro design supports recursive instances of the Bitcoin Script Taproot VM, meaning anything that can be expressed in the latest version of Script can be expressed in the Taro scripting system. Future versions of the scripting system can introduce new functionality on the Taro layer, like covenants or other updates. The Taro protocol is a multi-part suite consisting of the main Taro protocol, the MS-SMT structure, the Taro VM, the Taro address format, the Taro Universe concept, and the Taro flat file proof format. All the BIPs can be found on the provided links. Rather than modifying the internal network, the protocol proposes to only recognize "assets at the edges". This means that only the sender+receiver need to know about and validate the assets, which eliminates the need to build up an entirely new network and liquidity for each asset. Instead, all asset transfers will utilize the Bitcoin backbone of the Lightning Network. This results in increased demand for transfers of these assets as the edges, generating increased demand of LN capacity, more transfers, and also more routing revenue for the Bitcoin backbone nodes.
Updated on: 2023-06-03T08:11:23.011159+00:00