Written by: Jinse Finance 0xjs
On October 19, 2023, Lightning Network developer Lightning Labs announced the launch of the Taproot Assets protocol. The Taproot Assets protocol supports the issuance of assets on Bitcoin and the Lightning Network.
What is the Taproot Assets protocol? How does the Taproot Assets protocol issue and transfer assets? This article will guide you through it all.
Taproot Assets Protocol
According to the Taproot Assets Protocol BIP, the Taproot Assets protocol is a Taproot-native asset layer built on Bitcoin. Taproot assets can represent arbitrary assets on the Bitcoin chain without causing the Bitcoin network to bloat. The protocol is designed so that transactions interacting with Taproot assets are no different than regular Bitcoin transactions.
Taproot assets use a nested asset script tree (which is a merkle-sum Sparse Merkle Tree or MS-SMT). It extends the base Taproot script tree, which submits valid witnesses as structured metadata that can prove the movement of assets in the transaction graph. The proof of Taproot asset transfer can be verified using a hermetic proof or using an externally maintained universe . Universe is an MS-SMT for asset issuance + transfer on the index chain.
Taproot Assets supports off-chain single-hop and multi-hop transmission via Lightning Network channels (based on the BOLT protocol suite), the latter of which is embodied using Taproot Assets’ unique embedded asset scripting system. Light client verification of on-chain Taproot asset transfers is facilitated by a series of on-chain and off-chain Merkle proofs, which can be compressed by delegating trust relationships to active Universe instances.
Several concepts needed to understand the Taproot Assets protocol
Taproot deal
Taproot is a new transaction type defined in BIP 341, which will be online on the Bitcoin mainnet starting in November 2021. The main difference between Taproot transactions and traditional Bitcoin transactions is that the control script is contained in a tree structure called a "tapScript branch", which is a private commitment to participate in the transaction. If you use the KeySpend path to move Bitcoin, you don't need to reveal these scripts.
While traditional transactions require the entire script to be exposed, Taproot transactions can use keys to avoid disclosing the script and only expose the executed portion of the script on the blockchain if the key spending path is not feasible. All other script paths can remain private or optionally be exposed off-chain.
This makes it possible to create more complex scripts without the added cost of submitting additional data to the blockchain in the keySpend path, as well as efficient validation of pruned script data. In the context of Taproot Assets, it allows people to provably attach arbitrary data to transactions without leaking this data on-chain.
Taptweak: Commitment Hash
Transactions containing such arbitrary data are called commitments. Once a transaction is included in a block, we have committed to that data and can no longer change or modify it.
In order to commit data, people use a trick called "Taptweak" to adjust the public key of the Taproot spending key. It allows people to selectively expose data without revealing private keys, or spend outputs without revealing commitments.
This technique is used in Taproot transactions to commit to the Taproot script tree, and can be used to commit any arbitrary data.
Q= P+H(P|c)G
Q = final Taproot public key; P = internal public key; H(P|c) = internal public key and committed hash
To sign a transaction using our private key, the private key needs to be adjusted with the same hash H(P|c) as the public key and commitment.
Sparse Merkle Tree
Sparse Merkle Tree is a data structure that can prove that specific data does not exist in the Merkle tree. SMT is an authenticated key-value store, which means that the key or location of the leaf and the content of the leaf are tied to each other.
To implement this property, the contents of the leaves are hashed and a Merkle tree is created, where the positions of the leaves correspond to a bitmap of the hash digest. This would necessarily require a tree with 256 layers and 2^256 leaves. Tree generation is efficient - despite being significantly large in size - because the vast majority of branches contain empty leaves and can be represented with zero hashes.
Construct a Sparse Merkle Tree
For example, we can use the fictitious hash function sha002 to construct a Sparse Merkle Tree whose result is a number between 0 and 3. We generate a Sparse Merkle Tree with 4 leaves: 0, 1, 2 and 3. Only leaf 2 is filled, all other leaves are empty. To find leaf 2 (written as 10 in binary), we move right at the first branch (1) and then left at the second branch (0).
Identifying leaves in Sparse Merkle Tree
To verify leaf 2, we now only need to reveal the value of that leaf, plus the hash of leaf 3 and the hash of branch 0.
In a Sparse Merkle Tree, when represented in binary form, each leaf can be described by a map as a guide to itself. The map is the Sparse Merkle Tree itself, and the directions are represented by instructions on whether to turn left or right at each fork in the road. For example, the 9th leaf in a large 2^4 Sparke Merkle tree is represented in binary as 1001, which means we find the appropriate leaf by turning left, right, right, and finally left.
This property is very useful for constructing and reconstructing a Sparse Merkle Tree because it describes exactly which parts of the Sparse Merkle Tree we have to reconstruct. What's more, the data in each leaf can now be described by its position in the tree.
Using a Sparse Merkle Tree, we can associate data with a public key and prove in an easily verifiable way that we have deleted the data without revealing the entire tree.
Insert an item into Sparse Merkle Tree
Since each item has its predetermined position, the root hash of the tree does not depend on the order in which the items were inserted.
Merkle sum trees
A Merkle sum tree is a type of Merkle tree in which each leaf contains a numerical value and each node also contains the sum of the values below it. Merkle finds the root of the sum tree to be the sum of the total values in the tree.
Merkle Sum trees can effectively verify conservation (non-inflation) by committing quantities associated with leaves.
Large combination of Taproot, tapweak, Sparse Merkle tree and Merkle sum tree
Taproot Assets uses a combination of the above concepts to issue Bitcoin-native assets. Sparse Merkle trees and Merkle sum trees are combined into Sparse Merkle sum trees .
The root of the Sparse Merkle sum tree is added to the Taproot Tapscript and together creates the Taproot address.
Taproot Assets issuers do not have their own blockchain, but instead store Sparse Merkle sum trees off-chain and issue proofs to asset holders. Owners of such assets can independently verify that their accounts are included in the tree, filled with the appropriate amounts and that the corresponding Taproot transactions exist and are confirmed on the Bitcoin blockchain.
How to issue Taproot assets
Asset ID
To publish Taproot Assets, its identifier must first be created. The asset ID is 32 bytes in size and is generated by hashing three elements: the outpoint used to mint the asset, an asset tag chosen by the minter (e.g. a hash of the brand name), and Meta information associated with the asset, such as a link, image, or document.
asset_id = sha256(genesis_outpoint || asset_tag || asset_meta)
asset script
Asset scripts can have inputs and outputs, similar to Bitcoin transactions. Newly created assets do not contain any Taproot asset inputs, while asset transfers do.
The output of the asset script defines to whom the newly created asset will be issued. More precisely, this is done via a Sparse Merkle sum tree, where each account is identified by a 256-bit key, and each leaf corresponding to that key contains information about the amount held by that account.
Multiple assets can be issued in one transaction, but each asset has its own asset script and contains a Sparse Merkle tree within it. Assets can be unique or non-unique.
asset leaf
Each leaf contains a TLV (type, length, value) blob, similar to the TLVs used in the Lightning Network. It contains information such as version, asset ID, amount, and data related to previous transfers of the asset (such as signatures).
Commit to tree root
Once we have generated the Sparse Merkle sum tree and asset script, we can adjust our internal public key and obtain the contract’s address and complete the transaction.
post transaction
Once we publish this transaction and it is confirmed on the Bitcoin blockchain, we have irreversibly created the asset. To an observer, the transaction will look like any other standard Taproot transaction.
Proof of assets
Asset issuers can now selectively disclose which assets were created and to whom they were allocated. Most importantly, issuers can prove to recipients that assets have been transferred to them by revealing a specific proof of asset, which contains the asset script and the path to a Sparse Merkle sum tree keyed by the recipient's account.
Recipients can verify the partial Sparse Merkle sum tree to recreate the script, adjust the issuer’s public key and verify that the genesis transaction exists on the blockchain, while the partial Merkle tree provides them with a guarantee on the assets issued to them, and the total number of assets issued.
Check whether the proof is included in the Sparse Merkle tree
How to transfer Taproot assets
Taproot assets can be transferred on-chain and can also be used to open Lightning Network channels . This article only discusses on-chain transactions.
Taproot Assets does not dictate how individual account holders interact specifically, but it can be application-specific. Issuers have flexibility in defining their assets or how they intend to limit those assets.
Asset Root Commitment All assets held within the commitment tree and their sum. The asset_id is globally unique because it depends on the identifier output by its creation. The total root can contain multiple asset_ids, the preservation of which is provided by verifying the asset_tree_root.
asset_tree_root = sha256(asset_id || left_hash || right_hash || sum_value)
Taproot asset address
The Taproot asset address is a bech32m encoded identifier of the asset ID, the asset script hash, the internal key of the Sparse Merkle sum tree, and the amount, prefixed by the Taproot asset or taptb1 (testnet).
bech32(hrp=TapHrp, asset_id || asset_script_hash || internal_key || amt)
Issuers or asset holders can use the information in Taproot asset addresses to create or modify Sparse Merkle sum trees. This address format can also be used to request specific proof of the amount held at this address.
Move assets within the tree
To transfer Taproot assets, the recipient communicates its address to the current holder, who can initiate the transfer. Currently, the exact interaction between account holder and issuer is not strictly defined. It can be specified by each application or even the asset issuer.
The sender of funds needs to generate a new Sparse Merkle sum tree reflecting the new balance. This is done by decreasing the balance of some leaves and increasing the balance of others. The Sparse Merkle sum tree guarantees that no new assets will be created in such transactions and previous claims on the assets will be completely waived.
Identify account
Creating an asset requires an on-chain Taproot transaction, where there is no limit on how many assets can be minted or how many accounts can hold them. As mentioned above, to transfer assets, the Merkle tree needs to be reorganized and a new on-chain transaction issued. There is no limit to how many internal Taproot Assets transactions can be reflected in this on-chain transaction.
Using this method, funds are distributed to account holders, represented by leaves in the Sparse Merkle sum tree, but the ability to make such internal transfers is limited to the owner of the internal Taproot private key.
Universe
Universe is a service that provides asset holders with asset information and certificates . It is similar to the Bitcoin block explorer and displays Taproot Assets transaction data, which is stored off-chain with the Taproot Assets client. The main difference is that since most information related to Taproot Assets is off-chain, it is easier to hide.
Universes can be run by the asset issuer themselves or specified by the issuer. It is also conceivable that the community-operated Uniserve will aggregate information submitted by asset holders.
For example, given a known asset ID, a universe can provide information about its genesis output, as well as current meta-information such as documentation, asset scripts, or total tokens in circulation. Services may also be aware of multiple assets (Multiverse) or only a single output (Pocket Universe).
Universe does not have any privileges in the Taproot Asset Agreement. It generates transaction data that is verified against the Bitcoin blockchain. A hostile universe can only avoid returning data requested by the client. Taproot Assets transaction data is not bound to the universe. The data availability products offered by Universe are driven by entities that want fast and cheap verification of their Taproot assets.
Merger or division of Taproot assets
As mentioned above, assets can be transferred within the asset's Sparse Merkle tree, or they can be sent to another Taproot key holder. This is called asset division.
In asset splitting, the sender first needs to update the Sparse Merkle sum tree output by its own Taproot, adjust the balance and recalculate the Merkle root. In case of merging, the root sum also changes.
Additionally, there will be a second Sparse Merkle sum tree dedicated to the new Taproot output. The second Merkle tree is calculated by the receiver of the asset, which behaves similarly to the issuer in the above example, except that these assets are not created from scratch, but are separated from the previous output, such as the asset's Genesis output.
Proof of assets
In order to be able to verify whether the asset split has occurred, the operator of the new universe needs to prove
The asset was created at transaction zero (t0)
The asset exists on the leaf of the original Merkle tree at t0
The balance of this leaf is set to zero at t1
The asset exists on the leaf of the new Merkle tree at t1
Once an asset is divided, the owner of the asset can conduct internal transactions just like the issuer. Each certificate prior to splitting always needs to include proof of issuance for provenance verification.
Proof of Assets grows linearly with each new on-chain transaction. Every asset transaction needs to be audited back to its genesis output. Proof of Asset is only valid if the output it refers to has not been spent on the blockchain.
Destruction or invalidation of Taproot assets
Once an asset's output is spent without being committed to a new Sparse Merkle sum tree, the asset is considered invalid.
This is not obvious to a third party observer, and in some cases it is better to spend the output to a new empty Merkle tree to prove that the asset has been destroyed, invalidated, or "burned".
