78 lines
3.0 KiB
Org Mode
78 lines
3.0 KiB
Org Mode
|
#+title: 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.
|