- Defines a standardized way to package Taro asset proofs
- Flat File => plain text (.txt, .csv) or binary format
- Proof => contains data attesting to the taro assets in question
- Bitcoin merkle proof: https://en.bitcoinwiki.org/wiki/Merkle_tree
- Taro MS-SMT proof: https://docs.lightning.engineering/the-lightning-network/taro/taro-protocol#asset-proof
- Set of valid witnesses for the state transition: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#transaction-id
In crypto-lingo, a witness basically means a signature. It’s something that attests to the authenticity of something. For a Bitcoin transaction, the witness is the contents of the signature scripts, because that’s what proves the transaction is authenticated - Grokking Bitcoin, Ch 10
- Linear, append-only log containing lineage for a given asset
- Lineage is a list of state transitions allowing sender to simply append to the end of the file
- First line is the initial "genesis output" tx for a given asset
- Each line attests to a single Taro state transition
- A full state transition could be multiple lines if multiple actions are taken (i.e. sending multiple assets to multiple ppl)
- UTXO-based system roots each asset at an initial "genesis" transaction to mark taro asset creation
- Aka a taro asset is defined by its genesis output -- the start of its lineage
- Standard ensures that implementations across the ecosystem can verify assets provenance (lineage or origin)
- genesis outpoint showing the very first snapshot of the asset (i.e. its creation)
- valid merkle proof that proves inclusion of the genesis outpoint and resulting created asset
- each step/transition beyond genesis outpoint:
- valid merkle proof of a transaction spending outpoint
- valid MS-SMT opening proving the commitment of the new location of the asset
- valid asset witness state transition from the prior outpoint to the new location
- valid cannonical Taro asset commitment exists for the given asset
- If transaction has other outputs: include valid tapscript exclusion proof showing that the commitment is unique (i.e. not duplicated somewhere else in the tapscript tree on-chain)
- valid merkle proof of a transaction spending outpoint
- verification of a proof file starts at the first entry (the genesis output creation) and walks forward
- each line of a file is an inclusion and/or state transition proof
- file is verified incrementally, with verification halting if an invalid state transition or proof is encountered
- Given a proof file for a given asset ...
- Verify the integrity of the proof file
- Verify each inclusion proof and state transition
- https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki#proof-verification
- Defines a data structure used in the Taro protocol called a Universe
- To provide taro users/asset holders with a way to provide/obtain relevant data for fast, cheap asset verification
- Universe allows users to watch a set of on-chain outputs to be notified of further asset issuance/changes
- Scales taro transactions by allowing users the ability to delegate update rights to another party (single or federated set)
- e.g. user obtains asset from closed source game, user can delegrate update rights to game company to batch txs on-chain
- Analogous to a block explorer
- Publicly auditable MS-SMT over one or several assets
- Indexes the set of spent outpoints (on-chain) that track taro asset movement/transfer
- Can contain genesis outpoint set for one or several assets, track individual transactions, and be an aggregation layer
- Data structure gives users/asset holders an easy way to bootstrap:
- tracking provenance/origin of a taro asset and associating it with its genesis point
- tracking total issued units of a given taro asset
- Lowest tree key index is an outpoint rather than an asset script key (pubkey)
- Given an outpoint, the Universe maps from that to the Taro transaction + spending meta data (on-chain)
- Allows us to provably track the movement of assets from on-chain to off-chain
- Universe doesn't live within a solely controlled output (taro asset tree), may exist on its own as a distinct output
- bootstrap proof verification
- generate more compact proofs
- audit to the total amount of units in existence
- track new asset issuance for a given asset ID
- https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki#asset-universes
- Universes can be used to compress the history of a series of transfers into a single on-chain transaction
- Behavior can be seen as a "Taro asset channel"
- One party or many parties acting together (federation) batch update asset tree clearing N transfers in a single on-chain tx
- Party creating assets MAY also specify a
cannonical_universefield - Using this field necessitates that the second output of the next spend (after genesis) MUST commit to updated base Universe
- Updated Universe points back to genesis outpoint
- Must use the
asset_key_familyfield during asset creation, which is the internal key used for the output - The
cannonical_universefield should be updated with the new commit of the updated base Universe for each subsequent asset issuance event - The internal key specified in
asset_key_familyblesses a public key on-chain allowing it to be used to commit to the "canonical" history of an asset - Users wanting to be notified about new asset issuance can watch this output on-chain to track any modifications
- https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki#asset-universes
- "Primordial" defined as "existing at or from the beginning of time" (very clever!)
- Also called a base Universe
- Only commits to the "set of constituent assets present at the Beginning"
- i.e. only commits to the set of genesis outpoints for an asset
- All other transfers of this asset depend on this set of genesis outpoints
universeKeyused by anyone wanting to track any new asset issuance related to a Primordial Universe
clients are able to watch a select set of outputs on-chain, one for each
genesisAssetIDthey care about, effectively using the blockchain to be notified each time the total amount of issued assets changes. - Primordial Universes & Genesis Asset Verification
- "a Universe of Universes"
- a Universe w/ multiple assets
- Commits to several root
rootAssetIds, asset transfers proofs (including splits+merges) & set ofgenesisOutpoints - Essentially keeps a complete history from genesis to each subsequent transfer of multiple assets
- All leaves within a Multiverse are themselves a commitment to an event that happened on chain (A Taro asset transfer)
A Multiverse is therefore effectively a commitment to every asset transfer that may have ever happened. Importantly, one cannot prove that a Multiverse has complete history, as a Multiverse can only commit to what it directly observed, or was shown to it - Asset Multiverses
Pocket Universes are an off-chain transfer compression system that allows a consortium to stamp asset transfers that take place in an "imaginary" universe. - Pocket Universes: Off-Chain Taro Transfer Compression
- Normal asset proofs don't scale well due to their nature of divisibility
- e.g. a single asset held might actually be the merging of several Taro asset UTXOs
- Proof size for normal assets increases as the number of splits/merges in an asset's history increases
- Similar to a commit chain
- Single party or multiple parties commit to a set of transfers within the main chain
- These on-chain transfers are anchored to an initial verifiable
genesisOutpoint - A single new commitment on-chain can have a large # of transfers timestamped within the Pocket Universe commit chain
- https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki#pocket-universes-off-chain-taro-transfer-compression
Private Taro Code Repo: https://github.com/lightninglabs/taro