Instant Finality Hydra / L1 Snapshot - Checkpoints

[colll78]

Why

In a catastrophic situation where a participant is offline and does not come back in time to dispute a closing of the head, the participant can suffer great financial losses, and or a complete loss of his funds (ie. if the uncontested snapshot is an intermediate state that simply cannot be fanned-out ex. it has minted tokens or performed reward account related actions). This feature minimizes losses in such scenarios, because they are at-least guaranteed that the finalized state will be the last checkpoint or greater.

Also, this feature allows more flexibility, ie you can create Hydra deployments that have instant L1 settlement (no dispute period), if the participants are okay with subjecting themselves to very small rollbacks (in the case of a malicious participant). This is very desirable if you want to support quick lightweight hydra-deployments with strong interoperability.

What

Essentially, how it would work is that any participant can publish the snapshot to the L1 state at any time (provided that the signed timestamp of the snapshot is greater than the signed timestamp of the previous snapshot, enforced by the smart contract), and any participant can close-out the hydra head using that published L1 checkpoint snapshot without any need for a dispute period, in this case the finalized state is whatever the L1 checkpoint is.

How

So we add a field to the OpenDatum which we can call checkPoint.

-- | Sub-type for the open state-machine state.
data OpenDatum = OpenDatum
  { headId :: CurrencySymbol
  -- ^ Spec: cid
  , parties :: [Party]
  -- ^ Spec: kH
  , contestationPeriod :: ContestationPeriod
  -- ^ Spec: T
  , version :: SnapshotVersion
  -- ^ Spec: v
  , utxoHash :: Hash
  -- ^ Spec: η
  , checkpoint :: [Signature]
  -- -- ^ Multi-signature of most recent checkpoint snapshot 
  }
  deriving stock (Generic, Show)

And we add a redeemer that allows any participant to spend the head from the contract to the contract with no modification except the change of that field to a new more recent multi-signature. Then we add a new close redeemer that doesn't allow disputes (no contestation) and closes-out with that snapshot. Also this mechanism should be optional (you should be able to deploy a hydra-head that does not support no-contestation close-outs)

[colll78]

@ch1bo @v0d1ch @noonio @ffakenz @abailly

Any feedback? It seems from my perspective that this would be relatively simple to implement, and it would help prevent a lot of the liveliness issues and complexity for real world use-cases of hydra in its current state (which mostly seek to use hydra to manage data, not value), and where the tradeoff of accepting potential rollbacks in order to achieve instant L1 finality is valuable.

Also a separate suggestion (that complements this) would be to modify the signature scheme to use the new Halo2 ATMS scheme that was recently tested on mainnet.

[v0d1ch]

Sorry @colll78 somehow I missed this post. We'll take a look and get back to you when we get a chance, sounds interesting.

[ch1bo]

I like the general idea and purpose of this. I think it's very much related to #198 which is sketched in the original paper.

How would the participants of a head agree to such a checkpoint? Or can any snapshot be used as a check point?

If we do not have a contestation period, I'm not sure how this would be safe? Any participant could invalidate all the state channel progress by using any signed snapshot.

OTOH, this reminds me also of the incremental commit / decommit feature (even when nothing is committed / decommitted) where snapshots have versions and all participants need to agree on bumping the version. After bumping it, the head can only be closed with a snapshot of that latest or one version before. Hence, the snapshot with new version can be seen as a check point?

[colll78]

The participants agree to such a checkpoint by adding the signed snapshot of the agreed upon checkpoint to the datum of the Hydra head UTxO. The validator would enforce that the timestamp of the new checkpoint is greater than the existing checkpoint and that it indeed contains all required signatures.

The reason this is safe is because you are guaranteed that a participant can only "invalidate the state channel progress" by closing the head with the last agreed upon checkpoint (you cannot use any arbitrary signed snapshot). This means the true state of the state channel is the checkpoint that is currently provided on the Cardano L1 in the Hydra head UTxO. All progress that is not saved (ie. progress beyond the most recent checkpoint) is subject to rollbacks if a participant decides to close via checkpoint. The benefit here is clear, you get instant finality without any contestation period for fanouts even in a non-optimistic scenario and you get a very powerful failure recovery mechanism (ie. an operator goes offline).