Blockfrost chain layer

[v0d1ch]

Why

We think it would be useful to be able to run the hydra-node without the full cardano-node in a more light weight mode and it could provide more insights by dogfooding our product. The feature is also intersting to the BlockFrost people as a first step towards using Hydra for pay-per-use api changes they plan to implement.

What

• [ ] #1668

• Hydra node can be started with --blockfrost PROJECT_ID (providing an API key as project id) instead of --node-socket (et al)

• Both options, Blockfrost and Direct, should be available in the same hydra-node release

• There is documentation on how to run hydra-node using Blockfrost including the related trust assumptions

• If the API key is invalid (or expires), the hydra-node terminates with a meaningful message

• The same end-to-end tests we have right now (testing against a cardano-node), we also want to have tested with --blockfrost (against public testnets)

• This means, the blockfrost chain layer needs to be able to

  • Follow the chain
  • Submit Hydra transactions
  • Provide relevant hydra-node internal wallet queries

• Hydra internal wallet uses DirectChain component to get the information about the available UTxO at the wallet address and query the EpochInfo (in order to estimate the transaction fees). We should be able to get this information from blockfrost also https://blockfrost.dev/api/latest-epoch

How

First step:

• [ ] Map out components/modules and how they should be reused/reorganised across chain backends (see also https://github.com/cardano-scaling/hydra/issues/1612 ).

Next steps: https://github.com/cardano-scaling/hydra/pull/1631

• [x] Hydra chain observer run with --blockfrost ... (not available to hydra-node yet, just hydra-chain-observer)
• [x] Build a variant of hydra-explorer to the blockfrost-enabled hydra-chain-observer (noting that we might need a different way of discovering existing heads, because we can't look at all history; need to go looking explicitly?)

Later:

• [ ] Create and submit transactions
• [ ] Integrate with hydra-node
• [ ] End to end tests would run against a public blockfrost api (not local devnet)

Notes:

• Transaction submission uses https://blockfrost.dev/api/submit-a-transaction endpoint with transaction cbor (and projectId).
• Means of subscribing/listening to interesting transactions
  • In order to replace/have alternative to direct chain layer we need to investigate if the blockfrost api provides a way to detect incoming blocks/transactions in order for hydra-node to follow the chain (perhaps getting the block information and then querying the next block from there https://blockfrost.dev/api/latest-block). Alternatively we could listen to addresses we care about (eg. vHead script address) and be able to observe incoming interesting transactions this way.
• Note that there is existing client and api library in Haskell that should make our jobs easier https://hackage.haskell.org/package/blockfrost-client https://hackage.haskell.org/package/blockfrost-api

Open questions

• How exactly would the architecture change?
• What happens on a chain fork? Are there rollbacks?
• Is there a --start-chain-from when we use --blockfrost?
• Can we re-use tests between the direct and blockfrost way of running the hydra-node?

[ch1bo]

Contributed to the blockfrost-sdk in course of this: https://github.com/blockfrost/blockfrost-haskell/pull/63

[ffakenz]

Minor fix to above contribution: https://github.com/blockfrost/blockfrost-haskell/pull/65

[ch1bo]

This is not done yet. We only did the hydra-chain-observer in #1631