Only sign closable snapshots

[ch1bo]

What & Why

We want Hydra Heads to be secure. This means that we can close & fan out the L2 state at any point throughout the life-cycle of a Hydra Head.

There are however some situations which make the Head "unclosable", because our validator would fail. For example, if assets are minted in a Hydra Head, the UTxO set including the new assets would not be closable because the L1 would require the minting policy to mint the same tokens, but that might not even make validate anymore at the point of closing the Head. Another example is the current limitation on the maximum number of UTxOs supported (#190), or the fact that Byron addresses are not visible to Plutus scripts.

Hence, the goal of this is that our hydra-node is not signing any transaction/snapshot which cannot be fanned out.

As a consequence, if a user submits a transaction leading to such an unclosable UTxO, she will not se a SnapshotConfirmed message anymore. To notify clients about this more directly we want to have a server output when a snapshot was not signed because of an unclosable UTxO.

Requirements

• The hydra-node does not sign snapshots requests including transactions which are
  • is not valid on the L2 ledger (already the case right now)
  • the resulting UTxO would yield a fanoutTx that is invalid on the L1
• (optional) Transactions received via the NewTx client API are checked to be supported and a friendly warning is sent in case it makes the Head unclosable
• (optional) A server output is sent when a ReqSn was not signed because the head would be unclosable

Implementation ideas

• We could use the script evaluation like we do use in our tests/benchmarks to check phase 2 validation of a fanoutTx
  • The fanout validator is checking too much, we might need to distill out the relevant part of it -> ugly
• We could do check the UTxO size based on empirically determined limits

Tasks

• [ ] Check that any snapshot we sign can be fanned out

[abailly-iohk]

Other implementation idea: We could use a specially configured ledger, with specific rules preventing application of transactions leading to unclosable UTxO. This would have the nice property of encapsulating this filtering logic inside the Ledger interface, thus not requiring any change to the core logic or interfaces. This would have the additional benefit of providing some blueprint or forcing us to provide the capability to plug specific ledgers, something that users might need.

[abailly-iohk]

FWIW, one use-case for Hydra Head is micro-payments which could very easily lead to UTxO that cannot be committed back on-chain. How are we supposed to handle this problem if we implement this feature?

[ch1bo]

How are we supposed to handle this problem if we implement this feature?

I expect these UTxOs preventing snapshots to be signed until they are aggregated again. Maybe we could generalize #358 to also exclude these outputs from signing snapshots to have more confidence on unrelated outputs?

[abailly-iohk]

The more I think about it, the more I view this feature as problematic for quite a large number of use cases, to the point of making the Hydra Head protocol pretty much useless but for only a small subset of the usages we envisioned initially. If we don't sign snapshots that are not "fannoutable":

• We cannot post micro-payment transactions in the Head, where value is less than minimum on-chain value (1 ADA IIRC),
• We cannot mint tokens in the Head, a common pattern for DApps to maintain secure state.

More precisely, we can post one such transaction but it will never get confirmed, and because new transaction (received through NewTx or ReqTx) are checked against confirmed snapshot, and the latter will never change until we get a new snapshot, the transaction will be stuck forever. Of course, we could change the protocol to include a Seen snapshot so that users will be free to post more transactions, but then any kind of security guarantee is lost and Hydra users could as well send those transaction by email.

It seems to me we are facing a contradiction, which might or might not be a fundamental limitation of Hydra Head protocol, between broadening the use cases space and maintaining security properties of the protocol.

Given the Hydra Head nodes have to know each other in advance to form a head (they are supposed to communicate through pairwise authenticated channels as per Setup section of the paper), and there's no provision in the protocol or our implementation to protect against most malicious behaviours, Heads cannot be formed of arbitrary nodes, and thus require some form of trust between involved parties. For example, Head participants could "agree" to preserve liveness of the Head and define a mechanism to ensure snapshots can eventually be fanned out, for example by agreeing on some cleaning transaction at end of a period to remove "coin dust".

Rather than doing some filtering inside the Head, another option would be to modify the protocol to not limit the contestation period until FanOut is posted and finalised, eg. Head stays open until FanOut: Should a FanOut tx fail because it's invalid on L1, it's still possible to create a new snapshot, sign it, and "Contest" the latest one.

[ch1bo]

@abailly-iohk I think you are right and I shall think about this a bit more as well. One thing which struck my mind when reading your comment:

If we would be using MPTs, we could fan out the parts of the Head which are sound, even though the Head is closed.

However this would open up again "attacks" where a party says "yeah.. i'm not going to close the head while you have all your money in coin dust" .. and then they do it.

[abailly-iohk]

In any case, this seems a hot topic to discuss with research team.

[perturbing]

To add to this discussion, as @abailly-iohk mentioned, since participants know each other, there is more trust than on the layer 1. That said, if all parties commit the same amount to the head as collateral (e.g. bigger than the value that is transferred in the head), no party has the incentive to close a head that cannot fan out. This leverages the mutual assured destruction (MAD) principle.

Another additional idea, inspired by the kaleidoscope paper

Due to the fact that it is not reasonable to assume that the majority of the players are honest in a poker game, the secure poker protocol will not be able to guarantee fairness. Instead, we follow the approach of imposing a financial penalty on the party that interrupts the correct execution of the protocol, and use this money to compensate the honest parties

In that protocol, cards are shuffled using a n party public key to encrypt a deck of cards and re-randomize them. Each party holds a piece of the private key, and only together they can decrypt cards one by one. It feels like the same problem, if a party stops participating in the creation of a “valid” checkpoint, it is punished on the layer 1.