Deprecate cardano-api's ProtocolParameters

[smelc]

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]

cc @mkoura

[gitmachtl]

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

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]

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.

[github-actions]

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]

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]

This is parked until after Chang hard fork.

[Jimbo4350]

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]

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 😄

[github-actions]

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]

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]

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]

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]

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]

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.