universe - [feature]: finish implementation of on chain universe commitments

[Roasbeef]

Is your feature request related to a problem? Please describe.

Today we don't have a commitment maintained by an issuer on chain that can be used to authenticate new issuance, as outlined in the BIP.

Describe the solution you'd like

Revamp and review the section of the BIP listed above.

In addition, we want to expand the scope of the chain commitment to include 3 commitemtns:

• issued
• burned
• ignore

Issued is the root of the normal issuance universe tree we maintain today.

Burned is a new root that stores any relevant burning transaction as state transition proofs.

Ignore is another new root for outputs that should be ignored, meaning if an asset being verified has the specified asset outpoint/scriptkey in it's history, then it should be ignored.

Some very early interface definitions and structs can be found here which should prove to be useful:

taproot-assets/universe/interface.go

Lines 661 to 696 in 420f246

	// Commitment is an on chain universe commitment. This includes the merkle
	// proof for a transaction which anchors the target universe root.
	type Commitment struct {
	// BlockHeight is the height of the block that the commitment is
	// contained within.
	BlockHeight uint32
	// BlockHeader is the block header that commits to the transaction.
	BlockHeader wire.BlockHeader
	// MerkleProof is a merkle proof for the above transaction that the
	// anchor output was included.
	MerkleProof *proof.TxMerkleProof
	// UniverseRoot is the full Universe root for this commitment.
	UniverseRoot mssmt.Node
	}
	// CommittedIssuanceProof couples together a Bitcoin level merkle proof
	// commitment with an issuance proof. This allows remote callers to verify that
	// their responses re actually committed to within the chain.
	type CommittedIssuanceProof struct {
	// ChainProof is the on chain proof that shows the Universe root has
	// been stamped in the chain.
	ChainProof *Commitment
	// TaprootAssetProof is a proof of new asset issuance.
	TaprootAssetProof *Proof
	}
	// ChainCommitter is used to commit a Universe backend in the chain.
	type ChainCommitter interface {
	// CommitUniverse takes a Universe and returns a new commitment to that
	// Universe in the main chain.
	CommitUniverse(universe BaseBackend) (*Commitment, error)
	}

.

In particular, we'll need to decide on the finer details of the "canonical issuance" scheme, which as proposed, would reuse the asset_group_key as an on-chain taproot public key, in order to tie the off-chain asset group key to an on-chain UTXO.

With this, the total amount outstanding is: issued - burned - ignore.

Additional context

Such a feature can be used to authenticate any supply level information, useful for transparency pages involving bridges.

[dstadulis]

@ffranr this is the issue related to replicating "gettxoutsetinfo" type behavior in tapd

[jharveyb]

Writing back offline discussion:

The design as outlined in the BIP linked above has an issue with a circular dependency. Tl;dr:

• The proofs for any issuance event can only be created once the anchor TX for the issuance is confirmed.
• The canonical universe commitment should have the proofs for issuance events as leaves in an MS-SMT.
• Therefore, any commitment that includes an issuance event as a leaf must be anchored after the issuance event.
• This also means that the commitment update must happen in a TX separate from the issuance itself.

This presents a new question of how to link issuance events to the chain of canonical universe commitments.

One pattern mentioned in the BIP that could be preserved is using the tweaked_group_key as the internal key for the canonical universe commitments. In that case, updating the canonical commitment requires access to the same keys that were used to create the asset group and authorize re-issuance (which is desirable).

In that case, I'm not sure if we need to have an on-chain link between issuance events and the canonical commitment chain at all. One argument in favor of that link is that you could easily discover all the relevant keys for leaves in the issuance section of the canonical commitment.

I'm also not sure what constraints we actually need to apply to issuance events that would be related to a canonical commitment.

E.x. should minting batches only contain the single grouped asset (re)issuance to be compatible with the canonical commitments? What if we want to reissue assets for multiple groups in one batch? Or batch in ungrouped assets?

Here are some sketches of ways to link the anchor TX for an issuance to a canonical commitment TX chain:

This shows 4 TXs, with TX 1 in the top left, TX 2 in the top right, and TX 3 in the bottom left. TX 1 is an initial issuance event, TX 2 is a TX anchored in a later block that includes the first canonical commitment root, and TX 3 is what a possible second canonical commitment would be.

The transition rule being shown is to mint, and then begin the canonical commitment in a TX that also re-anchors the minted asset. This proves that the commitment maintainer is also the asset issuer by spending the anchor output for the batch. Future commitment updates would also re-anchor future issuances.

The second pattern is shown by TX 1 and the TX in the bottom right, TX 4. Here, instead of re-anchoring the minted assets, we create the issuance anchoring TX with a bitcoin-only change output where the internal key is the tweaked_group_key. This change output can be spent when starting the canonical commitment chain, and prove control of the tweaked_group_key.

[ffranr]

I think that in general here we need to keep a PSBT flow in mind.

I lean toward the 'bottom right TX 4' approach for spending, using the asset group key. This method effectively ties the group key's ownership to minting events, which I find compelling. However, it seems to me that the universe commitment transaction will also require support for a cold wallet PSBT signing process.

[Roasbeef]

The design as outlined in the BIP linked above has an issue with a circular dependency. Tl;dr:

This makes sense, that draft is from before the proof format was at concrete as it is now.

One pattern mentioned in the BIP that could be preserved is using the tweaked_group_key as the internal key for the canonical universe commitments. In that case, updating the canonical commitment requires access to the same keys that were used to create the asset group and authorize re-issuance (which is desirable).

Yep, the other idea I was playing around with was to have a NUMs key, but then replicate the leaves from the group key with the leaves of this output public key. This would allow for any threshold or multi-sig scripts to exist on the Bitcoin level as well. We can also opt to reuse the raw group key and also replicate all the leaves. In the context of the old design, it wouldn't be the same top level tweaked group key, as it would also contain the new unified universe commitment.

[Roasbeef]

In that case, I'm not sure if we need to have an on-chain link between issuance events and the canonical commitment chain at all. One argument in favor of that link is that you could easily discover all the relevant keys for leaves in the issuance section of the canonical commitment.

The original design goal here was that: light clients (or anyone really) can watch a special on-chain UTXO and know that when that was spent, a minting transaction also occurred. I think we can still retain that (first input of minting txn is always the prior UTXO), but we still need to wrangle with the circular dep interaction.

[Roasbeef]

I think you're correct that in order to handle this circular dep, we actually need at least two transactions. One to mint the assets (can replicate the group key on the Bitcoin level to ensure identical script satisfiability), and another to update the on-chain unified commitment.

So to summarize you propose two patterns to resolve this:

1. Mint, then re-anchor with the updated commitment.
   • First you mint, from that special output (spending the last output used for the commitment).
   • Then you spend the newly created transactions commit to the new unified commitment in a change output.
2. Mint as normal, but create a change output re-using the group key.
   • After the minting transaction confirms, you spend a change output in that transaction in a transaction that also spends the prior unified commitment (?).
     • So then the commitment chain is a transaction change that spends a change output from every minting transaction.