Report live value of decentralization parameter d.

[jonathanknowles]

Issue Number

#1693

Overview

This PR:

• Introduces the DecentralizationLevel type (based on the Percentage type).

  Greater values indicate greater levels of decentralization, as follows:

  Value	Meaning
  0%	Network is completely federalized
  100%	Network is completely decentralized

• Adjusts the wallet API server to convert from values of type DecentralizationLevel to values of type Quantity "percent" Percentage.

• Adjusts the wallet layer to store a value of type ProtocolParameters instead of TxParameters. (Note that ProtocolParameters includes TxParameters.)

• Adjusts the network layer to provide a getProtocolParameters function instead of getTxParameters.

• Adjusts the database layer to use a protocol_parameters table instead of a tx_parameters table. (Note that protocol_parameters is a superset of tx_parameters.)

• Adjusts the chain-following code to extract the live value of d, in the same way as we already do for transaction-related protocol parameters.

• Adds a conversion function to convert from d parameter values to values of type DecentralizationLevel.

  This function performs the following mapping:

  {1 → 0%, 0.9 → 10%, 0.8 → 20%, ..., 0 → 100%}
  

Comments

Starting a wallet with this PR applied will result in the creation of a new protocol_parameters table, if one does not already exist. (We rely on the automatic migration mechanism to create the table, and the network layer to add rows to the table.)

The redundant tx_parameters table, if it exists, will be ignored, but not deleted.

In a future PR, we can add a manual migration step that removes the tx_parameters table.

See Issue #1727.

[rvl]

Looks good so far

[rvl]

Write a manual DB upgrade step to cope with the changed schema.

Rather than doing this migration step, you could change readWalletProtocolParameters to use the genesis block as a fallback if the data is missing. That might be easier.

[jonathanknowles]

Rather than doing this migration step, you could change readWalletProtocolParameters to use the genesis block as a fallback if the data is missing. That might be easier.

After a discussion with @rvl, we decided to leave readWalletProtocolParameters unchanged.

Justification:

1. If a user starts with an old version of the wallet DB (one with a tx_parameters table instead of a protocol_parameters table), then the automatic migration mechanism will kick in and create an empty protocol_parameters table.
2. Once the network layer has started, it will populate the empty protocol_parameters with a row for the wallet.
3. The readWalletProtocolParameters function is only ever called by the selectCoinsSetup function.
4. This means that immediately after a migration from an older database without a protocol_parameters table, attempting to create a coin selection will fail if the network layer has not yet started, because we rely on the network layer to populate the protocol_parameters table.
5. However, in normal startup situations without a migration, if the protocol_parameters table already exists and is already populated, then creating a coin selection will succeed even if the network layer has not yet started.

So the corner case here is: attempting to create a coin selection immediately after a migration, but before the network layer has started. In this corner case, creating a coin selection will fail.

On the assumption that this corner case is relatively rare and easy to work around (by waiting for the network layer to start), we've decided to leave the readWalletProtocolParameters function unchanged, for the moment.

[rvl]

Great! 👍

[jonathanknowles]

bors r+

[iohk-bors]

Build succeeded

• ci/hydra-eval
• buildkite/cardano-wallet
• ci/hydra-build:required