[Tooling][Utility] CLI - Querying governance params

[Olshansk]

Objective

Improve the ability to access on-chain params while improving how they are maintained.

Origin Document

V0 Parametesr

The utility specification mentions a non-exhaustive list of on-chain parameters that will be used in V1.

The V0 RPC spec can be found here, allowing to query the v0 params like so:

curl --location -X 'POST' -H 'Content-Type: application/json' 'https://<user>:<pass>@<hostname>:<port>/v1/query/allParams' | jq

{
  "app_params": [
    {
      "param_key": "application/StabilityAdjustment",
      "param_value": "0"
    },
    {
      "param_key": "application/ParticipationRateOn",
      "param_value": "false"
    },
    {
      "param_key": "application/ApplicationStakeMinimum",
      "param_value": "1000000"
    },
    {
      "param_key": "application/BaseRelaysPerPOKT",
      "param_value": "200000"
    },
    {
      "param_key": "application/AppUnstakingTime",
      "param_value": "1814000000000000"
    },
    {
      "param_key": "application/MaxApplications",
      "param_value": "2295"
    },
    {
      "param_key": "application/MaximumChains",
      "param_value": "15"
    }
  ],
  "auth_params": [
    {
      "param_key": "auth/FeeMultipliers",
      "param_value": "{\"fee_multiplier\":null,\"default\":\"1\"}"
    },
    {
      "param_key": "auth/MaxMemoCharacters",
      "param_value": "75"
    },
    {
      "param_key": "auth/TxSigLimit",
      "param_value": "8"
    }
  ],
  "gov_params": [
    {
    ...

V1 Paramters

The code to list and maintain governance parameters is spread throughout the codebase. A good starting point would be to look at all *gov* files:

For example, gov_test.go or gov.go

Goals

• Enable querying localnet params via the CLI
• Reduce the code footprint of governance parameters. This has two underlying goles:
  • Easier to read & maintain code
  • Less context that will allow using this library with ChatGPT (more code -> more tokens -> less context)

Deliverable

• A PR that reduces the code footprint of everything related to maintaining governance paramsSelect and document build tags used to include/exclude actor-specific business logic
• Add a /v1/query/nodeParams to the v1 RPC spec.
• A make target that helps querying these params on localnet

Non-goals / Non-deliverables

• Adding/removing any existing parameters in the codebase

General issue deliverables

• Update the appropriate CHANGELOG(s)
• Update any relevant local/global README(s)
• Update relevant source code tree explanations
• Add or update any relevant or supporting mermaid diagrams

Testing Methodology

• Required: A make target that queries the on-chain parameters of localnet
• All tests: make test_all
• LocalNet: verify a LocalNet is still functioning correctly by following the instructions at docs/development/README.md

---

Creator: @Olshansk
Co-Owners: @jessicadaugherty

[h5law]

@Olshansk

Reduce the code footprint of governance parameters. This has two underlying goles:
- Easier to read & maintain code
- Less context that will allow using this library with ChatGPT (more code -> more tokens -> less context)

This is a little unclear to me, in this PR do something like this. I am unsure of the actual scope of this task.

[Olshansk]

@h5law That one was definitely a good start, but didn't result in much of a code footprint reduction in the grand scheme of things:

What I'm wondering is if we can remove redundancy throughout the entire codebase where we have lots of seemingly duplicate functions or unnecessarily long switch-case statements. gov.go and gov_test.go are two starting points but more exist throughout the codebase:

Off the top of my head (don't read into this code snippet), what if we had something along the lines of:

type GovParamConfig struct  {
    type string
	accessor func
}

var govParams map[string]GovParamConfig

func init() {
	govParams = map[string]GovParamConfig {
		"Param1": &GovParamConfig{...},
		"Param2": &GovParamConfig{...},
		"Param3": &GovParamConfig{...},
    }
}

Then we could just loop over the keys to get all the params, and have a single test that uses the accessors. I have a gut feeling there are few such opportunities but haven't put deep thought into it yet.

[h5law]

@Olshansk

Then we could just loop over the keys to get all the params, and have a single test that uses the accessors. I have a gut feeling there are few such opportunities but haven't put deep thought into it yet.

Okokok I see you this seems like a better way to do it. I will turn the current PR into a WIP and finish it off by adding this reduction in.

[h5law]

@Olshansk

So the issue I am coming across with your idea of the map with accessors in the structs is the use of generics - we will run into errors around using generics. One way I thought to go about it was to include the access function within the struct, but this causes issues with the different accessor functions having different signatures u.getBigIntParam vs u.getIntParam and without generalising these (which I don't think we should) we can generalise so I went with something like below:

func init() {
	GovParams = generateParamConfigs()
}

var (
	GovParams map[string]any
)

type govParamConfig[T any] struct {
	MetaData     utils.GovParamMetadata
	AccessorType T
}

func generateParamConfigs() map[string]any {
	metadataMap := utils.GovParamMetadataMap
	return map[string]any{
		typesUtil.AppMinimumStakeParamName: &govParamConfig[*big.Int]{
			MetaData:     metadataMap[typesUtil.AppMinimumStakeParamName],
			AccessorType: big.NewInt(int64(0)),
		},
		...
	}
}

func (u *baseUtilityUnitOfWork) getParam(paramName string) (any, typesUtil.Error) {
	paramConfig := GovParams[paramName].(govParamConfig[any])
	switch paramConfig.AccessorType.(type) {
	case *big.Int:
		return u.getBigIntParam(paramName)
	case int:
		return u.getIntParam(paramName)
	case int64:
		return u.getInt64Param(paramName)
	case []byte:
		return u.getByteArrayParam(paramName)
	case string:
		return u.getStringParam(paramName)
	default:
		return nil, typesUtil.ErrUnknownParam(paramName)
	}
}

However this is not very good as the AccessorType is always any as this is how I have to initialise it but this makes the whole thing fall apart as trying to generalise these things is causing problems. So I decided to scrap this approach until I can think of a better solution to this problem.

PS PR #622 Looking good with the cleanup of parameter owner logic so far