Taproot Assets: Protocol, Lightning Network Compatibility

08-07

This article is machine translated

Show original

Author: Lightning Labs
Source: https://docs.lightning.engineering/the-lightning-network/taproot-assets

"Taproot Assets" (formerly known as "Taro") is a new protocol, powered by Taproot, for issuing assets within the Bitcoin system that can be transferred within the Lightning Network, enabling timely, high-volume, low-fee transactions. At its core, Taproot Assets leverages the security and stability of the Bitcoin network with the speed, scalability, and low fees of the Lightning Network.

Taproot Assets relies on Bitcoin's recent upgrade, Taproot, which introduced a new tree structure that allows developers to embed arbitrary asset metadata within a Bitcoin transaction output. Taproot also uses Schnorr signatures to improve simplicity and scalability, and, importantly, it can also be combined with multi-hop transactions in the Lightning Network.

Throughout Bitcoin’s history, many proposals have been made to bring assets to the Bitcoin blockchain. Taproot Assets advances the ideas behind these proposals by leveraging the power of Taproot. In a Taproot-centric design, Taproot Assets can issue assets on both Bitcoin and the Lightning Network with greater privacy and scalability. Assets issued using the Taproot Assets protocol can be deposited into Lightning channels, allowing nodes to provide atomic swaps from Bitcoin to assets. This allows Taproot Assets to interoperate with the broader Lightning Network, benefiting from Lightning adoption and strengthening Lightning’s network effects.

Taproot Assets uses a "Sparse-Merkle Tree" structure to enable fast, efficient, and private retrieval and update of witness/transaction data; and a "Merkle-Sum Tree" to prove valid state transitions/no inflation. Assets can be transferred through on-chain transactions or through the Lightning Network after being deposited in a Lightning channel.

Participants in Taproot Assets transactions bear the cost of verification and storage (witness data for the relevant assets needs to be stored in local (off-chain) storage space), or, alternatively, an information repository called "Universes" can be used (similar to a git repository). To check the validity of an asset, it is necessary to verify the flow of the asset since the genesis output (state). This is achieved by receiving a verification file of the transaction data in the Taproot Assets gossip layer. Clients can cross-check their own copies of the blockchain and modify their own evidence when they need to transfer relevant assets.

Summarize:

Allows the issuance of assets on the Bitcoin blockchain
Leveraging taproot for privacy and scalability
Assets can be deposited into lightning channels
Assets can be transferred across the existing Lightning Network

Watch: Taproot Assets: A new protocol for multi-asset Bitcoin and Lightning

Features and limitations

Taproot Assets supports many features that make the protocol scalable, robust, and friendly to mobile devices with limited bandwidth and performance.

Taproot Assets are light-client friendly: verification is cheap and only requires access to trustless Bitcoin transactions. Taproot Assets do not require knowledge of the entire blockchain.
Taproot Assets allows atomic swaps of assets with Bitcoin.
Taproot Assets can issue unique assets, non-unique assets, and collectibles.
Taproot Assets allows for creative multi-signature and co-signature arrangements.
Taproot Assets channels can coexist with BTC channels in the same UTXO, which allows Taproot Assets to exist in the Lightning Network without consuming additional resources. For example, Alice and Bot can create two channels in a Bitcoin transaction, one for a certain asset and the other for BTC.
Features that may be introduced in the future include confidential transactions and zero-knowledge proofs as part of Taproot Assets transfers.

Taproot Assets Protocol

Taproot Assets is primarily an on-chain protocol where assets are issued on the Bitcoin blockchain using taproot transactions.

concept

To understand Taproot Assets, we need to be familiar with several concepts; some of which are relatively new, even in the context of the Bitcoin blockchain.

Read the BIP: Taproot Assets Protocol

Learn the basic concepts here:

Taproot Trading

Taproot is a new type of Bitcoin transaction defined by BIP 341 ; starting in November 2021, Taproot is fully activated on the Bitcoin blockchain. The main difference between a Taproot transaction and a traditional Bitcoin transaction is that the script that controls the funds is contained in a tree structure called a "tapScript branch", which is committed to privately. If the associated "key spend path" (script) is not used to move funds, its contents do not have to be exposed.

Traditional transactions require the disclosure of the entire script (regardless of which part of the script is used), while Taproot transactions can avoid exposing the script by exposing a public key (and its valid signature); if the key spending path is unavailable, only the executed script fragment needs to be revealed. All other unused script paths remain private, or can be selectively revealed off-chain.

This allows us to create more complex scripts without having to pay the extra cost of submitting extra data to the blockchain in key spending, and we can efficiently verify a pruned script fragment. In the context of Taproot Assets, this allows us to provably attach arbitrary data to a Bitcoin transaction without revealing that data on-chain.

Assume to a hash: Taptweak

We call such transactions that contain arbitrary data "commitments". Once such a transaction is included in a block, we have committed some data to it and can no longer change this data.

When committing data, we use an adjustment factor called "Taptweak" to distort the public key of our Taproot spending key. This allows us to selectively reveal the committed data without revealing our private key; or, we can spend the taproot output without revealing the commitment.

In Taproot transactions, this technique is used to commit to a script tree (multiple scripts organized in a tree structure); in fact, this can be used to commit to arbitrary data.

Q = P + H(P|c)G
Q is the final public key output by Taproot
P is the "internal public key" output by Taproot
H(P|c) is the hash of the internal public key and data commitment

When using our private key to sign the spending transaction of the Taproot output, this private key (the private key of the inner public key) also needs to be distorted with the hash of the public key and the data commitment (H(P|c)).

Read: Taproot is coming: What it is and how it could benefit Bitcoin

Watch: Bitcoin Optech Schnorr Taproot Workshop

Sparse Merkle Tree

A "sparse Merkle tree (SMT)" is a data structure that can be used to prove that a particular piece of data does not exist in a Merkle tree ("sparse" in this context means "sparsely"). An SMT is an authenticated key-value store, meaning that the key (or position) of a leaf in the tree is bound to its content.

To achieve this property, the contents of the leaves are hashed to create a Merkle tree, and the leaf positions correspond to a bitmap of their hash digests. This necessarily requires a 256-level tree, with 2^256 leaves. Generating such a tree is efficient, although it appears large, because most branches contain empty leaves, represented by nil hash values.

- Construct a sparse Merkle tree -

For example, we can create a sparse Merkle tree using a fictitious hash function sha002; the output of sha002 is a number between 0 and 3. Therefore, the sparse Merkle tree we create has 4 leaves: 0, 1, 2, and 3. Only leaf 2 has content, all other leaves are empty. To find leaf 2 (whose binary representation is "10"), we just need to choose the right branch (1) in the first step, and then choose the left branch (0) in the second step.

- Locating a leaf in a sparse Merkle tree -

To verify the contents of leaf 2, we only need to reveal the value in this leaf, the hash value of leaf 3, and the hash value of branch 0.

In a sparse Merkle tree, each leaf can be described as a guide that can be used to find itself through a map represented in binary form. This map is the sparse Merkle tree itself, and this guide can be represented as instructions on whether to turn left or right at each fork in the road. For example, in a 2^4 sparse Merkle tree, the 10th leaf can be represented in binary as 1001, which means that we only need to go right first, then left, then left again, and finally right to find the right leaf.

This property is extremely useful when constructing and reconstructing sparse Merkle trees, because it accurately describes which part of the sparse Merkle tree we want to reconstruct. More importantly, the data in each leaf can be described by the position of the leaf in the tree.

Using sparse Merkle trees, we can associate data with a public keyword and prove in an easily verifiable way that we have deleted this data without revealing the entire tree.

Because each piece of data has its own predetermined position, the root hash value of the tree is independent of the order in which the data are inserted into the tree.

Issued assets

Asset ID

When we issue a Taproot Asset, we first create an identifier for the asset. We create a 32-byte asset ID, which is hashed from three elements: the outpoint that will be spent to mint the asset, an asset tag chosen by the minter (e.g., a hash of its brand name), and metadata related to the asset, such as websites, images, and documents.

 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 Assets inputs, but transfers of assets do.

The output of the asset script defines to whom the newly created asset will be issued. More precisely, this is achieved through a sparse Merkle sum tree: in the tree, each account is identified by its 256-bit key, and the leaf corresponding to this key contains information about the amount owned by this account.

Multiple assets can be issued in a single Bitcoin transaction, but each asset has its own separate asset script and a sparse Merkle tree within it. Assets can be unique or non-unique.

Read BIP: Taproot Asset Script

Asset Leaf

Each leaf contains a TLV (type, length, value) data, similar to the TLV used in the Lightning Network. It contains some information (such as version, asset id, quantity), as well as data related to the previous transfer of this asset (such as signature).

Commitment to the roots

With the sparse merkle sum tree and asset script generated, we can distort our internal public key, get the address of this contract, and finalize the transaction.

Publish a transaction

By publishing this transaction and having it confirmed by the Bitcoin blockchain, we have irreversibly created an asset. To everyone else, this transaction looks no different than any other standard taproot transaction.

Proof of assets

Asset issuers can now selectively reveal what assets they have created and to whom they have been allocated. Most importantly, issuers can prove to recipients that an asset has been transferred to them by revealing a specific asset proof, including the asset’s script, and a path through a sparse Merkle sum tree with the recipient’s account as a key to the leaf.

- Prove that a state is not contained in the sparse Merkle tree -

Transferring assets

Taproot Assets can be transferred on-chain and can also be used to open Lightning Network channels. In this section, we only discuss transfers via on-chain transactions.

The Taproot Assets protocol does not specify how the holders of each asset account interact with each other. This is left to each application. Issuers have flexibility in defining the nature of assets or the intention of constraining assets.

The Asset Root Commitment commits all assets held in the tree and their sum. The asset id is globally unique because it depends on the identifier of its genesis output. The entire tree root can contain multiple asset ids, and the protection of funds is achieved by verifying the asset tree root (asset_tree_root).

 asset_tree_root = sha256(asset_id || left_hash || right_hash || sum_value)

Taproot Assets Address

Taproot Assets addresses are bech32m-encoded identifiers that encode the asset ID, the hash of the asset script, the internal public key of the sparse merkle sum tree, and the amount, prefixed with "Taproot Assets" or taptb1 (testnet).

 bech32(hrp=TapHrp, asset_id || asset_script_hash || internal_key || amt)

The issuer of an asset, or the holder of an asset, can use this information in the Taproot Assets address to create or modify the corresponding sparse Merkle sum tree (described below). This address format can also be used to request a specific proof that an address holds a certain amount.

Read BIP: Taproot Assets on-chain address

Transferring assets within a tree

To transfer Taproot Assets, the recipient sends their address to their transaction partner: the current holder of the asset who can initiate the transfer. The specific interaction between the asset holder and the issuer is not strictly defined yet. It can be left to the application or even the issuer of the asset to specify.

The sender of funds needs to create a new sparse Merkle sum tree reflecting the new balance. This is done by decreasing the balance of a particular leaf and increasing the balance of another leaf. The sparse Merkle sum tree guarantees that in such a transaction, no new assets are created (no inflation) and the sender's claim to the asset has been completely waived.

- Locate Account -

Creating an asset requires an on-chain taproot transaction, but there is no limit to how many assets can be minted or how many accounts can hold them. To transfer an asset, as described above, the Merkle tree needs to be reorganized and a new on-chain transaction issued. There is also no limit to how many internal Taproot Assets transactions a single on-chain transaction can reflect.

Using this approach, funds are distributed to account holders, represented as leaves on a sparse Merkle sum tree, but the ability to initiate such internal transfers is restricted to the owner of the taproot internal private key.

- Overview of various tree structures used in the Taproot Assets protocol -

Universe

"Universe" is a service that provides information about assets and proof of ownership of assets. It is like a block explorer for Bitcoin, but displays Taproot Assets transaction data, which itself is stored off-chain by the Taproot Assets protocol client. The main difference is that because the vast majority of information related to Taproot Assets is off-chain, it is easier to hide.

The universe can be run by the issuer of the asset itself, or it can be specified by the issuer. It is also convenient to run a universe that aggregates information submitted by asset holders.

For example, given an asset ID, Universe can provide information about its genesis output, as well as current meta information (such as documentation, asset scripts, and total number in circulation). The server can know about multiple assets (Multiverse) or just one output (Pocket Universe).

Universe has no privileges in the Taproot Assets protocol. It provides educational data that can be verified on the Bitcoin blockchain. A malicious Universe can only refuse to return data requested by the client. Taproot Assets transaction data is not tied to Universe. The data availability product provided by Universe is incentivized by users who want to quickly and cheaply verify their assets.

Read the BIP: Taproot Asset Universes

Merger and division of assets

Assets can be transferred internally on their own sparse Merkle tree (as described above), or they can be sent to another taproot key holder. This is called splitting of the asset.

In the case of asset splitting, the sender also needs to update the sparse Merkle sum tree of his taproot output: adjust the balance and recalculate the Merkle root. In the case of asset merging, the sum in the root will also change.

Additionally, this produces another sparse Merkle sum tree committed to a new taproot output. This Merkle tree is computed by the recipient of the asset in a similar way to the issuer in the example above, except that the asset is not created out of thin air, but is split from a previous output (such as the genesis output of the asset).

Proof of assets

To verify that the asset split has occurred, the operator of the new Universe requires the following evidence:

Assets are created in transaction t0
The asset exists in a leaf in the original Merkle tree at t0
The leaf's balance is set to 0 in transaction t1
The asset exists in a leaf of the new Merkle tree in t1

After the asset split is completed, the owner of the asset can perform internal transactions like the issuer. Before the split, the issuance certificate is always required for circulation verification.

The size of an asset proof grows linearly with the number of on-chain transactions used. Each asset transaction needs to be traced back to the genesis output for auditing. An asset proof is only valid if the on-chain output it references is a spend output.

Invalid assets

If the taproot output of an asset is spent, and the asset has not been committed to a new sparse Merkle sum tree, then it is considered to have become an invalid asset. This is not obvious to third-party observers, and in some situations, it may be better to commit the asset to a new, empty Merkle tree to prove that the asset has been destroyed, invalidated, or "burned".

Read BIP: Taproot Assets Flat File Proof Format

Taproot Assets enter the Lightning Network

The Taproot Assets protocol describes how to issue assets on the Bitcoin blockchain. These assets can be deposited into “ Lightning Network payment channels ” for instant transfer.

This principle allows users of the Lightning Network to hold assets other than BTC in their wallets: for example, stablecoins. They can receive payments denominated in stablecoins and use stablecoins to pay for goods and services through the Lightning Network.

Bitcoin is still the backbone of the Lightning Network, and payments for Taproot Assets can be routed through the existing Bitcoin Lightning Network without upgrading or switching. When Bitcoin provides liquidity for these payments denominated in other assets, operators of routing nodes can receive more routing fees paid in Satoshi.

Enable the Taproot Assets channel

The creation of Taproot Assets channels is similar to the creation of current Bitcoin channels. In these channels that can perceive Taproot Assets payments, HTLCs can be constructed to assist payments, just like transferring Bitcoin.

Assets are transferred by creating HTLCs nested in channel commitment transactions; when needed, the value in the HTLC can be claimed by the receiver by revealing a preimage , or retrieved by the sender after a timeout. These transactions are the Taproot Assets equivalent of Bitcoin transactions in Lightning channels.

Multi-hop Taproot Assets transfer

Historically, payment networks have struggled with the cold start problem — creating a new asset requires building a whole new payment network to service the payment needs of that asset. Taproot Assets supports a payment routing model that allows the Lightning Network to handle channels with any asset, while also having the ability to discover payment paths across different assets. Taproot Assets assets in a Lightning channel can be transferred across the broader Lightning Network. For example, in a scenario where all participants in the entire payment forwarding path have liquidity, they can choose to charge routing fees in Bitcoin or the Taproot Assets assets being transferred.

Even without such a fully supported path for Taproot Assets, the Bitcoin path can be used as long as the first node is willing to forward the value of the relevant Taproot Assets in Satoshis. This also allows the Lightning Network to facilitate the exchange of Bitcoin and Taproot Assets. This also allows the recipient of the payment to choose to use Taproot Assets (rather than Bitcoin) to receive the payment. In the example below, Bob and Carol can both act as such edge nodes and exchange the L-USD paid to BTC.

- An example of a Taproot Assets payment being made via the broader Lightning Network -

This also allows us to receive Taproot Assets but give the corresponding invoice to any other Lightning wallet - even if they don’t have the Taproot Assets protocol integrated - and they can pay the invoice with BTC.

This keeps Lightning Invoices as the standard solution. An invoice that is ultimately settled with Taproot Assets can be paid with BTC or any other asset; and anyone with a Taproot Assets balance can pay any Lightning Invoice.

- Example of a receiver choosing to receive a Taproot Assets payment in the same asset -

exchange rate

The Taproot Assets protocol itself provides integrated nodes with the choice of how to handle exchange rates. The two peers processing a swap in a channel autonomously determine the exchange rate. They may use a reference rate from a highly liquid exchange, or determine their own. Importantly, when receiving a payment, the invoice is generated by the recipient itself, which guarantees that it receives the appropriate amount of the desired asset.

Any Lightning Network node that can sense the Taproot Assets channel can serve as such an "Edge node". They compete with each other on forwarding and swapping fees. These fees include routing fees and swapping fees (also known as spreads).

When creating an invoice, the recipient (such as Zane in the example below) and his peer node (such as Yana) first agree on an exchange rate. They use this mutually agreed price to generate a regular Lightning Network invoice and give it to the payer; the invoice contains the forwarding instructions and the terms of the channel.

When the payee passes the payment through the payment path he constructed, the payment will arrive at Yana, and Yana will forward the L-EUR to Zane. Before releasing the preimage, Zane's wallet will check whether it has received the expected amount of L-EUR.

When paying an invoice denominated in Satoshis with L-USD, Alice must agree with Bob on the latest exchange rate and fees. She can confirm the payment and transfer the requested L-USD plus the fee to the other party, and the recipient will only release the original image when he receives the desired number of Satoshis.

- The sender and receiver do not need to use the same asset-

If edge nodes are concerned about their liquidity being abused, they can use other tools, such as closing a channel, reducing the validity of an invoice, or increasing the spread.

The Taproot Assets protocol will not regulate or set exchange rates, but will only provide the mechanisms required for useful markets, ensure low technical barriers to entry, and support automated, atomic, and instant forwarding.

Source

Disclaimer: The content above is only the author's opinion which does not represent any position of Followin, and is not intended as, and shall not be understood or construed as, investment advice from Followin.

Add to Favorites

Comments

Relevant content

Blockbeats

$55,000 will be the lifeline for Bitcoin.

BTC

0.66%

All-in station

The Vietnamese government is pushing for the operation of a gold and cryptocurrency exchange by February 28, 2026.

BlockTempo

Machi Big Brother lost so much money he couldn't sleep all night? Ethereum fell below 2000, causing panic. He long positions in ETH and HYPE, then sold at a loss, losing all 120,000 in magnesium.

ETH

1.76%