Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thoughts on addresses #802

Merged
merged 38 commits into from
Apr 7, 2021
Merged

Thoughts on addresses #802

merged 38 commits into from
Apr 7, 2021

Conversation

webmaster128
Copy link
Member

@webmaster128 webmaster128 commented Feb 25, 2021

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:

@webmaster128 webmaster128 marked this pull request as draft February 25, 2021 23:31
@ethanfrey
Copy link
Member

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

Copy link
Member

@ethanfrey ethanfrey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

contracts/hackatom/src/contract.rs Outdated Show resolved Hide resolved
contracts/hackatom/src/contract.rs Show resolved Hide resolved
contracts/hackatom/tests/integration.rs Outdated Show resolved Hide resolved
packages/std/src/traits.rs Outdated Show resolved Hide resolved
@webmaster128
Copy link
Member Author

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
Copy link
Member

ethanfrey commented Mar 30, 2021

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
Copy link
Member Author

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

@webmaster128 webmaster128 force-pushed the primary-address branch 2 times, most recently from acbb132 to c31519a Compare March 30, 2021 21:25
@webmaster128 webmaster128 mentioned this pull request Mar 31, 2021
5 tasks
@webmaster128 webmaster128 force-pushed the primary-address branch 6 times, most recently from 66ad164 to 2a8b36d Compare March 31, 2021 16:51
@ethanfrey
Copy link
Member

ethanfrey commented Apr 6, 2021

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

Copy link
Contributor

@maurolacy maurolacy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

CHANGELOG.md Show resolved Hide resolved
MIGRATING.md Outdated Show resolved Hide resolved
MIGRATING.md Outdated Show resolved Hide resolved
MIGRATING.md Outdated Show resolved Hide resolved
MIGRATING.md Outdated Show resolved Hide resolved
/// assumptions should be made other than being UTF-8 encoded and of reasonable length.
///
/// This type represents a validated address. It can be created in the following ways
/// 1. Use `Addr::unchecked(input)`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here, briefly detailing uses cases would be nice IMO.

packages/std/src/coins.rs Show resolved Hide resolved
packages/std/src/errors/system_error.rs Outdated Show resolved Hide resolved
packages/std/src/mock.rs Show resolved Hide resolved
packages/vm/src/backend.rs Show resolved Hide resolved
Copy link
Member

@ethanfrey ethanfrey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

MIGRATING.md Show resolved Hide resolved
contracts/hackatom/schema/state.json Show resolved Hide resolved
contracts/hackatom/src/contract.rs Show resolved Hide resolved
contracts/hackatom/src/contract.rs Show resolved Hide resolved
contracts/ibc-reflect-send/src/contract.rs Show resolved Hide resolved
packages/std/src/mock.rs Show resolved Hide resolved
packages/std/src/traits.rs Show resolved Hide resolved
packages/std/src/types.rs Show resolved Hide resolved
packages/vm/src/imports.rs Show resolved Hide resolved
contracts/ibc-reflect/src/contract.rs Outdated Show resolved Hide resolved
@webmaster128 webmaster128 added the automerge See mergify.io label Apr 7, 2021
@mergify mergify bot merged commit 0413557 into main Apr 7, 2021
@mergify mergify bot deleted the primary-address branch April 7, 2021 14:46
@ethanfrey
Copy link
Member

Good fixes. Glad to see this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automerge See mergify.io
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Improved address handling
3 participants