Cosmos-sdk: bech32: Add a way to change the default prefixes

[sherry13131]

In Cosmos-sdk, all the public keys and addresses are using Bech32 prefix. Is it possible to change it to other prefix by myself for my own project? If yes, what kind of files do I need to override or rewrite, and how? I see the prefix constant is in the cosmos-sdk/types/account.go, which is the file that developers do not need.
Since this is an SDK, I think it should have this feature (change the prefix of keys and address) when developers creating their own project, in view of project design.

[ValarDragon]

Thanks for pointing this out! We currently don't have a way to do this, we should add one though.

[ValarDragon]

I think it should be fine to make these unexported global variables, with getter methods, and a register function. The register function would then have a corresponding "seal" method, a paradigm used in many places. Then we'd expect apps to set these and seal these in their main app.go.

We're essentially then creating a constant, which can be initialized during runtime.

[svaishnavy]

Thanks @ValarDragon for linking me to this. I too feel it would be a very important feature as far as the SDK is concerned. I'll see how to implement this.

Also, two things -

1. Is it possible to extract Public key from Bech32 address?
2. The cosmos validator address, cosmos account address, consensus node address etc.. are they all derived from the same public key or do the users need to maintain separate key pairs for all these types of addresses?

[alexanderbez]

I like the idea @ValarDragon suggested. However, you may still actually use any bech32 prefixing you want, at least in a limited scope. The AccAddress type is just a byte slice alias so you can easily cast it and do any bech32 logic you wish, but again, it'll be limited because we assume our own prefixes.

We should still do something akin to what @ValarDragon suggested.

1. The cosmos validator address, cosmos account address, consensus node address etc.. are they all derived from the same public key or do the users need to maintain separate key pairs for all these types of addresses?

No, they are not all derived from the same public key (if you're referring to the various bech32 prefixes. Users only need to maintain their key pairs for accounts. Validators/consensus operators have their own key pairs.

[svaishnavy]

Thanks @alexanderbez

I was thinking about having the following function in types/address.go
RegisterAddressPrefix

So users would just call:
sdk.RegisterAddressPrefix({accPrefix: , valPrefix: , consPrefix: , pubkeyPrefix: }); at the time of creating the app and we would replace the constant prefix variables currently being used with getters. Let me know if this would be an acceptable approach.

Also, would it make sense to just use the plain hex encoding of address for the time being in our project until this is ready? And then later switch to using the Bech32 addresses?

[yangyanqing]

This issue should be closed. @sherry13131