Add parameter to track credit types and associated precision

[ruhatch]

As part of integration with x/bank, we decided to have a single consistent precision for each type of credit, rather than being able to set precision per credit class. This issue should:

• Add a governance parameter to x/ecocredit containing a map of credit types and precisions
• Remove the ability to set precision on a per-class basis
• Add credit type as a field on credit class
• Enforce precisions of vaules based on the governance parameter
• Ensure that precision cannot be updated via governance (at least until bank has support for decimals)

[ruhatch]

@aaronc how does this interact with #398?

Perhaps we have the parameter as a single map of type map[string]Unit, with:

type Unit struct {
        name      string
        precision uint32
}

e.g.

{
        "carbon": Unit {
                name:      "kg",
                precision: 6,
        },
        "biodiversity": Unit {
                name:      "hectares",
                precision: 3,
        },
}

[aaronc]

This can replace #398

[technicallyty]

was the intention to use the proto map type? might be an issue: the safety of using protobuf maps isn't quite well defined yet see: cosmos/cosmos-sdk#9073 (comment)

perhaps we do something like this using repeated:

// Params defines the updatable global parameters of the ecocredit module for
// use with the x/params module.
message Params {
  // -- snip -- //

  // credit_types is a list of definitions for credit types
  repeated CreditType credit_types = 2;
}

message CreditType {
    string typeOf = 1;
    string unit = 2;
    uint32 precision = 3;
}

[aaronc]

Let's use repeated 👍

[technicallyty]

should we just rip out all set precision from the proto files and stuff? or is there a smoother way to depreciate it?

[ruhatch]

should we just rip out all set precision from the proto files and stuff? or is there a smoother way to depreciate it?

I think just rip it out! This isn't currently deployed, so we're changing the design to just have precision at the credit type level.

[aaronc]

I would even goes as far as to say we might allow 6 as the only valid value for precision and then consider whether we loosen that in the future. What do you think @ruhatch?

[technicallyty]

I would even goes as far as to say we might allow 6 as the only valid value for precision and then consider whether we loosen that in the future. What do you think @ruhatch?

related q: how do we enforce credit types as a gov param while simultaneously not allowing the precision to change? the validation function is stateless so i can't grab the existing params and check for changes.. so is just enforcing a hard 6 the solution for now?

[aaronc]

I would even goes as far as to say we might allow 6 as the only valid value for precision and then consider whether we loosen that in the future. What do you think @ruhatch?

related q: how do we enforce credit types as a gov param while simultaneously not allowing the precision to change? the validation function is stateless so i can't grab the existing params and check for changes.. so is just enforcing a hard 6 the solution for now?

I think so. x/params is sort of broken anyway, we should have rewriting it as something in our roadmap (cosmos/cosmos-sdk#6983). An alternative would be just setting parameters directly in x/ecocredit without x/params when cosmos/cosmos-sdk#9438 is ready. But for now, I think hard-coded 6 is probably the solution.

[ruhatch]

I would even goes as far as to say we might allow 6 as the only valid value for precision and then consider whether we loosen that in the future. What do you think @ruhatch?

related q: how do we enforce credit types as a gov param while simultaneously not allowing the precision to change? the validation function is stateless so i can't grab the existing params and check for changes.. so is just enforcing a hard 6 the solution for now?

I think so. x/params is sort of broken anyway, we should have rewriting it as something in our roadmap (cosmos/cosmos-sdk#6983). An alternative would be just setting parameters directly in x/ecocredit without x/params when cosmos/cosmos-sdk#9438 is ready. But for now, I think hard-coded 6 is probably the solution.

Does that param issue mean that we can't validate param changes?

In that case I guess hardcoding seems like the best option for now and we can migrate it to a gov param once we can do validation and gov/group/param stuff is all a bit more stable?