Jae's Amino interface/proto3-compat proposal (version 1)

amino_proto3_proposal_1.md

Proposed solution:

• a Go interface is encoded as a top-level Proto3 message. In the example below, the Animal go interface is represented by a Animal proto3 message.

type Animal interface
type Dog struct
type Cat struct
type House struct {
	Pet Animal
}
type Skateboard struct {
	Decal Image
	Rider Animal
}

becomes

message House {
	Animal pet = 1;
}
message Skateboard {
	Image decal = 1;
	Animal rider = 2;
}
message Animal {
	oneof concrete {
		Dog dog = 1;
		Cat cat = 2;
		// New fields can be appended here,
		// but field numbers can never be released
		// for incrementing version numbers
		// (see below).
	}
	// Plus, some sort of meta-information about:
	// - the fact that this represents an Amino interface
	// - the version/revision number, incrementing
	// - the canonical URL identifier for this interface
}

The "fact that [Animal] represents an Amino interface" serves as a hint to code generators or other client libs.

The "canonical URL" allows apps to mirror the interface declaration that is to be defined elsewhere. For example, third party CosmosSDK blockchains (e.g. a DEX chain) may host their own schema declaration for Pubkey which is intended to track/follow changes (e.g. new concrete types registered) of the canonical one defined by the URL "amino://cosmos/PubKey" (say). Initially, we can use convention to come to sync (e.g. only the ICF or Cosmos Hub can publish new revisions for PubKey), but in the future there may be a specialized chain where this URL resolves to dynamically (such as the Cosmos Hub).

I don't think there's a need for Amino structs to have such "canonical URL" defined in the schema, because there is already a STATIC proto3 definition for the canonical URL of a typical proto3 message (even accounting for modifications). But Amino interfaces are arguably a bit different, given that across different blockchain applications (or across clients), the same conceptual interface (e.g. a PubKey) may be at different versions. In other words, a client or application may explicitly only support an older revision than the latest version of the same conceptual interface schema.

For example, if a DEX chain serves an older revision of the "amino://cosmos/PubKey" interface, it means the newer PubKeys are not yet supported on that chain. Perhaps we can let external chains always support the latest revision of an interface (read: new pubkey formats) by specifically referring to the canonical proto3 message URL (i.e. refer to the PubKey message as hosted by the Cosmos Hub, not the one hosted by the DEX chain).

TODO: Does the above really make sense?

(supposed) Rationale:

• Minimal changes to Amino code.
• Complete compatibility with Proto3.
• No Proto3 lib changes necessary for other languages.
• and, very compact.