Hydra explorer supporting multiple hydra versions
ch1bo opened this issue · 0 comments
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 tonetworks.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 onehydra-explorer
instance.- The
hydra-explorer
is decoupled from a specifichydra
version - The interface between observers and explorer is specified and tests will ensure we don't break it accidentally
- The
-
The
hydra-explorer
should be deployed from https://github.com/cardano-scaling/hydra-explorer using multiple versions of the mainhydra
repository -
We should delete the
hydra-explorer
folder from the mainhydra
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 tohydra-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
andhydra-explorer
are tested agains theobserver-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