Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to read protocol parameters via API #735

Closed
matiwinnetou opened this issue Feb 21, 2023 · 14 comments · Fixed by #989
Closed

Ability to read protocol parameters via API #735

matiwinnetou opened this issue Feb 21, 2023 · 14 comments · Fixed by #989
Labels
green 💚 Low complexity or well understood feature 💬 feature A feature on our roadmap
Milestone

Comments

@matiwinnetou
Copy link
Contributor

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

@matiwinnetou matiwinnetou added the 💭 idea An idea or feature request label Feb 21, 2023
@pgrange
Copy link
Contributor

pgrange commented Mar 1, 2023

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor

pgrange commented Mar 9, 2023

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 pgrange self-assigned this Mar 9, 2023
@pgrange
Copy link
Contributor

pgrange commented Mar 9, 2023

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

@pgrange pgrange added the good first issue Highlight opportunities for people to contribute to the project label Mar 15, 2023
@uhbif19
Copy link
Contributor

uhbif19 commented Mar 27, 2023

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
Copy link
Contributor

pgrange commented Mar 28, 2023

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
Copy link
Contributor

uhbif19 commented Mar 28, 2023

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 matiwinnetou changed the title Ability to read protocol parameters via websocket Ability to read protocol parameters via REST May 10, 2023
@matiwinnetou
Copy link
Contributor Author

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
Copy link
Contributor

uhbif19 commented May 10, 2023

@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
Copy link
Contributor Author

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
Copy link
Contributor

uhbif19 commented May 11, 2023

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

@v0d1ch
Copy link
Contributor

v0d1ch commented Jul 24, 2023

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.

@ch1bo ch1bo changed the title Ability to read protocol parameters via REST Ability to read protocol parameters via API Jul 24, 2023
@ch1bo ch1bo added this to the 0.12.0 milestone Jul 24, 2023
@uhbif19
Copy link
Contributor

uhbif19 commented Jul 25, 2023

@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.

@ch1bo ch1bo added 💬 feature A feature on our roadmap green 💚 Low complexity or well understood feature and removed 💭 idea An idea or feature request good first issue Highlight opportunities for people to contribute to the project labels Jul 25, 2023
@ch1bo ch1bo unassigned v0d1ch Aug 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
green 💚 Low complexity or well understood feature 💬 feature A feature on our roadmap
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants