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.