Taro, a new protocol proposed by Lightning Labs, leverages Taproot and the Lightning Network to bring new assets and scalability to Bitcoin.
Lightning Labs has introduced a new protocol proposal for Bitcoin and the Lightning Network, Taro, which seeks to bring new use cases to the network. The company has published
A Merkle tree is useful because it can store lots of data, it makes it easy to prove that some data exists in the tree, and it also allows us to check that data hasn’t been tampered with. In other words, a regular Merkle tree enables scalability, proof of membership and tamper resistance.
Moreover, we only need to store the root hash of the Merkle tree on chain to verify such properties. That’s because if the data in one leaf is tampered with, for example, its hash would also change, further changing all of the hashes at levels above it which would lastly change the root hash — which can have its change attested through comparison to the stored version.
The Merkle-Sum tree takes this one step further by allowing us to commit to the sum of all leaf values, meaning its root hash can also include information about the sum of the values of each leaf in the tree. In the context of assets, this property enables an asset’s supply to be more easily audited, as well as allowing the divisibility of the asset and preventing undesired issuance of new assets in transactions that are only supposed to transfer them. In our fictitious Merkle tree above, if each leaf held a value of one, the root hash would hold a value of four.
The Sparse Merkle tree adds yet another property. All of its leaves are indexed, allowing access to information on the tree in a key-value pair fashion, and it has empty leaves, which actually hold the “null” value, allowing us to check if some data is not in the tree. This property, known as proof of non-membership, is possible by proving membership of null in a given leaf which can be accessed through its index. For example, if there is a claim that the leaf with index six stores some information about an asset, we can prove that such information is not there by attesting that that leaf actually holds a value “null.”
Transferring A Taro Asset
Taro represents assets with nested MS-SMTs, one for each asset ID or asset type. The protocol enables those trees to be layered on top of each other, branching out of the initial Taproot script tree to represent an effectively unlimited number of assets in a single Taproot UTXO. Taro assets are therefore issued on chain.
At the basis of asset functionality on Taro is an asset script, a set of directives established by a developer to programmatically define how a given asset can be transferred on the protocol. The hash of that script is then included in the MS-SMT so it can be easily enforced later on — thereby making the asset and its attributes commit to the asset script hash.
The initial version of Taro proposes the use of a subset of Bitcoin Script, allowing assets to express arbitrary conditions for the valid transfer of an asset. As asset scripts inherit a level of programmability on par with Bitcoin Script, Taro assets can be transferred over Lightning in multi-hop transactions off-chain through hash time locked contracts (HTLCs) embedded in the asset script. However, future versions could introduce new opcodes and extra functionality that would only exist at the Taro level.
“Doing Taproot-within-Taproot makes the initial version simpler and gives us more time to figure out what use cases pop up and desire more expressivity,” Osuntokun said.
For on-chain transfers, Taro leverages a new address format based on bech32 that also includes the asset script hash. To receive a Taro asset on chain, the receiver would need to create an address with enough data that details how the sender can construct a new asset script group that contains the information needed to spend the asset once it is transferred over to the new owner. In other words, the extra information, in the asset script hash, tells the receiver what the unlocking capability is for the asset that is being transferred, so that it can eventually be transferred again.
Since the receiver has all of that information, they can compute the asset leaf, which then lets them compute the asset root, and finally the entire output itself, letting them watch the Bitcoin blockchain for the result they computed.
Additionally, by having the receiver send that defining information beforehand, the only way the sender can make the transaction valid is if they send exactly what the receiver is expecting. If the wrong asset or the wrong amount is sent, the hashes won’t match and the receiver can easily tell that the sender did something wrong.
Assets And Collectibles On Bitcoin
The issuance and transfer of assets in Taro vary, depending on whether the asset is a regular one or a collectible.
A collectible, or non-fungible asset, is a one-of-a-kind representation of value, with a unique identifier that establishes a claim on an asset at the Bitcoin chain level or at the real-world level and makes it impossible to counterfeit ownership. A collectible on Taro could be a tokenized rare baseball card, for example. Collectibles are created in a single batch transaction, cannot be split or merged, and need to be transferred off-chain or put into a multiparty channel to be transferred among a known set of participants.
A regular asset, on the other hand, commits to a total value of held assets and can be split and merged. Splits can happen within a tree, configuring an internal split, or across different Taproot outputs, configuring an external split. During transfer, the asset holder proves they hold a valid split with a Merkle-Sum proof and the corresponding created assets commit to a new Merkle-Sum output split that ensures the total amount of assets after transfer equals the total amount there was before the transaction.
Assets At The Edges: Lightning As A Decentralized Backbone Payment Network
As mentioned earlier, Taro can port assets issued on-chain onto the Lightning Network, similar to how bitcoin can be sent through Lightning after being locked up in a two-of-two multisignature output that gets confirmed on the Bitcoin blockchain. A Lightning channel holding Taro assets leverages the same flow, however the two-of-two Schnorr Taproot output would also commit to the set of assets in the channel.
“Using the Taro protocol, Lightning channels anchored with a Taproot output are able to send both bitcoin and Taro assets off-chain, with multi-hop payments being facilitated by new HTLCs on the Taro level, which use the scripting system to implement the expected end-to-end payment security guarantees,” Osuntokun told Bitcoin Magazine.
Osuntokun added that Lightning Labs’ proposed deployment path for Taro on the Lightning Network seeks to first only introduce assets at the edges, meaning it would avoid both having to modify the core of the network and bootstrap a new network with adequate liquidity for each Taro asset. Rather, the company’s plans would have Taro plug into bitcoin liquidity on Lightning and require only the sender and receiver of a given asset to use Taro-aware channels.
“The only constraint is that in order to receive/send using a particular asset, corresponding inbound/outbound liquidity is required,” Osuntokun said.
In addition to the similar Lightning on-ramp setup, multi-hop transfers of Taro assets over Lightning would leverage a similar invoicing system that is commonplace on the second layer today. However, instead of denominating the invoice in BTC, the invoice would be denominated in the Taro asset itself.
“As an example, if Alice wants to send Bob a Taro stablecoin asset, she’ll create a new invoice that quotes, say, $10,” Osuntokun said. “Bob will then use a ‘hop hint,’ which are extra routing details provided in the invoice to complete the route and calculate the amount of network fees (paid in bitcoin) to send over his first hop, which will traverse the internal Bitcoin backbone and eventually drop off enough BTC at the final hop to complete the payment.”
The Taro protocol will specify the extra information that needs to be sent to the Lightning peers at the edges in order to update all channels properly, he added.
Making Bitcoin The De-Facto Base Layer
Taro seeks to leverage Bitcoin’s latest soft fork upgrade to bring assets with real-word use cases like U.S. dollar stablecoins onto the peer-to-peer (P2P) digital currency stack. It enables the issuance of a nearly unlimited number of assets with a single Taproot UTXO, as well as the transfer of such assets with instant, low-fee multi-hop transactions on Lightning.
By leveraging Bitcoin and Lightning as its rails, Taro could establish an interoperable ecosystem of assets that can unite different use cases while not affecting parties that may not care about such assets. At the same time, the protocol also contributes back to Bitcoin by increasing its network effects in the event that a popularization of the concept drives traffic on the network, thereby increasing the fee payout to miners and ramping up BTC liquidity on the Lightning Network.
Though its initial iteration accommodates a limited number of use cases, in an attempt to make the jump onto the new protocol easier for developers through a familiar Bitcoin scripting suite, the possibilities of extensions and further developments are nearly endless, as builders and entrepreneurs get creative and spin the protocol to suit their needs.
“The hope is to open up people’s eyes to what the future of Bitcoin holds and what Taproot can enable,” Stark told Bitcoin Magazine. “The goal is to have Bitcoin be the underlying global monetary network powered by open protocols.”