Thoughts on addresses

[webmaster128]

Some thoughts on the future of addresses in CosmWasm. This prepares a renaming from HumanAddr to just Addr as the primary address type.

What I learned:

1. info.sender -> JSON state becomes much nicer
2. JSON state -> query response becomes much nicer
3. Using CanonicalAddr for storage keys (such as bucket) remains possible
4. Address validation works, but is easier to forget than before

Thinking about HumanAddr in state again: Is it realistic that the human readable address format changes over the lifetime of a chain? Should we avoid the human readable address format in state? How do native modules handle hat?

---

Updates:

• Closes Improved address handling #856

[ethanfrey]

Thinking about HumanAddr in state again: Is it realistic that the human readable address format changes over the lifetime of a chain? Should we avoid the human readable address format in state? How do native modules handle hat?

It has never been done yet. And as they were working on ADR 028, care was taken to not change existing addresses. Furthermore, if a chain forks, the standard way of avoiding replay attacks is to change the chainId on one (or both) side. Since ChainID is included in the SignBytes, this chain alone avoids replay attacks, but allows existing wallets to work on either chain with the same key pair and address

[ethanfrey]

Nice idea. A few comments to give feedback on finishing it

[webmaster128]

I added all the validation features now, but removed the change from CanonicalAddr -> HumanAddr in state as I'm still unsure about the potential profix change.

It has never been done yet. And as they were working on ADR 028, care was taken to not change existing addresses. Furthermore, if a chain forks, the standard way of avoiding replay attacks is to change the chainId on one (or both) side. Since ChainID is included in the SignBytes, this chain alone avoids replay attacks, but allows existing wallets to work on either chain with the same key pair and address

What this preserves is the data part of a bech32 address, not its prefix and encoded representation. Addresses are stored as 20 bytes in a lot of places in the Cosmos SDK.

Wouldn't a chain change chain ID and prefix when they fork, keeping the same keypairs but different addresses?

[ethanfrey]

Wouldn't a chain change chain ID and prefix when they fork, keeping the same keypairs but different addresses?

One might think that would be the desired path. chain id is enough to avoid reply attacks, the bech32 prefix helps with ux confusion.

However, the Cosmos SDK stores addresses as bech32 internally already (example staking), so I think we should just go with the flow and store them as bech32 strings as well.

It will clearly be a major issue to change bech32 prefix and I doubt anyone would undertake it. If they did, migrating contract state should also be a feasible solution - it's not like it is that much harder than migrating everything else. (And unlikely that either happen... like everyone still uses the cosmos hub's bip44 derivation path)

That said, I fully support updating this PR and getting it in as the standard way to use things. Providing Human <-> Canonical is good, but let's have some validate(String) -> HumanAddr method as well and use that in the sample contracts

[webmaster128]

Good. I'll update this PR then and will ping you for a review when done.

[ethanfrey]

First glance looks good. I did not have time to review today, it is high on my list for tomorrow.

Once this is in, do you want to cut a 0.14.0-beta2 so we can try this out in cosmwasm-plus?
The update has already started: CosmWasm/cw-plus#260

[maurolacy]

Particularly for newcomers, I think this new format / API will be simpler / clearer. Thanks for doing this.

[maurolacy]

Here, briefly detailing uses cases would be nice IMO.

[ethanfrey]

Nice stuff.

I left lots of comments (looking closely at everything) and found a few issues with the ibc contracts and one small enhancement request. Otherwise, looks good to me.

[ethanfrey]

Good fixes. Glad to see this.