This week, Lightning Labs unveiled the alpha release of the TARO (Taproot Asset Representation Overlay) daemon software, an open-source daemon that sits on top of the lightning network and is anchored to the bitcoin blockchain. I’ve successfully installed and played with it for the past two days. This article is a summary of my thoughts on what’s working now and how this will play out in the future. With any new software, there are a lot more questions than answers. So, if anything is missed out or misrepresented, please reach out to me directly, and I will make effort to add/update.
Here is the press release from Lightning Labs.
Why do we need assets on the blockchain?
Before we get into TARO, let’s try to answer this question. Almost every blockchain created after bitcoin supports asset/token representation. Many bitcoiners feel that all tokens/coins are useless and that nothing can exist and replace bitcoin. However, in some cases, using a stablecoin/asset is desirable. In nations like El Salvador, I’ve witnessed how the bitcoin lightning network is used for daily transactions. However, due to bitcoin’s volatility, many low-income merchants cannot afford to accept bitcoin payments. Today, businesses cope with this issue by hedging it on an exchange or converting it to a stablecoin. However, there is a true demand for a stable asset that is decentralized, instantly settled, and enables peer-to-peer transactions without the involvement of financial middlemen. Today’s stablecoin market is dominated by two large centralized for-profit corporations with a massive attack surface from nation-states. If TARO can only solve this one issue, it will be worth the effort. While the TARO solution with lightning and bitcoin may be technically sophisticated, the goal for end users should be as simple as using Apple Pay.
What makes TARO different?
First and foremost, there are no modifications to the Bitcoin blockchain. The Bitcoin blockchain is still based on the same UTXO model. TARO, on the other hand, makes use of Taproot support, which was enabled by a soft fork upgrade last year. Lightning Network continues to operate in the same manner by establishing payment channels, and it now supports Taproot as well. TARO is capitalizing on these qualities to enable assets on the edge. This contrasts with other blockchains in which asset information is entered on layer one blockchain, and all development and upgrades take place on the main layer.
Does it work?
Yes. The alpha software was able to run successfully, mint an asset anchoring onto the Bitcoin blockchain and send it to another address. But it is an alpha version with no graphical user interface and comes with issues, and many features are still under development. Creating an asset is as simple as providing a name, amount, and asset type. The genesis transaction needs to be entered on the bitcoin blockchain to get a unique asset ID. These on-chain transactions can be batched to save on-chain transaction costs.
There are two types of assets supported. One is “Normal” and the other is “Collectible”. Normal assets are fungible, while collectibles are non-fungible. Also, the amount is 1 when the type is “collectible”. Right now, collectible asset transfers are supported only on-chain and not through lightning channels.
Here is the result of generating a new address. Similarly, to a lightning invoice, the encoded value can be displayed to the end user as a QR code to be scanned by the wallet App before initiating the send from the wallet App.
tarocli addrs new — genesis_bootstrap_info abaa19a1d858b9c50be78e9f8117c39371ebabc8bebd27ba99f85bac5b0aca9f0000000209737461726261636b720f737461726261636b72206d6f6e65790000000000 — amt 50
{
“encoded”: “tarotb1qqqsqqjr4w4pngwctzuu2zl8360cz97rjdc7h27gh67j0w5elpd6ckc2e20sqqqqqgyhxarpwf3xzcmtwg8hxarpwf3xzcmtwgsx6mmwv4usqqqqqqqqggzg4yzwvwakhel5pqc0k8034x4g89ygg0yecnymj7687ul3agewcvrzpd6u76ec7dzz3tlxtnjqdkpv7vpgz6l3pkq9wy62s6ystuw2fwqepqqnyf879jy”,
“asset_id”: “7d6ab43142e0fd09848e3b368a8ee0ed2878958ad53659aec7857c38a21de787”,
“asset_type”: “NORMAL”,
“amount”: “50”,
“family_key”: null,
“script_key”: “0248a904e63bb6be7f40830fb1df1a9aa83948843c99c4c9b97b47f73f1ea32ec3”,
“internal_key”: “02b75cf6b38f34428afe65ce406d82cf302816bf10d8057134a868905f1ca4b819”,
“taproot_output_key”: “93212fb4971b28565463dd161122dcd27075eaa2677b32fc6f128472b404a9a1”
}What is the universe?
Since the information about the assets is stored outside the blockchain, there needs to be some mechanism like blockchain explorer to view and verify data independent of the asset issuer. Universes will allow users and asset issuers to provide proof of asset provenance, supply issuance and more easily interact with Taro asset data. And the universe is not ready and still under development. However, anyone can build a universe/crawler to expose information. Until then, for asset transfers, you will need to manually import/export proofs and use it to generate the address for the transfer. I assume several open-source projects are underway to create this universe and will make it easier for users to verify and transfer assets.
How to avoid double-spending?
The question in everyone’s mind is how this mechanism stops double-spending. Lightning Labs documentation goes into detail to explain this concept. But if you don’t want to break your head diving deeper, just remember that the state transition will fail when trying to create an address to double-spend. Merkle sum sparse merkle trees are used to store data. Merkle sum corresponds to the total asset minted value that cannot increase or decrease. Only the transfer is recorded by moving from one leaf to another.
Is it possible to create a decentralized finance app?
With LND and TARO, the technology components needed to build a decentralized finance app are now available on the bitcoin blockchain. Issuing centralized stable coins like USDT or USDC is more accessible and may come first, but we can see a new ecosystem emerging on top of TARO. This is one of the reasons lightning labs created the bare minimum foundation layer for creating assets and allowed app developers to build on top. We will need to develop specifications such as lightning addresses to make it easier for many wallets and apps to support minting and transferring assets.
Notable features
- Like a lightning invoice, the recipient needs to create a new address by inputting the asset genesis information and amount. It is recommended to create a new address for each transfer. This removes spamming worthless assets or losing assets by sending it to the wrong address.
- Grouping of assets using a family key. Minters can link different sets of the same asset under the same family key to achieve the properties necessary for interchangeability for the same assets minted in different tranches. This feature needs to be explored further for new use cases
- Although TARO requires LND daemon to run, it does not require lightning channels to send and receive assets. You can send and receive via on-chain directly and even batch up multiple sends and receive transactions to save cost.
- It has many similarities with LND like gRPC, Rest API, logs, certificates, and macaroons.
- Data is stored in SQLite database and can be easily queried
- “Burn” assets — This feature is still in development, but the approach is to use a new “empty” merkle tree that the taro asset is spent on, and then the sats in the outpoint can be spent back to your regular wallet
- Combining multiple Taro transactions into one bitcoin transaction is accomplished with the parameter chain_anchor
For folks like me who have explored numerous blockchains, worked with tokens/assets, yet returned to build on the bitcoin blockchain, TARO gives a beautiful chance for builders and entrepreneurs to address real-world problems without the cacophony of Web3.
I will continue to explore further and update this blog on a weekly basis.
Gracias,
Starbackr Builder
