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

Deprecate cardano-api's ProtocolParameters #384

Open
smelc opened this issue Nov 23, 2023 · 12 comments
Open

Deprecate cardano-api's ProtocolParameters #384

smelc opened this issue Nov 23, 2023 · 12 comments
Assignees
Labels
enhancement New feature or request Technical debt

Comments

@smelc
Copy link
Contributor

smelc commented Nov 23, 2023

From @Jimbo4350 here on Slack (context: IntersectMBO/cardano-cli#455 caused IntersectMBO/cardano-cli#472 and IntersectMBO/cardano-cli#474):

A potential way forward would be to:
• Define JSON instances for cardano-api's LedgerProtocolParameters that are identical to what we have for ProtocolParameters.
• We should be able to begin the deprecation of cardano-api's ProtocolParameters .
• Talk to QA about relying fully on the ledger's PParams JSON instances for Conway on wards.

@smelc smelc added enhancement New feature or request Technical debt labels Nov 23, 2023
@smelc
Copy link
Contributor Author

smelc commented Nov 23, 2023

cc @mkoura

@gitmachtl
Copy link
Contributor

gitmachtl commented Nov 23, 2023

@smelc @mkoura @Jimbo4350 just to give you also some context about external tools. we heavily use the protocol-parameters.json output to use it for the build-raw command and calculate things and switch tool behavior on protocol version...
For example, during the pool registration certificate generation query the parameters, and than look at the current minPoolCost value to validate that the generated certificate is within the allowed boundaries. Later on when it comes to the pool registration, query the parameters and look at the stakePoolDeposit parameter to calculate the right amount for the build-raw command. Also for example i am using my own minOutUTXO value function i created to be independend from the inbuilt one of the cli. Also looking at values like protocolVersion.major, utxoCostPerByte, minUTxOValue, utxoCostPerWord. When it comes to the stake key registration, looking for the stakeAddressDeposit parameter to calculate the correct amounts for the transaction. PoolRetirement, and so on ...

All these actions must be possible in complete offline mode without a node running, just with the values in the protocol-parameters.json.

So whatever change will be made in the future, please keep such things in mind. CLI tools like Jormanager, CN-Tools, StakepoolOperatorScripts are building transactions via build-raw to do explicit era transaction (often needed for hw-wallet restrictions) and so on. We are not using the "easier" build command for this.

Best regards, Martin

@Jimbo4350
Copy link
Contributor

Jimbo4350 commented Nov 23, 2023

Thanks @gitmachtl. Just to confirm you would like us to maintain cardano-api's existing JSON serialization of ProtocolParameters?

Why are you still interested in utxoCostPerWord? It was deprecated in Babbage.

@gitmachtl
Copy link
Contributor

gitmachtl commented Nov 23, 2023

Thanks @gitmachtl. Just to confirm you would like us to maintain cardano-api's existing JSON serialization of ProtocolParameters?

yes. but it would be good if we could use unified names for the parameters era-independent. just in case parameter names are changing in conway+ era, it would be nice to also backport those name changes starting from shelley. for the tools its not important if a parameter is called poolPledgeInfluence or a0 in the json. but it would be nice if its the same one for all eras. so we change it all one time in the tooling, and no need to always check if a parameter is named that or that way.

Why are you still interested in utxoCostPerWord? It was deprecated in Babbage.

utxoCostPerWord was just an example for pre babbage eras, we don't have it often now, but for the testnets we are going thru all the eras over and over again. i am using utxoCostPerByte starting for protocol major 7+ yes.

Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

@github-actions github-actions bot added the Stale label Dec 24, 2023
@smelc smelc removed the Stale label Jan 2, 2024
Copy link

github-actions bot commented Feb 2, 2024

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

@carbolymer
Copy link
Contributor

This is parked until after Chang hard fork.

@Jimbo4350
Copy link
Contributor

Thanks @gitmachtl. Just to confirm you would like us to maintain cardano-api's existing JSON serialization of ProtocolParameters?

yes. but it would be good if we could use unified names for the parameters era-independent. just in case parameter names are changing in conway+ era, it would be nice to also backport those name changes starting from shelley. for the tools its not important if a parameter is called poolPledgeInfluence or a0 in the json. but it would be nice if its the same one for all eras. so we change it all one time in the tooling, and no need to always check if a parameter is named that or that way.

Why are you still interested in utxoCostPerWord? It was deprecated in Babbage.

utxoCostPerWord was just an example for pre babbage eras, we don't have it often now, but for the testnets we are going thru all the eras over and over again. i am using utxoCostPerByte starting for protocol major 7+ yes.

So the plan is to eventually deprecate the JSON serialization of ProtocolParameters in cardano-api in favour of PParams in cardano-ledger. Probably some time after the Chang hardfork. This should make life easier for everybody as there will be a single JSON serialization for the protocol parameters (in our libraries anyways).

@gitmachtl
Copy link
Contributor

I am quite happy with the latest update tbh, were we have the "normal" and the "governance" parameters both in the protocol-parameters input/output. Just saw, my last post was from Nov2023 😄

Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

@github-actions github-actions bot added the Stale label Aug 23, 2024
@smelc smelc removed the Stale label Aug 23, 2024
Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.

@github-actions github-actions bot added the Stale label Sep 24, 2024
@smelc smelc removed the Stale label Sep 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Technical debt
Projects
None yet
Development

No branches or pull requests

4 participants