Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

question about generated code for amino encoding #4

Open
pyramation opened this issue Jun 8, 2022 · 2 comments
Open

question about generated code for amino encoding #4

pyramation opened this issue Jun 8, 2022 · 2 comments

Comments

@pyramation
Copy link

Hello! I'm working on a transpiler that can hopefully help us solve amino encoding once and for all. In order to do that, I need to understand a bit better how the proto maps between what the developer writes, and the output options.

It seems that some of the options that get generated here are not always inside of the proto files, but are inside of the generated go files. My thought is, if I can understand what this library is doing to create these options, I'll be able to automate any creation of all amino converters that use this library (likely most cosmos chains)

example

In this case, I've changed start_time to startTime

original

message EpochInfo {
  string identifier = 1;
  google.protobuf.Timestamp start_time = 2 [
    (gogoproto.stdtime) = true,
    (gogoproto.nullable) = false,
    (gogoproto.moretags) = "yaml:\"start_time\""
  ];
  google.protobuf.Duration duration = 3 [
    (gogoproto.nullable) = false,
    (gogoproto.stdduration) = true,
    (gogoproto.jsontag) = "duration,omitempty",
    (gogoproto.moretags) = "yaml:\"duration\""
  ];
  int64 current_epoch = 4;
  google.protobuf.Timestamp current_epoch_start_time = 5 [
    (gogoproto.stdtime) = true,
    (gogoproto.nullable) = false,
    (gogoproto.moretags) = "yaml:\"current_epoch_start_time\""
  ];
  bool epoch_counting_started = 6;
  reserved 7;
  int64 current_epoch_start_height = 8;
}
-  google.protobuf.Timestamp start_time = 2 [
+  google.protobuf.Timestamp startTime = 2 [

in osmosis is where I'm testing, and I run make proto-all, which results in a change to the file x/epochs/types/genesis.pb.go

-	StartTime               time.Time     `protobuf:"bytes,2,opt,name=start_time,json=startTime,proto3,stdtime" json:"start_time" yaml:"start_time"`
+	StartTime               time.Time     `protobuf:"bytes,2,opt,name=startTime,proto3,stdtime" json:"startTime" yaml:"start_time"`

As you can see, it seems that we could derive now the information for how to do the amino<>proto conversion. It seems that the json property is the amino style, and the yaml is the proto — however, this information is not in the .proto file, but instead only in the .pg.go file.

Can somebody point to the algorithm/calculation in this codebase for where this is done? This information would greatly help the ability to generate amino converters.

@blushi
Copy link
Member

blushi commented Jun 9, 2022

The thing is that using camelCase breaks proto convention for naming field names https://developers.google.com/protocol-buffers/docs/style
Amino JSON encoding would rather be snake case which is already in the json struct tag.
Also you still need to get the amino type name anyway.

Also please note that we're actually in the process of migrating to use https://github.com/cosmos/cosmos-proto and that there will be some work related to amino support as part of that: cosmos/cosmos-sdk#10993
Also see: cosmos/cosmos-sdk#7488 and cosmos/cosmos-sdk#9705

cc/ @aaronc

@pyramation
Copy link
Author

thanks @blushi t's amazing that you've organized all these issues. I'll dig more into these!

For camelCase, I agree and we're also moving towards using snake case, however some chains including Osmosis currently use it in their proto definitions and I'm just trying to support existing definitions. I'm curious how/if the new migration would change the amino converters on the JS side of things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants