Head in Head

[ch1bo]

trafficstars

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: https://github.com/cardano-scaling/hydra/issues/1590#issuecomment-2334402926

How

• [ ] Map out components/modules and how they should be reused/reorganised across chain backends (see also https://github.com/cardano-scaling/hydra/issues/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 #1581
• [ ] SnapshotConfirmed contains full confirmed transactions, while TxValid only contains a txId #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 #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 #1618
• [ ] Is including full txs in SnapshotConfirmed fine? We moved away from it when we also did #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?