Cosmos Scalars

[amaury1093]

Summary

Introduce the notion of cosmos scalars.

Part of #7091.

Problem Definition

We decided to use strings to represent addresses in proto definitions. A string can mean anything, and it sometimes be hard to guess that the string actually represents an address.

This issue introduces the notion of a Cosmos "Scalar" type (similar to the notion of Scalar type in GraphQL), which would just be simple aliases that give human-understable meaning to the underlying type, both in Go code and in Proto definitions.

How it looks like

Introduce the following Cosmos scalar types (naming to be confirmed):

• cosmos.AddressString: the string representation of an address.
• cosmos.AddressBytes: address as bytes,
• cosmos.Int: integers
• cosmos.Dec: decimals

Other scalars can be introduced in the future.

Usage in Protobuf

message MyMsgSend {
  // annotations either using string
  string sender = 1 [(cosmos_proto.scalar) = "cosmos.AddressString"]; // so that clients know that `sender` holds the string repr of an address
  // or using enum
  bytes  rcpt = 2   [(cosmos_proto.scalar) = cosmos_proto.ADDRESS_BYTES];
}

Usage in Go Code

The above code would generate in Go (with cosmos-proto):

// somewhere in the SDK
type AddressString string
type AddressBytes bytes

// in the .pb.go file
type MyMsgSend struct {
  Sender sdk.AddressString
  Rcpt sdk.AddressBytes
}

Proposal

Go through all the proto files, and add annotations to all relevant fields.

Types we need add annotation for:

• AddressString
• AddressBytes
• Int
• Dec

Open questions:

• Names to be confirmed
• cosmos_proto.scalar = : string or enum (do we want people to extend scalars)?

cc @aaronc @cyberbono3

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alexanderbez]

ACK 👍

[fdymylja]

I'm not a fan of changing internal structure of protobuf objects as it's done by gogoproto "customtype", it means that every protobuf generator used needs to be aware of those definitions and how they change structures internally.

First pain-point it's gonna be in ORM codegen, which will need to also understand to cast the type too for example when someone is wishing to index every balance by address which should be a protobuf string but needs to be casted to the custom type.

I think it would be fine to mark how certain types should be decoded, but I wouldn't go as far as mangling with protobuf object structures, for the sake of more mantainable and losely coupled code-bases.

I'm bringing this up because I'm currently working on the ORM codegen and I'm constantly hitting walls due to gogoproto, incompatibility with the protobuf plugin, and the need to be aware of gogoproto options to parse objects and generate clients in the correct way.

[aaronc]

So the idea with the new codegen would be to properly implement protoreflect.Message so that other tools can use that rather than reflect over golang fields like you'd need to do with gogo. That is the correct way to do things with v2 afaik so it shouldn't matter what happens with the go fields as long as protoreflect works.

Also I'd like to coordinate the ORM codegen work with the codegen work we're doing, but still if protoreflect is correct it shouldn't matter.

[fdymylja]

Also I'd like to coordinate the ORM codegen work with the codegen work we're doing, but still if protoreflect is correct it shouldn't matter.

Absolutely. The problem we'd hit, for example, would be in Client generator, in which you'd need to check for scalar/customtype option and modify the arguments of the client functions, alongside protoreflect.Value for secondary key value to []byte encoding. I'll sync here #9156 with the API I have come up with (maybe it's a non-issue).

[amaury1093]

We need to decide in which repo to put these annotations (e.g. in cosmos-proto or here)?

related cosmos/cosmos-proto#4