- Docs
- Smart Contracts
- Names and addresses
Names and addresses in CosmWasm
In blockchain systems, addresses are used to identify external actors, typically represented as a hash of a public key. These on-chain addresses are stored in a concise, immutable binary format, often 20 or 32 bytes long, and derived from a cryptographic hashing function. However, these binary addresses can be converted into various human-readable formats for easier interaction with clients.
Address formats
Different blockchains use different formats for representing addresses. Here are examples of two commonly used formats:
- Bech32: A human-readable format used in Bitcoin and some Cosmos SDK-based chains.
- Example:
bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9
- Example:
- Checksummed Hex (EIP-55): A format used in Ethereum to prevent errors in address representation.
- Example:
0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed
- Example:
Address representation in CosmWasm
Addr
In the Cosmos SDK, addresses are typically 20-character long strings with built-in security features, such as a chain prefix in Bech32, checksums in Bech32, and checksummed hex formats (EIP-55). Since CosmWasm is an extension of the Cosmos SDK, it adheres to the same address rules. Each entity, whether it's a wallet, smart contract, or module, has a unique address with a specific prefix. For example, the "archway1..." prefix is used for Archway addresses, while "wasm1..." is used for certain CosmWasm-enabled chains.
In CosmWasm, when providing an address to a smart contract, you can submit it as a string. The string is then validated and wrapped in an Addr type, which serves as a utility wrapper for addresses. The Addr type ensures that the address follows the correct format and includes methods for validation.
Canonical addresses
A Canonical Address is the binary representation of an address used internally within the blockchain. While addresses are typically represented as human-readable strings for client interactions, canonical addresses are used for internal storage lookups. This internal representation can be converted back and forth between the canonical format and the human-readable string format.
Understanding Canonical Addresses is crucial for blockchain operations. For example, in Bitcoin's transition from Base58 to Bech32 encoding (along with SegWit), once the encoding changed, the message signer might lose access to their own account if the canonical format was not preserved. In CosmWasm, Canonical Addresses provide a stable identifier that remains consistent, even as encoding methods evolve.
Naming in CosmWasm
Names in CosmWasm can be considered a form of address, although they require a contract query with storage access to resolve. Unlike addresses, names cannot be resolved by merely calling a pure function. Instead, they rely on contract state to determine the associated address. This approach allows for more dynamic and flexible addressing, where the resolution of a name to an address can change over time based on the contract's state.
Practical example
For instance, you could have a naming service contract where users register names that resolve to their wallet addresses. The contract stores these mappings, and whenever someone queries a name, the contract returns the associated address. This is similar to how DNS (Domain Name System) works on the internet, translating domain names to IP addresses.