Yasuke/hydra-docs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
dabce6404b
hydra-docs/hydra-pay.org
Sky O dabce6404b Initial commit
2023-06-07 18:43:09 +00:00

3.0 KiB
Raw Blame History

Hydra Pay

What is the point of Hydra Pay

Manage Monitor Interact

with Hydra Heads

We want to hide Node setup and configuration We want to intercept the Node messages to know about status

Conceptually a head is a running blockchain We care about Status

  • Participants
  • Balances
  • State (Open | Closed | Contestation)

Proxy Addresses

We don't want users to have to give us their private keys to use Hydra Heads instead we match unique users up with a different address.

HydraPay.Server.hs:156 runHydraPay :: HydraPayConfig -> (State -> IO a) -> IO a

The main entry point into hydra pay currently this takes a configuration of mode (Managed or Unmanaged) which boils down to should hydra-pay run a devenet or should it connect to an existing cardano node.

data State HydraPay.Server.hs:98 data HydraPayConfig HydraPay.Config.hs:6

When hydra pay is running it provides a state this state gives us

  • The handle to the cardano node
  • The mapping of L1 addresses to their proxy addresses and hydra keys
  • The current heads
  • The subscribers to those heads
  • The Networks for each Head (Meaning the hydra-nodes that all belong to a head)
  • The keypath where all the private keys of the proxy addresses are stored.
  • getPorts and freePorts to allocate and deallocate ports for new hydra-nodes
  • apiKey the key in config/backend/api-key for authentication
  • config the bind address, port, and mode (Managed or Connect to existing node)

runHydraPay is a bracketted function that gives you the State which is needed to run 'Hydra-Pay' actions. Similar to runDb like in gargoyle-postgres.

The key interactions are going to be related to creation and management of heads the Hydra Pay websocket API can be found in handleClientMessage HydraPay.Server.hs:1072

For each message there is a function that will take the state and modify it, returning the result.

For example to create a Head, you would, from the websocket API, send a CreateHead message containing the participants, and a unique name. That once it reaches hydra-pay will call the createHead function:

HydraPay.Server.hs 606 createHead :: (MonadIO m, MonadLog (WithSeverity (Doc ann)) m) => State -> HeadCreate -> m (Either HydraPayError Head)

which takes the State, and the HeadCreate information (embedded in CreateHead) and will perform the requested changes, spinning up the network, and giving back either a Head or Error.

All of what hydra pay does can be tracked in this way, Find the action in client websocket ClientMsg type:

data ClientMsg HydraPay.Api.hs:127

then find where that message is handled in the handleClientMessage

handleClientMessage HydraPay.Server:1072

Then from there you can find the actual call made when that message is processed.

Currently we shell out to cardano-cli and our transaction building is highly simplified, we would likely want to change to cardano-transaction-builder like dango/nunet is using as it seems to work pretty well.

We are going to have to do a bunch of nix/dependecy bumping anyways to get hydra-pay on 8.10.7 at least. So this is necessary work regardless.