Exclude phantom tokens from snapshots

[ch1bo]

What & Why

This idea is based on a discussion between @KtorZ and @Quantumplation on what they called "phantom tokens": Generically minting assets in a Hydra Head would render it likely unclosable because the fanout transaction does not satisfy the minting policy on L1 as it was satisfied on the L2. However, not all minted tokens are always intended to be used outside of a Hydra Head, so it might be useful to exclude some tokens from the signed L2 state (snapshots) - hence they are phantoms and will not exist on L1.

TBD

• Currently this is only an idea right now and requires further discussion.
• how does the hydra-node know which tokens are phantom tokens
• how are phantom tokens observable by clients if they're not part of snapshots
• what are the security implications of not signing the full UTxO?
• Can we use u0 to know what tokens had been minted in the L2 instead of some bookkeeping?
• Concerns of "stripping state off contracts", so the UTxO with the minted tokens should not be separable because of security concerns?

[ch1bo]

Related to #370

[ch1bo]

@Quantumplation what is your opinion in how to (avoid) configuring this? Also, you might have an opinion on:

how are phantom tokens observable by clients if they're not part of snapshots

[Quantumplation]

@Quantumplation what is your opinion in how to (avoid) configuring this? Also, you might have an opinion on:

how are phantom tokens observable by clients if they're not part of snapshots

Seems like this and time granularity settings form the basis for a need of a parameters file specific to the hydra head; like a "hydra-genesis" settings file?

As for the snapshots, they could still be a part of the snapshots so long as it was understood that they were part of an ephemeral state that was tolerated on fan-out;

For example, they could be included in the snapshot, but just understood by the layer 1 tx to be ignored when comparing values of the utxos.

[ch1bo]

As for the snapshots, they could still be a part of the snapshots so long as it was understood that they were part of an ephemeral state that was tolerated on fan-out;

I read this as: A snapshot contains

• the definite, signed (confirmed) UTxO set without phantom tokens, and
• an ephemeral (seen) UTxO set with phantom tokens.

[Quantumplation]

As for the snapshots, they could still be a part of the snapshots so long as it was understood that they were part of an ephemeral state that was tolerated on fan-out;

I read this as: A snapshot contains

• the definite, signed (confirmed) UTxO set without phantom tokens, and
• an ephemeral (seen) UTxO set with phantom tokens.

We'll, sort of; a given UTXO may contain ephemeral state and nonephemeral state.

It's also feasible that you'd want similar things for smart contract addresses to recover/remap state; so long as all parties agreed on that remapping at the start / explicitly as part of a snapshot, it should be safe. for example, the SundaeSwap smart contract addresses are unique to a specific instantiation of the protocol, and you may want the liquidity from the pool contract to get deposited into the layer one version of the contract on head closure.

Arguably it becomes a matter of how much customization you want to allow before just telling protocols to build their own hydra-like instead.

[ch1bo]

Comment from researchers: Not bringing back state thread tokens is a security risk to the contract running in the L2, as it will be stripped off any guarantees on contract continuity when bringing it back to L1.

[Quantumplation]

@ch1bo correct; that's why it would be opt-in per-head and agreed-upon by all participants, rather than universal.

Often you don't want contract contuinuity. It's worth noting that head participants can implement this themselves by just arbitrarily signing whatever final state they want anyway. This is just providing a user interface over that, rather than forcing protocols to implement it themselves.

[matiwinnetou]

+1

[ch1bo]

@Quantumplation @GeorgeFlerovsky might want to continue your discussion from https://github.com/cardano-scaling/wg-hydra/blob/main/meetings/2024-07-17.md here.

[GeorgeFlerovsky]

@Quantumplation @GeorgeFlerovsky might want to continue your discussion from https://github.com/cardano-scaling/wg-hydra/blob/main/meetings/2024-07-17.md here.

At the Hydra WG meeting, I raised the concern of data loss when a Hydra Head abruptly closes (loss of consensus/connection) before parties are finished processing the phantom state to something that they'd like to be settleable on L1.

@Quantumplation raised the point that the L2 parties could choose to restore the full L2 state (including phantom state) on a new Hydra Head instance — theoretically, they have the information to do so if they haven't deleted their ledgers from the previous head. However, I think that this would require them to identify phantom state in the L2 snapshots that they sign, as otherwise they might not agree on the phantom state that they decide to recover in the new Head instance.

Thinking about this further after the meeting, I came up with a new approach to the more general "L1 closeability" problem (#370): https://github.com/cardano-scaling/hydra/issues/370#issuecomment-2233736093

TLDR; we can fan-out an aggregate "continuation" tx that can be committed into the new head instance by the parties to recover the phantom state in the new L2 ledger. This removes the risk of data loss from abrupt head closure and gives the L2 parties the opportunity to process more phantom information into L1-valid information.

[ch1bo]

Marking this issue as "not planned" as we in fact aim to solve the original purpose of this

minting assets in a Hydra Head would render it likely unclosable because the fanout transaction does not satisfy the minting policy on L1 as it was satisfied on the L2

By making the part of the L2 state that is intended for the L1 partially fanout as described in #1468.

The 💭 idea of "continuing" or "resuming" a closed Hydra head into a new instance is interesting and we should consider that in a separate item!

[GeorgeFlerovsky]

As discussed at today's Hydra working group meeting, the partial fanout mechanism in #1468 does not fully resolve the phantom tokens issue described here.

It is fairly straightforward to identify L2 utxos that cannot be resolved on L1 based on their local properties and prevent them from being fanned out while allowing other utxos to be fanned out.

However, it is unclear how to identify L2 utxos that cannot be resolved on L1 based on their relation to the global ledger state and transaction history on L2, unless we add further bookkeeping/restrictions to the L2 ledger and/or further capabilities to the L1 Hydra contracts.

Example

Consider an L2 utxo that contains non-ADA tokens and exists in a Hydra head that allows non-ADA tokens to be deposited from L1 and minted/burned on L2. The resolvability of this utxo on L1 cannot be determined solely by looking at its contents; we need more information about these tokens, how the utxo came to hold them, and whether other utxos have competing claims.

For example, suppose that:

• Four Y-tokens were deposited into the Hydra head from L1.
• Three Y-tokens were minted on L2.
• Two Y-tokens were burned on L2.

The resulting L2 utxo set from the above events contains five Y-tokens in total, but we have no idea how to distribute them if we only look at this utxo set. Relevant questions:

• Which of the five Y-tokens correspond to the original four deposited Y-tokens? Perhaps it is uncontroversial that these Y-tokens should be resolvable on L1, given their unbroken provenance from deposits.
• Which of the two burned Y-tokens correspond to the original four deposited Y-tokens? Should these tokens remain forever locked in the L1 Hydra contract because no L2 utxo claims them?
• Which of the five Y-tokens corresponds to the three minted Y-tokens? Should all of these tokens be automatically unresolvable on L1, or can we justify resolving some of them on L1 if some of the deposited Y-tokens were burned (i.e., infer some kind of transfer)?

Options

To deal with this problem, we need some combination of the following techniques:

1. Control which asset classes can be deposited from L1. Options:

   a. Restrict all non-ADA asset classes from being deposited from L1. b. Allow only an explicit list of asset classes to be deposited from L1.

2. Control which asset classes can be minted/burned on L2 and accommodate their minting/burning on L1. Options:

   a. Restrict all asset classes from being minted/burned on L2. b. Allow only an explicit list of asset classes to be minted/burned on L2. The minting policy of every member of this list must provide the Hydra head instance with delegated authority to mint/burn tokens as needed.

3. Keep track of tokens minted/burned on L2, separately from assets deposited from L1. Options to modify the L2 ledger:

   a. Prefix every minting policy ID with a network ID to indicate whether the token originates from L1 or L2. b. Add an additional l2_value field to every utxo. Use the original value field for L1 tokens and the new l2_value field for L2 tokens. c. Add a mapping from each utxo ref to the (possibly empty) value of L2 tokens held by that utxo.

(Edited) Hydra's current approach is just (2a).: https://github.com/cardano-scaling/hydra/issues/358#issuecomment-2417632417

Another basic approach is just (1a) -- if non-ADA tokens cannot be deposited and the L1 Hydra contract cannot mint/burn tokens, then all non-ADA tokens on L2 are unresolvable on L1 per se, so we don't need to track them differently.

However, I think other combinations will probably be more useful for users and dApps.

Also, I think that this problem is universal to all L2s that want isomorphic L2 ledgers, so it's potentially relevant to the L2 interoperability initiative.

[GeorgeFlerovsky]

@colll78 @noonio @Quantumplation Anything to add?

[Quantumplation]

Hydra's current approach is just (2a).

I don't think this is true; I believe we've successfully minted tokens in the hydra head before, so unless this has changed recently, I think the current hydra head is just not dealing with the problem, signing un-resolvable snapshots, and then assuming that the head operators will resolve whatever issues they create by the time the head is closed.

[GeorgeFlerovsky]

Hydra's current approach is just (2a).

I don't think this is true; I believe we've successfully minted tokens in the hydra head before, so unless this has changed recently, I think the current hydra head is just not dealing with the problem, signing un-resolvable snapshots, and then assuming that the head operators will resolve whatever issues they create by the time the head is closed.

Oh. I thought @v0d1ch said in today's meeting that Hydra does prevent L2 minting/burning...

[v0d1ch]

We prevent any minting when you commit to a Head using blueprint tx. In case you have some minting policy available inside L2 already then you can mint freely but fanout becomes the issue.

[v0d1ch]

@GeorgeFlerovsky curious to see if you already tried some experiments with token minting? I wanted also to write a small test and see for myself what happens if:

• You have a minting policy on L1
• You commit it to a Head
• Mint a token on L2
• Close and fanout and see what happens? I think this could work with some interventions on the fanout tx related to minting

[GeorgeFlerovsky]

@v0d1ch No, I haven't yet. This is still mostly theoretical for me in Hydrozoa