Architecture
This document describes the architecture of the current implementation
of a hydra-node
. The following diagram represents the main
components of a Hydra node using the C4 Component
Diagram notation.
This diagram is manually produced using the PlantUML graphing tool with C4 extensions.
$ plantuml -Tsvg architecture-c4.puml
Network
The network component is responsible for communication between Hydra nodes related to the off-chain part of the Hydra protocol. See Networking for details.
Chain interaction
Chain
The chain component interfaces the Hydra node with the Cardano (layer 1) chain. The current implementation, called Direct
, uses the node-to-client
protocol to both 'follow the chain' and observe new blocks and transactions that can change the state of the head. It also submits transactions in response to client requests or as needed to advance the protocol's state. This component connects to a locally spun cardano-node
using the local socket and contains the off-chain logic, based on cardano-api
, which knows how to observe and build transactions relevant to the Hydra protocol. For more details, see ADR-10.
Wallet
The Hydra node maintains an internal wallet using the Cardano signing key provided to the hydra-node
. This wallet is used to handle the payment of transaction fees and to sign transactions.
Head logic
This component is at the core of the Hydra node, implementing the protocol's state machine. It is structured around the concepts of Input
s and Effect
s. Input
s from the outside world are interpreted against the current state, potentially resulting in internal Event
s, which are aggregated into an updated state. This can then produce Effect
s, leading to 'side effects' on the outside world. The state available to the head logic consists of the head's content (eg, current ledger, pending transactions) and the data from layer 1 needed to observe and trigger on-chain transitions.
Hydra smart contracts
This component represents all the Hydra smart contracts needed for the Hydra Head protocol operation. Currently, the contracts are written using Plutus-Tx
. The scripts are optimized using a custom ScriptContext
and specific error codes.
API
The hydra-node
component exposes an asynchronous API through a WebSocket server. This API is available to the Hydra client for sending commands and observing changes in the state of the Hydra head. Upon startup, the API server loads all historical messages from the persistence layer and serves them to clients interested in observing them.
Persistence
All API server outputs and the hydra-node
state are preserved on disk. The persistence layer is responsible for loading historical messages and the Hydra state from disk, as well as storing them. Currently, there hasn't been a need to increase the complexity of this layer or use a database.
Logging
The Hydra node logs all internal side effects as JSON-formatted messages to its standard output stream. The log format adheres to a documented JSON schema, following the principles outlined in ADR-9.
Monitoring
The Hydra node optionally exposes Prometheus-compliant metrics through an HTTP server, on the standard /metrics
endpoint.