Ability to read protocol parameters via API

[matiwinnetou]

We need to be able to read protocol parameters via websocket interface from hydra node.

[pgrange]

Hello @matiwinnetou, thank you for using Hydra and reporting this issue.

That would help us a lot if you may explain why you need this (e.g. problem, challenge, pain, benefit) in your current situation.

And if you also have any idea of what the API endpoint or message format should look like to solve your issue do not hesitate to share that with us too.

[matiwinnetou]

Protocol parameters are used to evaluate cost of transaction in java layer. Keep in mind that in java and other runtimes we do not have access to ExUnits via Haskell library, we typically do this via protocol parameters.

Aiken for instance allows to return ExUnits based on protocol parameters and we are using this via binding library: https://github.com/bloxbean/aiken-java-binding

For L1 this works like a charm and we need the same process for Hydra.

[matiwinnetou]

From my point of view some http endpoint to read Protocol Parameters would suffice, or alternatively it can be added to the existing web socket based protocol but separate endpoint would probably be better since websocket interface is async and there is no reason this method should be async.

[pgrange]

Thank you @matiwinnetou.

As a workaround, for now, I would suggest that you just get the protocol parameters from the hydra-node configuration if you're also operating your node. This is how it looks like on the master branch right now: protocol-parameters.json

Next, given the current state of the API, we can certainly consider adding a new request in the same shape of GetUTxO but like GetProtolParameters and that would return the same json object as the one in protocol-parameters.json.

[pgrange]

@matiwinnetou let me know if the above API would work for you

[uhbif19]

Could you also provide era history and system start? They seem to be needed for auto balancing transactions.

May be Hydra could just re-export Cardano querying Api used by your queryUTxO-like utilities? I guess it may be already implemented by ledger code you use.

https://input-output-hk.github.io/cardano-node/cardano-api/lib/Cardano-Api-Query.html

[pgrange]

Hello @uhbif19 and thank you for using Hydra.

There is usually no fees in a hydra head. So you don't need to use the auto-balance mechanism which takes care of the complexity of computing fees depending on all these protocol parameters.

Take a look at Hydraw transaction construction for layer2, for instance. You can see that we use makeTransactionBody to build the transaction instead of makeTransactionBodyAutoBalance because we have much more control on the transaction and its context than what we usually have on layer 1.

Does that help?

[uhbif19]

There is usually no fees in a hydra head.

There still are script fees, no? Your protocol params are not zeroing script fee.

And even if they are zero, should not ExecutionUnits in Script Witnesses be calculated correctly either way?

Also auto-balancing may be required when somebody will do not-trivial ADA transfers on Hydra, to count UTxO change.

[matiwinnetou]

After talking more about this we agreed that ecosystem libraries including ourselves would much prefer REST endpoint.

Rationale: currently many libraries use blockfrost to deliver protocol parameters from the node so they are made to easily plug into such an interface.

[uhbif19]

@matiwinnetou So like this REST will be same as one in Blockfrost API? If that is not specified that could lead to client errors if that API would diverge.

[matiwinnetou]

IMHO it doesn't have to be the same API as blockfrost (at least for u s this is irrevelant) but good that it would be some http interface (ideally REST) but honestly even plain http is fine. It is reading remotely json... could be even file server...

Interesting detail is that since other params can be changed, it is not only about ProtocolParams it is also about e.g. minFeeA and minFeeB which are part of shelley genesis. All these params play a role in transaction cost and serialisation.

[uhbif19]

So regular Hydra clients should use two connections? Regular for WS, and transient for this HTTP request.

[v0d1ch]

Could you also provide era history and system start? They seem to be needed for auto balancing transactions.

May be Hydra could just re-export Cardano querying Api used by your queryUTxO-like utilities? I guess it may be already implemented by ledger code you use.

https://input-output-hk.github.io/cardano-node/cardano-api/lib/Cardano-Api-Query.html

@uhbif19 we have a small PR here to address protocol parameters. Do you still have the need to have era history and system start too? If so we could work on this pretty soon.

[uhbif19]

@v0d1ch We use them for auto-balancing and slot timing. Right now AFAIU slots on L2 are same as L1, so using L1 values should be safe, I believe.