hydra
hydra copied to clipboard
input-output-hk
Exclude phantom tokens from snapshots
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?
@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 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.
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)
UTxOset without phantom tokens, and - an ephemeral (seen)
UTxOset with phantom tokens.
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)
UTxOset without phantom tokens, and- an ephemeral (seen)
UTxOset 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.