Hydra compatibility

[szg251]

Required work to make this happen

1. tx-indexer:
   • Investigate and implement an alternative source for the tx-indexer
     • a) Hydra node as Oura source
     • b) using the Hydra websocket API directly as event source of tx-indexer
2. tx-bakery:
   • ChainQuery alternative source investigation and implementation:
     • a) using the Hydra websocket API directly as a ChainQuery client in tx-bakery
     • b) implement Ogmios compatibility with Hydra (likely the former will suffice)
   • Implement an alternative way to calculate transaction execution budget (Haskell LedgerSimulator or Rust (pallas) based tx-bakery solution)
3. Hydra based testing: an environment to run the same testsuites we used in Plutip

[KtorZ]

Some thoughts:

Ogmios compatibility with Hydra will be challenging but doable. My fear is to turn Ogmios into something a bit too frankenstein-ish as many parts will have to be conditionally disabled. Ogmios actually runs all 4 mini-protocols clients behind the scene and keep long-lasting connections to the node. That is necessary in many cases to smooth the user experience down the line and provide features that aren't available from the mini protocols out-of-the-box (like transaction evaluation).

Looking at the ChainQuery API in tx-bakery; I believe it should be possible to emulate each required call directly with the Hydra node API, without the need for Ogmios. I don't know if you use Ogmios for other matters than implementing the 'ChainQuery' ?

• get_network: seems trivial to add as an API endpoint to Hydra, although this seems like it ought to be a configuration setting instead of being queried?

• query_system_start / query_era_summaries: I believe these are necessary for the slotting arithmetic. These are mostly system globals which depend on the network. There's no "era" on Hydra (or more specifically, there's only a single era); so both are pretty static. It also sounds trivial to add an endpoint to the Hydra node to serve those through the API.

• query_protocol_params: https://hydra.family/head-protocol/api-reference#operation-subscribe-/protocol-parameters

• query_tip: can be tracked internally in some mutable memory variable, by subscribing to the SnapshotConfirmed from the Hydra node.

• query_utxos_by_addr / query_utxos_by_ref: I haven't looked in detail but, I would expect those ones to be available via the tx-indexer already? (or else, what's the role of that indexer 😅...?). If anything, those queries can actually be implemented using kupo ( https://github.com/CardanoSolutions/kupo ) which can already be configured to synchronize data from hydra.

[szg251]

I agree with you 100%, we don't need a modified Ogmios, we could have a ChainQuery trait implementation for a HydraNodeClient directly. We also have a Submitter trait, which have the following methods on it:

pub trait Submitter {
    fn evaluate_transaction(
        &self,
        tx_builder: &csl::tx_builder::TransactionBuilder,
        plutus_scripts: &Vec<csl::plutus::PlutusScript>,
        redeemers: &Vec<csl::plutus::Redeemer>,
    ) -> impl Future<
        Output = Result<
            BTreeMap<(csl::plutus::RedeemerTag, csl::utils::BigNum), csl::plutus::ExUnits>,
            SubmitterError,
        >,
    >;

    /// Submit a fully build and balanced tranasaction
    fn submit_transaction(
        &self,
        tx: &csl::Transaction,
    ) -> impl Future<Output = Result<TransactionHash, SubmitterError>>;

    /// Wait for transaction confirmation on the chain
    fn await_tx_confirm(
        &self,
        tx_hash: &TransactionHash,
    ) -> impl Future<Output = Result<(), SubmitterError>>;
}

I remember we discussed the evaluate_transaction part, we could perhaps handle this with pallas, but we also have a way to inject the ex units externally (from Haskell for example).

submit_transaction should be straightforward I think.

await_tx_confirm is instantaneous on Hydra, am I right?

[szg251]

On the ChainQuery methods:

get_network, query_system_start andquery_era_summaries can configurations as you just said, no need to implement an API handler for that.

query_utxos_... we treat indexing slightly differently than usual. The indexer is not general, we're only storing data that are interesting for the domain. This means that we need another source to fetch UTxOs, such as fee inputs from a user, uniqueness input for uniquely minted tokens, etc. Would this be possible to implement on the hydra node API?

[KtorZ]

await_tx_confirm is instantaneous on Hydra, am I right?

Within few milliseconds. So instantaneous for us humans, but still taking some time for a computer 😶.

The indexer is not general, we're only storing data that are interesting for the domain. This means that we need another source to fetch UTxOs, such as fee inputs from a user, uniqueness input for uniquely minted tokens, etc.

Feels a lot like what kupo provides, unless I am missing something?

Would this be possible to implement on the hydra node API?

Yes! Kupo does it 😄! ( https://github.com/CardanoSolutions/kupo/blob/master/src/Kupo/App/ChainSync/Hydra.hs )

[szg251]

Feels a lot like what kupo provides, unless I am missing something?

Okay, I wanted to avoid pulling in another component, maybe we'll need to implement a general UTxO storage in our indexer.