Migrate Keyring to Protobuf

[aaronc]

This got missed in the migration. I don't consider it a blocker for Stargate so marking this for 0.40.1. Does that sound okay @alexanderbez ?

It would be good if we can do this in a backwards compatible way. i.e. if a keyring is in amino format, it gets read as amino but reserialized to proto after that. We should either make a backup when doing this, or even better just use different files for proto keys and keep the amino ones untouched.

[alexanderbez]

Yes, that's fine. In fact, I think I have a comment in a thread somewhere that alludes to this very idea -- use Amino for legacy key material and use Proto for new key material while also having a built-in and opt-in command to migrate anything that is legacy so we can ultimately phase out Amino entirely from the Keyring logic.

[alessio]

IMHO keys material does not necessarily have to be encoded with proto. The keyring is a Cosmos SDK pure Go tool and is not meant to be used in conjunction with messages over the wire (e.g. private keys don't travel over the wire). I think the objective of this issue should be stop using amino for keyring's keys material.

[amaury1093]

Could you explain a little bit more @alessio?

From what I understand, if we stop using amino for keyring's keys material, then we will use protobuf for serialization between the keyring and the keyring-backend, which is the objective of this issue.

[alessio]

protobuf for serialization between the keyring and the keyring-backend, that's generally ok - as long as client developers don't need to write proto files specific to the keys the use.

Keyring just handle bytes-to-disk serialization of a few internal structures (see *info types in crypto/keyring). For that, gob should suffice?

[amaury1093]

I'm not familiar with gob, how does gob encode interfaces? Say I want to serialize localInfo:

cosmos-sdk/crypto/keyring/info.go

Lines 38 to 43 in 54201d1

	type localInfo struct {
	Name string `json:"name"`
	PubKey cryptotypes.PubKey `json:"pubkey"`
	PrivKeyArmor string `json:"privkey.armor"`
	Algo hd.PubKeyType `json:"algo"`
	}

How will the PubKey field (an interface) be encoded? Proto uses Any, amino also has its own mechanism.

[fedekunze]

We are seeing another issue on Ethermin due to the fact that the SDK uses keyring.CryptoCdc and legacy.Cdc.Amino inconsistently, see v0.40.0-rc3...chengwenxi:vincent-v0.40.0-rc3

[amaury1093]

This is not closed by #7987

[robert-zaremba]

Scope

Create a migration for keyring keys:

• don't use legacy codec
• remove crypto/keyring.multiInfo.PubKeys field

[robert-zaremba]

Problem

Currently, all user keys in keyring are serialized using Amino. This blocks adding new key types to keyring unless we implement Amino codec interface to that types.

[outdated] Proposed Migration Algorithm

See #7108 (comment) below for the algorithm we picked.

Add keyring migration for user keys:

1. Add migration to the constructor
2. In the constructor check if keyring migration was already done (see below how we do it)
3. If done, return new kerying
4. If not, go through all keyring records and migrate from Amino to Protobuf
5. Save an extra record to the keyring: {Key: "migration", Data: versionNumber}, where version number for this migration is 1.
6. Return keyring.

All keyring functions must use protobuf for serialization.

Ref: discussion on Discord

[robert-zaremba]

Algorithm v2

The logic we are implementing is:

1. Add migration to the constructor
2. When constructing the keyring, check a version (using a special "keyring-cosmos-version" key), if the key doesn't exist then migrate:
   1. Iterate through all keys
   2. try proto deserialization
   3. if it fails -> migrate the from amino to proto
   4. if it stil fails -> return warning, and continue with other keys.
   5. set a version to 1.
3. A user access a key
   • Try proto deserialization
   • if it fails - try amino and and migrate the single key.

Using a version will allow us to do future migrations if needed.