wasm/MsgStoreCode incorrect Amino encoding

[noah]

I noticed two issues when trying to Amino encode wasm/MsgStoreCode, one that's indicative of an error that needs to be fixed everywhere, and one that essentially means that autogenerating Amino types from protobuf files is impossible (rip).

MsgStoreCode uses AccessConfig, which has an AccessType enum. The AccessConfig encoding is the source of the issue.

For AccessConfig (in cosmwasm/wasm/v1/types.ts), the amino encoders need to change as follows:

   fromAmino(object: AccessConfigAmino): AccessConfig {
     const message = createBaseAccessConfig();
     if (object.permission !== undefined && object.permission !== null) {
       message.permission = accessTypeFromJSON(object.permission);
     }
     message.addresses = object.addresses?.map(e => e) || [];
     return message;
   },

   toAmino(message: AccessConfig, useInterfaces: boolean = false): AccessConfigAmino {
     const obj: any = {};
-    obj.permission = message.permission;
-    if (message.addresses) {
+    obj.permission = accessTypeToJSON(message.permission);
+    if (message.addresses?.length) {
       obj.addresses = message.addresses.map(e => e);
-    } else {
-      obj.addresses = [];
     }
     return obj;
   },

Notice how:

• toAmino is not using accessTypeToJSON (relevant in the next section)
• message.addresses should only be added to the Amino encoding if it's non-empty. this is because the cosmwasm/wasm/v1/types.proto protobuf has repeated string addresses = 3, and it does NOT have (amino.dont_omitempty) = true. for comparison, MsgSubmitProposal in cosmos/gov/v1/tx.proto has a repeated initial_deposit field WITH (amino.dont_omitempty) = true, meaning that it should include an empty array ([]) if there is no deposit included. i believe this holds true everywhere—if a repeated field does NOT have (amino.dont_omitempty) = true, it should only be included in toAmino if it has at least one element.

I believe this omit repeated issue shows up everywhere and can be fixed easily.

Amino types cannot be generated from protobufs alone

Additionally, the accessTypeToJSON and accessTypeFromJSON helper functions themselves are incorrect. The correct functions are:

 export function accessTypeFromJSON(object: any): AccessType {
   switch (object) {
     case 0:
-    case "ACCESS_TYPE_UNSPECIFIED":
+    case "Unspecified":
       return AccessType.ACCESS_TYPE_UNSPECIFIED;
     case 1:
-    case "ACCESS_TYPE_NOBODY":
+    case "Nobody":
       return AccessType.ACCESS_TYPE_NOBODY;
     case 3:
-    case "ACCESS_TYPE_EVERYBODY":
+    case "Everybody":
       return AccessType.ACCESS_TYPE_EVERYBODY;
     case 4:
-    case "ACCESS_TYPE_ANY_OF_ADDRESSES":
+    case "AnyOfAddresses":
       return AccessType.ACCESS_TYPE_ANY_OF_ADDRESSES;
     case -1:
     case "UNRECOGNIZED":
     default:
       return AccessType.UNRECOGNIZED;
   }
 }

 export function accessTypeToJSON(object: AccessType): string {
   switch (object) {
     case AccessType.ACCESS_TYPE_UNSPECIFIED:
-      return "ACCESS_TYPE_UNSPECIFIED";
+      return "Unspecified";
     case AccessType.ACCESS_TYPE_NOBODY:
-      return "ACCESS_TYPE_NOBODY";
+      return "Nobody";
     case AccessType.ACCESS_TYPE_EVERYBODY:
-      return "ACCESS_TYPE_EVERYBODY";
+      return "Everybody";
     case AccessType.ACCESS_TYPE_ANY_OF_ADDRESSES:
-      return "ACCESS_TYPE_ANY_OF_ADDRESSES";
+      return "AnyOfAddresses";
     case AccessType.UNRECOGNIZED:
     default:
       return "UNRECOGNIZED";
   }
 }

This one is tricky because the real strings for enums are not stored in the protobuf files, instead living in the Go code directly. This is found in x/wasm/types/params.go:

func (a AccessType) String() string {
	switch a {
	case AccessTypeNobody:
		return "Nobody"
	case AccessTypeEverybody:
		return "Everybody"
	case AccessTypeAnyOfAddresses:
		return "AnyOfAddresses"
	}
	return "Unspecified"
}

And digging deeper, we find this other enum string encoding for VoteOption in x/gov/types/v1/gov.pb.go:

func (x VoteOption) String() string {
	return proto.EnumName(VoteOption_name, int32(x))
}

...which corresponds to the correct encoders for MsgVote in the gov module, which uses the uppercase enum names.

This reveals that Cosmos SDK modules have no standard for how enums are encoded, and it's up to the module author to decide how to encode an enum. Thus any attempt to autogenerate Amino encoders from protobuf files will fail, and instead it needs to actually parse and construct these types from Go code.

[Dan Lynch]

#625 #624