Head in Head

[ch1bo]

Why

When a Hydra head is opened, a part of the underlying ledger state gets locked up and made available off-chain to a small group of participants. While this is already quite a "small world" to process transactions, we encountered use cases where it would make sense to even open further heads with different/even smaller groups of participants on parts of the L2 state into L3 heads. Hydra doom is one of those use cases where fragmentation of ledger state is not a problem as the Head ledger is merely used to off-chain check transactions of game sessions.

There are still some liveness caveats about opening a Head in another head, but this would not be scope of this feature.

What

This is a follow-up to a previous spike #1590

• The hydra-node can be pointed to another hydra-node API endpoint instead of --node-socket of a directly connected cardano-node
  • Observe Hydra protocol transactions from SnapshotConfirmed server outputs of the underlying node
  • Evolve current slot of the L3 ledger state based on a new server output sent by the underlying node
  • Create and send Hydra protocol transactions to the underlying node, e.g. to initialize, close or fanout a head
• The hydra-tui can commit into such a head by using the hydra-node API of the underlying node.
• A head in a head can be opened in a similar sequence way like this: Spike: Hydra Head in Head #1590 (comment)

How

• Map out components/modules and how they should be reused/reorganised across chain backends (see also Blockfrost chain layer  #1305 ).
• Add a new Tick server output to inform clients of time evolution
  • This could be problematic through an ever growing server output history, see also Event Log Rotation and Memory Growth #1581
• SnapshotConfirmed contains full confirmed transactions, while TxValid only contains a txId API: Full transaction in SnapshotConfirmed #1685
• Create a hydra-client package that allows for
  • easy fetching of /protocol-parameters, /snapshot/utxo using Haskell types
  • open a websocket and with it: submit ClientInput messages, receive and subscribe to some ServerOutput messages
• Make script publishing independent of Hydra.Chain.Direct (see early commits of Spike / Not merge: Inception chain component #1603)
• Implement a new Hydra.Chain.Inception component that uses hydra-client
  • Make prepareTxToPost re-usable by generalizing concepts like ChainContext, ScriptRegistry and TimeHandle to work for both, Direct and Inception (cardano) chain backends
    • This could mean that we unify the concept of IsChainTx (or so) which is instantiated using hydra-tx tx construction for Cardano Tx
  • Re-organize Hydra.Options to be able to re-use --hydra-scripts-tx-id, --cardano-signing-key etc. between Direct and Inception chain backends

TBD

• We had a Tick server output at some point - what happened?
  • We should add this to the website (leads to more history growth) ; see Constant memory API server history using StateEvents #1618
• Is including full txs in SnapshotConfirmed fine? We moved away from it when we also did ReqSn only sends transaction ids #728
• Instead of submitting through the websocket NewTx, we could create a synchronous tx submission API.
  • This was also wished by @Quantumplation in hydra-doom
• What should happen with /POST/cardano-transactions endpoint on an inception node? (i.e. if it can't send a tx to L1 at all)
• What happens if the L2 hydra-node disconnects from L3 hydra-node; how should it catch up? Can it catch up? For any L3 Head closures on L2 Idea: Use the API history?