Skip to main content

Managed Hydra head

note

🛠️ This document is a work in progress.

This document outlines the managed Hydra head topology, which could also be described as Hydra as a service.

Managed Hydra Head

The basic Hydra head setup requires each participant to host an instance of a hydra-node, similar to how cardano-nodes operate on the Cardano network. In contrast, 'light node' setups allow users to access the blockchain through a hosted API, with light wallets being a common example.

In this topology, clients do not need to run their own hydra-nodes but instead access a hydra-node provided by a service provider. Client applications, such as light wallets, do not need to be aware of individual hydra-node instances. Instead, logical Hydra heads are accessible via an API.

The illustration above depicts three different Hydra heads: two pairwise (yellow and green) and one multi-party (blue). Clients A, B, and C access their heads using the service provider, while client D manages their own hosting. For this setup to be feasible, it is crucial that the Hydra keys remain on the client side and that the hydra-node serves purely as infrastructure — it does not take custody of the user's funds.

As a result, the client must be online for any progress to occur within a Hydra head. This requirement can be cumbersome in multi-party Hydra heads, as they may stall if a lightweight mobile client is offline for a period. However, this setup aligns well with two-party Hydra heads, where a transaction is only completed if both parties are online to send, receive, and acknowledge it.

An example use case for two-party Hydra heads includes payment channels between two machines or individuals, especially if such multiple channels are logically interconnected, similar to the Lightning Network.

Although access to Hydra heads is facilitated by the service provider, this does not centralize the system. A client can always close a head and recover funds with an alternative provider or even use a transaction created out-of-band (eg, by the client application using another service to submit the transaction).