Why

The Hydra explorer should be able to report Hydra heads from multiple different protocol versions on all public networks. The explorer can be used to give usage information about each version.

What

• The hydra-explorer lists heads from all networks and supported versions according to networks.json

• The hydra-explorer does not need to be updated on every script change (e.g. when we switch plutus-tx/GHC versions)

• The hydra-explorer reports a protocol version per head.

• Can run multiple "(chain) observers", one for each network and hydra protocol version, feeding information into one hydra-explorer instance.

  • The hydra-explorer is decoupled from a specific hydra version
  • The interface between observers and explorer is specified and tests will ensure we don't break it accidentally

• The hydra-explorer should be deployed from https://github.com/cardano-scaling/hydra-explorer using multiple versions of the main hydra repository

  • We need to do this because, say, the script hashes are not enough to distinguish the version; i.e. we can't make hydra-node/src/Hydra/Chain/Direct/Tx.hs generic across versions; the easiest way is just to depend on the entire codebase 🥲

• We should delete the hydra-explorer folder from the main hydra repo

How

• The endpoint is a POST to /v1/observations/<network>/<version> with request body of some JSON object enumerating the observations

• Add an observer-side API definition to hydra-explorer OpenAPI schema

• The interface should be JSON-based simpler HTTP requests; so that it's easy reason about backwards compatibility and debug, and test

• hydra-chain-observers are HTTP clients sending requests to hydra-explorer observer-side API whenever a head transition is observed

• Observer-side API is exposed on separate port so we can host and port configurable on the command-line of hydra-explorer

• Both hydra-chain-observer and hydra-explorer are tested agains the observer-side API schema

TBD

• Is specifying an interface + testing against enough to keep this maintainable?
• Make the explorer understand any "old versions" of observer data?
  • Eventually drop too old observer versions
  • For how long should be support older versions? Will we have some separate notion of LTS versions for Hydra?
  • Might be older versions that we don't support but keep an eye on
• Can this support protocol changes like
  • additional transitions (incremental commit)
  • not having a commit phase anymore
• Protocol version is basically:
  • scripts, their hashes and addresses
  • datums and redeemers as contained in transactions (their format)
  • structure of protocol transactions