Skip to content

Instantly share code, notes, and snippets.

@bnonni
Last active September 13, 2022 21:56
Show Gist options
  • Save bnonni/f4e29adade243abcaf891970659d1375 to your computer and use it in GitHub Desktop.
Save bnonni/f4e29adade243abcaf891970659d1375 to your computer and use it in GitHub Desktop.

image

What does this BIP do?

  • Defines a standardized way to package Taro asset proofs

What is a Flat File Proof?

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

What are the attributes of the standard?

  • 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)

Why do we need a flat file proof standard?

  • 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)

What data is required in the proof file?

  • genesis outpoint showing the very first snapshot of the asset (i.e. its creation) image
  • valid merkle proof that proves inclusion of the genesis outpoint and resulting created asset image
  • each step/transition beyond genesis outpoint:
    • valid merkle proof of a transaction spending outpoint image
    • valid MS-SMT opening proving the commitment of the new location of the asset image
    • valid asset witness state transition from the prior outpoint to the new location image
    • valid cannonical Taro asset commitment exists for the given asset image
    • 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) image

What does a single inclusion and state transition proof look like?

How is the data in the file verified?

  • 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 ...
    1. Verify the integrity of the proof file
    2. Verify each inclusion proof and state transition
  • https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki#proof-verification

image

What does this BIP do?

  • Defines a data structure used in the Taro protocol called a Universe

Why do we need 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

What is a Universe?

  • 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 image

How is it different from normal MS-SMTs?

  • Lowest tree key index is an outpoint rather than an asset script key (pubkey) image
  • 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

How is a Universe used?

Any special properties?

  • 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_universe field
  • 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_family field during asset creation, which is the internal key used for the output
  • The cannonical_universe field 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_family blesses 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

What is a Primordial Universe?

  • "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
  • universeKey used 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 genesisAssetID they care about, effectively using the blockchain to be notified each time the total amount of issued assets changes. - Primordial Universes & Genesis Asset Verification

What is a Multiverse?

  • "a Universe of Universes"
  • a Universe w/ multiple assets
  • Commits to several root rootAssetIds, asset transfers proofs (including splits+merges) & set of genesisOutpoints
  • Essentially keeps a complete history from genesis to each subsequent transfer of multiple assets image
  • 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

What is a Pocket Universe?

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment